Boost logo

Boost :

From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-09-19 12:37:43

From: "Darin Adler" <darin_at_[hidden]>
> on 9/19/01 8:57 AM, Peter Dimov at pdimov_at_[hidden] wrote:
> > I'll try. 4p3 doesn't apply when e is already of type T. In this case
> > reference is bound directly to the argument (8.5.3/5.) See also
> >
> I agree that binding a reference to an lvalue does not involve implicit
> conversion. I thought we were talking about binding a reference to an
> rvalue.

In this case you are right, there is a qualification conversion involved,
since a pointer to a function is a non-class type.

> > I think that the intent of is to use argument deduction as in a
> > function call, with lvalues as expressions.
> I agree that it must be deduction as in a function call. I think this is a
> minor editorial issue, not a real ambiguity. For the other forms of
> deduction there are no arguments, only argument types. But
> specifically talks about synthesizing values to use as arguments. I don't
> agree with the comments of the people who submitted issue 214 to the core
> language issues list in sub-issue 2. Sub-issue 2 talks about using the
> directly and ignores the synthesized arguments. That seems to willfully
> ignore what the standard says.

I agree. However the other alternative is a lot simpler and more intuitive.
It says, in effect, "template argument A is more specialized than template
argument B when the set of possible types denoted by A is a subset of the
set of possible types denoted by B." So T * const & < T const &, but T * and
T const & don't order.

Many compilers actually implement this version.

> On the other hand, it doesn't seem to me that the synthesized values
> be treated as lvalues. When someone says "value of type int", it almost
> almost always means an rvalue, not an lvalue, unless that is specifically
> stated. Isn't that right?

Perhaps; I used to think so since an 'rvalue' of a reference type is an
'lvalue', so it makes sense for the non-reference arguments to be treated as
rvalues. But...

> template<typename T> void f(const T&);
> template<typename T> void f(T*) { }

... the problem is that when the second template uses a class type, the
reference might bind directly even to the rvalue; and the standard leaves
that as implementation-defined. We can't use something that is
implementation-defined to determine which function template is more

Peter Dimov
Multi Media Ltd.

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