[parameter] Parameter-Enabled Class Templates: combining keyword and deduction for the same parameter
The docs explain that a parameter can be named: typedef parameter::parameters< required<tag::threading_policy> ...
class_signature; ... class_<threading_policy<single_threaded>,...>;
or else be deduced: typedef parameter::parameters< required< deduced<tag::threading_policy>, is_base_and_derived<threading_policy_marker,_> > ...
class_signature; ... class multithreaded: threading_policy_marker{...}; class_<multithreaded,...>;
Now, is it possible to combine these two options into one, so that the the two syntaxes class_<threading_policy<single_threaded>,...>; class_<multithreaded,...>; are accepted? If so, how? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
on Thu Jul 19 2007, Joaquín Mª López Muñoz <joaquin-AT-tid.es> wrote:
The docs explain that a parameter can be named:
typedef parameter::parameters< required<tag::threading_policy> ...
class_signature; ... class_<threading_policy<single_threaded>,...>;
or else be deduced:
typedef parameter::parameters< required< deduced<tag::threading_policy>, is_base_and_derived<threading_policy_marker,_> > ...
class_signature; ... class multithreaded: threading_policy_marker{...}; class_<multithreaded,...>;
Now, is it possible to combine these two options into one, so that the the two syntaxes
class_<threading_policy<single_threaded>,...>; class_<multithreaded,...>;
are accepted? If so, how?
Just used deduced<tag::threading_policy>; deduced parameters can be deduced from argument types or from the names attached to named arguments. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
----- Mensaje original ----- De: David Abrahams <dave@boost-consulting.com> Fecha: Jueves, Julio 19, 2007 9:06 pm Asunto: Re: [Boost-users] [parameter] Parameter-Enabled Class Templates:combining keyword and deduction for the same parameter Para: boost-users@lists.boost.org
on Thu Jul 19 2007, Joaquín Mª López Muñoz <joaquin-AT-tid.es> wrote:
The docs explain that a parameter can be named:
typedef parameter::parameters< required<tag::threading_policy> ...
class_signature; ... class_<threading_policy<single_threaded>,...>;
or else be deduced:
typedef parameter::parameters< required< deduced<tag::threading_policy>, is_base_and_derived<threading_policy_marker,_> > ...
class_signature; ... class multithreaded: threading_policy_marker{...}; class_<multithreaded,...>;
Now, is it possible to combine these two options into one, so that the two syntaxes
class_<threading_policy<single_threaded>,...>; class_<multithreaded,...>;
are accepted? If so, how?
Just used deduced<tag::threading_policy>; deduced parameters can be deduced from argument types or from the names attached to named arguments.
Just to be sure: so, given the parameter specification required<deduced<tag::T>,F>, Boost.Parameter matches it to T<X> even if X does *not* satisfy F, correct? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
on Thu Jul 19 2007, "JOAQUIN LOPEZ MU?Z" <joaquin-AT-tid.es> wrote:
Just to be sure: so, given the parameter specification
required<deduced<tag::T>,F>,
Boost.Parameter matches it to T<X> even if X does *not* satisfy F, correct?
That's the intention... although I can't promise SFINAE won't kick in in some cases. -- Dave Abrahams Boost Consulting http://www.boost-consulting.com The Astoria Seminar ==> http://www.astoriaseminar.com
David Abrahams wrote:
on Thu Jul 19 2007, "JOAQUIN LOPEZ MU?Z" <joaquin-AT-tid.es> wrote:
Just to be sure: so, given the parameter specification
required<deduced<tag::T>,F>,
Boost.Parameter matches it to T<X> even if X does *not* satisfy F, correct?
That's the intention... although I can't promise SFINAE won't kick in in some cases.
Joaquin was talking about class templates, so the above holds true. SFINAE will kick in if you use the restriction mechanism for function templates. The PP interface does that, so if you use that you can't supply parameter types that doesn't match the predicate. -- Daniel Wallin Boost Consulting www.boost-consulting.com
----- Mensaje original ----- De: Daniel Wallin <daniel@boost-consulting.com> Fecha: Viernes, Julio 20, 2007 0:11 am Asunto: Re: [Boost-users] [parameter] Parameter-Enabled Class Templates:combining keyword and deduction for the same parameter Para: boost-users@lists.boost.org
David Abrahams wrote:
on Thu Jul 19 2007, "JOAQUIN LOPEZ MU?Z" <joaquin-AT-tid.es> wrote:
Just to be sure: so, given the parameter specification
required<deduced<tag::T>,F>,
Boost.Parameter matches it to T<X> even if X does *not* satisfy F, correct?
That's the intention... although I can't promise SFINAE won't kick in in some cases.
Joaquin was talking about class templates, so the above holds true. SFINAE will kick in if you use the restriction mechanism for function templates. The PP interface does that, so if you use that you can't supply parameter types that doesn't match the predicate.
I've read this over and over and can't say whether you're correcting Dave or me :( excuse my incompetence. So, given (in the context of class template parameters) required<deduced<tag::T>,F>, can Boost.Parameter match it to T<X> even if X does *not* satisfy F? Thank you! Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
JOAQUIN LOPEZ MU?Z wrote:
----- Mensaje original ----- De: Daniel Wallin <daniel@boost-consulting.com> Fecha: Viernes, Julio 20, 2007 0:11 am Asunto: Re: [Boost-users] [parameter] Parameter-Enabled Class Templates:combining keyword and deduction for the same parameter Para: boost-users@lists.boost.org
David Abrahams wrote:
on Thu Jul 19 2007, "JOAQUIN LOPEZ MU?Z" <joaquin-AT-tid.es> wrote:
Just to be sure: so, given the parameter specification
required<deduced<tag::T>,F>,
Boost.Parameter matches it to T<X> even if X does *not* satisfy F, correct? That's the intention... although I can't promise SFINAE won't kick in in some cases. Joaquin was talking about class templates, so the above holds true. SFINAE will kick in if you use the restriction mechanism for function templates. The PP interface does that, so if you use that you can't supply parameter types that doesn't match the predicate.
I've read this over and over and can't say whether you're correcting Dave or me :( excuse my incompetence. So, given (in the context of class template parameters)
required<deduced<tag::T>,F>,
can Boost.Parameter match it to T<X> even if X does *not* satisfy F? Thank you!
Yes, that is correct. However, is you use `parameters::match<>` to restrict a function template, SFINAE will kick in. For example: BOOST_PARAMETER_FUNCTION((void), f, tag, (deduced (required (x, (std::string))) ) ); f(x = 10); // no overload matches -- Daniel Wallin Boost Consulting www.boost-consulting.com
Daniel Wallin <daniel <at> boost-consulting.com> writes:
JOAQUIN LOPEZ MU?Z wrote:
[...]
I've read this over and over and can't say whether you're correcting Dave or me :( excuse my incompetence. So, given (in the context of class template parameters)
required<deduced<tag::T>,F>,
can Boost.Parameter match it to T<X> even if X does *not* satisfy F? Thank you!
Yes, that is correct. However, is you use `parameters::match<>` to restrict a function template, SFINAE will kick in. For example:
BOOST_PARAMETER_FUNCTION((void), f, tag, (deduced (required (x, (std::string))) ) );
f(x = 10); // no overload matches
OK, thanks for the info! Since it's only class templates that I'm interested, the behavior is exactly what I need. In the meantine, I've tried the lib and learnt the additional fact that, for required<deduced<tag::T>,F>, if T<X> is passed and T<X> (rather than X) satisfies F, then Boost.Parameter returns X as the matched arg rather than T<X>. Not that this poses any particular difficulty with what I'm trying to use the lib for, but it's a somewhat corner case I'd like to share with you. BTW, Boost.Parameter is a pleasure to work with! I hope to be able to show soon a B.P-powered lib where your stuff makes it a joy, both for the lib writer and the user, to deal with class templates with lots of parameters. Best, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo
participants (5)
-
"JOAQUIN LOPEZ MU?Z" -
Daniel Wallin -
David Abrahams -
Joaquin M Lopez Munoz
-
Joaquín Mª López Muñoz