3 ms·

Thanks to Comeau C++'s standard compliance, you can put the template into the .cc files. ;)

KMag 14y ago
I think the complaint is more about the C++ compiler needing to expand the template every place it's used, as opposed to Java/C# generics and OCaml functors (functions taking modules as arguments and returning modules as values) which necessitate a pointer indirection at runtime (which a VM/JIT/smart linker may or may not be sophisticated enough to optimize away) but allow the call site to be ignorant of the implementation details at compile time. There are workarounds in C++, but they're less elegant. Arguably, the decision to keep using the C linker and use name mangling and template expansion in the compiler instead of making the linker smarter (or adding a phase between compilation/assembly and linking) was a mistake. Some kind of object file pre-processor that performed name mangling and template expansion on object files probably would have still been necessary, at least in the early years. Certainly incremental compilation and linking would be easier if template expansion were performed on object code (or a low-level intermediate representation) rather than source code.
- cbsmith 14y ago
  Actually, C#'s generics don't require a pointer indirection. It works almost like a hybrid between C++'s templates and Java's Generics.
- cbsmith 14y ago
  > Arguably, the decision to keep using the C linker and use name mangling and template expansion in the compiler instead of making the linker smarter (or adding a phase between compilation/assembly and linking) was a mistake. I don't know that it was a mistake per se, but this problem with template compilation overhead is definitely a seemingly inevitable consequence. > Certainly incremental compilation and linking would be easier if template expansion were performed on object code (or a low-level intermediate representation) rather than source code. This is effectively what happens... it just happens at compile time instead of link time. Given this template: <bar.hpp> template <typename foo> foo bar(foo x) { return foo; } a compiler is asked to compile: #include <bar.hpp> //source code is parsed and intermediate representation generated by the compiler int x = bar(some_int); //performs template expansion on said object code float y = bar(some_y); //performs template expansion on said object code //bar.hpp's source is examined only once! This is why you can't do some things in templates that you can do with say, C macros (and vice-versa).
shawn-butler 14y ago
I think Sun's compiler also was compliant.
cbsmith 14y ago
Even the EDG guys who wrote that support for the export keyword feel like it was a really, really bad thing: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n142...
- cpeterso 14y ago
  The template export feature was removed in C++11 (though the keyword itself is still reserved for potential future use).

KMag 14y ago

I think the complaint is more about the C++ compiler needing to expand the template every place it's used, as opposed to Java/C# generics and OCaml functors (functions taking modules as arguments and returning modules as values) which necessitate a pointer indirection at runtime (which a VM/JIT/smart linker may or may not be sophisticated enough to optimize away) but allow the call site to be ignorant of the implementation details at compile time. There are workarounds in C++, but they're less elegant. Arguably, the decision to keep using the C linker and use name mangling and template expansion in the compiler instead of making the linker smarter (or adding a phase between compilation/assembly and linking) was a mistake. Some kind of object file pre-processor that performed name mangling and template expansion on object files probably would have still been necessary, at least in the early years. Certainly incremental compilation and linking would be easier if template expansion were performed on object code (or a low-level intermediate representation) rather than source code.

cbsmith 14y ago
Actually, C#'s generics don't require a pointer indirection. It works almost like a hybrid between C++'s templates and Java's Generics.
cbsmith 14y ago
> Arguably, the decision to keep using the C linker and use name mangling and template expansion in the compiler instead of making the linker smarter (or adding a phase between compilation/assembly and linking) was a mistake. I don't know that it was a mistake per se, but this problem with template compilation overhead is definitely a seemingly inevitable consequence. > Certainly incremental compilation and linking would be easier if template expansion were performed on object code (or a low-level intermediate representation) rather than source code. This is effectively what happens... it just happens at compile time instead of link time. Given this template: <bar.hpp> template <typename foo> foo bar(foo x) { return foo; } a compiler is asked to compile: #include <bar.hpp> //source code is parsed and intermediate representation generated by the compiler int x = bar(some_int); //performs template expansion on said object code float y = bar(some_y); //performs template expansion on said object code //bar.hpp's source is examined only once! This is why you can't do some things in templates that you can do with say, C macros (and vice-versa).

shawn-butler 14y ago

I think Sun's compiler also was compliant.

cbsmith 14y ago

Even the EDG guys who wrote that support for the export keyword feel like it was a really, really bad thing: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n1426.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2003/n142...

cpeterso 14y ago
The template export feature was removed in C++11 (though the keyword itself is still reserved for potential future use).