Zitat von David Sankel <camior@gmail.com>:
I think the ADAPT_CLASS macros fundamentally change the expected behavior of struct adaptation in a negative way. A non-template class/struct is a collection of
a) types (declared as nested typedefs or other structs) b) values of the following variety i) static member variables (values that are non-functions) ii) static member functions (values that are functions) iii) member functions (values that are "special" functions over the instance record) c) an instance record, which includes member variables
Up until this point, struct adaptation has exclusively been over the instance record, point c) above. This is very simple to understand and implies exactly one canonical adaptation for every struct/class.
ADAPT_CLASS mixes point c) and point iii) in an arbitrary way.
although I wouldn't say ADAPT_CLASS should be removed as I don't know its use cases (supposedly it is used in Boost.Spirit?) I agree that there are significant differences between ADAPT_CLASS and _STRUCT that aren't clear from their names. for my use case (SYB) I have to document the rather confusing fact that _classes_ must be adapted with ADAPT_STRUCT, and while ADAPT_CLASS might seem to work at first, classes (or structs) must NOT be adapted using ADAPT_CLASS. the reason for that is that the "reference type" of ADAPT_CLASS sequences iterator is a proxy object, instead of a reference to the value. on 2 different notes, related to ADAPT_*: - although christopher understandably wasn't enthusiastic about adding new macros, we've agreed to a way to implement "derived" adapt macros. suggested interface: ADAPT_SUBCLASS/ADAPT_SUBSTRUCT, including all variants like NAMED, ASSOC, AS_VIEW - the ASSOC variants are documented to adapt an associative sequence. which they do according to the fusion concepts, but it does seem rather strange to me that the keys are not part of the value type of the sequence. for example: struct A{ int a; struct a_key; }; FUSION_ADAPT_ASSOC_STRUCT(A, (int,a,A::a_key)) void f(fusion::pair<A::a_key,int> p){ ... } fusion::for_each(A(),bind(f,_1)); error: the value type of the first element is "int", not a pair <a_key,int>. although this seems to be in perfect compliance with the Fusion associative sequence concept, is there any other associative sequence like that? fusion::map does have a fusion::pair<> value type. iterating a ADAPT_ASSOC_STRUCT sequence with its keys is a big hassle, probably using fusion::iter_fold and accessing the keys from the associative iterator. -Stefan