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
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk