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