Re: extending c++ classes and enumerations
perrog@gmail.com wrote:
James Kanze skrev:
perrog@gmail.com wrote:
In sum, if I understand correctly, you want something equivalent
to the implicit this-> you get within a class. I'll admit that
I've never found it a problem not having it outside the class.
C++ is build on top on C, and if I program in C++ I wan't to program in
C++, not in C because of C++'s syntax limitations.
Then you definitly want classes to be closed; access control is
the defining difference between C and C++, and not having
classes closed breaks it.
With syntax short-cuts I referring to the way C++ take care of object
initialisation, error checking, operands, implicit this-> pointer,
encapsulation, member function pointers, etc. and not only implicit
this-> pointer.
I'm adjusting my statement simply because I don't know how to express
myself. So now, I want something that helps my syntax preserve its
C++-ish notation, without taking help from plain C. Adding a free
function that simulates a class member function, would be to make
something in C that should be done in C++.
I think I understand. You want the code to look like C++, but
not to be able to exploit the real advantages of C++.
Try to understand: the differences between C and C++ have
nothing to do with syntax. The difference is encapsulation.
(The original difference, at any rate.) The fact that a class
definition is closed, that you cannot add to a class after the
fact, is a defining aspect of this difference. Remove that, and
you've got C.
[...]
And of course, you'd probably not subclass here---it's not
generally a good idea to derive from std::string, and in this
case, the relationship you're looking for is "implemented in
terms of", which means a member, and not a base class. Of
course, this means more typing, but it keeps the two different
abstractions separate. The result is code that is cleaner and
easier to understand.
Whether sub-classing std::string is god or bad; whether templates must
be trivial code or not; whether the situation is reasonable or not; is
somewhat uninteresting. What I wanted to touch is that ability to
extend classes can minimise the friction between libraries, since
libraries usually implement or models own container classes.
Which is a problem, but not a problem which can or should be
addressed by breaking the C++ object model.
Container models ("implemented in terms of") is neither something
uncommon or unrealistic, considering that you could treat C++'s generic
algorithms as a subset of this mechanism. However, I never use generic
algorithms, because operating system's APIs 1) didn't provided
std::iterators; and 2) sometimes provides similar functionality.
Are you trying to say class extension is useless, besides violating
against encapsulation?
Define extension. C++ offers controlled mechanisms for
extension, that in my experience work very well. The key word
is controlled. You can't do just anything.
could also be achieved by adding a member function to std::ostream.
:-)
Which would buy us?
Well, static non-member operator functions reminiscent some kind of
class extending:
R operator operator-id(F, ...) -> R F.operator-id(...)
so obviously you are already sold.
Static non-member functions (operator or not) cannot access
private members.
C++ has three function call syntaxes: one for free functions,
one for member functions, and one for overloaded operators. One
can argue that it doesn't need all three, that in particular,
there's no reason to have a different syntax for free functions
and member functions. But that is orthogonal to the idea of
being able to extend a class.
I don't see your point (and I haven't seen Ondrej's posting
yet), but derivation does NOT allow accessing private members.
That is the key point. The fact that a class is closed is a
basic principle in C++, and the basis of C++'s support for
encapsulation. Remove it, and there is no fundamental
difference between classes and namespaces.
That would be another possibility if namespace names could be combined
with class names to put constants and functions under its label scope.
But will free function automatically become class' member function,
then?
No. You don't seem to understand: the key difference between a
member function and a non-member function is that the member
function can access private parts of the class; the non-member
can't. And that making a class closed with respect to which
functions can access private elements is an essential part of
encapsulation. Thus, for example, a free function can access
private parts of the class, but only if it is declared friend
within the class.
If I may friendly mimic yourself :-). You've got this encapsulation
already, just with a slightly different syntax. Typedef your type in
the declaration header file and define the type in your implementation
file. Then use free functions taking a pointer to the type as first
parameter, rather than member functions. You can encapsulate to your
hearts desire. :-)
That's what we had to do in C. The problem is that it requires
all objects of the type to be dynamically allocated. And it
doesn't support inheritance.
Honesty, I don't understand why you react so largely about accessing
private members.
Because it is the fundamental property that separates C++ from
C. It is literally the original raison d'jtre of C++. Throw it
out, and you might as well use C.
Since a class extension would rather be a member of
the original class, and not a class derivation, it wouldn't access
violate more than the class itself accessing its private member. The
rationale about allowing extending is that you preserve C++ notation
and may put constants and functions in class' name scope, not breaking
the law.
On the other hand, since static non-member operator functions uses the
friend mechanism, it would be natural class extension followed that
pattern.
However, there are ways to bypass the encapsulation. #defining private
to public just before #including would do the trick.
Except that it isn't legal, and results in undefined behavior.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientie objet/
Beratung in objektorientierter Datenverarbeitung
9 place Simard, 78210 St.-Cyr-l'Icole, France, +33 (0)1 30 23 00 34
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]