Boost logo

Boost :

Subject: Re: [boost] [fusion] Definition for FUSION_MAX_MAP_SIZE
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-06-30 19:24:25


On 6/30/2014 4:37 PM, Joel de Guzman wrote:
> On 6/30/14, 11:44 PM, Agustín K-ballo Bergé wrote:
>> On 30/06/2014 12:40 p.m., Edward Diener wrote:
>>> On 6/30/2014 11:15 AM, Agustín K-ballo Bergé wrote:
>>>> On 30/06/2014 09:26 a.m., Edward Diener wrote:
>>>>> The documentation for fusion implies that FUSION_MAX_MAP_SIZE is
>>>>> defined
>>>>> whenever a fusion header is included.
>>>>
>>>> It doesn't, it simply reserves the option for any header to define
>>>> it or
>>>> include a header that does. This is the general case for max sizes, and
>>>> allows fusion to do things as implementing a container in terms of a
>>>> different one.
>>>>
>>>>> What fusion header needs to be
>>>>> included in order to bring in the definition for FUSION_MAX_MAP_SIZE ?
>>>>
>>>> As far as I can tell, `FUSION_MAX_MAP_SIZE` is only defined if you
>>>> include <boost/fusion/container/map.hpp> and the implementation is
>>>> non-variadic.
>>>
>>> What do you mean by 'and the implementation is non-variadic' ?
>>>
>>
>> If the compiler has enough C++11 support, you'll get a variadic
>> implementation:
>>
>> template <typename ...Ts> struct map;
>>
>> For such implementation, `FUSION_MAX_MAP_SIZE` makes no sense as there
>> is no hard limit.
>
> Yes, that is correct.

So if the compiler has variadic template support 'FUSION_MAX_MAP_SIZE'
is not defined ? Which config macro is being checked ?

If this is so then it should be documented, especially as other
libraries might be using the macro and assume it is defined to a default
value. In particular I see that Boost MSM uses the macro in the
expansion to its 'BOOST_MSM_EUML_EVENT_WITH_ATTRIBUTES' macro. I had
been trying to trace a failure in expanding this macro when compiling
with VC++ 12 in the ;develop' branch and it is because it relies on
'FUSION_MAX_MAP_SIZE' always being defined.


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