Boost logo

Boost :

From: Aleksey Gurtovoy (agurtovoy_at_[hidden])
Date: 2005-05-06 11:17:51


Joel writes:
> Joel wrote:
>> Brian Braatz wrote:
>>
>>> Could it be as simple as missing the namespace on the is_sqeuence<>
>>> call?
>>
>>
>> Have you tried it? If it was, I wouldn't have bothered the list ;-)
>> Try replacing int_<0> with int.
>
> I think the problem is the way mpl::is_sequence is implemented.
> It tries to detect the presence of a "tag" typedef and a "begin"
> typedef and concludes that a type is an mpl::sequence if it
> has both.

Of course it doesn't. The behavior you cite only takes place as a
workaround for broken compilers (MSVC <= 7.0) -- which is quite
obvious from the code.

> I've complained a long time ago about this.

A link?

> I think
> this behavior is error prone. It's quite easy to come up with
> a situation where I have a type T with a "tag" and a "begin"
> but is not an MPL sequence.

Not that I think it's an implementation that is worth defending,
but in all fairness it's hard to imagine a real-world occurrence
of a type with nested _typenames_ "tag" and "begin" that wasn't
intended to be an MPL sequence. IOW, the workaround is a good
enough real-world approximation of the real thing.

> There must be a better way.

http://www.boost.org/libs/mpl/doc/refmanual/is-sequence.html#expression-semantics

> Anyway, in any case, is_sequence<int_<0> >::value should never
> fail to compile.

Yes, it shouldn't. I'll look into it.

--
Aleksey Gurtovoy
MetaCommunications Engineering

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