A retrial and an appeal is significantly different in countries that don't base their legal system on English common law. A retrial would usually involve hearing the full case again, possibly with new charges, while an appeal involves reexamining parts of a case while most evidence and arguments entered as part of the original case will stand and be used as a basis, and the lower courts findings and judgement will be given considerable weight by the higher court.
This isn't a retrial, it's an appeal. It does make it suck considerably less than if it had been a retrial.
You're missing the fact that most countries don't have the kind of double jeopardy that stems from English common law. Norway, and a lot of other countries with legal systems that evolved independent of common law, have protection against retrial - where retrial is taken to mean the restart of legal proceedings in the lowest applicable court, possibly with new charges -, not against appeal to a higher court.
So no, they can't retry you as many times as they please. They can appeal, usually no more than twice, and with severe restrictions on what parts of the case the higher court will reexamine.
And saying that Scandinavian states have a history of significant right wing politics and social repression of dissident groups show a fundamental lack of knowledge of Scandinavian history. The Norwegian labour party, for instance, which has ruled Norway most of the time since WWII, is far left of the US Democrats, and used to have significant communist ties (the Norwegian Communist Party split off after a small majority voted against entering Komintern, the Communist International in the prewar years).
And currently, Norwegian polls indicate that the socialist party may become as big or bigger than labour, and that the two may be able to secure absolute majority in the next election.
I just wonder where you've got the "right wing politics" idea from, as Scandinavia is more commonly being "accused" of being socialist.
There have been brief periods of right wing support in recent years, right wing in Scandinavian sense means mostly parties that are about as right wing as the Democrats in the US, with fringe parties approaching the Republicans in extremism...
If you brand Scandinavia right wing, what do you think about the US?
As for social repression, while left wing and right wing extremist groups used to be under significant surveillance, in particular because some of them openly advocated violent overthrow of the government, they have been free to operate more or less as they please.
The same goes for the other Scandinavian countries.
Tell that to my 3 year old tri-band phone . Almost wherever I go (including most larger US cities) the first thing I do when I step of the plane is turn on my cellphone. And most of the time it'll pick up a provider that I can roam with
immediately. It's so much more convenient than being without a cellphone or
having to resort to renting one at ridiculous rates.
Whatever technological advantages you might think of, there are a couple of huge advantages with GSM: There's a much larger production volume for GSM handsets (face it, Europe tend to get the newest handsets before the US, and we have a much wider selection), and with a decent handset you'd be able to use it in practically any country in the world (including other countries in the region).
Considering the deployment of GSM it is clear that GSM is good enough, and that technical considerations therefore should be a secondary issue for most people considering building out a network - cost and convenience for the users should be much more important as that is what will drive sales.
That said, I think the important part of this is the idea that the idead that the US should have any say whatsoever over what Iraq does when "liberated" is disgusting. The US lost all legitimacy when it violated the UN charter and attacked a sovereign nation, and any hope for the US in getting any sort of credibility back will be lost if there's even the slightest little hint of US colonialism after the war.
And for the people who have problems with too heavy glasses Lasik is unlikely to be an option. My gf is one of them - she spends a fortune getting her lenses halved, and even then they look quite thick at the edges. If she'd gone for glass lenses they'd be unbearably heavy. The thickness of the lenses also means she have to go for thicker (and heavier) frames to keep the lenses from falling out.
For her Lasik is getting within reach, but still carries a significant risk of further loss of vision and is unlikely to get her eyesight to the point where she don't need glasses.
Glasses is going to remain the only safe option for a lot of people for years to come.
The common base class + template approach does not generate more method calls by itself. You (that is, the developer) generate more more method calls if you split up methods to separate out more generic functionality than you would if size what not one of your concerns. In other words, it's a classic size vs. performance tradeoff that is a pure technical design issue.
I have no problem agreeing with you that there's a lot of crappy compilers out there, though...:)
How does templates "smell funny"? I've outlined several methods for documenting requirements on templates usage that will even trigger nice compiler warnings if you don't follow them. How will that be solved by derivation? You will still need documentation to know what requirements needs to be filled. I'd make the argument that using some of the techniques I outlined could be beneficial when using derivation as well, simply for the reason that relying on a "it compiles, so I've satisfied the requirements" mentality is dangerous when only satisfying a few syntactical constraints will make things compile without any real understanding of what requirements must be filled.
Compile time assertions can strengthen that a lot. You end up with a compile/edit cycle only if you've actually failed to understand a requirement or failed to comply or indicate your compliance.
Personally I find using templates a lot cleaner than derivation. Derivation introduce a tight coupling which, like in your mention of a "Testable" interface, is unhealty: Class hierarchies grow and expand for functionality that may be unrelated to the problem domain, and introducing new interfaces may require changes to a large number of existing classes. Templates, used sensibly, allow for much smaller, more cohesive components that can easily be decoupled and reused.
In general I tend to take a long hard look at class hierarchies that grow above maybe 3-4 levels of inheritance and 10-15 classes total and try to split them up - large class hierarchies tend to make it hard to introduce change. Often such class hierarchies can be dramatically reduced by using templates and policy or traints classes to encapsulate specific parts of the functionality in cohesive reusable components that can be maintained and developed separately.
Ever tried installing Linux in 4MB flash and 4MB RAM and then have space left for a full set of userspace applications (shell, linker, module management, various programs such as mv,cp,ln etc)? You're not left with much for the actual application.
Anway, what overhead from an inheritance structure? Unless you use virtual functions, there is no overhead from it if you use compiler that isn't a pile of shit. If you do use virtual functions, then yes. However, if you use virtual functions properly the size overhead of using them is often less that the size overhead of designing your system to do without. In other words, use C++ features that cost when the advantage they provide outweigh the space or performance overhead - analysing when what features are appropriate (and knowing which features introduce what cost) is an integral part of every developers job.
I agree that using C might be the better choice in systems as small as you suggest, but the discussion was over using templates or not in C++, not about using another language. If you do make the decision to use C++, it would not make sense to not use features that can help you keep performance to a max and space to a minimum, and when properly used templates is just such a feature.
It doesn't happen "behind your back", the behaviour is quite well behaved, and by passing an allocator you can control it even further. If you allocate many enough objects that memory allocations show up in your profiling, then implement a specialized allocator. Often, allocator classes such as small object allocator can be effectively generalized using templates so that they can be easily reused. As for list linkage, it is part of your core data structures if you make an STL list of objects instead of a list of pointers.
I was under the impression that even pointers to unrelated classes could have different size. Can you point me to where in the standard it says specify that all pointers to class types must be the same type? I'm genuinely curious. 3.9.2.3 says "The value representation of pointer types is implementation-defined. Pointers to cv-qualified and cv-unqualified versions (3.9.3) of layout-compatible types shall have the same value representation and alignment requirements (3.9)".
I can't find any language that narrow it down further, except for stating that all types must be convertible to/from void *, and that char * and void * must have the same value representation and alignment requirements (3.9.2.4)
The standards document is big, though, so I wouldn't be surprised if I've missed some paragraph that narrows it further down, so if you have a reference it would be appreciated.
I pointed to Boost because it contains examples of expression templates that illustrate how to achieve what you suggested with standard C++ features. In particular the lambda library illustrate the techniques quite well. Maybe I missed something - looking at for instance the lambda library, which parts of what you suggested do you think wouldn't be implementable using those techniques?
Ah, no. Void pointers are explicitly required to be able to hold a pointer to any type. 3.9.2.4 in the ISO C++ standard has the following to say on the subject: "Objects of cv-qualified (3.9.3) or cv-unqualified type void * (pointer to void), can be used to point to objects of unknown type. A void * shall be able to hold any object pointer. A cv-qualified or cv-unqualified (3.9.3) void * shall have the same representation and alignment requirements as a cv-qualified or cv-unqualified char*." [cv-qualified/cv-unqualified refer to const and volatile qualifiers]
In other words casting to void * is always allowed, but casting "Foo *" to "Bar *" where Foo and Bar are unrelated types might cause you to lose information.
If you define "use effectively" as "exploit the features of the language to it's full potential", then there's no way around templates in C++ - it is one of the primary benefits above C for instance. If I had to choose between classes+inheritance and templates and not use the other, I'd choose templates hands down - classes are easy to emulate just by being structured (been there, done that, implemented several OO class hierarchies using plain C)
I don't think object oriented design is useless - the combination of templates and OO is even more powerful than each of them on their own, but if you use C++ and don't use templates you're ignoring a major part of the language, and perhaps the largest single part of the language that differentiates it from many alternatives and that is difficult to emulate with other language features in any meaningful way.
If you define "use effectively" as "accomplishing a specific goal", then of course you can do that in C++ without templates, but not exploiting the advantages of templates make the case for using C++ over language Foo or Bar much less compelling.
You don't need to. You need to understand what the compiler optimizes away and what it doesn't. My capability for reading x86 assembly is mediocre at best, but I certainly read it well enough to see when I've done something that makes GCC suddenly collapse a few hundred lines of code down to a compile time constant value by structuring my template code in a way that is "optimizer friendly".
The typical reason for doing so in C++ is to be able to highly specialize a template to a particular usage. Say you need a sort that needs to be efficient on a very specific set of data. Quicksort is a good overall choice, but you can do vastly better if you can provide hints about your input. With templates you can still write a generic sort that will compose the right algorithm for you by inlining code and having the optimizer collapse it all down to a single function for you depending on information you provide (a typical example would be to sort subsets of the data of a certain size or below with a more specialized sorting algorithm)
In that case, even someone who has never seen assembly before will notice the difference easily just be looking at executable size and do some basic benchmarking - the advantage of looking at the assembly is that even with just a basic knowledge of assembly you will get a much better overview of why the damn compiler didn't optimize away as much as you'd hoped.
Actually, the C++ standard specifically does NOT require all pointers to be the same size. One of the reasons for this is that not all hardware platforms allow you to directly address every single byte, so that for instance a char pointer might need a pointer to the word a character is contained in and an offset into the word, or similar. The C++ standard only guarantee that all pointers to the same type are the same size.
Either the function is generic, in which case, as I wrote, you should write your template properly by using a common base class containing the generic functions, and you won't have 24 copies, you will have one, and your runtime overhead of templating the class (I'm assuming a class, since templating a single function that is already generic enough to cover the types you need is meaningless) both in terms of space and time is exactly nothing - or the function is specific to the types in question, in which case the choice isn't between 24 copies or 1, but between a template or 24 hand written copies.
Doing work near the hardware is no excuse not to use templates. On the contrary, I'd say that when you work on extremely performance critical code there is one thing you don't want your developers to do: reinventing the wheel over and over for non trivial parts of code - reinventing the wheel is something that's all too often done badly. A well written template will allow you to reuse well written, well tested efficient and small code over and over again for different types and different conditions without that risk.
Another reason to use templates in an embedded system is that it allow you to easily write reusable components that can be adapted to a particular situation at compile time instead of runtime, opening up reuse opportunities across projects that would otherwise be difficult. This is often done with traits classes or policy classes that allow you to turn on and off functionality of a template at compile time, leaving out any code that isn't actually used.
In fact, this is an important property of templates in C++: Code that isn't used isn't even semantically analysed, and certainly not included in the generated executable, while the same is not true for members of any class that is externally visible. So you might actually reduce your code size merely by changing some classes into templates even if they don't depend on any type parameter.
Oh, and I've worked on embedded systems, using exactly the above techniques, including one platform that had 4MB flash and 4MB RAM that we ran Linux on together with FTP and SNMP servers that I wrote (in C++) as well as various other application code, a shell, etc., so I am familiar with how to make C++ code small, and that is one of the reasons I love templates.
I don't really see your particular case as a problem - as you say it is already typesafe, and so a comment at the top of your function "requires type Foo to support interface Bar" would serve the same purpose as what you suggest.
However if you want more user friendly compiler error messages, that's another matter. A lot of work has gone into "compile time asserts", to catch as many problems as possible at compile time and give more intuitive errorts (in this case you got an error, but consider the problems if the classes supported the operators you needed but made them do something entirely different).
Instead of deriving, you could for instance check for an enum "supports_someinterface" in the types using a standard assert.
This allow you to use "assert(Foo::supports_interface_Bar);" in the functions
that have specific requirements. Note that the value of the enum is irelevant as long as it's non-null, and since the enum is a constant value known at compile time, there should be no runtime overhead (neither space nor performance) of the assert at all if your compiler is reasonably smart.
With GCC, this gives me the reasonably friendly error message: "'supports_interface_Bar' is not a member of type `Foo'" instead of (or rather, in addition to) some hopelessly cryptic error message if I try to instantiate a template with the above assert on a type that doesn't have the enum.
Of course, you might not have the luxury of changing all types you might want to use with your template, and some of them may already fulfill the requirements even if they don't contain the enum.
Fear not, that's what traits are for. Declare a template. Specialize the template for any type that supports your interface, and instead of "assert(Foo:supports_interface_Bar)", you might do "assert(Supports<Foo>::interface_Bar)" or "assert(Supports<Foo>::requirement_HasOutputOperat or)".
Strategically placing these at the top of your functions also serve to document the requirements.
Ok, so I saved the simplest option for your case until last (the above is better suited for complex requirements, not something as simple as "this templates needs member functions A,B and C to be implemented) :
assert(&Foo::operator<<)
With GCC, this produces the error message "`operator<<' is not a member of type `A'" if the operator isn't supported. Place asserts covering all the member functions you need at the head of your function and you both have documentation and reasonable error messages.
The above should have no runtime cost at all provided that the compiler at compile time is willing to guarantee that Foo::operator<< will never occupy address 0. However, don't assume your C++ compiler that smart (GCC 2.96 doesn't appear to be, I haven't checked any newer versions), so one improvement: "assert(sizeof(&Foo::operator<<))". sizeof is evaluated at compiletime, resulting in a constant that in this case must be non-null, meaning the assert will neven trigger, meaning the compiler will discard the code (this was enough to make GCC optimize the thing away).
This leaves us with this nice little macro (who I'm sure someone will find a nasty problem with:-):
Hot tip: sizeof() is extremely versatile for compile time testing whenever you can reduce the problem to either making code illegal in one case or return a constant expression (which is needed to apply sizeof to it), or when you an reduce a problem into a constant expression that will be a different size (that you can compare with a known quantity) depending on the outcome.
The book being reviewed contains at least one good example of this.
If you're a C++ programmer and don't use templates, you're not doing your job. If you've ever used map,vector,multimap,set,multiset,list,string,pair or most other classes from the C++ standard library, you've been using templates (yes, even "string" - string is a typedef for std::basic_string).
You're also being left behind in the dust. Modern C++ is all about exploiting
templates to simplify development, and even reduce code bloat (by making it easier to reuse common code) and increase performance (through automatic compile time generation of heavily inlined versions of algorithms).
If you make a huge template with lots of code that could be easily generalized for all types, then you're writing a bad template: You should factor all common code into a base class and make a template that contain the few parts of the code that are type specific. On the other hand, if your code can't easily be generalized for the types you need, templates save you the tedious and error prone task of maintaining multiple versions of your code specialized for multiple types.
In that respect templates dramatically reduce the amount of work you need to do, if applied properly.
As mentioned above, template techniques can dramatically improve performance over a generic algorithm by providing you with an automated way of generating heavily optimized inlined versions of an algorithm. The C++ template syntax is not really ideal for this, but the benefits from using templates for this are tremendous enough to make it worthwhile. Do a search for Vandevoorde's work on expression templates, or for Alexander Alexandrescu on Google to find more, or read Alexandrescu's articles in CUJ.
Continue to believe your prejudices if you want, but consider that if you can't use or write templates you've essentially shut yourself out of a huge segment of the C++ development job market. I would certainly never hire a "C++ developer" that don't at the very least have thorough experience with the STL, and preferrably understand how to write (and when to write) templates.
For one it would dramatically simplify colonization of Mars: You wouldn't have to bring huge quantities of your own water, and you'll have hydrogen readily available for fuel (for return flights). Both dramatically reduce the mass you'd need to transport to Mars to set up and maintain a colony.
It might not have anything to do with what current theories say goes on inside a black hole. And granted, those theories are probably a lot more likely to be close to reality than crazy ideas posted here.
But I'd be careful about talking about black holes as if we know for sure how they behave - after all we haven't exactly observed any up close, and most of the theories related to black holes are based on finding something that fit nicely with other current theories. It's not that long ago since black holes were considered pure unsubstantiated conjecture, and our understanding of black holes might suddenly change dramatically tomorrow.
Fact is, we don't know what goes on inside a black hole, and we don't know how to find out and be able to report anything meaningless back. Some guesses, theories and ideas are more likely to be right, sure.
But you're answering the wrong question: You're answering the question of how this fits in to current theories about what is going on inside a black hole, while the real question is whether or not the concept outlined could fit in with the existing observed behaviour of the universe.
You're probably right that the idea wouldn't fit in with current theories, but are there observations that would directly contradict this idea?
His point is that if you imagine that the singularity the existed at the point of the big bang was actually the singularity of a black hole, then our entire current universe is the singularity of a black hole contained in a another universe, expanding at the speed of light. I'm not even going to bother trying to discuss the merits of that idea, as physics isn't my strong side:-)
But in other words, you're probably right that being around at the time the even horizon formed wouldn't be a good idea. On the other hand it is an interesting question whether it would be possible that conditions inside a singularity as seen from the inside could allow something like our universe to form. And if not, then why not?
I've no interest in discussing the documentation - I don't do GTK nor QT programming so I've never had any reason to look at the respective documentations. I commented on the argument that a "new QPushButton("label")" was somehow clearer or superior to gtk_button_new_with_label("label"), to point out that C++'s different syntax and built in language support for classes doesn't give you any more knowledge of the semantics by looking at the API alone.
In other words, given the two statements that were given as an example, without resorting to knowledge about the respective toolkits or their documentation you have little, if any, basis for saying anything more about the likely behaviour of the C++ version than the C version.
If you don't like GTK because of documentation, fine, but then say that right away instead of pretending that the fact that QT is C++ by default give developers more knowledge about how it works - that's the kind of attitude
that make developers get burned when they run into a system that doesn't fit their assumptions.
I do about 95% of my work in C++, but I certainly don't see C++ classes as any inherently better than C based object systems - as long as the design is clean a C based class hierarchy can be just as easy to use as a C++ one. In fact, implementing your own object oriented system in C give you freedom to make a lot of design choices that are really hard to achieve using C++ classes, For example, one of my hobby projects at the moment is a system for composing classes and aspects programmatically, to give a more generalized object oriented system that doesn't need inheritance and offer more generic polymorphism, and where you can add features to a class at runtime. Doing what that system does using C++ classes would require many times the amount of code (of course you could do it the "C way" in C++, but then what would be the point?)
Doing preemtive multitasking on the C64 via interrupts should be feasible, though, as the interrupt handler is responsible for storing registers and flags, as far as I can remember, and it could just as well run a scheduler and restore registers belonging to a different thread before exiting. Of course it's about 11-12 years since I last seriously used a C64, so I might be forgetting something obvious...:)
Slashdot Mirror
This isn't a retrial, it's an appeal. It does make it suck considerably less than if it had been a retrial.
So no, they can't retry you as many times as they please. They can appeal, usually no more than twice, and with severe restrictions on what parts of the case the higher court will reexamine.
And saying that Scandinavian states have a history of significant right wing politics and social repression of dissident groups show a fundamental lack of knowledge of Scandinavian history. The Norwegian labour party, for instance, which has ruled Norway most of the time since WWII, is far left of the US Democrats, and used to have significant communist ties (the Norwegian Communist Party split off after a small majority voted against entering Komintern, the Communist International in the prewar years).
And currently, Norwegian polls indicate that the socialist party may become as big or bigger than labour, and that the two may be able to secure absolute majority in the next election.
I just wonder where you've got the "right wing politics" idea from, as Scandinavia is more commonly being "accused" of being socialist.
There have been brief periods of right wing support in recent years, right wing in Scandinavian sense means mostly parties that are about as right wing as the Democrats in the US, with fringe parties approaching the Republicans in extremism...
If you brand Scandinavia right wing, what do you think about the US?
As for social repression, while left wing and right wing extremist groups used to be under significant surveillance, in particular because some of them openly advocated violent overthrow of the government, they have been free to operate more or less as they please.
The same goes for the other Scandinavian countries.
Tell that to my 3 year old tri-band phone . Almost wherever I go (including most larger US cities) the first thing I do when I step of the plane is turn on my cellphone. And most of the time it'll pick up a provider that I can roam with immediately. It's so much more convenient than being without a cellphone or having to resort to renting one at ridiculous rates.
Whatever technological advantages you might think of, there are a couple of huge advantages with GSM: There's a much larger production volume for GSM handsets (face it, Europe tend to get the newest handsets before the US, and we have a much wider selection), and with a decent handset you'd be able to use it in practically any country in the world (including other countries in the region).
Considering the deployment of GSM it is clear that GSM is good enough, and that technical considerations therefore should be a secondary issue for most people considering building out a network - cost and convenience for the users should be much more important as that is what will drive sales.
That said, I think the important part of this is the idea that the idead that the US should have any say whatsoever over what Iraq does when "liberated" is disgusting. The US lost all legitimacy when it violated the UN charter and attacked a sovereign nation, and any hope for the US in getting any sort of credibility back will be lost if there's even the slightest little hint of US colonialism after the war.
For her Lasik is getting within reach, but still carries a significant risk of further loss of vision and is unlikely to get her eyesight to the point where she don't need glasses.
Glasses is going to remain the only safe option for a lot of people for years to come.
So by your definition I guess he's Indian then, since he moved to India years ago.
I have no problem agreeing with you that there's a lot of crappy compilers out there, though... :)
Compile time assertions can strengthen that a lot. You end up with a compile/edit cycle only if you've actually failed to understand a requirement or failed to comply or indicate your compliance.
Personally I find using templates a lot cleaner than derivation. Derivation introduce a tight coupling which, like in your mention of a "Testable" interface, is unhealty: Class hierarchies grow and expand for functionality that may be unrelated to the problem domain, and introducing new interfaces may require changes to a large number of existing classes. Templates, used sensibly, allow for much smaller, more cohesive components that can easily be decoupled and reused.
In general I tend to take a long hard look at class hierarchies that grow above maybe 3-4 levels of inheritance and 10-15 classes total and try to split them up - large class hierarchies tend to make it hard to introduce change. Often such class hierarchies can be dramatically reduced by using templates and policy or traints classes to encapsulate specific parts of the functionality in cohesive reusable components that can be maintained and developed separately.
Anway, what overhead from an inheritance structure? Unless you use virtual functions, there is no overhead from it if you use compiler that isn't a pile of shit. If you do use virtual functions, then yes. However, if you use virtual functions properly the size overhead of using them is often less that the size overhead of designing your system to do without. In other words, use C++ features that cost when the advantage they provide outweigh the space or performance overhead - analysing when what features are appropriate (and knowing which features introduce what cost) is an integral part of every developers job.
I agree that using C might be the better choice in systems as small as you suggest, but the discussion was over using templates or not in C++, not about using another language. If you do make the decision to use C++, it would not make sense to not use features that can help you keep performance to a max and space to a minimum, and when properly used templates is just such a feature.
It doesn't happen "behind your back", the behaviour is quite well behaved, and by passing an allocator you can control it even further. If you allocate many enough objects that memory allocations show up in your profiling, then implement a specialized allocator. Often, allocator classes such as small object allocator can be effectively generalized using templates so that they can be easily reused. As for list linkage, it is part of your core data structures if you make an STL list of objects instead of a list of pointers.
I can't find any language that narrow it down further, except for stating that all types must be convertible to/from void *, and that char * and void * must have the same value representation and alignment requirements (3.9.2.4)
The standards document is big, though, so I wouldn't be surprised if I've missed some paragraph that narrows it further down, so if you have a reference it would be appreciated.
I pointed to Boost because it contains examples of expression templates that illustrate how to achieve what you suggested with standard C++ features. In particular the lambda library illustrate the techniques quite well. Maybe I missed something - looking at for instance the lambda library, which parts of what you suggested do you think wouldn't be implementable using those techniques?
In other words casting to void * is always allowed, but casting "Foo *" to "Bar *" where Foo and Bar are unrelated types might cause you to lose information.
What you want are "expression templates" (do a search, or look at Boost) which does what you suggest with plain C++.
I don't think object oriented design is useless - the combination of templates and OO is even more powerful than each of them on their own, but if you use C++ and don't use templates you're ignoring a major part of the language, and perhaps the largest single part of the language that differentiates it from many alternatives and that is difficult to emulate with other language features in any meaningful way.
If you define "use effectively" as "accomplishing a specific goal", then of course you can do that in C++ without templates, but not exploiting the advantages of templates make the case for using C++ over language Foo or Bar much less compelling.
The typical reason for doing so in C++ is to be able to highly specialize a template to a particular usage. Say you need a sort that needs to be efficient on a very specific set of data. Quicksort is a good overall choice, but you can do vastly better if you can provide hints about your input. With templates you can still write a generic sort that will compose the right algorithm for you by inlining code and having the optimizer collapse it all down to a single function for you depending on information you provide (a typical example would be to sort subsets of the data of a certain size or below with a more specialized sorting algorithm)
In that case, even someone who has never seen assembly before will notice the difference easily just be looking at executable size and do some basic benchmarking - the advantage of looking at the assembly is that even with just a basic knowledge of assembly you will get a much better overview of why the damn compiler didn't optimize away as much as you'd hoped.
Of course... Arghh, the curse of Friday afternoons :-)
Actually, the C++ standard specifically does NOT require all pointers to be the same size. One of the reasons for this is that not all hardware platforms allow you to directly address every single byte, so that for instance a char pointer might need a pointer to the word a character is contained in and an offset into the word, or similar. The C++ standard only guarantee that all pointers to the same type are the same size.
Doing work near the hardware is no excuse not to use templates. On the contrary, I'd say that when you work on extremely performance critical code there is one thing you don't want your developers to do: reinventing the wheel over and over for non trivial parts of code - reinventing the wheel is something that's all too often done badly. A well written template will allow you to reuse well written, well tested efficient and small code over and over again for different types and different conditions without that risk.
Another reason to use templates in an embedded system is that it allow you to easily write reusable components that can be adapted to a particular situation at compile time instead of runtime, opening up reuse opportunities across projects that would otherwise be difficult. This is often done with traits classes or policy classes that allow you to turn on and off functionality of a template at compile time, leaving out any code that isn't actually used.
In fact, this is an important property of templates in C++: Code that isn't used isn't even semantically analysed, and certainly not included in the generated executable, while the same is not true for members of any class that is externally visible. So you might actually reduce your code size merely by changing some classes into templates even if they don't depend on any type parameter.
Oh, and I've worked on embedded systems, using exactly the above techniques, including one platform that had 4MB flash and 4MB RAM that we ran Linux on together with FTP and SNMP servers that I wrote (in C++) as well as various other application code, a shell, etc., so I am familiar with how to make C++ code small, and that is one of the reasons I love templates.
However if you want more user friendly compiler error messages, that's another matter. A lot of work has gone into "compile time asserts", to catch as many problems as possible at compile time and give more intuitive errorts (in this case you got an error, but consider the problems if the classes supported the operators you needed but made them do something entirely different).
Instead of deriving, you could for instance check for an enum "supports_someinterface" in the types using a standard assert.
This allow you to use "assert(Foo::supports_interface_Bar);" in the functions that have specific requirements. Note that the value of the enum is irelevant as long as it's non-null, and since the enum is a constant value known at compile time, there should be no runtime overhead (neither space nor performance) of the assert at all if your compiler is reasonably smart.
With GCC, this gives me the reasonably friendly error message: "'supports_interface_Bar' is not a member of type `Foo'" instead of (or rather, in addition to) some hopelessly cryptic error message if I try to instantiate a template with the above assert on a type that doesn't have the enum.
Of course, you might not have the luxury of changing all types you might want to use with your template, and some of them may already fulfill the requirements even if they don't contain the enum.
Fear not, that's what traits are for. Declare a template. Specialize the template for any type that supports your interface, and instead of "assert(Foo:supports_interface_Bar)", you might do "assert(Supports<Foo>::interface_Bar)" or "assert(Supports<Foo>::requirement_HasOutputOperat or)".
Strategically placing these at the top of your functions also serve to document the requirements.
Ok, so I saved the simplest option for your case until last (the above is better suited for complex requirements, not something as simple as "this templates needs member functions A,B and C to be implemented) :
assert(&Foo::operator<<)
With GCC, this produces the error message "`operator<<' is not a member of type `A'" if the operator isn't supported. Place asserts covering all the member functions you need at the head of your function and you both have documentation and reasonable error messages.
The above should have no runtime cost at all provided that the compiler at compile time is willing to guarantee that Foo::operator<< will never occupy address 0. However, don't assume your C++ compiler that smart (GCC 2.96 doesn't appear to be, I haven't checked any newer versions), so one improvement: "assert(sizeof(&Foo::operator<<))". sizeof is evaluated at compiletime, resulting in a constant that in this case must be non-null, meaning the assert will neven trigger, meaning the compiler will discard the code (this was enough to make GCC optimize the thing away).
This leaves us with this nice little macro (who I'm sure someone will find a nasty problem with :-):
#define REQUIRE_MEMBER(expr__) assert(sizeof(&(expr__)))
Which can be used like this:
REQUIRE_MEMBER(Foo::operator<<);
Hot tip: sizeof() is extremely versatile for compile time testing whenever you can reduce the problem to either making code illegal in one case or return a constant expression (which is needed to apply sizeof to it), or when you an reduce a problem into a constant expression that will be a different size (that you can compare with a known quantity) depending on the outcome.
The book being reviewed contains at least one good example of this.
You're also being left behind in the dust. Modern C++ is all about exploiting templates to simplify development, and even reduce code bloat (by making it easier to reuse common code) and increase performance (through automatic compile time generation of heavily inlined versions of algorithms).
If you make a huge template with lots of code that could be easily generalized for all types, then you're writing a bad template: You should factor all common code into a base class and make a template that contain the few parts of the code that are type specific. On the other hand, if your code can't easily be generalized for the types you need, templates save you the tedious and error prone task of maintaining multiple versions of your code specialized for multiple types.
In that respect templates dramatically reduce the amount of work you need to do, if applied properly.
As mentioned above, template techniques can dramatically improve performance over a generic algorithm by providing you with an automated way of generating heavily optimized inlined versions of an algorithm. The C++ template syntax is not really ideal for this, but the benefits from using templates for this are tremendous enough to make it worthwhile. Do a search for Vandevoorde's work on expression templates, or for Alexander Alexandrescu on Google to find more, or read Alexandrescu's articles in CUJ.
Continue to believe your prejudices if you want, but consider that if you can't use or write templates you've essentially shut yourself out of a huge segment of the C++ development job market. I would certainly never hire a "C++ developer" that don't at the very least have thorough experience with the STL, and preferrably understand how to write (and when to write) templates.
For one it would dramatically simplify colonization of Mars: You wouldn't have to bring huge quantities of your own water, and you'll have hydrogen readily available for fuel (for return flights). Both dramatically reduce the mass you'd need to transport to Mars to set up and maintain a colony.
But I'd be careful about talking about black holes as if we know for sure how they behave - after all we haven't exactly observed any up close, and most of the theories related to black holes are based on finding something that fit nicely with other current theories. It's not that long ago since black holes were considered pure unsubstantiated conjecture, and our understanding of black holes might suddenly change dramatically tomorrow.
Fact is, we don't know what goes on inside a black hole, and we don't know how to find out and be able to report anything meaningless back. Some guesses, theories and ideas are more likely to be right, sure.
But you're answering the wrong question: You're answering the question of how this fits in to current theories about what is going on inside a black hole, while the real question is whether or not the concept outlined could fit in with the existing observed behaviour of the universe.
You're probably right that the idea wouldn't fit in with current theories, but are there observations that would directly contradict this idea?
But in other words, you're probably right that being around at the time the even horizon formed wouldn't be a good idea. On the other hand it is an interesting question whether it would be possible that conditions inside a singularity as seen from the inside could allow something like our universe to form. And if not, then why not?
In other words, given the two statements that were given as an example, without resorting to knowledge about the respective toolkits or their documentation you have little, if any, basis for saying anything more about the likely behaviour of the C++ version than the C version.
If you don't like GTK because of documentation, fine, but then say that right away instead of pretending that the fact that QT is C++ by default give developers more knowledge about how it works - that's the kind of attitude that make developers get burned when they run into a system that doesn't fit their assumptions.
I do about 95% of my work in C++, but I certainly don't see C++ classes as any inherently better than C based object systems - as long as the design is clean a C based class hierarchy can be just as easy to use as a C++ one. In fact, implementing your own object oriented system in C give you freedom to make a lot of design choices that are really hard to achieve using C++ classes, For example, one of my hobby projects at the moment is a system for composing classes and aspects programmatically, to give a more generalized object oriented system that doesn't need inheritance and offer more generic polymorphism, and where you can add features to a class at runtime. Doing what that system does using C++ classes would require many times the amount of code (of course you could do it the "C way" in C++, but then what would be the point?)
Doing preemtive multitasking on the C64 via interrupts should be feasible, though, as the interrupt handler is responsible for storing registers and flags, as far as I can remember, and it could just as well run a scheduler and restore registers belonging to a different thread before exiting. Of course it's about 11-12 years since I last seriously used a C64, so I might be forgetting something obvious... :)