Nitpicking a couple of your examples. Example 1: "...will not just be a simple shift...". No, it will be an *arithmetic* shift, where the topmost bit is preserved and replicated into the second-to-topmost bit. Something even the 6502 had. Example 2: "'divide by 10' is not exactly the same as 'multiply by 0.1'" -- particularly as 0.1 cannot be represented precisely in IEEE floating point.
I just tried it out, and immediately blew up with a floating point exception. The function eligible uses fgets to read a line from the beginning of a file. If that line starts with a zero byte (like the invisible.DS_Store on MacOS X) then fgets returns success, and a little later on we divide by strlen(buf), which is of course zero. Oops.
>Garbage collection is nothing more, nothing less than pointer manipulation.
This notion that memory is the only resource that needs management is pernicious and damaging. A running system uses many resources apart from memory. They all need management. And they're all susceptible to the same problems as memory -- dangling references, double disposal, difficulty in determining ownership and therefore responsibility over lifetime etc.
A system which removes the burden of memory management is clearly very valuable, but if it simultaneously makes it harder to build infrastructure that can help with other resource types then I think one has to question the overall benefit.
For the creation of reliable systems, I would claim that _destructors_ are the single biggest advantage C++ has over Java, C#, perl, python and the rest. A C++ destructor is reliably invoked at predictable times. This makes it, in conjunction with constructors of course, a key building block in the management of all kinds of resources.
Speaking more plainly, my own experience is that memory management is a non-issue -- it is simply a special case of the more general management of any resource (network socket, dma channel, sound output etc) And we have problems with that management when the the ownership of a resource may change over time.
And the solution? (Well, a solution): Reference Counting.
Before you turn away in disgust, take a look through the linux kernel source. You'll see pervasive use of reference counting. It's had a bad rep since early smalltalk days, where it was used for the management of every single object. And that's very costly, when most of the time who owns what is obvious. But dismissing reference counting based on poor results when it's over-used is a mistake, just as claiming that Java et al solve the number one problem in software reliability by providing pervasive automatic garbage collection of objects.
Someone else has almost certainly posted a correction, but just in case:
The first digit of an ISBN is basically, but not rigidly, a language indicator -- zero and one being English. The remaining digits have a variable length publisher code and a variable length product code -- Prentice Hall is 13, Oxford is 19, Addison Wesley is 201, Perseus is 7382, O'Reilly is 56592. As you can see the larger publishers are effectively allocated a bigger chunk of the number space (Prentice Hall have six digits to allocate, O'Reilly only three), and smaller publishers get less. But the space is actually flat -- it's just easier to delegate the assignment of individual numbers to the publishers by giving them a block in which they have free rein than it would be to have a central authority handing out numbers one by one.
Slashdot Mirror
Nitpicking a couple of your examples.
Example 1: "...will not just be a simple shift...". No, it will be an *arithmetic* shift, where the topmost bit is preserved and replicated into the second-to-topmost bit. Something even the 6502 had.
Example 2: "'divide by 10' is not exactly the same as 'multiply by 0.1'" -- particularly as 0.1 cannot be represented precisely in IEEE floating point.
I just tried it out, and immediately blew up with a floating point exception. The function eligible uses fgets to read a line from the beginning of a file. If that line starts with a zero byte (like the invisible .DS_Store on MacOS X) then fgets returns success, and a little later on we divide by strlen(buf), which is of course zero. Oops.
A system which removes the burden of memory management is clearly very valuable, but if it simultaneously makes it harder to build infrastructure that can help with other resource types then I think one has to question the overall benefit.
For the creation of reliable systems, I would claim that _destructors_ are the single biggest advantage C++ has over Java, C#, perl, python and the rest. A C++ destructor is reliably invoked at predictable times. This makes it, in conjunction with constructors of course, a key building block in the management of all kinds of resources.
Speaking more plainly, my own experience is that memory management is a non-issue -- it is simply a special case of the more general management of any resource (network socket, dma channel, sound output etc) And we have problems with that management when the the ownership of a resource may change over time.
And the solution? (Well, a solution): Reference Counting.
Before you turn away in disgust, take a look through the linux kernel source. You'll see pervasive use of reference counting. It's had a bad rep since early smalltalk days, where it was used for the management of every single object. And that's very costly, when most of the time who owns what is obvious. But dismissing reference counting based on poor results when it's over-used is a mistake, just as claiming that Java et al solve the number one problem in software reliability by providing pervasive automatic garbage collection of objects.
Someone else has almost certainly posted a correction, but just in case:
The first digit of an ISBN is basically, but not rigidly, a language indicator -- zero and one being English. The remaining digits have a variable length publisher code and a variable length product code -- Prentice Hall is 13, Oxford is 19, Addison Wesley is 201, Perseus is 7382, O'Reilly is 56592. As you can see the larger publishers are effectively allocated a bigger chunk of the number space (Prentice Hall have six digits to allocate, O'Reilly only three), and smaller publishers get less. But the space is actually flat -- it's just easier to delegate the assignment of individual numbers to the publishers by giving them a block in which they have free rein than it would be to have a central authority handing out numbers one by one.