Subject: Re: [boost] [fusion] [intro] ADAPT_STRUCT extensions
From: Joel de Guzman (joel_at_[hidden])
Date: 2010-08-11 23:29:18
On 8/12/10 9:46 AM, David Sankel wrote:
> On Sat, Jul 31, 2010 at 9:02 AM, Christopher Schmidt<
> mr.chr.schmidt_at_[hidden]> wrote:
>> Joel de Guzman schrieb:
>>> On 7/30/2010 6:35 AM, Stefan Strasser wrote:
>>>> Zitat von Hartmut Kaiser<hartmut.kaiser_at_[hidden]>:
>>>>> Have you seen the new BOOST_FUSION_ADAPT_CLASS() family of utilities
>>>>> allow using (member-) functions instead of direct access to the data
>>>>> of a class/struct?
>>>> no I had not, I was using 1.41. where can I see those? can't seem to
>>>> find them in 1.43 or
>>>> the trunk.
>> The BOOST_FUSION_ADAPT_xxxCLASSxxx-macros are not documented yet. For
>> more information, refer to the code and the testcases:
> 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. Stefan's
> suggestions, on the other hand, are a straightforward extension of the
> original semantics. I'd personally like to see the latter incorporated and
> the former removed.
What's wrong with having both? Non-intrusive class adaptation, IMO, is
very important too. I like Stefan's suggestions too but I don't understand
why we can't have both.
-- Joel de Guzman http://www.boostpro.com http://spirit.sf.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk