Re: [boost] Formal review for QVM

Subject: Re: [boost] Formal review for QVM
From: Agustín K-ballo Bergé (kaballo86_at_[hidden])
Date: 2015-12-14 07:46:48

On 12/13/2015 9:07 PM, Emil Dotchevski wrote:
> On Sun, Dec 13, 2015 at 1:16 PM, Agustín K-ballo Bergé <
> kaballo86_at_[hidden]> wrote:
>
>> On 12/13/2015 5:13 PM, Emil Dotchevski wrote:
>>
>>> Yes, I'm interested to understand what brought this comment, though I am
>>> not sure that there is a solution. The problem is that QVM can't invoke
>>> constructors (other than the default constructor) for user-defined types,
>>> because different types could have different constructors (believe me,
>>> I've
>>> seen game programmers define some crazy matrix/vector constructors).
>>> Because functions like normalized() operate on user-defined types, they
>>> use
>>> the default constructor to make a local object before returning it by
>>> value.
>>>
>>
>> There's always the copy constructor, which I believe is already implicitly
>> required by the library. Have you experimented with this before?
>>
>
> Actually, there might not be a copy constructor. In QVM views are
> non-copyable. For example the return type of qvm::row and qvm::col, which
> present a row or a column of a matrix as a vector, return non-copyable
> types (which are still valid arguments for the normalized() function in
> question.)

That's odd, views as I know them are copyable and cheaply so, since they 
are shallow. I would expect those views you mention not only to be 
copyable, but to be trivially-copyable. Could you expand on that?

Anyways, I imagine calling `normalized` with one of those views either 
won't return something of that view's type, or it won't 
default-construct a view. Am I close here?

> Regardless, the copy constructor can't be used to create a vector from 3
> scalars. Perhaps I misunderstand you.

You say QVM can't invoke constructors other than the default constructor 
for user-defined types, but it already does call copy and move 
constructors already. Considering that, in the following call:

     myvec3 n = normalized(myvec3(1, 2, 3));

if the compiler says there is an error here because `normalized` needs a 
default constructor, I'm gonna start suspecting something wrong is going 
on with the library. This is what I would naively expect `normalized` to 
be doing:

    template <typename Vec>
    Vec normalized(Vec v) {
      return v /= length(v);
    }

Now I vaguely recall something about being able to explicitly specify 
the return type, or specializing some kind of deduction facilities, or 
at least another place were one wouldn't have a source value to copy 
from, where a default construction would be unsurprising.

Regards,
-- 
Agustín K-ballo Bergé.-
http://talesofcpp.fusionfenix.com