[parameter] BOOST_PARAMETER_CONSTRUCTOR bug
I've already submitted a bug report, but I'm also posting it here in case
anyone has more info.
-------------
The following variation on the example from the boost::parameter tutorial,
where the required parameter is changed to optional, fails to compile.
myclass_impl is being passed an empty argument list.
#include <iostream>
#include
James Hirschorn wrote:
struct myclass_impl { template <class ArgumentPack> myclass_impl(ArgumentPack const& args) { std::cout << "name = " << args[_name] << "; index = " << args[_index] << std::endl; } };
I believe when you have an optional constructor parameter, you must access it with the default value supplied: struct myclass_impl { template <class ArgumentPack> myclass_impl(ArgumentPack const& args) { std::cout << "name = " << args[_name | ""] << "; index = " << args[_index | 0] << std::endl; } }; (Note the bitwise or "|"). This is a little different than for named function parameters, it seems. HTH, Nate
Nathan Crookston wrote:
James Hirschorn wrote:
I believe when you have an optional constructor parameter, you must access it with the default value supplied:
struct myclass_impl { template <class ArgumentPack> myclass_impl(ArgumentPack const& args) { std::cout << "name = " << args[_name | ""] << "; index = " << args[_index | 0] << std::endl; } };
(Note the bitwise or "|"). This is a little different than for named function parameters, it seems.
HTH, Nate
Yes, that works. I should have checked here before making the report... Thanks, James
The following variation does not seem to work according to the documentation.
Can someone explain this?
--------------------
#include <iostream>
#include
Hello, James. In order to enable argument deduction, you need to augment your parameter declaration clause with either an explicit type or a Unary Metafunction Class--essentially an MPL Lambda Expression--that returns mpl::true_ when the argument type fulfills the requirements you want to impose on it. Try one the following macro invocations: BOOST_PARAMETER_CONSTRUCTOR( myclass, (myclass_impl), tag , (optional (name, (char const*)) (index, (int)) ) (deduced (optional (ratio, (double))) ) ) or BOOST_PARAMETER_CONSTRUCTOR( myclass, (myclass_impl), tag , (optional (name, (char const*)) (index, (int)) ) (deduced (optional (ratio, *(boost::is_floating_pointboost::mpl::_))) ) ) HTH, Cromwell D. Enage
Cromwell Enage wrote
Hello, James.
In order to enable argument deduction, you need to augment your parameter declaration clause with either an explicit type or a Unary Metafunction Class--essentially an MPL Lambda Expression--that returns mpl::true_ when the argument type fulfills the requirements you want to impose on it. Try one the following macro invocations: ...
Have you tried to compile your examples? They both fail for me, with the exact same error as the original. Also, I have read the documentation many times, and did not notice the requirement you mentioned. -- View this message in context: http://boost.2283326.n4.nabble.com/parameter-BOOST-PARAMETER-CONSTRUCTOR-bug... Sent from the Boost - Dev mailing list archive at Nabble.com.
James Hirschorn wrote:
Cromwell Enage wrote
Hello, James.
In order to enable argument deduction, you need to augment your parameter declaration clause with either an explicit type or a Unary Metafunction Class--essentially an MPL Lambda Expression--that returns mpl::true_ when the argument type fulfills the requirements you want to impose on it. Try one the following macro invocations: ...
Have you tried to compile your examples? They both fail for me, with the exact same error as the original. Also, I have read the documentation many times, and did not notice the requirement you mentioned.
I agree with Cromwell, to have a hope of working, you'd have to some way of identifying the expected type of the argument to have a hope of deducing it. However, I haven't found a syntax that works here either -- my suspicion is that deduced constructor parameters aren't currently supported. Certainly there aren't any tests which validate such functionality, and no documentation regarding it either. Unfortunately, a cursory glance through the code wasn't very illuminating -- it would take me some serious study to really understand the code. Hopefully I'm wrong and a maintainer will be able to set us straight. Sorry, Nate
participants (3)
-
Cromwell Enage -
James Hirschorn -
Nathan Crookston