gmane.comp.parsers.spirit.devel

[fusion] Constructing fusion::map<P1, P2, .., PN> Requires same ordering of P's?

Hi Everyone,

I don't know if this is a bug or intended behavior, given the snippet
below:

<code>

struct tags {
  struct type_1 { };
  struct type_2 { };
};

typedef map< pair<tags::type_1, int>, pair<tags::type_2, int> > 
	my_map_type;

void foo() {
  my_map_type instance( make_pair<tags::type_2>(1),
make_pair<tags::type_2>(2) );
};

</code>

It complains that instance does not have a defined constructor given the
order of arguments. I'm using Fusion that's in Boost SVN trunk revision
39151 -- frozen due to internal development/engineering decisions.

Is this a bug, or a feature?

Insights would be most appreciated.

(Continue reading)

headers

Joel de Guzman | 1 Nov 00:06

Re: [fusion] Constructing fusion::map<P1, P2, .., PN> Requires same ordering of P's?

Dean Michael C. Berris wrote:
> Hi Everyone,
> 
> I don't know if this is a bug or intended behavior, given the snippet
> below:
> 
> <code>
> 
> struct tags {
>   struct type_1 { };
>   struct type_2 { };
> };
> 
> typedef map< pair<tags::type_1, int>, pair<tags::type_2, int> > 
> 	my_map_type;
> 
> void foo() {
>   my_map_type instance( make_pair<tags::type_2>(1),
> make_pair<tags::type_2>(2) );
> };
> 
> </code>
> 
> It complains that instance does not have a defined constructor given the
> order of arguments. I'm using Fusion that's in Boost SVN trunk revision
> 39151 -- frozen due to internal development/engineering decisions.
> 
> Is this a bug, or a feature?

This code is wrong, AFAIK:

(Continue reading)

headers

Dean Michael Berris | 1 Nov 06:22

Re: [fusion] Constructing fusion::map<P1, P2, .., PN> Requires same ordering of P's?

On 10/31/07, Joel de Guzman <joel <at> boost-consulting.com> wrote:
> >
> > It complains that instance does not have a defined constructor given the
> > order of arguments. I'm using Fusion that's in Boost SVN trunk revision
> > 39151 -- frozen due to internal development/engineering decisions.
> >
> > Is this a bug, or a feature?
>
> This code is wrong, AFAIK:
>
> my_map_type instance(
>      make_pair<tags::type_2>(1), make_pair<tags::type_2>(2) );
>                ^^^^^^^^^^^^                ^^^^^^^^^^^^
>
> Are you sure you want both type_2?
>

Oh, yes you're right. No, actually it should be

my_map_type instance(
  make_pair<tags::type_2>(1), make_pair<tags::type_1>(2) );

Even in this case it complains that there isn't a defined constructor
that takes the arguments in that order. Re-ordering them would make it
work.

It might be too much to ask, but would doing an mpl::sort<> of the
arguments in this case work? For example,

fusion::map< pair<tags::type_1, int>, pair<tags::type_2, int> >

(Continue reading)

headers

Joel de Guzman | 2 Nov 03:41

Re: [fusion] Constructing fusion::map<P1, P2, .., PN> Requires same ordering of P's?

Dean Michael Berris wrote:

> It might be too much to ask, but would doing an mpl::sort<> of the
> arguments in this case work? For example,
> 
> fusion::map< pair<tags::type_1, int>, pair<tags::type_2, int> >
> 
> can be equivalent/convertible to
> 
> fusion::map< pair<tags::type_2, int>, pair<tags::type_1, int> >
> 
> By both forwarding/inheriting from a base fusion::map_impl<> where the
> template arguments of fusion::map<> are sorted? Then the constructors
> can be template argument deduced, so that it actually sorts the
> argument types using the same sorting algorithm used when the template
> arguments of fusion::map<> are sorted to forward to fusion::map_impl<>
> ?
> 
> I know it might be too much work for very little gain -- but it allows
> the fusion::map<> to just be a tad bit more flexible and more
> "map-like". Thoughts?

Not sure. I'm sure you are aware of the complexity of doing a sort
at compile time, right? That's out of the question. It's simpler
would be to do the "assignment" in the constructor body. Like:

     at_key<K1>(*this) = arg1;
     /*...*/

But that would add a requirement that the elements are default

(Continue reading)

headers

Dean Michael Berris | 2 Nov 07:16

Re: [fusion] Constructing fusion::map<P1, P2, .., PN> Requires same ordering of P's?

On 11/1/07, Joel de Guzman <joel <at> boost-consulting.com> wrote:
> Dean Michael Berris wrote:
> >
> > I know it might be too much work for very little gain -- but it allows
> > the fusion::map<> to just be a tad bit more flexible and more
> > "map-like". Thoughts?
>
> Not sure. I'm sure you are aware of the complexity of doing a sort
> at compile time, right? That's out of the question. It's simpler
> would be to do the "assignment" in the constructor body. Like:
>
>      at_key<K1>(*this) = arg1;
>      /*...*/
>
> But that would add a requirement that the elements are default
> constructible.
>

Right. There might be another way, but with permutation generation
using Boost.PP -- though it does certainly make the implementation
more complex than necessary.

> I'll try to think of a better strategy. In the meantime, I suggest
> you add a Trac feature request for this.
>

Thanks, filed feature request: http://svn.boost.org/trac/boost/ticket/1404

Have a great weekend everyone!

(Continue reading)

headers

Larry Evans | 22 Jan 16:12

Re: [fusion] Constructing fusion::map<P1, P2, .., PN> Requires same ordering of P's?

On 11/01/07 21:41, Joel de Guzman wrote:
 > Dean Michael Berris wrote:
 >
 >> It might be too much to ask, but would doing an mpl::sort<> of the
 >> arguments in this case work? For example,
 >>
 >> fusion::map< pair<tags::type_1, int>, pair<tags::type_2, int> >
 >>
 >> can be equivalent/convertible to
 >>
 >> fusion::map< pair<tags::type_2, int>, pair<tags::type_1, int> >
 >>
[snip]
 > at compile time, right? That's out of the question. It's simpler
 > would be to do the "assignment" in the constructor body. Like:
 >
 >      at_key<K1>(*this) = arg1;
 >      /*...*/
 >

The attached code is a prototype of a somewhat similar method
using std::set and fusion+mpl::for_each.

The prototype just has the essentials for doing the construction
, IOW, it doesn't have the actual code for inserting into the
map or getting output from the map.  I think the
statement:

     at_key<K1>(*this) = arg1

(Continue reading)

headers

Larry Evans | 23 Jan 05:23

Re: [fusion] Constructing fusion::map<P1, P2, .., PN> Requires same ordering of P's?

On 01/22/08 09:12, Larry Evans wrote:
[snip]
> On 11/01/07 21:41, Joel de Guzman wrote:
>  > Dean Michael Berris wrote:
>  >
>  >> It might be too much to ask, but would doing an mpl::sort<> of the
>  >> arguments in this case work? For example,
>  >>
>  >> fusion::map< pair<tags::type_1, int>, pair<tags::type_2, int> >
>  >>
>  >> can be equivalent/convertible to
>  >>
>  >> fusion::map< pair<tags::type_2, int>, pair<tags::type_1, int> >
>  >>
> [snip]
[snip]
> The attached code is a prototype of a somewhat similar method
> using std::set and fusion+mpl::for_each.
[snip]
> OTOH, maybe there's some way to use an mpl::set instead
> of the std::set to record which keys are in the a_pairs
> arg to composite_ctor CTOR.

<boost-vault>/Data Structure/unordered_pairs_ctor_mplset_proto.cpp

contains a prototype of this idea.  The output is:

<--- cut here ---

gcc.link

(Continue reading)

headers

dan marsden | 2 Nov 08:34

Re: [fusion] Constructing fusion::map<P1, P2, .., PN> Requires same ordering of P's?


On 11/1/07, Joel de Guzman <joel <at> boost-consulting.com> wrote:
> Dean Michael Berris wrote:
> >
> > I know it might be too much work for very little gain -- but it
 allows
> > the fusion::map<> to just be a tad bit more flexible and more
> > "map-like". Thoughts?
>
> Not sure. I'm sure you are aware of the complexity of doing a sort
> at compile time, right? That's out of the question. It's simpler
> would be to do the "assignment" in the constructor body. Like:
>
>      at_key<K1>(*this) = arg1;
>      /*...*/
>
> But that would add a requirement that the elements are default
> constructible.

A couple of questions:
* Have you got a use case for this in some generic library, where lack of
the feature forces awkward code into the generic library implementation
* Or does the feature just seems more convenient / consistent

If you've got a genuine use case where this feature saves significant complexity
in generic library code, I'd say it belongs in fusion, particularly if it requires
PP metaprogramming to do well.

If its just a convenience to avoid needing to specify arguments in order, I think we should avoid it,
as other users will pay the compile time overhead for however the feature is

(Continue reading)