Zitat von Christopher Schmidt <mr.chr.schmidt@online.de>:
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.