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@hotmail.com> 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