[boost] Re: parameters library and rvalue pitfall

From: Daniel Wallin (dalwan01_at_[hidden])
Date: 2005-05-10 17:49:01

David Abrahams wrote:
> Daniel Wallin <dalwan01_at_[hidden]> writes:
> 
> 
>>David Abrahams wrote:
>>
>>>Daniel Wallin <dalwan01_at_[hidden]> writes:
> 
> Done now.  I hate the name index_result, though.  I was thinking maybe
> 
>      parameter::binding<p, key, default>::type
> 
> ??

Sure. Maybe we should have two, so people who want to do metaprogramming
 doesn't have to remove_reference<>?

  binding<p, key, default>::type -> T | default
  binding_result<p, key, default>::type -> T& | default

?

>>>I think we might be able to make it a bit safer by detecting when the
>>>default is a non-const rvalue and having p[...] 
>>
>>Can we really detect that?
> 
> 
> I'm pretty sure that for all practical purposes, we can.
> 
>   struct fu
>   {
>       template <class T>
>       int operator|(T& x) const;
> 
>       template <class T>
>       char* operator|(T) const volatile;
>   };
> 
>   int a = 1;
>   int x = fu() | a;
>   char* y = fu() | 999;
> 
> Clearly you can also use a free function with enable_if to avoid the
> volatile interaction if you really care.

OK, cool.

>>There's only so much we can do. This case seems hard to get wrong for
>>the user.
> 
> 
> Well I guess ultimately you want a macro (ick, in this case) with
> decltype:
> 
>   binding<p, k, decltype(some_expression)>::type x = p[x | some_expression];
> 
> right?

Ultimately I would want to write:

  auto y = p[x | some_expression];

and have p[...] detect rvalues and return by value when appropriate. ;)

-- 
Daniel Wallin