www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Inconsistency of .mangleof?

reply Ary Borenszweig <ary esperanto.org.ar> writes:
Hi all,

Object.mangleof == "C6Object"
Interface.mangleof == "S6object9Interface"

Both are defined in the module object.d

Why Object.mangleof isn't "C6object6Object"? It also happens with 
ClassInfo ("C9ClassInfo").

I'm currently using mangled representations of types to store references 
to other types in Descent, while at the same time respecting the D spec. 
Then I search for a symbol in the hierarchy by parsing the mangled name. 
But because of the inconsistency of "C6Object" I'll have to hardcode 
that value means "Object in module object". Same as for other types in 
module object (in other, user defined modules it doesn't happen).

Is there any reason for this?

Thanks,
Ary
Dec 24 2007
parent Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:
Ary Borenszweig wrote:
 Object.mangleof == "C6Object"
 Interface.mangleof == "S6object9Interface"
 
 Both are defined in the module object.d
 
 Why Object.mangleof isn't "C6object6Object"? It also happens with 
 ClassInfo ("C9ClassInfo").
 
 I'm currently using mangled representations of types to store references 
 to other types in Descent, while at the same time respecting the D spec. 
 Then I search for a symbol in the hierarchy by parsing the mangled name. 
 But because of the inconsistency of "C6Object" I'll have to hardcode 
 that value means "Object in module object". Same as for other types in 
 module object (in other, user defined modules it doesn't happen).
 
 Is there any reason for this?
I always assumed it was so those classes don't need to be directly in object.d, allowing them to be in publicly imported modules instead, without breaking linking. This way, references to stuff belonging to these classes may be emitted without checking to see what module they're actually in. IIRC the same happens for std/typeinfo/*.d, by the way.
Dec 25 2007