[local] Bound types for concepts, etc?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[local] Bound types for concepts, etc?

lcaminiti
On Sun, Feb 6, 2011 at 2:25 PM, Mathias Gaunard
<[hidden email]> wrote:
> As I said, it does. With Boost.Local, you can still call polymorphic
> functions on the variables captured from scope without specifying the types
> of the arguments.

I am thinking to provide the type of the bound parameters within the
local function body as `<BOUND_PARAM_NAME>_type`. This way you can use
such types to check concepts, etc...

Is there value in this?

#include <boost/local/function.hpp>
#include <boost/concept_check.hpp>
#include <iostream>

template<typename T>
class Addable {
    T x;
    T y;
    void return_type(T); // Used to check addition returns type `T`.
public:
    BOOST_CONCEPT_USAGE(Addable) {
        return_type(x + y); // Check addition `T operator+(T x, T y)`.
    }
};

struct pod {};

int main() {
    pod sum; // Can't be added.
    int factor = 10;

    BOOST_LOCAL_FUNCTION(
    (void) (add)( (double)(num) (const bind)((factor)) (bind)((&sum)) )
    ) {
        // In here `sum_type` and `factor_type` are the types of the
respective bound parameters.
        BOOST_CONCEPT_ASSERT((Addable<sum_type>));

        sum = sum + factor * num; // Error because `sum`'s type can't
be added :(
    } BOOST_LOCAL_FUNCTION_END(add)

    add(100.0);

    return 0;
}

On GCC:

$ g++ -Wall -Werror -I../../.. concepts.00.cpp
concepts.00.cpp: In static member function ‘static void
main()::boost_local_auxXfunctorXadd::boost_local_auxXbody(main()::boost_local_auxXfunctorXadd&,
int, main()::boost_se_capture_t_1_add35&, double)’:
concepts.00.cpp:39: error: no match for ‘operator+’ in ‘sum +
(#‘float_expr’ not supported by dump_expr#<expression error> * num)’
concepts.00.cpp: In destructor ‘Addable<T>::~Addable() [with T = pod]’:
/usr/include/boost/concept/detail/general.hpp:29:   instantiated from
‘static void boost::concept::requirement<Model>::failed() [with Model
= Addable<pod>]’
concepts.00.cpp:37:   instantiated from here
concepts.00.cpp:22: error: no match for ‘operator+’ in
‘((Addable<pod>*)this)->Addable<pod>::x +
((Addable<pod>*)this)->Addable<pod>::y’

Note: In this specific case even the GCC error without the concept
assert (error on line 39) is pretty clear but in general allowing
programmer to add concept specifications might lead to better error
reporting and a better specification of the local function.

--
Lorenzo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [local] Bound types for concepts, etc?

lcaminiti
On Sat, Feb 12, 2011 at 1:34 PM, Lorenzo Caminiti <[hidden email]> wrote:

> On Sun, Feb 6, 2011 at 2:25 PM, Mathias Gaunard
> <[hidden email]> wrote:
>> As I said, it does. With Boost.Local, you can still call polymorphic
>> functions on the variables captured from scope without specifying the types
>> of the arguments.
>
> I am thinking to provide the type of the bound parameters within the
> local function body as `<BOUND_PARAM_NAME>_type`. This way you can use
> such types to check concepts, etc...
>
> Is there value in this?
>
> #include <boost/local/function.hpp>
> #include <boost/concept_check.hpp>
> #include <iostream>
>
> template<typename T>
> class Addable {
>    T x;
>    T y;
>    void return_type(T); // Used to check addition returns type `T`.
> public:
>    BOOST_CONCEPT_USAGE(Addable) {
>        return_type(x + y); // Check addition `T operator+(T x, T y)`.
>    }
> };
>
> struct pod {};
>
> int main() {
>    pod sum; // Can't be added.
>    int factor = 10;
>
>    BOOST_LOCAL_FUNCTION(
>    (void) (add)( (double)(num) (const bind)((factor)) (bind)((&sum)) )
>    ) {
>        // In here `sum_type` and `factor_type` are the types of the
> respective bound parameters.
>        BOOST_CONCEPT_ASSERT((Addable<sum_type>));
>
>        sum = sum + factor * num; // Error because `sum`'s type can't
> be added :(
>    } BOOST_LOCAL_FUNCTION_END(add)
>
>    add(100.0);
>
>    return 0;
> }

Sorry, I forgot to mention... of course, with the new simplified
Boost.Local syntax and using C99 variadic macros, the above example
will actually become:

int main() {
    pod sum;
    int factor = 10;

    void BOOST_LOCAL_FUNCTION_PARAMS(double num, const bind factor, bind& sum) {
        BOOST_CONCEPT_ASSERT((Addable<sum_type>));

        sum = sum + factor * num;
    } BOOST_LOCAL_FUNCTION_NAME(add)

    add(100.0);

    return 0;
}

> On GCC:
>
> $ g++ -Wall -Werror -I../../.. concepts.00.cpp
> concepts.00.cpp: In static member function ‘static void
> main()::boost_local_auxXfunctorXadd::boost_local_auxXbody(main()::boost_local_auxXfunctorXadd&,
> int, main()::boost_se_capture_t_1_add35&, double)’:
> concepts.00.cpp:39: error: no match for ‘operator+’ in ‘sum +
> (#‘float_expr’ not supported by dump_expr#<expression error> * num)’
> concepts.00.cpp: In destructor ‘Addable<T>::~Addable() [with T = pod]’:
> /usr/include/boost/concept/detail/general.hpp:29:   instantiated from
> ‘static void boost::concept::requirement<Model>::failed() [with Model
> = Addable<pod>]’
> concepts.00.cpp:37:   instantiated from here
> concepts.00.cpp:22: error: no match for ‘operator+’ in
> ‘((Addable<pod>*)this)->Addable<pod>::x +
> ((Addable<pod>*)this)->Addable<pod>::y’
>
> Note: In this specific case even the GCC error without the concept
> assert (error on line 39) is pretty clear but in general allowing
> programmer to add concept specifications might lead to better error
> reporting and a better specification of the local function.

--
Lorenzo
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|

Re: [local] Bound types for concepts, etc?

Vicente Botet
In reply to this post by lcaminiti
Lorenzo Caminiti wrote
On Sun, Feb 6, 2011 at 2:25 PM, Mathias Gaunard
<mathias.gaunard@ens-lyon.org> wrote:
> As I said, it does. With Boost.Local, you can still call polymorphic
> functions on the variables captured from scope without specifying the types
> of the arguments.

I am thinking to provide the type of the bound parameters within the
local function body as `<BOUND_PARAM_NAME>_type`. This way you can use
such types to check concepts, etc...

Is there value in this?
Yes sure. What about adding a macro BOOST_LOCAL_TYPEOF that hides the name of the type and will allow you to change it if some constraints force appear in the future?

Best,
Vicente