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<VectorView<Ref> >
{
public:
operator const Ref &() const { return _ref; }
private:
Ref _ref;
};

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

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

(); }

};

int amin(const DenseVector<double> &x) { return 1; }
int amin(const DenseVector<float> &x) { return -1; }

int main()
{
DenseVector<double> 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<double>. 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

 

[Valentin Samko]

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(const Vector<Impl> &rhs) {}

1) what causes the ambiguity. The conversion operator in
class VectorView returns a DenseVector<double>. 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?

 

[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<VectorView<Ref> >
{
public:
operator const Ref &() const { return _ref; }
private:
Ref _ref;
};

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

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


};

int amin(const DenseVector<double> &x) { return 1; }
int amin(const DenseVector<float> &x) { return -1; }

int main()
{
DenseVector<double> 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<double>. 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:perator const Ref() produces a DenseVector<double>,

DenseVector<float>:enseVector(x) produces a DenseVector<float>, and

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.

 

[Alexander Stippler]

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?

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]

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

 

[Alexander Stippler]

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]

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.

 

[Aleksey Loginov]

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/Expression-Templates/exprtmpl.html

regards,
Alex

 

[Alexander Stippler]

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.

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.

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.

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

"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

 

[Alexander Stippler]

http://osl.iu.edu/~tveldhui/papers/Expression-Templates/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.

 

[Aleksey Loginov]

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.

Especially for "large scale matrix-vector-products" they are good
choice.
For tiny matrices you can implement auto_ptr-like class.

And they are not flexible enough for our purposes.

Expression templates very flexible.

 

[Valentin Samko]

We take the first approach, nevertheless the line will not produce any
temporary object.

And what does "A*x" return, if not a temporary?

The second approach does an assignment and two
updates as separated operations.

You need to do assignment and two updates anyway. The only question is whether you assign
the whole matrix, and do two updates, or you do assignment and two updates for each
element in the matrix (I understand that is what you do, and indeed this would be a bit
faster because of the CPU cache).

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

So, in some cases there will be temporaries, and you can not guarantee that the compiler
will optimise them away.

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.

So, you do return a small temporary proxy from all the operators, and then you overload
the assignment operator for your Vector to accept that proxy and do all the calculations
at that point. This is quite a standard technique, but it gets ugly with complicated
expressions, and it also has its limits. In other words, you are delaying the execution of
your expression until you actually need the final result.

In any case, you do not prevent any copying and temporaries, you just have lightweight
proxy temporaries, if I understand your library design.

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

Then why are you relying on compiler optimisations which you can not guarantee? I did some
work with large scale matrices, and it was much more important for me to guarantee the
performance, than the syntactic sugar. Also, my code was used on many platforms/compilers,
some of which were pretty old, without any performance problems.