Re: extending c++ classes and enumerations
perrog@gmail.com wrote:
James Kanze skrev:
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.
But classes aren't only used to encapsulate. Classes are also a name
scope.
That's not what they were designed for. And as you have
noticed, they aren't very good at it, because they are closed.
That's why namespace was added to the language. (Before
namespace, the "standard" solution for managing scope was naming
conventions. Which actually worked pretty well too.)
And templates can utilize name scopes. Thus, C++ has obviously
syntax limitations, when the only name scope you can extend is
namespaces. If class scope names should be sealed, then it feels like
the same logic should be applied to namespace names.
The roles of the two elements are different. Namespaces are
simply there to manage names. Classes are designed for
encapsulation.
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.
If you consider the class as a name scope, it's like you consider the
name scope be part of encapsulation; like it was a trademark.
If you consider the class as simply a name scope, you're not
writing C++. You've misunderstood the basic principles of the
language.
And if you consider the class be a C++ notational group (like the
arithmetic rules for the set of integer forms a group in algebra),
adding e.g. a free function makes you go outside this C++ notational
group, in this case plain C group. The side-effect of this I can come
up with is that free function pointers becomes orthogonal to member
function pointer (or to put it simply; they become different C++
types), but I don't exclude there are other drawbacks that I'm not
currently aware of.
Why do you want to consider a class as something it isn't. A
class is a unit of abstraction. That's its entire raison
d'jtre. If all you want is some sort of notational grouping,
struct's, namespaces, or even just a naming convention are
probably more what you are looking for.
On the other hand, if a member function was binary compatible with a
free function taking a pointer to the type as the first parameter, one
would be allowed to reinterpret_cast free and member function pointers.
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.
Well, I can't see this beeing a practical paradigm.
It's never the less the most widespread one in C. I'd say that
about 2/3 of my C struct's used it.
The result is, of course, that C++ code generally runs faster
than C, because I don't have to allocate everything on the heap.
Just put the
internal struct definitions in private headers, and then including
those base structure in derived's definition file, so that the derived
struct have access to its base struct.
Fortunately, C++ provides us with some syntax benefits when we trying
to achieve this.
Certainly. This is why C++ was developped. So that I could
have encapsulation without necessarily allocating everything on
the heap.
Of course, the fact that classes are sealed is essential if this
is to work.
--
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! ]