Re: extending c++ classes and enumerations
perrog@gmail.com wrote:
James Kanze skrev:
perrog@gmail.com wrote:
Secondly, XML parser Expat can be a sample how difficult it is to read
such source. The first time I saw Expat source-code I thought it was
written in C++ and then preprocessed into C with some utility parser.
Thirdly, projects that uses "light C++" (not using RTTI, templates and
exceptions in the code) only use C++ for these "lexical benefits", and
I can give examples of such project.
Again, I don't know what "lexical benefits" you're talking
about. The important difference between class in C++ and struct
in C is access control, and allowing extension of a class blows
that away.
I'm sorry I'm using phrases like "lexical benefits" but I'm refering to
the way a C++ interface and implementation is specified in text files,
the practical part of encapsulation, operator overloading, and the way
they can be used by other sources.
I've taken the term from the very first optimization phase in GNU-C
compiler, where the "lexical optimizer" performs arithmetic
simplification, constant folding, local variable re-use, etc. Hope I'm
not mixing the term with another term.
I've never heard of lexical optimziation before, and the term
sounds almost like an oxymoron. I'm still not clear, either, as
to what you understand under "lexical benefits"; if you're
referring to the separation of implementation and interface,
there are doubtlessly better ways of doing this than the textual
inclusion model used by C++ (which, of course, should not be
used as an excuse for not doing it at all). And I don't see
where a generalized possibility to extend the class would change
much here, although it could be useful to be able to add
private, non-virtual functions (a case I mentionned in my first
posting).
Adding support for extending classes is hopefully a toll-free change if
it is limited to static and non-virtual functions.
Adding support for extending classes breaks encapsulation.
Completely and thoroughly. It returns C++ back to the level of
C.
Can you give any practical example of how encapsulation will be broken
if class extending is allowed? Not just that it breaks (your) idea of
encapsulation? :-)
Can you give a case where it wouldn't break encapsulation.
Anyone who feels like it adds a member function, and uses it to
access all of the private data of the class. It's quite the
opposite of encapsulation.
Perhaps the well-know sample of data abstraction and encapsulation is
the C++ STL library, adding new concepts as generic functions,
containers, iterators, adaptors, and function objects.
I'm not sure what you're referring to here. One of the guiding
principles in the STL part of the standard library seems to be
to use non-member functions whenever possible.
Rather than saying that extending classes will break data abstraction
and encapsulation, I would claim class extending takes these concepts
one step further.
By allowing just any and everybody to access private members?
We must have very different notions concerning encapsulation, if
you consider that encapsulation is improved by allowing anyone
to access all parts of you class.
As I mentionned in my first post, there is an argument for being
able to add private member functions to a class. But all in
all, classes that are complicated enough for it to make a
difference use the compilation firewall pattern anyway, so the
question is moot, and it wasn't deemed worth the effort.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, 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! ]