Re: [boost] [fusion] [intro] ADAPT_STRUCT extensions

Subject: Re: [boost] [fusion] [intro] ADAPT_STRUCT extensions
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-08-12 07:32:35

Zitat von David Sankel <camior_at_[hidden]>:

> 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