I've read the book (unlike the reviewer, I suspect), and I concur, there is plenty of information on different compiler implementations. The fact that one particular compiler isn't listed in the index is a poor measure.
Great book, by the way. I found it to be an excellent mix of theoretical style ("this is the current state of the art on now templates work") versus practical tips ("this is what you need to know to write templates successfully").
Can you provide any details on this? My understanding was that Java generics was essentially a syntactic hack so that you don't have to manually insert casts when using containers, the generated bytecode is identical to the non-generic case.
This misses 80% of the uses of templates in C++: generic algorithms, traits, compile-time algorithm evaluation etc.
Actually, it does require that all pointers to class types must be the same size. Pointers to builtin types and pointers to functions and pointers to members can be different sizes.
It is also guaranteed that a cast to void* and back preserves all information.
In fact, POSIX requires that in C, all pointers are the same size (or at least convertible to one another without losing information). That doesn't apply to pointers to members, of course.
Removing parts of the library might be a good idea (IOStreams, for example, is pretty slow, for example), and may be desirable in some cases, but the language features you mentioned should not affect performance. One of the design principles (not always kept, mind you) of C++ is that you don't pay for what you don't use.
If you don't use multiple inheritance, then you don't suffer a performance drop. If you don't use exceptions, you don't suffer a performance drop. Templates, namespaces, and new-style casts all provide the programmer with more tools, and have no intrinsic performance issues while allowing more flexibility of program design.
In other words, the reason why embedded C++ is so disparaged in the mainstream C++ community is that the subset of C++ it implements is based more around what is easy for compiler writers to implement, rather than what is desirable for a programmer in an embedded environment.
In some forms of template programming, with some compilers, there is a bloat problem. For the most part, this has been fixed by better compilers (recognising when two different instantiations produce equivalent code) and better design.
Hey, I looked at your hash_map implementation a while ago. I thought it was nice, but I didn't end up using it for a few reasons (none terribly major):
Inconsistent capitalization of method names. I guess you put the 'semi-standard' names in lower case for consistency with the STL containers, but then having other methods in UpperCaseStyle looks weird.
Why use my_pair instead of std::pair?
I couldn't convince myself that your hashing itself was correct, especially when deleting items. Rather than 'chaining' items when a hash collision occurs (using a list of some sort), you probe for an empty bucket with (hashLocation + hashIncrement)%maxLength. This means that the delete function must probe ahead and see if other objects need to be moved into its place. But I don't see how that works from looking at the code.
I ended up writing my own, based (loosly) on Matt Austern's standard library proposal, using the doublely linked list scheme. It turned out to be very elegant, the iterator type is just list::iterator, so no need to write a custom iterator class. The only thing I didn't get right is the complexity requirements for the bucket interface, but I don't use that anyway so I havn't bothered trying to fix it.
And compilers are getting much better at doing this optimization themselves, even in cases where it would be hard to do manually (say, for templates instantiated on both int and long, on a platform where these have the same representation).
The parent was probably put off by some bad experience with an older compiler.
Where did you get that idea? You are completely wrong.
There is no difference at all in performance cost of a template function versus a non-template function. The generated code is exactly the same as if you had explicitly written a non-template function to do the same thing. So there is no performance loss at all due to template. (There might be due to some poor usage of templates, but you could say that about anything, even assembly language!)
On the other hand, templates allow a style of code that retains some flavour of OO polymorphism while being very fast, as all of the function calls etc are resolved at compile-time. The alternatives are to use dynamic polymorphism (slow), or bloat the source code by manually writing stupid functions like
And I would add, the need to do lots of casting (as opposed to simply calling a virtual function on the base class object) is a sure sign of a screwed up design.
I don't understand the comment about examples. In the early part of the book, it is true that many of the examples are rather generic, but adding another set of more concrete examples would bloat the book, and would be completely unncesessary IMHO. They are easy enough to understand as it is (with well thought-out identifier names etc.)
Later in the book, on template metaprogramming etc, there are lots of concrete examples. Perhaps the reviewer didn't read that far?
True, the book deals exclusively with C++. But contrary to what the reviewer states, it deals extensively with differences in C++ implementations. Whether or not one particular C++ compiler is listed in the index is not a very good judge!
Reading his last paragraph, I am sure now the reviewer did not read all of the book. It is not written in "cookbook" style, but for sure everyone reading the book will learn and discover new ideas for template design that they didn't know before. And the capabilities of parametric polymorphism are explored in detail, with quite large sections on how they could be extended (and possibly will, in the next C++ standard) to make some types of programming easier.
In short, this book is a mix between an academic treatise (it encapsulates practically all that is currently known about the C++ template mechanism), and practical guide to writing your own templates.
Sure, a slow leak is no problem. But a window or door failure is NOT a slow leak, it is a very rapid depressurization! A friend of mine who is an ATC once decribed a flight attendant training film he once saw. On failure of a window at altitude, the first thing that happens is that everyone sitting in that row disappears out the window (whether they are wearing seatbelts or not). People in surrounding rows who are not wearing seatbelts are also in trouble. Sharp pain in the ears as you have a couple of minutes (perhaps less) to struggle to get the oxygen mask on. The pilot is likely to start a rapid descent, scaing the sh*t out of the passengers, who most likely cannot hear anything because of the noise. Need I go on?
Presumably the intent is that the suit has to be in relation to the standard in question. I suspect that is so obvious that they didn't feel the need to state it explicitly? (or perhaps they did, elsewhere?)
Yes, but windows doesn't allow you to do it transparantly. Say you were running out of disk space so you wanted to shift some stuff onto another disk. Trivial on Linux, using either symlinks or just copy some subtree onto a new disk and mount it in place of the original.
How do you do that in Windows? The only way I know of safely 'moving' applications around is to uninstall it from one location and re-install it somewhere else. And what if you want to mix'n'match disks with another machine?
Assuming that developers are equally productive on both platforms. Then in the long term, an imbalance in developers inevitably leads to an imbalance in software (either more software, or higher quality, or a combination of both).
Of course that is only the long term trend. But in the past M$ has considered it an absolute priority to capture the 'developer mindshare' and get them writing code for the Windoze platform, and only for the Windoze platform. A trend away from that will have Bill in a spin.
A linux user using 'doze for the first time experiences exactly the same thing, if anything even worse, if you compare the amount of cruft and general weirdness of linux vs 'doze.
True, learning a new system is a big barrier, but I don't think there is anything intrinsically harder about learning linux.
Its like saying "DVD players arn't for the masses" just because the controls are different from a VCR. If its useful enough, then people will just learn to use it.
Absolutely true, it is a compromise position that is perhaps more politically realistic, but Lessig himself would be the first to acknowledge that it is not the 'ideal'.
It is similar in some ways to the pragatism RMS showed in devising the GPL - using copyright law to circumvent... copyright law.
But would this proposal have the effect of making the last 2% all but impossible to achieve?
As far as I know, they have not. I think the ability to use a second shuttle as a rescue craft was part of the original plans, the idea being that in an emergency a second shuttle could be prepared for launch in less than a week. But this was at a time when NASA were forecasting close to a shuttle launch a week anyway. NASA gave up on that a long time ago.
$t-15 billion is similar to the cost of designing the shuttle (and the ISS, for that matter). However, there is a quite big difference between the design process for the shuttle and the design process for a "space elevator", namely:
'Most' of the engineering required to build a space elevator is understood (well, so the proponents claim). The only thing missing is, ahem, the construction material simply does not exist today.
In theory, diamond or carbon nanotubes could do it. But nanotubes are so hard to make that I don't think there is a single example of an object make of nanotubes larger than a few microns, at best. Certainly no one has ever made an object of any use at all to the construction industry (even a small beam or rod would have immense use, so it is not through lack of interest).
The space elevator is no less "pure science fiction" than it was 50 years ago.
The idea of repairing satellites in space was a nice idea, but it was apparant even very early on in the shuttle design phase that it would not work out.
The Shuttle only goes to low earth orbit, the bulk of the satellites that would be candidates for repair are boosted much higher. It is simply not possible to retrieve them from this location.
Secondly, compared with the cost of a shuttle mission itself, satellites are not so expensive. In many cases, it is cheaper to just write-off the old sat and put a new one up there.
Thirdly, the ability to repair a satellite in space depends critically on what is wrong with it. Satellites, once they are deployed, are often given a fairly high rotational velocity to keep them stable. Retriving the satellite can only be done if it can be placed in a safe position for it to be retrieved, which requires that (1) whatever problems that caused the sat to malfuction in the first place do not affect the guidance system, (2) the sat has the capabilities to manouver itself into a safe position, and (3) it has enough fuel remaining to do so. Retriving an unstable satellite was never considered a possibility.
Slashdot Mirror
A closure is (if I understand correctly) like a lambda-expression, where you construct a function as part of an expression. Something like
foreach(mylist.being(), mylist.end(), lambda(int& y) { y *= 2; });
Where the function to apply to all elements of mylist is defined as part of the foreach() call itself.
Interestingly, you can do this in C++ too (after a fashion)! Have a look at boost.org.
Great book, by the way. I found it to be an excellent mix of theoretical style ("this is the current state of the art on now templates work") versus practical tips ("this is what you need to know to write templates successfully").
This misses 80% of the uses of templates in C++: generic algorithms, traits, compile-time algorithm evaluation etc.
It is also guaranteed that a cast to void* and back preserves all information.
In fact, POSIX requires that in C, all pointers are the same size (or at least convertible to one another without losing information). That doesn't apply to pointers to members, of course.
If you don't use multiple inheritance, then you don't suffer a performance drop. If you don't use exceptions, you don't suffer a performance drop. Templates, namespaces, and new-style casts all provide the programmer with more tools, and have no intrinsic performance issues while allowing more flexibility of program design.
In other words, the reason why embedded C++ is so disparaged in the mainstream C++ community is that the subset of C++ it implements is based more around what is easy for compiler writers to implement, rather than what is desirable for a programmer in an embedded environment.
In some forms of template programming, with some compilers, there is a bloat problem. For the most part, this has been fixed by better compilers (recognising when two different instantiations produce equivalent code) and better design.
Inconsistent capitalization of method names. I guess you put the 'semi-standard' names in lower case for consistency with the STL containers, but then having other methods in UpperCaseStyle looks weird.
Why use my_pair instead of std::pair?
I couldn't convince myself that your hashing itself was correct, especially when deleting items. Rather than 'chaining' items when a hash collision occurs (using a list of some sort), you probe for an empty bucket with (hashLocation + hashIncrement)%maxLength. This means that the delete function must probe ahead and see if other objects need to be moved into its place. But I don't see how that works from looking at the code.
I ended up writing my own, based (loosly) on Matt Austern's standard library proposal, using the doublely linked list scheme. It turned out to be very elegant, the iterator type is just list::iterator, so no need to write a custom iterator class. The only thing I didn't get right is the complexity requirements for the bucket interface, but I don't use that anyway so I havn't bothered trying to fix it.
The parent was probably put off by some bad experience with an older compiler.
There is no difference at all in performance cost of a template function versus a non-template function. The generated code is exactly the same as if you had explicitly written a non-template function to do the same thing. So there is no performance loss at all due to template. (There might be due to some poor usage of templates, but you could say that about anything, even assembly language!)
On the other hand, templates allow a style of code that retains some flavour of OO polymorphism while being very fast, as all of the function calls etc are resolved at compile-time. The alternatives are to use dynamic polymorphism (slow), or bloat the source code by manually writing stupid functions like
void foo_SomeType(SomeType x) { ... }
... }
...
void foo_SomeOtherType(SomeOtherType x) {
And I would add, the need to do lots of casting (as opposed to simply calling a virtual function on the base class object) is a sure sign of a screwed up design.
The point is though, with templates the compiler would not have allowed you to add an object of incorrect type to the container in the first place.
if (!signature) throw std::runtime_error("No sig!");
The template version would give a compile-time error instead - type-safe and no need to to runtime error handling!
Later in the book, on template metaprogramming etc, there are lots of concrete examples. Perhaps the reviewer didn't read that far?
True, the book deals exclusively with C++. But contrary to what the reviewer states, it deals extensively with differences in C++ implementations. Whether or not one particular C++ compiler is listed in the index is not a very good judge!
Reading his last paragraph, I am sure now the reviewer did not read all of the book. It is not written in "cookbook" style, but for sure everyone reading the book will learn and discover new ideas for template design that they didn't know before. And the capabilities of parametric polymorphism are explored in detail, with quite large sections on how they could be extended (and possibly will, in the next C++ standard) to make some types of programming easier.
In short, this book is a mix between an academic treatise (it encapsulates practically all that is currently known about the C++ template mechanism), and practical guide to writing your own templates.
Sure, a slow leak is no problem. But a window or door failure is NOT a slow leak, it is a very rapid depressurization! A friend of mine who is an ATC once decribed a flight attendant training film he once saw. On failure of a window at altitude, the first thing that happens is that everyone sitting in that row disappears out the window (whether they are wearing seatbelts or not). People in surrounding rows who are not wearing seatbelts are also in trouble. Sharp pain in the ears as you have a couple of minutes (perhaps less) to struggle to get the oxygen mask on. The pilot is likely to start a rapid descent, scaing the sh*t out of the passengers, who most likely cannot hear anything because of the noise. Need I go on?
What happens if a bullet hits a window? Or some mechanism inside the door?
Presumably the intent is that the suit has to be in relation to the standard in question. I suspect that is so obvious that they didn't feel the need to state it explicitly? (or perhaps they did, elsewhere?)
How do you do that in Windows? The only way I know of safely 'moving' applications around is to uninstall it from one location and re-install it somewhere else. And what if you want to mix'n'match disks with another machine?
Hey, you just made that up!
The real figure is 83.04% of statistics are made up, of course!
Of course that is only the long term trend. But in the past M$ has considered it an absolute priority to capture the 'developer mindshare' and get them writing code for the Windoze platform, and only for the Windoze platform. A trend away from that will have Bill in a spin.
A linux user using 'doze for the first time experiences exactly the same thing, if anything even worse, if you compare the amount of cruft and general weirdness of linux vs 'doze.
True, learning a new system is a big barrier, but I don't think there is anything intrinsically harder about learning linux.
Its like saying "DVD players arn't for the masses" just because the controls are different from a VCR. If its useful enough, then people will just learn to use it.
What would that achieve that existing user-space solutions do not?
It is similar in some ways to the pragatism RMS showed in devising the GPL - using copyright law to circumvent ... copyright law.
But would this proposal have the effect of making the last 2% all but impossible to achieve?
What is the conceptual basis of copyright, if it is not a 'moral right' of the artist?
As far as I know, they have not. I think the ability to use a second shuttle as a rescue craft was part of the original plans, the idea being that in an emergency a second shuttle could be prepared for launch in less than a week. But this was at a time when NASA were forecasting close to a shuttle launch a week anyway. NASA gave up on that a long time ago.
$t-15 billion is similar to the cost of designing the shuttle (and the ISS, for that matter). However, there is a quite big difference between the design process for the shuttle and the design process for a "space elevator", namely:
'Most' of the engineering required to build a space elevator is understood (well, so the proponents claim). The only thing missing is, ahem, the construction material simply does not exist today.
In theory, diamond or carbon nanotubes could do it. But nanotubes are so hard to make that I don't think there is a single example of an object make of nanotubes larger than a few microns, at best. Certainly no one has ever made an object of any use at all to the construction industry (even a small beam or rod would have immense use, so it is not through lack of interest).
The space elevator is no less "pure science fiction" than it was 50 years ago.
The Shuttle only goes to low earth orbit, the bulk of the satellites that would be candidates for repair are boosted much higher. It is simply not possible to retrieve them from this location.
Secondly, compared with the cost of a shuttle mission itself, satellites are not so expensive. In many cases, it is cheaper to just write-off the old sat and put a new one up there.
Thirdly, the ability to repair a satellite in space depends critically on what is wrong with it. Satellites, once they are deployed, are often given a fairly high rotational velocity to keep them stable. Retriving the satellite can only be done if it can be placed in a safe position for it to be retrieved, which requires that (1) whatever problems that caused the sat to malfuction in the first place do not affect the guidance system, (2) the sat has the capabilities to manouver itself into a safe position, and (3) it has enough fuel remaining to do so. Retriving an unstable satellite was never considered a possibility.