[GCC-XML] Xrtti.h

[Bryan Ischo]

> I was waiting for someone to ask that question, as it took us about a
> week of mind-racking to come up with a solution.  Unfortunately, since
> it's one of the key novel contributions for our work, I can't release
> the details until after the June 4th ASE submission deadline.  I hate
> having to keep certain things a secret, but suffice it to say that when
> we do release it, you'll definitely get an "ah-ha!" moment (after
> spending about an hour trying to figure out what the heck is going on). :)

I'll be very interested in seeing your solution.  I hope you don't mind if
in the meantime I try to figure it out for myself :)

> However, for a temporary solution, why not use the friend keyword?  That
> was our initial idea.  Also, for #5 I know of at least one tool, C++2MPI
> (not based on GCCXML), which does something very similar but slightly
> tweaked due to the way that MPI works.

As to the friend keyword - that would work too.  But it would require that
all classes which are to be serialized have a "friend Serializer;" or some
such statement added to their definition.  Wherever possible, I am trying
to eliminate requirements of the developer in adding special code to their
classes to enable serialization.  Many such techniques require class
definers to put "DECLARE_PROXY" or other strange macros at the front of
their class definitions; that always leaves a bad taste in my mouth so I
try to avoid anything special like that.

My goal really and truly is to make serialization come "for free" for a
developer - just run the serialization-generation tool at build time and
instantly, all of your classes are serializable without any additional
work or special friend declarations or macros in the class definitions. 
It truly saddens me that not every C++ class can be serialized due to the
"how many elements are in the array" problem, because it means that
developers do have to be aware of a couple of caveats when defining their
classes that they intend to be serialized.  But in every case where it is
possible, I try to make serialization come without any extra steps from
the developer.  Hence I avoid "friend" and macro requirements.

It's one of my philosophies of development that it should be priority #1
of each developer to make everyone else's job easy wherever possible.  So
when a new framework or tool is developed, the developer should first
think, how can I write this so that it requires the minimum of explanation
of how to use it?  How can I design this so that its use follows naturally
from the problem that it is attempting so solve, so that it will seem like
the obvious way to do things to the developer who needs this tool?  Of
course you can't sacrifice functionality or correctness to this goal, and
of course not everyone would do things the same way so you can't always
make everything obvious to everyone, but I think it's a good goal to have
nonetheless.

What I think would be awesome is if the C++ language incorporated
serialization into its definition.  My serialization-generation stuff
could work even better *in the compiler* instead of as a secondary
code-generation step.  Maybe someday ...

Here are a couple of fundamental rules that I think would really help the
software development community:

1. No programming language should be defined without a way to serialize
data structures of the language.  Languages typically specify in-memory
(transient) representations of data structurs (ABIs) - why not also
specify on-disk (persistent) representations also?

2. No RFC or "standard" (such as XML) should ever be written without a
complete reference implementation.  An RFC should be rejected until there
is a reference implementation proving its feasability.  If this rule were
followed, it would keep standards from being defined that end up being a
real pain in the butt to implement, because the designer of the standard
would have to "eat their own dog food" and implement the thing, probably
leading to simplifying and streamlining in many cases where the designer
didn't realize the actual complexities of the design.

Anyway, just a couple of things to think about ...

Thanks, and best wishes,
Bryan

------------------------------------------------------------------------
Bryan Ischo                bryan at ischo.com            2001 Mazda 626 GLX
Hamilton, New Zealand      http://www.ischo.com     RedHat Fedora Core 5
------------------------------------------------------------------------