Date: 2002-12-18 10:53:25
On Wed, 18 Dec 2002, William E. Kempf wrote:
> > I don't know if there's a
> > policy about library submissions depending on closed-source tools. I
> > don't think there should be a problem (after all, most compilers Boost
> > supports are closed-source), but it seems prudent to ask up-front.
> I'm confused. Above you said it was open-source, now you talk about it
> being closed-source?
Sorry for not being very clear. The EDG front-end is closed source: it's
used to generate IL, which is then parsed by (I believe) closed-source IL
transformation tools (I think EDG considers their IL format a trade
secret), to human-readable PDB files. From there, everything is
open-source. Since all the binaries are freely redistributable, as is the
source (where it is provided), in my estimation the toolkit as a whole
meets the Boost license requirements. But I'm not sure if my opinion is
the one that counts. ;-)
> > Finally, is there anyone interested in working on a reflection
> > framework? Does anyone have other ideas on approaching this problem? Any
> > comments at all? I'll consolidate the information and put them up on the
> > Wiki board.
> I'm very interested in having a reflection library available, but I can't
> afford any time to helping with the work, sorry. However, I'd suggest you
> take into consideration XTI, which is an idea for reflection in C++ from
> Bjarne Stroustrup (there's several links to this on the web, one of which
> is http://www.klid.dk/arrangementer/XTI_kbh.pdf, do a Google search for
> the others). I think his work on it has stagnated, at least from some
> things I've heard from others, which is unfortunate. But I think his work
> would be a great place to start from for a Boost reflection framework.
I'm definitely looking into this. After educating myself, I was planning
on contacting BS about the current status of his project. If anyone
happens to know more information, or is in a position to find out more,
please do so and/or let me know. TIA.
> > Were talking exclusively about reflection now... I don't want this
> > muddled with the serialization discussion. They are separate topics. :-)
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk