eyt*
Aug 17, 2004

The C++ Export Keyword...

In the InformIT C++ Newsletter, Danny Kalev discusses the export keyword. As Danny points out, not a lot of developers know this keyword, mostly because up until last year, it was not implemented. Comeau C++ is the only compiler to date to support it.

The article provides a good introduction to the keyword and how it works, however, I disagree with his conclusion. Danny concludes that since no one has implemented this feature and that developers want to see compilation errors early, that it is a doomed feature that failed. Most compiler vendors have not implemented this feature because most compiler vendors have not implemented the entire C++ ISO Standard; the last time I checked, Visual C++ 7.1 (2003) was the compiler that implemented the most, at 98%, and definitely a language feature that is widely used has more precedence over a language feature that no other compiler supports; its the nature of business.

Anyone that has worked with explicit template instantiation knows what it is to have link-time errors with templates. By default, most compilers default to implicit template instantiation, which means that when it sees you use a template, it instantiates that template immediately, and the linker does its best at sorting it all out. This generally leads to some code-bloat, since the compiler will instantiate more than is really required, and the linker does not remove enough.

Explicit template instantiations is meant to resolve this issue, by making the developer explicit state which templates should be instantiated. This generally leads to a file per project that explicitly instantiates only the required template functions that are required to link. Of course, when you forget one to instantiate one, you will get some error messages during link-time, or runtime with DSO's, and this usually takes a few times of going back and forth like this until everything is resolved. This especially makes people who did not like templates before to especially despise them after doing this a few times :-).

One advantage that was not mentioned of the export keyword is that since templates are presently implemented in header files, any change to the template requires a total rebuild of the the users of this. Some coding standards require that the interface and implementation be separated, using file.h to denote a header and a file.imp.h to denote an implementation. Using this standard, if a class references a template class, they only include the former, whereas if the class actually uses the implementation, the latter file is included, but never in an interface file (i.e.: only in the .cpp). This isolates such changes to only the need to recompile the true users of the template, but even still, if the change in the template is minor, there is no true reason to recompile all the users of the template. The export keyword would allow this to happen and solve all the aforementioned instantiation issues.

Of course, the tools are getting better at supporting templates, and I still think that the best is still to come. If you forget all the comparisons of the power of C++ templates verses the Java Generics for a moment and only consider the approach that Java has taken, the export keyword could be similarly implemented in C++. In Java, a generic module is compiled into a class object that is essentially incomplete, and when a reference to that generic module is made, the Java Runtime molds everything together.

A method similar to this could be done in C++, and given all the research that has gone into finding this solution for Java, I am sure that there is an even better, more transparent solution for C++ vendors. It is just a matter of time.

Filed In

Navigation

eyt*