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

[Aleksey Loginov]

Alexander Stippler wrote:

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.

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]

Alexander Stippler wrote:

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.

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.

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.

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.

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.

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.

--

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