Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-05-10 07:23:34


Daniel Wallin <dalwan01_at_[hidden]> writes:

> David Abrahams wrote:
>> Daniel Wallin <dalwan01_at_[hidden]> writes:
>>
>>
>>>David Abrahams wrote:
>>>I propose that the user tells index_result<> if the result of the
>>>default expression should be by reference, so that:
>>>
>>> index_result<.., int>::type whatever = p[x | 0];
>>>
>>>whatever stores a copy of 0 in the default-case, and stores a reference
>>>to p[x] otherwise.
>>>
>>> int default_ = ...;
>>> index_result<.., int const&>::type whatever = p[x | default_];
>>>
>>>See what I'm saying now? Am I missing the point?
>>
>>
>> That's not too bad.

Done now. I hate the name index_result, though. I was thinking maybe

     parameter::binding<p, key, default>::type

??

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

>> return by value in that case. However, that might come at the cost of
>> some efficiency if the user also happens to use a non-reference
>> variable:
>>
>> index_result<.., heavyweight_type>::type = p[x | rvalue_expr() ]
>>
>> Of course, when it's heavy the user will probably be using || for lazy
>> defaults, in which case, can we protect her?
>
> 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?

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk