One of the best examples perhaps is the STL vector class, which has three implementations. An implementation for a vector of booleans (made specifically to save space), a vector for any type of pointer, and then the generic vector class that covers anything else. Templates have some powerful features.
The standard only suggests a specialization for std::vector<bool> and this is now seen by most of the standardization committee as a poor decision.
But you're right: The possibility for an implementation to transparently partially specialize the pointer case (and other cases) is very useful.
(I'm the first author of the book, and one of the 3 engineers who implemented the "export" feature.)
The feature is certainly difficult to implement. I think the lack of support was primarily due to the "unknown" factors: "How expensive is it to implement?", "Can it be done at all?" and "Will users care?" So far, we have only proved that it can be done and that for EDG it was fairly expensive to do.
I've changed my mind a few times on this topic. In an original draft of the book, there was a long discussion that strongly suggested staying away from "export." However, the more I tried to support that suggestion with examples, the more I found that realistic examples worked very nicely with export, and only truly hideous examples did not (which can hardly be blamed on "export"). As a consequence I started thinking about ways to improve the EDG implementation, and I now think that export could bring to the programmer what many expected it would: Faster build times and "templates in binary form."
The front end is certainly the biggest part of our C++ product. It generates an intermerdiate representation that gives you all the info about a C++ (or C) program. We also provide a module that "lowers" the C++-specific constructs to C-equivalent constructs (though you can opt not to lower e.g. exception handling). Two other modules generate C or C++ from the intermediate representation; we can them the C-generating and C++-generating back ends. (The ability to generate C++ is used by various source-to-source tool vendors.)
Slashdot Mirror
Darn. And I thought that hiding under a Belgian surname was a good idea. -YKH
The standard only suggests a specialization for std::vector<bool> and this is now seen by most of the standardization committee as a poor decision.
But you're right: The possibility for an implementation to transparently partially specialize the pointer case (and other cases) is very useful.
(I'm the first author of the book, and one of the 3 engineers who implemented the "export" feature.) The feature is certainly difficult to implement. I think the lack of support was primarily due to the "unknown" factors: "How expensive is it to implement?", "Can it be done at all?" and "Will users care?" So far, we have only proved that it can be done and that for EDG it was fairly expensive to do. I've changed my mind a few times on this topic. In an original draft of the book, there was a long discussion that strongly suggested staying away from "export." However, the more I tried to support that suggestion with examples, the more I found that realistic examples worked very nicely with export, and only truly hideous examples did not (which can hardly be blamed on "export"). As a consequence I started thinking about ways to improve the EDG implementation, and I now think that export could bring to the programmer what many expected it would: Faster build times and "templates in binary form."
The front end is certainly the biggest part of our C++ product. It generates an intermerdiate representation that gives you all the info about a C++ (or C) program. We also provide a module that "lowers" the C++-specific constructs to C-equivalent constructs (though you can opt not to lower e.g. exception handling). Two other modules generate C or C++ from the intermediate representation; we can them the C-generating and C++-generating back ends. (The ability to generate C++ is used by various source-to-source tool vendors.)
Because it's insanely hard to implement ;-)
(I work for EDG)
Our front end (EDG) also implements all of C99 (it has for over a year). I believe Dinkumware has a matching library.