constructor ambiguity

[Alexander Stippler]

Hi

I have already posted and discussed the following problems once, but
despite really helpful hints I did not get any further with my problem
(I at least learned, first to exactly consider why something does not
work instead of immediately searching for work arounds) . I have the
following code resulting in an ambiguity:
--------------------------------------------------------
template <typename Impl>
class Vector {};

template <typename Ref>
class VectorView : public Vector<VectorVi ew<Ref> >
{
public:
operator const Ref &() const { return _ref; }
private:
Ref _ref;
};

template <typename T>
class DenseVector : public Vector<DenseVec tor<T> >
{
public:
DenseVector() {}

template <typename Impl>
DenseVector(con st Vector<Impl> &rhs) {}

VectorView<Dens eVector<T> >
operator()(int from, int to) { return VectorView<Dens eVector<T>

(); }

};

int amin(const DenseVector<dou ble> &x) { return 1; }
int amin(const DenseVector<flo at> &x) { return -1; }

int main()
{
DenseVector<dou ble> x;
int i = amin(x(1,3));
}
--------------------------------------------------------
Some things are not really clear to me:

1) what causes the ambiguity. The conversion operator in
class VectorView returns a DenseVector<dou ble>. Why is any further
conversion considered as I have an exact matching function amin?

2) It's the templated constructor of DenseVector causing the trouble.
I cannot make it explicit, what would work in the example. Is there
another way to have this constructor, but prevent it from being
considered a candidate, if Impl is DenseVector<T2> ?

best regards,
Alex

[Alf P. Steinbach]

* Alexander Stippler:

I have already posted and discussed the following problems once, but
despite really helpful hints I did not get any further with my problem
(I at least learned, first to exactly consider why something does not
work instead of immediately searching for work arounds) . I have the
following code resulting in an ambiguity:
--------------------------------------------------------
template <typename Impl>
class Vector {};

template <typename Ref>
class VectorView : public Vector<VectorVi ew<Ref> >
{
public:
operator const Ref &() const { return _ref; }
private:
Ref _ref;
};

template <typename T>
class DenseVector : public Vector<DenseVec tor<T> >
{
public:
DenseVector() {}

template <typename Impl>
DenseVector(con st Vector<Impl> &rhs) {}

VectorView<Dens eVector<T> >
operator()(int from, int to) { return VectorView<Dens eVector<T>

(); } };

int amin(const DenseVector<dou ble> &x) { return 1; }
int amin(const DenseVector<flo at> &x) { return -1; }

int main()
{
DenseVector<dou ble> x;
int i = amin(x(1,3));
}
--------------------------------------------------------
Some things are not really clear to me:

1) what causes the ambiguity. The conversion operator in
class VectorView returns a DenseVector<dou ble>. Why is any further
conversion considered as I have an exact matching function amin?

Because the compiler must choose a conversion (you haven't specified
one), and there are three equally good candidates:

VectorView::ope rator const Ref() produces a DenseVector<dou ble>,

DenseVector<flo at>::DenseVecto r(x) produces a DenseVector<flo at>, and

DenseVector<dou ble>::DenseVect or(x) produces a DenseVector<dou ble>.

2) It's the templated constructor of DenseVector causing the trouble.
I cannot make it explicit, what would work in the example.
Why? It works just fine.

Is there
another way to have this constructor, but prevent it from being
considered a candidate, if Impl is DenseVector<T2> ?

I don't think so. You cannot have it as both an implicit conversion,
and as a non-implicit conversion. If you absolutely must have it then
you'll have to choose. But you haven't said what problem it's intended
to solve. Perhaps the real problem admits some acceptable solution.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Valentin Samko]

Alexander Stippler wrote:

Hi

I have already posted and discussed the following problems once, but
despite really helpful hints I did not get any further with my problem
(I at least learned, first to exactly consider why something does not
work instead of immediately searching for work arounds) . I have the
following code resulting in an ambiguity:
-------------------------------------------------------- template <typename Impl>
DenseVector(con st Vector<Impl> &rhs) {}

1) what causes the ambiguity. The conversion operator in
class VectorView returns a DenseVector<dou ble>. Why is any further
conversion considered as I have an exact matching function amin?

2) It's the templated constructor of DenseVector causing the trouble.
I cannot make it explicit, what would work in the example. Is there
another way to have this constructor, but prevent it from being
considered a candidate, if Impl is DenseVector<T2> ?

Yes, the problem is that you have a constructor which allows implicit conversion from any
DenseVector with any template parameter to any other DenseVector with any other template
parameter. Another reason to avoid non trivial implicit constructors.

Why can not you make it explicit?

--

Valentin Samko - http://www.valentinsamko.com

[Alexander Stippler]

In <43************ ***********@aut hen.white.readf reenews.net> Valentin
Samko wrote:

Alexander Stippler wrote:

Hi

I have already posted and discussed the following problems once, but
despite really helpful hints I did not get any further with my
problem (I at least learned, first to exactly consider why something
does not
work instead of immediately searching for work arounds) . I have the
following code resulting in an ambiguity:
--------------------------------------------------------

template <typename Impl>
DenseVector(con st Vector<Impl> &rhs) {}

1) what causes the ambiguity. The conversion operator in
class VectorView returns a DenseVector<dou ble>. Why is any further
conversion considered as I have an exact matching function amin?

2) It's the templated constructor of DenseVector causing the trouble.
I cannot make it explicit, what would work in the example. Is there
another way to have this constructor, but prevent it from being
considered a candidate, if Impl is DenseVector<T2> ?

Yes, the problem is that you have a constructor which allows implicit
conversion from any DenseVector with any template parameter to any
other DenseVector with any other template parameter. Another reason
to avoid non trivial implicit constructors.

Why can not you make it explicit?

--

Valentin Samko - http://www.valentinsamko.com

In principle you're right. But for my purposes the 'assign notation'
for constructor is the natural way. What I would really like is a
mixture of explicit and implicit:
an explicit constructor, but allowing "Object A = something;" as
implicit initialization. But I found a workaround for my problem:
giving the constructor a second argument with default initialization
and restricting the availability of the constructor by SFINAE for the
second argument. Thus I can explicitely control for wich
instantiations the constructor is available and for which not.
Thanks for your help.

regards,
Alex

[Valentin Samko]

Alexander Stippler wrote:

In principle you're right. But for my purposes the 'assign notation'
for constructor is the natural way. What I would really like is a
mixture of explicit and implicit:
an explicit constructor, but allowing "Object A = something;" as
implicit initialization. But I found a workaround for my problem:
giving the constructor a second argument with default initialization
and restricting the availability of the constructor by SFINAE for the
second argument. Thus I can explicitely control for wich
instantiations the constructor is available and for which not.
Thanks for your help.

I still do not understand why you can not make your constructor explicit. You could still
have "Object A(something)".

--

Valentin Samko - http://www.valentinsamko.com

[Alexander Stippler]

In <43************ ***********@aut hen.white.readf reenews.net> Valentin
Samko wrote:

Alexander Stippler wrote:

In principle you're right. But for my purposes the 'assign notation'
for constructor is the natural way. What I would really like is a
mixture of explicit and implicit:
an explicit constructor, but allowing "Object A = something;" as
implicit initialization. But I found a workaround for my problem:
giving the constructor a second argument with default initialization
and restricting the availability of the constructor by SFINAE for the
second argument. Thus I can explicitely control for wich
instantiations the constructor is available and for which not.
Thanks for your help.

I still do not understand why you can not make your constructor
explicit. You could still have "Object A(something)".

Quite simple. It's a math library. And I want to have natural
notation like
Vector b = A*x-y
and not
Vector b(Ax-y).
This library is already used in lectures for students with no C++
knowledge at all. And then explain why you can write
Vector b; b = A*x-y;
but not
Vector b = A*x-y;
By the way. It is not only a nice notation, but also really efficient
since it prevents all unneccessary copying and temporaries.
Our other posting deals with this topic. We HEAVILY rely on
the copy constructor optimization the standard allows. And since C++
would be terribly slow if an implementation would not utilize this
optimization, we wonder why in some circumstances this optimization
is not done.

regards,
Alex

[Valentin Samko]

Alexander Stippler wrote:

I still do not understand why you can not make your constructor
explicit. You could still have "Object A(something)".
Quite simple. It's a math library. And I want to have natural
notation like
Vector b = A*x-y
and not
Vector b(Ax-y).

If it is a math library, I would expect high performance, and
Vector b = A*x - y;
is likely to be much slower than
Vector b = A;
b *= x;
x -= y;
as the first option may create two temporaries, and second option will not create any
temporaries.

Also, why do you need that constructor which accepts a template type at all? Why can't you
have a normal copy constructor?
This library is already used in lectures for students with no C++
knowledge at all. And then explain why you can write
Vector b; b = A*x-y;
but not
Vector b = A*x-y; You can definitely write this without your templated constructor as long as the type of
"A*x-y" is Vector.
By the way. It is not only a nice notation, but also really efficient
since it prevents all unneccessary copying and temporaries. How does it prevent all copying and temporaries? From what I see, it actually creates many
copies and temporaries (unless operator * returns a small proxy object, and you
overloaded operator - for that proxy object).
Our other posting deals with this topic. We HEAVILY rely on
the copy constructor optimization the standard allows. You can not really rely on NRVO/RVO, unless your library is not supposed to be used with
compilers which do not implement it.
And since C++
would be terribly slow if an implementation would not utilize this
optimization, we wonder why in some circumstances this optimization
is not done.

"C++ would be terribly slow" is a very generic comment. C++ is used for quite many years
without RVO/NRVO. By the way, even the newest compilers do not do RVO/NRVO if you return a
value from a function called in a function. For example:
struct A : public std::string { };
A foo() { A a; return a; }
int main() { A a = foo(); }
creates two objects of type A with VC++ 7.1, and only one with g++ 3.4, because g++
implements NRVO and VC++ does not.

But if we change "foo" to
A foo() { { A a; return a; } }
then you get a temporary with g++ as well.

--

Valentin Samko - http://val.samko.info

[Aleksey Loginov]

Alexander Stippler wrote:

In <43************ ***********@aut hen.white.readf reenews.net> Valentin
Samko wrote:

Alexander Stippler wrote:

In principle you're right. But for my purposes the 'assign notation'
for constructor is the natural way. What I would really like is a
mixture of explicit and implicit:
an explicit constructor, but allowing "Object A = something;" as
implicit initialization. But I found a workaround for my problem:
giving the constructor a second argument with default initialization
and restricting the availability of the constructor by SFINAE for the
second argument. Thus I can explicitely control for wich
instantiations the constructor is available and for which not.
Thanks for your help.
I still do not understand why you can not make your constructor
explicit. You could still have "Object A(something)".

Quite simple. It's a math library. And I want to have natural
notation like
Vector b = A*x-y
and not
Vector b(Ax-y).
This library is already used in lectures for students with no C++
knowledge at all. And then explain why you can write
Vector b; b = A*x-y;
but not
Vector b = A*x-y;
By the way. It is not only a nice notation, but also really efficient
since it prevents all unneccessary copying and temporaries.
Our other posting deals with this topic. We HEAVILY rely on
the copy constructor optimization the standard allows. And since C++
would be terribly slow if an implementation would not utilize this
optimization, we wonder why in some circumstances this optimization
is not done.

http://osl.iu.edu/~tveldhui/papers/E.../exprtmpl.html
regards,
Alex

[Alexander Stippler]

In <43************ ***********@aut hen.white.readf reenews.net> Valentin
Samko wrote:

Alexander Stippler wrote:

I still do not understand why you can not make your constructor
explicit. You could still have "Object A(something)".
Quite simple. It's a math library. And I want to have natural
notation like
Vector b = A*x-y
and not
Vector b(Ax-y).

If it is a math library, I would expect high performance, and
Vector b = A*x - y;
is likely to be much slower than
Vector b = A;
b *= x;
x -= y;
as the first option may create two temporaries, and second option will
not create any temporaries.

We take the first approach, nevertheless the line will not produce any
temporary object. The second approach does an assignment and two
updates as separated operations. We map the line above to simply
storage allocation and one call to the appropriate underlying BLAS
routine. So temporaries are only generated if an expression can't be
mapped directly and has to be split into two or more (In some situations
there will be temporaries though a mapping to a BLAS
routine exists if there were a neccessity to reorder it to get a
matching - but optimizations will take place here in future).
Also, why do you need that constructor which accepts a template type
at all? Why can't you have a normal copy constructor?

Just to realize the mechanism used above.

This library is already used in lectures for students with no C++
knowledge at all. And then explain why you can write
Vector b; b = A*x-y;
but not
Vector b = A*x-y;

You can definitely write this without your templated constructor as
long as the type of "A*x-y" is Vector.

not if it has to be explicit.

By the way. It is not only a nice notation, but also really efficient
since it prevents all unneccessary copying and temporaries.

How does it prevent all copying and temporaries? From what I see, it
actually creates many copies and temporaries (unless operator *
returns a small proxy object, and you overloaded operator - for that
proxy object).

A user shall not see anything of it, correct. The feature we post
about is just another litte feature of the library. So no need
to deal with operator mapping here.

Our other posting deals with this topic. We HEAVILY rely on
the copy constructor optimization the standard allows.

You can not really rely on NRVO/RVO, unless your library is not
supposed to be used with compilers which do not implement it.

And since C++
would be terribly slow if an implementation would not utilize this
optimization, we wonder why in some circumstances this optimization
is not done.

"C++ would be terribly slow" is a very generic comment. C++ is used

In our case even one additional copy of a matrix is two much if
avoidable. We talk about large scale matrices and vectors.

for quite many years without RVO/NRVO. By the way, even the newest compilers do not do RVO/NRVO if you return a value from a function
called in a function. For example: struct A : public std::string { };
A foo() { A a; return a; }
int main() { A a = foo(); }
creates two objects of type A with VC++ 7.1, and only one with g++ 3.4,
because g++ implements NRVO and VC++ does not.

But if we change "foo" to
A foo() { { A a; return a; } }
then you get a temporary with g++ as well.

--

Valentin Samko - http://val.samko.info

[Alexander Stippler]

In <11************ **********@g43g 2000cwa.googleg roups.com> Aleksey
Loginov wrote:

Alexander Stippler wrote:

In <43************ ***********@aut hen.white.readf reenews.net> Valentin
Samko wrote:

> Alexander Stippler wrote:
>
>> In principle you're right. But for my purposes the 'assign
>> notation' for constructor is the natural way. What I would really
>> like is a mixture of explicit and implicit: an explicit
>> constructor, but allowing "Object A = something;" as implicit
>> initialization. But I found a workaround for my problem: giving
>> the constructor a second argument with default initialization and
>> restricting the availability of the constructor by SFINAE for the
>> second argument. Thus I can explicitely control for wich
>> instantiations the constructor is available and for which not.
>> Thanks for your help.
>
> I still do not understand why you can not make your constructor
> explicit. You could still have "Object A(something)".
>

Quite simple. It's a math library. And I want to have natural
notation like
Vector b = A*x-y
and not
Vector b(Ax-y).
This library is already used in lectures for students with no C++
knowledge at all. And then explain why you can write
Vector b; b = A*x-y;
but not
Vector b = A*x-y;
By the way. It is not only a nice notation, but also really efficient
since it prevents all unneccessary copying and temporaries.
Our other posting deals with this topic. We HEAVILY rely on
the copy constructor optimization the standard allows. And since C++
would be terribly slow if an implementation would not utilize this
optimization, we wonder why in some circumstances this optimization
is not done.

http://osl.iu.edu/~tveldhui/papers/E.../exprtmpl.html

expression templates are a good choice in certain fields but have
their restrictions. Especially for large scale matrix-vector-products
they are IMHO not the best choice. And they are not flexible enough
for our purposes.

regards,
Alex