Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-06-19 17:12:37

Tobias Schwinger <tschwinger_at_[hidden]> writes:

> Hi Dave,
> David Abrahams wrote:
>> I can only explain the reasons I chose a reference and not a pointer
>> in the context of Boost.Python: pointers can be null, but references
>> cannot, and you can never call a member function on a null pointer.
> We have to start a "bit further above" ;-).

I don't know what you mean.

> If we want to unify parameters and class type we have to either use a reference
> or a pointer to it for things to make sense.


> The by-value case (operator() member of a simple functor) is too unusual to make
> sense in general.

Not sure what you mean here. I don't think there's any case in which
a member function can reasonably have the target object passed by

> I also agree, that a reference is the more reasonable default.
> Further, it is attractive to have a reference (as opposed to a value) in the
> sequence because (e.g):
> // Let t be a variable of type T and some
> // T be some (member) function pointer/reference type
> function< typename function_type<plain_function,T>::type > x = t;
> // ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> // "rebinds" the subtypes of T to a plain_function
> will just work.


> I still don't think it is good to hard-wire this, though.


> If I understand your case correctly, you want remove const qualification of the
> class type (which are not there, currently - but planned):
> typename add_reference
> < typename remove_cv
> < typename remove_reference
> < typename function_type_class<T>::type
> // or typename at_c<sig,1>::type
> >::type
> >::type
> >::type

Yes, but I don't really think this library should make any special
allowances for my weird case. Boost.Python may not be able to use
this library anyway because of the need for vc6/7 compatibility, but
if it can, I'll strip the cv-qualification myself.

> Slightly better for those who want a pointer:
> typename add_pointer
> < typename remove_reference
> < typename function_type_class<T>::type
> // or typename at_c<sig,1>::type
> >::type
> >::type
> So I believe it is perhaps best to parametrize the decoartion we want on the
> class type:

I disagree. Too much parameterization is an impediment to usability.

[BTW, so is the endline layout you're using for nested templates.
There's little precedent for it anywhere that I've seen. You wouldn't

   ( bar
     ( baz(1)

would you?]

> Sidenote: I'm not entirely sure on the MPL-Lamda expression

Your posting didn't show one above, although I can guess what the example
you would have written would look like.

> - we could also use
> some kind of tag type or an enum, I guess. Or we use MPL-Lambda exressions, but
> only evaluate them as a fallback when there is no optimized specialization, as
> for add_reference<_>, add_pointer<_> and identity<_> (maybe even one to create
> an unqualified reference for the Boost.Python case). Thoughts welcome.
> template<typename T, typename ClassDecoration = add_reference<_> >
> struct function_type_signature;
> template<typename T, typename ClassDecoration = add_reference<_> >
> struct function_type_class;
> And if we want to add a unified one:
> template<typename T, typename ClassDecoartion = add_reference<_> >
> struct function_type_effective_parameters;
> (Jonathan Turkanis has suggested adding one like this. He also came up with
> "effective" for the name, which I happen to like).

Remind me again why you're still using the function_type_ prefix?

> And perhaps even:
> template<typename Tag, typename TypeOrTypes,
> typename ClassDecoartion = add_reference<_> >
> struct function_type;
> // ignores it, unless it specializes function_type_signature
                  ^^ ^^
                  what are these? Are they the same "it?"
> Revisiting the example from above we could say:
> function< typename function_type<plain_function,T,add_pointer<_> >::type >
> And easily even use our favourite proxy, e.g. a smart pointer...

Now that you bring that case up, parameterization starts to look a bit
more attractive. I'm still leary of going in that direction, though.

Dave Abrahams
Boost Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at