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 16:12:36

On 12/14/2015 5:53 PM, Emil Dotchevski wrote:
> On Mon, Dec 14, 2015 at 4:46 AM, Agustín K-ballo Bergé <
> kaballo86_at_[hidden]> wrote:
>
>> 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.)
>>>
>> 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?
>
> Calling normalized() on a view returns a type deduced by deduce_v, the
> default for views being a compatible instantiation of the qvm::vec<>
> template. Such types are required to be copyable and to have accessible
> default constructor.

Nod, this is one of the unsurprising cases I mentioned. Reinstating some 
snipped context:

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

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

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