Title: Epilogue

Author: 

Date: 30 April 1993 11:49:00 +01:00 or Fri, 30 April 1993 11:49:00 +01:00

Summary: 

Body: 

Well, that's it for this edition of Overload. I hope you enjoyed reading it, and hopefully gleaned some knowledge from it. If there are any features that you do not like, please let me know. I do want to tailor the magazine to members' requirements (though it will not be possible to please all of the people all of the time...).

Recently, I was fortunate enough to hear an excellent discourse on Bjarne Stroustrup's Name Space proposal, given by Francis Glassborow. In the next edition of Overload, I would like to present some of the ideas in the Name Space proposal, together with a discussion of RTTI (Run Time Type Identification), another proposed extension to the C++ language. As a prelude to the Name Space article, I feel I must say a few words on name-mangling, as the under­standing of name-mangling can aid the understanding of Name Space Management and the problems that it needs to address.

The name-mangling discussed here is based on Borland's implementation of C++. The authoritative reference for this subject is Borland's Open Architecture Handbook.

So what is name-mangling? The compiler has the problem that it must produce unique names for all data and func­tions so that the linker can resolve all links. This is not a problem in the C language as there is no overloading and no polymorphism. In C++, however, the linker has the problem of resolving multiply-overloaded member functions on the basis of not only the function name, but also the argument list.

We also have the situation where the same function name may appear in many classes or even many times within a single class, in addition to any virtual functions in derived classes.

If this were left to the linker, it would create massive headaches as the linker requires unique names. This is solved by mangling the names of functions and classes so that the linker is able to successfully resolve any ambiguities.

The resulting encoded (mangled) names take on one of four forms:

1. @classname@memberfunctionname$argumentlist
2. @functionname$argumentlist
3. @classname@staticdataname
4. @classname@

The first three should be self-explanatory; the last one is used to handle the virtual table for the class in question. The $argumentlist is composed of a series of codes to specify each of the argument types and their order in the argu­ment list. This should the have the effect that all callable units can be uniquely identified.

This does get a little more complicated for templates where values and parameterised types become involved, but this has been resolved by indicating a template with a % symbol instead of a @.

Where the system does fall down is in the situation where two class libraries are used and at some point they use the same function/member function name and argument list. Even though the libraries have come from differing sources, the linker will see the first one as the right one (How many class libs are based on Object?). This is where namespaces would solve the problem. How? Read the next edition of Overload and find out what's been proposed.

Notes: 

More fields may be available via dynamicdata ..