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 18:16:21

On 12/14/2015 7:57 PM, Emil Dotchevski wrote:
> On Mon, Dec 14, 2015 at 1:12 PM, Agustín K-ballo Bergé <
> kaballo86_at_[hidden]> wrote:
>
>> On 12/14/2015 5:53 PM, Emil Dotchevski wrote:
>>
>>> On Mon, Dec 14, 2015 at 4:46 AM, Agustín K-ballo Bergé <
>>>
>> 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);
>>>>      }
>>>>
>>>
>>> It can't be implemented that way because the type of the argument might
>>> not
>>> be copyable.
>>>
>>
>> Does this mean that the library explicitly supports movable-only types?
>> That's somewhat unexpected, given that the library requires all type
>> information necessary for embedded storage, but it's not a bad thing. It
>> would be good to add this information to the reference documentation.
>
> QVM is neutral wrt move semantics but views are non-copyable and
> non-movable because copy or move semantics would require a temporary
> object, which QVM views are carefully designed to avoid. You can assign to
> a view and it will convert to any compatible type, but you can't copy or
> move it. That's why you can chain views up with no overhead: any operation
> on a view or multiple chained views works with the original object, no
> other objects are created.

Views are special, that has already been established. My question was 
not in regard of views, whose case I said is unsurprising. My question 
was with respect to this simple guy requiring the presence of a default 
constructor:

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

Why does this guy require a default constructor? Now you said the 
library cannot call a constructor other than the default one, which is 
not the case. So I wonder if you had experimented with this particular 
case, which does not conceptually require a default constructor, and for 
which the library is already calling another constructor, a copy/move 
constructor given the simple fact that it is being returned from a function.

Why does this guy require a default constructor? I understand now that 
it doesn't, you simply don't want to handle this case any different than 
you already do views. There's nothing wrong with that.

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