Boost logo

Boost :

From: remi.chateauneu_at_[hidden]
Date: 2007-05-13 17:06:26

Larry Evans a écrit :
> On 05/12/2007 04:23 PM, remi.chateauneu_at_[hidden] wrote:
> [snip]
>> I do not know enough of this great library 'Fusion' to make a serious
>> analysis, and BOOST_FUSION_ADAPT_STRUCT seems very close to what I did,
> FWIW, I found the following two links useful for comparison:
> For crd, see lines 29-42 of:
> For fusion, see lines 39-43 of:
Yes, crd's representation is heavier, although preprocessor macros could
easily lighten it (but this is not the point I guess). Crd is a very
modest library compared to Fusion and simply tries to focus on the needs
I presented. Although it is very probably possible to do that with
Fusion, crd is modelled after the need of some business applications to
have an all-purpose definition of classes on which many commonly used
algorithms would be 'plugged' onto. For example, this motivated the
choice to use std::type_info * as unique key for all manipulation of
members lists. This defines, for example, the column names of a table,
with a std::map< const std::type_info *, std::string >.

There are, as well, two specific features I wish to implement:
- Loading classes definition from a compiled object files with debug
information ( Please see this: or what
is returned by readelf), or from shareable libraries. This would target
existing applications which cannot be modified for organisational or
budget reasons.
- Given a dynamic class definition (list of members), creating an object
with these members, but with a blob as underlying storage. The goal is
to be able to manipulate class-like objets, with the same interface as a
real class. ( ... maybe std::map< const std::type_info *, boost::any > ,
with type_info referring a class'member ? ) I agree that the concept is
not quite clear at the moment, but again this is related to
communicating data with software components which cannot be re-compiled
at each modification of a user's class.

Thanks for your attention.

>> although the whole library seems more oriented towards compile-time
>> operations ?
> Well, according to:
> the library is a "fusion" of compile time metaprogramming with runtime
> programming.
> >from the page:
> libs/fusion/doc/html/fusion/preface.html
> it should do both. Of course I realize "seems more oriented towards
> compile-time operations" is a "judgment call". However, it seems
> that the "basic operations" in both crd and fusion is accessing
> the I-th member in a tuple (or struct) and that the specific needs
> you mention below can be implemented using either the fusion
> "basic operations" or the crd "basic operations". If that's true
> (i.e. the "basic operations" are the "basis of comparison") then
> fusion is just as runtime oriented as crd.
>> My specific needs are:
>> - Iterations at run-time on class members, not only at compile-time,
>> because some operations might be difficult to code (Trivial example: Add
>> the latest ')' in a SQL query string). This implies, for example, that
>> manipulation on a list of class members are done with plain STL algorithms.
>> - The possibility to add dynamic attributes for class members, indexed
>> for example by typeid (Column names in a SQL table, or specific format
>> for displaying a given class member), which may change from one object
>> to another of the same class.
>> - The possibility to consider as a plain data member, any method
>> (getter/setter ...) of a class, even if there is no underlying member,
>> or if they are private, and also base classes.
> [snip]
> _______________________________________________
> Unsubscribe & other changes:

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