|
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