Boost logo

Boost :

Subject: Re: [boost] [fusion] [intro] ADAPT_STRUCT extensions
From: Stefan Strasser (strasser_at_[hidden])
Date: 2010-08-12 15:19:54


Zitat von Christopher Schmidt <mr.chr.schmidt_at_[hidden]>:

>> a) the use of the word CLASS. This is inappropriate since that family of
>> functions applies to a subset of classes and structs that use the getter
>> setter idiom (GSI).
>> b) the GSI is one of many possible idioms. One might also wish to include
>> static member variables in the sequence, for example.
>> c) I don't think GSI should have the same "status" as the STRUCT family
>> since it is one of many possible idioms and one that is particularly bad (I
>> can elaborate on why if someone wants).
>>
>> So, I suppose I would be in support of the CLASS family if it was renamed to
>> GSI and put in a separate header for GSI support functions.
>
> The BOOST_FUSION_ADAPT_xxxCLASSxxx-macros are not exclusively limited to
> getter and setter methods. Any expression that denotes to the given
> lvalue or rvalue types may be used.
>
> float ff;
> struct S{static int T;};
> float& f(S){return ff;}
> BOOST_FUSION_ADAPT_CLASS(
> S,
> (int&,int&,S::T,S::T)(float&,float const&,f(obj),f(obj))
> )
>
> In this regard I like 'CLASS' as it implies a somewhat public interface
> with a black box implementation.

I don't think the fact that ADAPT_CLASS isn't limited to getter and
setter _methods_, but allows get/set expressions, changes the argument.

ADAPT_CLASS doesn't distinguish itself from ADAPT_STRUCT by what is
the difference between c++ "class" and c++ "struct".
I'd argue that it doesn't even adapt a class, but defines a fusion
sequence from a series of c++ expressions.

that might be a useful feature, and one useful variant of that feature
might be a macro that defines "obj" for the scope of the expressions,
but I think the naming is confusing. see my previous mail for a
practical example.

finding a name for this feature along the line of "define sequence
from expressions" would also reduce the number of macros. I don't
think the SUB-/DERIVED variants I proposed are needed for this.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk