Re: [boost] [fusion-2] compile time pair

From: Eric Niebler (eric_at_[hidden])
Date: 2005-12-02 18:53:05

Andreas Pokorny wrote:
> On Fri, Dec 02, 2005 at 12:11:32PM -0800, Eric Niebler <eric_at_[hidden]> wrote:
> 
>>Andreas Pokorny wrote:
>>
>>>Hi,
>>>The default implementation of boost::fusion::pair<first,second> only stores 
>>>an instance of second. I might need a fusion::pair which does not store
>>>that instance either, 
>>
>>
>>If you want a map with *no* runtime data, then you should use 
>>mpl::map<>, not fusion::map<>. mpl::map<> uses mpl::pair<>, which has no 
>>runtime data. (Caveat: mpl::map is broken in more than one respect at 
>>the moment. Hopefully, it'll be fixed soon.)
> 
> 
> Ah, I could write an interleaved map that splits the pair sequence into 
> runtime and compile time info holders. 

I'm not sure I follow, but if my suggestion led you to a solution, I'm 
happy to take the credit. ;-)

> How is mpl::map broken?
> 

mpl::map doesn't guarantee unique keys at the moment. For instance, this 
doesn't work.

    typedef mpl::insert<mpl::map0<>, mpl::pair<int, float> >::type t1;
    typedef mpl::insert<t1, mpl::pair<int, double> >::type t2;
    // Oops, this assertion fails
    BOOST_MPL_ASSERT_RELATION(mpl::size<t2>::value, ==, 1);

After the two insertions, the map contains pair<int,float> and 
pair<int,double>, but AFAICT it should only contain mpl::pair<int, float>.

Also, mpl::insert_range does not work with mpl::map<> even though the 
docs say it should.

Also, I have found places where using an mpl::map<> fails where using 
mpl::map0<> works. Ditto for mpl::set<> and mpl::set0<>.

If you decide to go this route, be aware, or else wait for the fixes.

-- 
Eric Niebler
Boost Consulting
www.boost-consulting.com