Hi Martin, (I assume you missed my reply to your original post -- http://article.gmane.org/gmane.comp.lib.boost.user/36892)
Hm, typeof is not yet part of the C++ standard, as far as I know. This means, that Boost MPL relies on non-standard behaviour to work correctly (in this case). What makes this very problematic is, that there is no error or warning, simply different behaviour across platforms.
It would be very problematic *if* the behaviour you witnessed was somehow inherent / by design. However, it's not. It was simply a bug, albeit a nasty one, which I fixed in the trunk -- http://svn.boost.org/trac/boost/changeset/46546
This means I will have to stumble through each case, where the availability of the typeof operator makes a difference.
Please see my post above. In short, the referenced changelist gives us a reasonable degree of assurance that you don't have to do that. The original bug that would lead to a silent failure dependening of the typeof availability had a limited scope (push_back/push_front) and has been fixed, and the related issue of sequence algorithms/metafunctions silently doing nothing if passed a non-sequence (regardless on typeof) has been also addressed (although not completely). We also will be working on adding more test coverage for this particular aspect of the library (http://svn.boost.org/trac/boost/ticket/2041).
To me it looks, as if apply should not compile, if its argument is not a metafunction.
While the 'apply' heuristic is increasing the possibility of your code silently doing something else from what you think it's doing, it behaves consistently across all platforms, and it was not the culprit in your original example.
But I don't have enough overview of the internal workings of MPL to estimate the consequences of this. Or is there any way to at least notice, that something is going wrong without testing the software relying on MPL completely?
Please let us know if the above addresses your concerns. -- Aleksey Gurtovoy MetaCommunications Engineering