FTFY

To the best of my knowledge, no one has won multiple Nobels in a single field.

Okay, after checking that statement, it is not true. Frederick Sanger has won two Nobel prizes in Chemistry. He won it alone, in 1958, "for his work on the structure of proteins, especially that of insulin", and again in 1980, with Walter Gilbert, "for their contributions concerning the determination of base sequences in nucleic acids" (source).

It seems to me that the Nobel committee does not like to award the same prize twice. I think, had Frederick done the nucleic research on his own, he would not have won the second one. I think the committee only awarded him the second prize because not doing so would have denied Walter Gilbert the prize (and awarding only Walter a prize for joint work would be strange).

In that respect, Einstein got only one Nobel because he did his research alone.

Shachar

The action against Microsoft was based on anti-competitive acts, founded on the assumption (validated by the court) that Microsoft is a monopoly.

This action is based on strict copyright. Oracle is not alleging that Google are trying to harm Java, just that they didn't have the right to do what they did.

Shachar

Upon re-reading, I realize that parent might be joking. Still, it is important to note that Unicomp do, in fact, cater for the Model-M fanatics too.

Shachar

Did you buy the full size or what they call the "space saver"?

I am typing this on the space saver, and I can, indeed, flex it (if I try hard enough) by a few millimeters. For me, the reduced weight is a plus, though.

If you consider that a minus, you should go with the "Classic" version. I doubt you'll see any difference, USB and extra keys aside.

Shachar

Smart pointers in C++ are rarely larger in size than normal pointers.

std::unique_ptr has the same sizeof of void *. std::shared_ptr has the same sizeof as void *, but adds another allocation. Then again, boost::intrusive_ptr has the same sizeof as void *, does reference counting, does not require virtual functions in the destination class and carries no extra allocations (but does require that the class being indexed be aware it has references).

Shachar

Yeah, Linus mentioned those too. Where does C++ do hidden heap allocations?

The only example I can think of is when throwing an exception (and see below about that), and even then, the compiler rarely actually performs a heap allocation. Small exception classes are stored in a pre-allocated static buffer.

And if you are talking about library use, then you need to realize two things:
1. STL is the most allocation aware library I have ever seen. With a few C++11 related exceptions, it will always allow you to pick an allocator, and will always avoid allocation where one can be avoided.
2. If you think even that level of care is not enough, then you are free to not use STL. Assuming you are correct, your options are "Don't use STL, implement your own implementation in C++" or "Don't use STL, implement your own in C", and I fail to see how option 2 is preferrable to option 1.

As for the other two, RTTI cost you a few extra bytes per defined class (not instance). You are free to tell your compiler not to generate those if you don't use it (for user space, I rarely bother).

Exceptions are a different story. They get a very bad rap, and it's only partially justified. There are two reasons to not like exceptions for kernel code. The first is that exception use is a fundemental design decision. It is not something that can be slapped on to existing code. To do it properly, you must also have RAII and a good structuring of your code. Since those two are a good idea regardless, most good C++ programmers don't mind, but it's hard to migrate existing code to use it properly.

The other reason exceptions are not liked is because of a design decision made by the C++ committee that exceptions have no runtime cost when an exception is not thrown. This leads to the compiler generating the same code twice, and to a very complicated stack unwind code. I don't think either of these will prevent exceptions from working in the kernel (given the proper adaptations), but I do understand how these cause people to be weary of them.

I do agree with Linus about one thing. C++ is a language that is too complex. This leads to good C++ programmers being a minority among C++ programmers.

Shachar

I will help you out. I'm sure it's going to be a huge improvement over Windows 8.

Shachar

Just to add pedanticity (pedanticness?) to the discussion....

You forgot Windows 95 OSR2 and Windows 98SE, both technically OS versions of their own.

Shachar

Menus on the Amiga were bound to the screen, not the window. You are probably remembering a full-window.

Shachar

You can keep your ancient 1.3 books. I have the shining new 2.04 manuals in one of my unpacked boxes here (or maybe it is in storage, next to my actual Amiga?)

Shachar

The original Amiga 500, including the early Kickstart 1.3 ones, would actually completely turn off the LED. If you don't believe me, you are welcome to visit me. I still have my original machine in (more or less) working order.

You are correct that later models would not turn it off completely, but rather only dim it. I only remembered that fact after I hit Send, and thought no one will be anal enough to demand a clarification.

In other words, the hardware does not support it.

That is one point I am not as sure about. It goes against what I remember, but I might be wrong on that point. However:

Do provide links. Please. I failed to find them, and my black 2.04 books are buried in some box from my latest moving day (if I had not thrown them out).

Shachar

You misremember. The Copper code to change display modes took several scan-lines to run. Having a window with different display mode was impossible. You could, and did, have a UI construct called a "screen", which had its own display mode. You could drag a screen down and see another screen behind it.

AFAIK, none of those utilized SKIP. They were all based on WAIT and MOVE. If you know differently, please provide further details.

I don't think so. I am, however, fairly sure you mis-remember.

Shachar

You got a partial answer. If "SKIP" was ever used, I'm interested to know by whom. I only know of a single example, which was EXTREMELY special case.

The commands:
MOVE: move immediate value into copper register. These included such actions as where in memory the video memory was (i.e. - where to fetch the picture from), what is the palette, video resolution, where on screen the video fetch starts and where it ends and many others.
WAIT: wait for the screen update to reach a certain point. There was a mask argument which allowed you to have don't cares on some of the bits.

These two was how most of the programs worked. From simply displaying a static image (the memory fetch registers had to be reset each frame), through "copper waves" (things like telling the hardware to start displaying the image in a different timing each line, so that a straight in memory was a wave on screen), to what matfud erroneously called "display HAM in a window" (it took several scan lines for the copper to completely replace the display mode, so you couldn't display two modes side by side, but you could display them one above the other). It also allowed "virtual sprites" by reusing the same 8 hardware display sprites for different things in the same frame, so long as they were not in the same line.

The third command, skip, had the same arguments as WAIT. Instead of waiting, however, it skipped the next command if the condition was not met. Add to that copper registers that restarted the copper program if written to, and the fact you could load two start addresses and switch between them, and you get the ability to perform a loop.

Back in 1994 there was a Mac "emulator" called A-Max. It was not really an emulator. It loaded Mac ROMs into the ram, patch some hardware related entry points so that it would work on the Amiga, load a copper instruction that caused the Amiga display to act like a Mac black & white display, and simply executed the ROMs. As a result, a 7.2Mhz Amiga 500 ran programs written for the 8Mhz Mac at 120% speed.

One (rather minor) problem they had was that while the display content was showing correct colors, the Amiga was hard-coded to use color 0 for the overscan. As a result, the overscan, black on the Mac, was white on A-Max. Around 1993 I figured a way to resolve this, using the SKIP command and the loop method mentioned above. I assumed that if I figured it, it was obvious, and didn't do anything with it. Around a year or two later, A-Max released a version which had text similar to the following:
Thank you (don't remember the name) for providing us with a method to give a black overscan without writing a huge copper program. As thanks, we've given him a free version of A-Max.

Which caused me to kick myself no ends, and never assume my ideas aren't innovative.

As far as I know, there was no other use for the skip command (which might explain why the A-Max guys never thought about it themselves).

Shachar

And then Commodore went on to (half inherit, half design) the Amiga. Maybe "cobbled together" is too harsh for it, but still. Floppy controller that can decide, per track, whether to work in MFM or RLL (but not read a single sector, mind you), more DMA channels than the CPU can handle, and a display processor with a built-in three commands machine language (one of which was only ever used by one application ever) to change display resolution mid-monitor.

I loved it, but the Amiga gave the impression that it was designed by engineers that couldn't make up their mind on what choice to make, so they created hardware that would offload all decisions to software.

One last anecdote. Many have heard of the famous "Guru meditation". What only Amiga users know is that you knew one was coming because the power led would blink three times. Yes, the power led was software controlled, making the Amiga the first ever computer that could play dead.

Shachar