[mpl] BOOST_MPL_HAS_XXX_TEMPLATE_NAMED_DEF
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 ).
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. In Christ, Steven Watanabe
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: ---------------------------------------------------- #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 ---------------------------------------------------- error C2977: 'has_AAMemberTemplate' : too many template arguments see declaration of 'has_AAMemberTemplate' error C2133: 'yz' : unknown size error C2512: 'has_AAMemberTemplate' : no appropriate default constructor available etc. Of course I expect a BOOST_MPL_ASSERT failure for: BOOST_MPL_ASSERT((has_AAMemberTemplate<AAType,int,int>)) but not a compiler error. The Concept Traits Library also had a macro which worked similarly, but also failed for the same reason. When I discovered the implementation in the trunk version of MPL I had hopes that this was better. Sigh ! 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.
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.
----------------------------------------------------
#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 can detect member templets with any number of arguments up to the configurable BOOST_MPL_LIMIT_METAFUNCTION_ARITY, which defaults to 5. <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. Daniel Walker
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.
On Sun, Jul 18, 2010 at 8:39 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 7/18/2010 8:02 PM, Daniel Walker wrote:
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 ?
Hmm, that's a good question. The doc sources are updated on trunk, but I'm not sure when the actual html is generated for the release...
<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.
Yes, please do look into it. As a hint for understanding preprocessor metaprograming, compile with -E and look at the preprocessor output for different macros. It will help you find your way around. I believe it's entirely possible to write a template_arity metafunction analogous to function_arity in Boost Function Types. There is something close in boost/mpl/aux_/template_arity.hpp. It might also be nice to have an is_variadic_template for c++0x. Just ask if you have any questions. Daniel Walker
AMDG Daniel Walker wrote:
On Sun, Jul 18, 2010 at 8:39 PM, Edward Diener <eldiener@tropicsoft.com> wrote:
On 7/18/2010 8:02 PM, Daniel Walker wrote:
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 ?
Hmm, that's a good question. The doc sources are updated on trunk, but I'm not sure when the actual html is generated for the release...
I think the compiled docs are just checked into svn. I can regenerate the html, but I haven't figured out what I need to do to build the pdf version. Aleksy? In Christ, Steven Watanabe
On Sun, 18 Jul 2010 22:08:14 -0500, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Daniel Walker wrote:
Hmm, that's a good question. The doc sources are updated on trunk, but I'm not sure when the actual html is generated for the release...
I think the compiled docs are just checked into svn.
Yep.
I can regenerate the html, but I haven't figured out what I need to doto build the pdf version. Aleksy?
The PDF version hasn't been rebuilt in ages; I was thinking of dropping it altogether. -- Aleksey Gurtovoy MetaCommunications Engineering
On Tue, Jul 20, 2010 at 7:17 PM, Aleksey Gurtovoy <agurtovoy@meta-comm.com> wrote:
On Sun, 18 Jul 2010 22:08:14 -0500, Steven Watanabe <watanabesj@gmail.com> wrote:
AMDG
Daniel Walker wrote:
Hmm, that's a good question. The doc sources are updated on trunk, but I'm not sure when the actual html is generated for the release...
I think the compiled docs are just checked into svn.
Yep.
I can regenerate the html, but I haven't figured out what I need to doto build the pdf version. Aleksy?
The PDF version hasn't been rebuilt in ages; I was thinking of dropping it altogether.
Well, it's probably OK if the pdf isn't updated this release, but I suppose the html should be. I'm having trouble building it, though. Steven, if you can regenerate the html, could you just check it in? Daniel Walker
Edward Diener <eldiener <at> tropicsoft.com> writes:
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.
I gave you code to detect member template arity a few days ago on the MSDN forums [1], highly suited to preprocessor generation. Does it not suit your needs? [1] http://preview.tinyurl.com/32aghf3
On 7/19/2010 1:32 AM, Adam Merz wrote:
Edward Diener<eldiener<at> tropicsoft.com> writes:
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.
I gave you code to detect member template arity a few days ago on the MSDN forums [1], highly suited to preprocessor generation. Does it not suit your needs?
Thanks for reminding me of your solution for template arity !
participants (5)
-
Adam Merz -
Aleksey Gurtovoy -
Daniel Walker -
Edward Diener -
Steven Watanabe