Boost logo

Boost :

From: Chuck Messenger (chuckm_at_[hidden])
Date: 2003-05-26 13:20:53

Scott Woods wrote:
>>* use an XML schema, but some schema information, perhaps in another
>> file, support C++ specific issues (e.g. does the data go into a list
>> or a vector?)
> Where the variant contains a something "with internal structure" (e.g. an
> array, vector or record) it is currently using a std::vector. Give the user
> (author of schema) control over underlying container? If this is what you
> meant then its interesting.

Right -- that's what I meant -- ability to specify the type of the
receiving container.

> So, potential benefits [of native byte order] seem small vs added complexity.

It's not a "needed" feature -- a future enhancement, perhaps.

>>* support for "integrated header files" -- that is, rather than
>> generating a C++ header, it should be possible to use an existing one
>> (allowing you to customize it).
> Considered. Possibly hiding from the nasty of parsing a C++ header ;-)

You might look at the Boost Spirit lib -- I thought I saw some code to
parse C++. Still a hairy problem, of course...

>>* support for complex data structures, including recursive structures.
>> It should be possible to re-establish pointers, in other words.
> Currently supports arbitraily complex structures;
> sensor_signal log[][ 2 ]
> log could be described as a "vector of pairs of sensor_signals". Think I put
> my "toe-in-the-water" as far as pointers goes - another "nasty" if I follow
> your suggestion properly. Generally this is moving into an area that is
> covered by OODBs and relational DBs. My simplification of what (I think)
> you want would be some kind of "persistent object id"? Worked with

Each pointed-to object would be associated with a unique ID. Pointers
to that object would then be represented by that ID. Perhaps it would
only work with Boost smart pointers.

     - Chuck

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