Re: C++14: Papers
On Thursday, 30 May 2013 00:38:50 UTC+3, James Kanze wrote:
On Friday, May 24, 2013 1:02:08 AM UTC+1, =D6=F6 Tiib wrote:
It means basically standardizing some common virtuals like 'equals',
'swap', 'clone', 'dump' and 'hash'. On most cases those could be made=
to default to something that makes sense:
'T* T::clone() const {return new T(*this);}'
I'm afraid I don't see the logic here. Consider equals. In
C++, this is spelled operator==, and it is implemented over a
large number of object types (like int, double, etc.). Making
everything derive from Object, and have a virtual function
equals, however, doesn't make sense: it means that you can
compare the incomparable, and only get an error at runtime,
rather than from the compiler.
The incomparable objects are not equal. Why it does not make sense?
I avoided operator== because that requires the objects to be
comparable or convertible to comparable.
I nowhere said that everything should derive from object. Only
the classes that for whatever reason have virtual functions can
be made to implicitly derive from object. The feature as I see it is
questionable feature for close to zero cost.
Similar comments apply to all of
the functions you define: they don't make sense across unrelated
types (and in some cases, don't make sense at all).
Most examples were common unary operations so why across different
types? Copy assignment and copy constructor do not also make sense
at all on lot of cases.
Not to mention that most classes in (well written) C++ don't
have virtual functions.
So such classes do not get those things that do not make sense
for them.
The advantages (and disadvantages) of it can be similar to other
implicitly available things. There is number of such things in C++
(like copy constructor or assignment operator) already. Sometimes these
are helpful.
Things like copy construction and assignment were originally
only present for reasons of C compatibility.
Regardless, we have now something. Something that is sometimes good to
have.