On 21/12/2009 22:41, Kevin Bealer wrote:
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
a few points:
Java generics are poorly designed and create holes in the type system.
Some of the designers of the language admit this openly. This
implementation doesn't represent the general concept.
your performance / impl-hiding conflict doesn't exist. I already
mentioned in a previous post how the C# compiler handles generics. Also
you assume the same (broken) compilation model as in C++. don't.
