Re: C++14: Papers
On Thursday, May 30, 2013 10:59:08 AM UTC+1, =D6=F6 Tiib wrote:
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?
It makes sense. And comparing void* does that in C++.
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.
In real applications, there will be a number of "generic" base
classes: Serializable, etc. But it makes more sense to me for
the application to define them. The fact that I write class
Something shouldn't automatically lead to any inheritance.
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.
Exactly. The only reason they exist is for reasons of C
compatility.
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 the=
se
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.
And usually leads to errors, since the default copy constructor
and assignment operator don't do what we want.
--
James