Boost logo

Boost :

From: Joel de Guzman (joel_at_[hidden])
Date: 2005-05-06 12:36:44


Hi Aleksey,

Aleksey Gurtovoy wrote:

>>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.

Oh sorry :( Should've read the code more closely.

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

T'was a private email. Sorry, can't find it. I'm wrong.

>>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.

Understood.

>>There must be a better way.
>
>
> http://www.boost.org/libs/mpl/doc/refmanual/is-sequence.html#expression-semantics

Looks good. I wasn't aware that begin<x> can return void_ when
x is not a sequence.

>>Anyway, in any case, is_sequence<int_<0> >::value should never
>>fail to compile.
>
>
> Yes, it shouldn't. I'll look into it.

Thanks! I wonder what you have to say regarding the argument
on the existence of is_sequence?

Regards,

-- 
Joel de Guzman
http://www.boost-consulting.com
http://spirit.sf.net

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