
On 7/18/2010 8:02 PM, Daniel Walker wrote:
On Sun, Jul 18, 2010 at 7:11 PM, Edward Diener<eldiener@tropicsoft.com> wrote:
On 7/18/2010 12:26 PM, Steven Watanabe wrote:
AMDG
Edward Diener wrote:
I found the BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF macro in the latest has_xxx.hpp of mpl on the trunk.
Is BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF ( and its corresponding BOOST_MPL_HAS_XXX_TEMPLATE_DEF ) scheduled to be added to Boost in an upcoming release ? I find it useful for TMP introspection in much the same way as BOOST_MPL_HAS_XXX_TRAIT_NAMED_DEF ( and its corresponding BOOST_MPL_HAS_XXX_TRAIT_DEF ).
It's currently in the release branch and should be released in 1.44.
That is good to hear but...
My testing with VC9 and VC10 shows that if I pass too many tempate arguments I get a compiler failure:
Do an svn update on your local copy of trunk. You no longer need to pass arguments to detect member templates. This change was checked in a couple of weeks ago, so you might not have gotten it yet. See the updated documentation.
I did not find anything in the updated documentation about these macros. Was I supposed to generate updated docs for MPL in the trunk through some jamfile ?
----------------------------------------------------
#include<boost/mpl/has_xxx.hpp>
struct AAType { template<class X> struct AAMemberTemplate { }; };
BOOST_MPL_HAS_XXX_TEMPLATE_DEF(AAMemberTemplate)
has_AAMemberTemplate<AAType,int,int> yz; // error
After updating from svn, change the line to has_AAMemberTemplate<AAType> yz;
You should no longer see an error.
You are correct.
You can detect member templets with any number of arguments up to the configurable BOOST_MPL_LIMIT_METAFUNCTION_ARITY, which defaults to 5.
OK. Thanks !
<snip>
The code in the MPL is highly complicated, else I would spend the hours trying to understand it and perhaps fix it. But I hope that at least reporting my failure with VC9 and VC10 will help to get this working.
Thanks for reporting! Actually, when I ran your example code I noticed a header dependency in boost/mpl/has_xxx.hpp that I had accidentally missed. So, your report has helped improve things already.
I am glad. Thanks for your code. I will look at it and see if I can't do something further on my own which would allow one to find out the number and type of the template parameters of a class template at compile time, given the template name. Something instinctively tells me that this might be accessible, if it has not already been done.