Boost logo

Boost :

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

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;


void f(fusion::pair<A::a_key,int> p){ ... }


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.


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