dsimcha Wrote: > == Quote from Yigal Chripun (yigal...@gmail.com)'s article > > but even more frustrating is the fact that > > template compilation bugs will also happen at the client. > > There's a whole range of designs for this and related issues and IMO the > > C++ design is by far the worst of them all. not to mention the fact that > > it isn't an orthogonal design (like many other "features" in c++). I'd > > much prefer a true generics design to be separated from compile-time > > execution of code with e.g. CTFE or AST macros, or other designs. > > Since generics work by basically casting stuff to Object (possibly boxing it) > and > casting back, I wonder if it would be easy to implement generics on top of > templates through a minimal wrapper. The main uses for this would be > executable > bloat (for those that insist that this matters in practice) and allowing > virtual > functions where templates can't be virtual.
In C++ you could define a MyObject and MyRef (smart pointer to Object) types that implement the methods you need (like comparisons) as virtual functions that are either pure or throw exceptions. Then just define a non-template class that inherits from (or just aggregates and wraps) a vector<MyRef> and map<MyReft, MyRef>. Now you can use this map and vector code to build whatever solution you need, using dynamic_cast<T> to insure the types are what you want. If you want you can throw a type safe wrapper that uses dynamic_cast<T> around this, as long as all the methods of that class are inlined, it should have no extra bloat. Now your back at the Java level of expressiveness. I wonder, though, if you actually save anything. Since vector::operator[](size_t) is just an array index that will get inlined into your code, I think it should have much *less* code bloat in your executable than a function call (to virtual MyRef vector<MyRef>::operator[](size_t)) plus dynamic casts to figure out if all the types are castable. Movie Poster: Dr. Stroustrouplove: or How I Stopped Worrying and Learned to Love the Bloat. As for mixing template code and client code, is it that big of a deal in practice? If you are making something big enough to be worth patenting, won't most of the "heavy lifting" classes probably not be templates? Unless you are marketing template/container libraries specifically I guess... Personally I'm reluctant to buy that sort of thing from someone if I *can't* see the source. If I need a class like "vector", in practice I need to be able to dig into its methods to see what they do, e.g. is it really guaranteed that storage is contiguous, etc. On the other hand, if I was buying code to print a Word document to a pdf file, I could accept that I don't need to look into the code. But something like vector<> or map<> ends up getting so "intimate" with the rest of my design that I want to know how it works in detail just as an end-user. (Yeah, yeah, I know encapsulation says I shouldn't have to.) I think performance outweighs the needs of any particular business model, especially when you can do your own Object based version if you need to. I agree there should be ways to hide the implementation from the client, but if templates aren't one of them, then just factor that into where and how you use templates and when you use OO and virtual instead. It's enough that it's possible and practical to hide your impl, you don't need *every* language feature to make that its #1 priority. The performance / impl-hiding conflict is a fundamental problem -- if the user's compiler can't see the template method definitions, then it can't optimize them very well. If it can, then the user can too. Any method of compiling them that preserves enough info for the compiler to work with will probably be pretty easily and cleanly byte-code-decompilable. Kevin
