[lug] C++ question, without buying expensive doc.s

Tkil tkil at scrye.com
Tue Jan 11 15:50:59 MST 2005


>>>>> "Paul" == Paul E Condon <pecondon at mesanetworks.net> writes:

Paul> Serialize/deserialize really needs a linkage (_not_ in the
Paul> compiler technical sense) from an object back to its text name,
Paul> otherwise such linkage must be hand crafted for each individual
Paul> object that is to be serialized.

At least at runtime, this capability is usually called "introspection"
or "reflection".

>>>>> "Tkil" == Tkil  <tkil at scrye.com> writes:

Tkil> I wonder what Tom Tromey has to say about [automagic
Tkil> serialization in C++, involving ganking object/function names
Tkil> out of preprocessor macrs]...

>>>>> "Tom" == Tom Tromey <tromey at redhat.com> writes:

Tom> I was called, but I'm afraid I don't have much useful to say.

You came to mind because you're a GCC hacker, and because you've done
so much work on gjc -- I figured that you would have hit quite a few
of the bumps on this road.  (That is, it seems that the intersection
of "Java requires serialization support" and "compiling Java to native
machine code" would have brought some of these monsters to light...)

Tom> I've heard of folks doing serialization by reading debug info
Tom> describing their structures, then generating code from that.

That's pretty brutal.

Tom> GCC itself does some serializing to implement precompiled headers
Tom> and its garbage collector.  This involves annotating the sources
Tom> with a special macro (look for "GTY") and then having another
Tom> program that scans the sources and generates code to mark
Tom> structures and the like.

This sounds like the one system I dealt with briefly: POET.  You
marked up your class in a certain way, then pre-processed it with the
POET tools before feeding it into your real compiler.

Too much behind-my-back shenanigans for my taste -- if I want that
much machinery these days, I'd just switch over to Java anyway.

Tom> I suppose if I had to do this these days, I would try to modify
Tom> g++ to generate the information I needed.  There's been a little
Tom> talk about this on the GCC list lately.

Hm.  Don't remember seeing it, but I haven't been paying all that much
attention to the lists lately.  Will scan for it again.

Tom> BTW, fun trick: in the old days folks used to find the list of
Tom> symbols that a compiler predefined by using "strings" on the
Tom> executable, then transforming the result into something like:

Tom>     #ifdef foo
Tom>       printf("foo\n");
Tom>     #endif

Tom> Then you compile this with the compiler and it will tell you what
Tom> the compiler defined.

The phrase "sick little monkey!" comes to mind.  And then my own
monkey brain comes up with questions about what happens with the
various "personality" flags in a compiler like gcc ("-std=c99", etc).

Thanks for the ideas,
t.




More information about the LUG mailing list