Boost logo

Boost :

From: William E. Kempf (wekempf_at_[hidden])
Date: 2002-12-19 09:45:31

craigp_at_[hidden] said:
> On Wed, 18 Dec 2002, William E. Kempf wrote:
>> But they *can* be related. I know you can do serialization with out
>> reflection, but I think the serialization capabilities of Java show
>> that reflection can vastly simplify the implementation of a
>> serialization library. (Though with out language support you can't
>> access the private data of an object to make serialization automatic
>> in C++.)
> I agree. OTOH, I think a full-fledged reflection library will be some
> ways off. We could start with a bare-bones system designed to explicitly
> support serialization, but I think it would slow down the adoption of
> the existing serialization effort, and I'd rather not stir up more
> controversy (unless there's a clear benefit to doing so, which I don't
> see). Once a reflection library is more-or-less in place, extending it
> to handle serialization will be relatively straightforward, whether with
> a brand-new design or adapting it to an existing library.

Well, just to voice my own annoying opinion... ;)

I am personally *MUCH* more interested in reflection. I can usually deal
with hard coded serialization with out the advanced factory creators
and/or pointer handling infrastructure. However, I can find uses for
reflection on a daily basis. I realize this is only because of the types
of software I deal with, and that others will have different experiences,
but because of my own experience I'd much rather see reflection. So my
personal priority would be to have a _FULL_ reflection framework before
addressing serialization.

That said, since I don't have time to work on this, I'll have to live with
the priorities that those who do volunteer to work on it want to put in
place. I just hope that if the priorities aren't set in stone yet, that I
can sway some opinions ;).

William E. Kempf

Boost list run by bdawes at, gregod at, cpdaniel at, john at