Boost logo

Boost :

From: craigp_at_[hidden]
Date: 2002-12-17 09:34:20


On Tue, 17 Dec 2002, Robert Ramey wrote:

> A very interesting post.
>
> I also believe it is interesting to consider whether it is valuable
> to make a system of reflection for C++. I'm not sure whether
> it is or not - but it is interesting non the less. In particular we
> would be interested in compile-time reflection as well as
> runtime reflection. I found the links on your subject interesting.

A reflective framework would certainly be valuable to *me*, and I suspect
to a number of other people on this list, whom I've seen express interest.
IMHO, reflection is the best thing about Java, and one that is quite
useful and generally applicable, particularly with serialization and
persistence. I'm not arguing we should implement a serialization engine
via a reflective framework for C++; I think we're in agreement that the
serialization engine is at a much lower layer. A reflective framework
could simply be used to automate [hopefuly transparently] much of the
tedium (eg: read/write methods used by the serialization engine).

Can you elaborate on compile-time reflection? We have the type-traits
library, which may be an example what you have in mind. But this will
always be limited without further compiler support. It would be ideal to
see some kind of typeof operator added to the C++ standard. In the
meantime (which could be a loong time ;-), I'd like a workable reflection
framework. Whether it belongs to Boost is certainly an open question,
however.

A reflective framework could be in three stages: a preprocessing stage
(which creates the reflection data), an optional code
generation/transformation stage, then a compilation stage. In this sense,
it would be both a compile and run-time framework.

> >Second, in terms of Serialization, I'm willing to create a portable,
> >efficient binary archiver based on CDR (the format used by CORBA). Since
> >I'm lazy, I will probably steal most of the code from ACE/TAO
> >(http://www.cs.wustl.edu/~schmidt/ACE.html). Note that CDR has minimal
> >overhead (eg: it has variable byte-ordering, so byte swapping may not be
> >necessary). If there's interest, let me know.
>
> There was much interest in implementing XDR. I believe that initially
> it proceeded rapidly but bogged down because it depended on the
> existence of some code shipped only with unix. Ultimately, implemenation
> of a portable binary stream, requires specific coding for each machine
> architecture. This makes the task larger than it first appears.

ACE has been ported to many platforms. It comes down to a fairly
straightforward, if tedious, refactoring. At bottom, it's only software.
;-)

In any case, I'll wait at least until the serialization interface
solidifies a bit more.

cheers,
--craig


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk