[Parameter] Constructors and more
Johan Nilsson <r.johan.nilsson <at> gmail.com>
2006-03-01 10:32:30 GMT
Hi,
I've just started playing around with Boost.Parameter. I'm in the progress
of wrapping a legacy C library and some of the structs used have plenty of
members, most of which have reasonable defaults. I thought that the
Parameter library would be a nice fit here, but ended up with a couple of
questions:
1. How can I define constructor for a class taking named parameters, without
using the double parentheses syntax? The following basic idea works, but is
ugly:
---
...
BOOST_PARAMETER_KEYWORD(tag, minVal)
BOOST_PARAMETER_KEYWORD(tag, maxVal)
struct Foo
{
template<typename ArgPack>
Foo(ArgPack& args)
{
m_minVal = args[minVal|0];
m_maxVal = args[maxVal|100];
}
...
};
void bar()
{
Foo foo(( minVal = 1, maxVal = 2)); // Note double parens
}
---
I've experimented some with defining a parameter::parameters specification
and use (the undocumented) BOOST_PARAMETER_MEMFUN, but that obviously
doesn't work (forwarding, return values and constructors don't mix). It
should be possible (I think) to define a BOOST_PARAMETER_CTOR macro that
generate the ctor overloads and forwards to a setter method instead of the
other way around.
I guess I could create a free or static member function that constructs an
object, but that would either force me to create heap-based objects, or
invoke potentially expensive copy ctors.
2. Is there a way of detecting whether an argument was passed using position
or name? Or, even better, is there a way of restricting the arguments to
only be passed by name using the parameters specification?
3. Not a question really, but having a default arity of 5 seems awfully low
to me. I hit that limit on first usage, and as the named parameters are
supposed to be used in the interface of my wrapping library, forcing users
to define BOOST_PARAMETER_MAX_ARITY "globally" feels a bit like asking for
someone coming up and asking me to decode some compile errors.
[I'm using the latest cvs head of boost, in combination with VC 8.0]
Regards,
Johan Nilsson
) well known. It was discussed during review and I even tried to find a workaround for it not too long ago. The solution is very simple and is even described in the reference manual under the requirements for the InnerInitial parameter: <quote> An mpl::list<> containing models of the SimpleState or State concepts or instantiations of the shallow_history or deep_history class templates. If there is only a single inner initial state _that_is_not_a_template_instantiation_ then it can also be passed directly, without wrapping it into an mpl::list<>. [...] </quote> (_Note_the_underlined_part_). So, the only thing you need to do is to wrap every templated InnerInitial parameter into an mpl::list and everything will work as expected (see attached example). The reason why compilers rightly choke on the code lies in the fact that simple_state internally checks whether the InnerInitial parameter already is an mpl::list. This check works perfectly even on forward-declared classes. However, as soon as InnerInitial is a class template instantiation, for some reason that template needs to be fully instantiated. The problem is described in more detail here: <http://article.gmane.org/gmane.comp.lib.boost.devel/128741> I guess it was simply a little too late yesterday, sorry... #include <boost/statechart/state_machine.hpp> #include <boost/statechart/simple_state.hpp> #include <boost/mpl/list.hpp>
RSS Feed