Home

Templates vs. Generics

Bruce Eckel gives his take on C++ Templates vs. Java Generics, using the example of an apply() function that will apply any method to every object in a sequence:

What I found in modifying this example and translating it to Java was surprising. As far as generics go, it does in fact support my thesis that erasure emasculates generics. What is surprising is that ... the Java code is small and elegant, and far less verbose than the C++ code,... Alas, generics had nothing to do with this succinctness – it was actually reflection and varargs that were responsible. And so the power of reflection continues to be one of the most interesting features of Java, even though its runtime uncertainty is at odds with the Java Generics goal of eliminating ClassCastExceptions.
I figure the goal is for the compiler to proof the type correctness, but he's right in that RTTI is at odd with that goal.
(Also of interest, is the link to the Java Generics FAQ).


[Edit Note: The URLs should be working again]

By Chris Rathman at 2004-10-06 00:38 | General | other blogs | 13183 reads

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

That link appears to be missi

That link appears to be missing the URL.

By Doug Orleans at Wed, 2004-10-06 03:43 | login or register to post comments

Seems to have disappeared.

Fixed the URL, but gives an error for the page in question. I'll try to fix the link when, and if, it gets fixed on the site.

By Chris Rathman at Wed, 2004-10-06 04:04 | login or register to post comments

Other articles

Until it comes back, the previous four entries are a good warm-up:

By Dan Winship at Wed, 2004-10-06 13:36 | login or register to post comments

Forward and Backward Compatibility

From Puzziling Through Erasure II:

'I checked this out with Anders Hejlsberg (the lead designer of C#) and he said:



'".NET is backwards compatible in the sense that older .NET applications and libraries continue to function on newer releases of the .NET Framework. To me, this is the essential meaning of backwards compatible.

'"[Later] ... there is no need to recompile .NET 1.0 (or 1.1) libraries in order to run them on .NET 2.0. The old binaries continue to work."'



I thought that this was forward compatibility: old object (well byte) code will run on new systems (JVM/CLR). Backward compatibility is when new object (/byte) code will run on old systems (JVM/CLR). Sun have aimed at preserving both of these (and it is reported that they have succeeded - I havn't checked). Microsoft appear to have abandoned backward compatibility (hence the version 2.0 .NET CLR ie broken compatibility, whereas Sun have stuch with 1.5, but confusingly called it 5) in order to add generics. .NET v2 byte codes will not run on CLR v1 systems (no backward compatibility - move the code backward a runtime version). .NET v1 byte codes will run on CLR v2 (forward compatibility - move the code forward a runtime version).

At the source-level the language extensions for generics are not compilable under old versions, so both Java Generics and .NET generics break source backward compatibility (but both retain forward source compatibility - pre-generic code will continue to compile on the new compilers).

Am I right in saying that this is the usual terminology and that Eckel and/or Anders Hejlsberg have confused backward vs. forward?

By Alex Tibbles at Thu, 2004-10-07 10:00 | login or register to post comments

Nanoo-nanoo.

I think you have it, er, backwards. For example, Windows 98 was backwards-compatible with DOS since it ran DOS programs (well, mostly).

This jibes with FOLDOC's definition.

Maybe you can reverse the sense by exchanging the role of "program"/"file format"/"input"/whatever and "system"/"environment"/whatever2. That is, perhaps it is sensible to say "Windows 98 is backwards-compatible with DOS if and only if DOS programs are forwards-compatible with Windows programs." But the FOLDOC definition specifically refers to the system and not the inputs, so I guess that would be a generalization.

By Frank Atanassow at Thu, 2004-10-07 10:41 | login or register to post comments

Continuations subtype contravariantly?

"Windows 98 is backwards-compatible with DOS if and only if DOS programs are forwards-compatible with Windows programs."

Somehow reminds of subtyping rules for functions, which are covariant in the result type and contravariant in the argument type. Or, better yet, we can say that "system"s are (isomorphic to? :) ) typed continuations, and as such subtype contravariantly.

By Andris Birkmanis at Sat, 2004-10-09 06:52 | login or register to post comments