Ah... different interpretations of the same terms... everyone's faviourite conflict generator raises its head againmystran wrote: Let me first make it clear that I was completely ignoring all implementation issues, and as such I didn't quite realize that if someone WOULD consider implementation, then some of my choices for terms might have meaning, and a mess would result. Sorry about that.
In that case, I also apologise, for I should've tried to look for potential misunderstandings as well.
They're not equivalently type-checkable if we also allow value parameters to types (recall that type checking in this case can be reduced to the halting problem). So let's restrict templates to type parameters beforehand. In this case, as I've tried to outline in my last mail, there is still the significant difference that Java's (so-called F-bounded) polymorphism allows type parameters to be constrained by a given type; C++ does not allow this (and, instead, uses implicit constraints which solely depend on whichever methods you may happen to wind up calling).mystran wrote: But you notice that C++ templates and Java generics are equivalent in terms of compile-time checkability. Only when we consider separate compilation (which is overrated anyway) are they different (in terms of compile-time chekability, that is).
This means that in C++ you produce a type error here if your actual type parameter doesn't meet the requirements of the formal type parameter if and only if some method you happen to call winds up using a method not defined on this type, whereas in Java you produce a type error at the point where you pass the type parameter if you do not meet the requirements of the parametric type. So, first of all, Java constraints are placed explicitly "up-front", whereas C++'s constraints are implicit. Second, Java constraints are checked at formal-type-parameter-passing time (analogously to Haskell and its type classes, by the way), whereas C++'s constraints are checked at method invocation time.
I would like to point out here that Java's approach has one significant software engineering benefit: If you know the requirements up front, you can verify not only that you export the neccessary methods, but also that they exhibit the desired semantics (for example, a common requirement is that the "+" operator should be associative for anyone defining it, but C++ does not-- and could not if it wanted to-- enforce this property): The library designer is forced to specify an interface that lists all methods (and hopefully defines their properties, though this cannot be checked) in Java, for otherwise the library will not compile, whereas in C++ it can't be compiled up front anyway, so the library designer can get away (even by accident) with using methods on the parametric types which haven't been specified in whichever documentation he may have elected to write.
On a final note, I disagree about separate compilation being overrated-- I rather appreciate not having to recompile my libc every time I compile my own piece of code, and would appreciate it if this property would extend to all other libraries I wind up using. Compilation is supposed to be approximately linear in the size of the program; without separate compilation, you have to include (for each unit of compilation) potentially all information from the other units of compilation, making compilation time quadratic on the size of the program. Considering that there seems to be little benefit in doing this as default behaviour (as opposed to, perhaps, a final optimising-by-cross-module-inlining stage (or whole-program optimisation, as in MLton) before shipping the resulting program), as most compiles tend to be for type checking and testing in the end, I personally don't see why this would make sense. Recall that most other languages seem to get away with modular compiling.
on RTTI:
For what Microsoft called "Managed C++", yes. Full C++ has too many ugly features to admit proper gc, unfortunately (though there are conservative approximations to this which, however, are neither completely safe for the full language nor particularly efficient).mystran wrote: You might want that for GC though.
[...to be continued...]
