[boost] [parameter] BOOST_PARAMETER_CONSTRUCTOR bug

[James Hirschorn]

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 <boost/parameter.hpp>


BOOST_PARAMETER_NAME(name)
BOOST_PARAMETER_NAME(index)

struct myclass_impl
{
template <class ArgumentPack>
myclass_impl(ArgumentPack const& args)
{
std::cout << "name = " << args[_name]
<< "; index = " << args[_index]
<< std::endl;
}
};

struct myclass : myclass_impl
{
BOOST_PARAMETER_CONSTRUCTOR(
myclass, (myclass_impl), tag
, (optional (name, *) (index, *)
)
) // no semicolon
};

int main(int argc, char * argv[])
{
myclass C(_name="hello", _index=0);
}


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

[Nathan Crookston]

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

[James Hirschorn]

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

[James Hirschorn]

The following variation does not seem to work according to the documentation.
Can someone explain this?

--------------------

#include <iostream>

#include <boost/parameter.hpp>


BOOST_PARAMETER_NAME(name)
BOOST_PARAMETER_NAME(index)

BOOST_PARAMETER_NAME(ratio)

struct myclass_impl
{
template <class ArgumentPack>
myclass_impl(ArgumentPack const& args)
{
std::cout << "name = " << args[_name | ""]
<< "; index = " << args[_index | 0]

<< "; ratio = " << args[_ratio | 1.0]

<< std::endl;
}
};

struct myclass : myclass_impl
{
BOOST_PARAMETER_CONSTRUCTOR(
myclass, (myclass_impl), tag

, (optional (name, (char const*)) (index, (int))
)
(deduced
(optional (ratio, *))
)
)

};

int main(int argc, char * argv[])
{

myclass C(_name="hello", _index=1);
myclass D(4.6);
}

----------------

In the construction of D, 4.6 is not deduced as having the keyword ratio,
and the program fails to compile. The deduced clause seems to be ignored.
Is this not a bug?




--
View this message in context: http://boost.2283326.n4.nabble.com/parameter-BOOST-PARAMETER-CONSTRUCTOR-bug-tp4647592p4648390.html
Sent from the Boost - Dev mailing list archive at Nabble.com.

[Cromwell Enage]

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_point<boost::mpl::_>)))
                )

)

HTH,
Cromwell D. Enage

[James Hirschorn]

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-tp4647592p4648398.html

Sent from the Boost - Dev mailing list archive at Nabble.com.

_______________________________________________

[Nathan Crookston]

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