Boost logo

Boost :

From: Dean Michael Berris (mikhailberis_at_[hidden])
Date: 2008-03-22 07:12:10


On Sat, Mar 22, 2008 at 12:05 AM, Eric Niebler
<eric_at_[hidden]> wrote:
> Dean Michael Berris wrote:
> >
> > I'm nowhere near being an expert, but how would a BOOST_STATIC_ASSERT
> > fit in ensuring that Args has the correct arity provided in the
>
> What do you mean by "correct" here?
>

I say "correct" and mean that Args really does have arity 'Arity'.

> > construction of expr<>? Would there be a way to statically assert that
> > 'Args' has arity 'Arity' from within Proto? Or would that be too much
>
> Oh, Arity is the size of Args by default. expr<> is defined like:
>
> struct expr<Tag, Args, long Arity = Args::size>
>
> Nowhere does Proto enforce that Arity really *is* Args::size, though.
>

The question then should be, would it be beneficial (for correct
usage's sake) if Proto did make sure that the Arity parameter of the
construction of an 'expr<>' was really the correct arity of the Args
parameter? This should make defining expr's that have different
Arity's but the same Arguments incorrect usage:

expr<my_tag, my_args, 2> should not compile if my_args really has an
arity other than 2, and expr<my_tag, my_args, 2> shouldn't be
different from expr<my_tag, my_args, 3> (which given that we assert
my_args has arity 2, would be illegal). In this case 'expr<my_tag,
my_args>' is really just what's necessary.

> > compile time trouble on top of all the compile time burdens
> > Proto+Fusion+MPL already bring?
>
> I don't think a static assert would be very expensive, but I also don't
> think it would add much safety. In fact, it would force me to remove an
> optimization in matches.hpp, where I fudge the Arity parameter to save a
> few template instantiations.
>

I think this begs the question then, what is the necessity for an
Arity parameter as part of the definition of an expr<>?

Should expr<my_tag, my_args, 3> and expr<my_tag, my_args, 2> be
different? Should the arity even be part of the instantiation of the
expr<>, or should it really be just a nested value inside expr<>?

template <class Tag, class Args>
struct expr {
  static typename arity_count<Args>::type arity = arity_count<Args>::value;
  ...
};

Of course, the above requires the arity_count<> trait/metafunction to
be defined for each Args possibility (in which case it can be an
overloaded metafunction wrapper to existing Sequence arity counting
metafunctions). Which eerily, can also be applied to the 'tag' instead
of the Args parameter, coming close to what Larry has been proposing
of having the arity associated somehow with the tag instead. Moreover,
something like:

arity_count< expr<my_tag, my_args> >

May even make some sense, although it's hard for me to think about a
use case for that from within or even outside of Proto.

Just throwing some ideas around. I hope this helps.

-- 
Dean Michael C. Berris
Software Engineer, Friendster, Inc.
[http://blog.cplusplus-soup.com]
[mikhailberis_at_[hidden]]
[+63 928 7291459]
[+1 408 4049523]

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