Re: extending c++ classes and enumerations
perrog@gmail.com wrote:
James Kanze skrev:
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).
Lets forget about all "lexical benefits" and use "C++ language
benefits", please. I'm not yet a compiler writer.
So, what do I mean with C++ language benefits? I'm refering to the
lexical, syntaxical and grammatical principles of the language, and
a) how classes encapsulate data and functions,
b) how classes and templates allows me to write less code than in plain
C (eg. instead of writeToFileInt8(), writeToFileUInt8(),
writeToFileInt16(), etc... utilizing templates.)
c) how classes can be combined and result in less written code (e.g
design patterns),
d) how the language helps getting faster insight in third-party source
code,
e) how classes and templates maps real scenarios to source code (e.g.
writing a USB driver with C++ device driver library),
f) how classes can be re-used in application, and
g) etc.
But you still haven't given a concrete example of exactly what
benefits you're referring to, and what C++ in particular offers
to provide those benefits. The main mechanism that C++ offers
for encapsulating data and functions is access control, and the
fact that a class is closed---that it cannot be extended.
(Namespaces, for example, to not provide nearly the same
benefits with regards to 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.
In theory, there is an intermediary form between "patching" the
originial class, and "sub-classing" the class.
In practice, there may be circumstances where some of the encapsulated
code contains code that isn't part of the real encapsulation. Take e.g.
the GNU implementation of basic_string, where there are lots of extra
code to make it work.
I don't have the complete implementation in my head, but from
what I remember, most of that "extra code" is in (private)
member classes. And of course, the implementation of
basic_string doesn't hesitate to make use of lower level
abstractions which are available (e.g. atomic_add, or whatever
the name is).
And I'm not sure what you're trying to get at. The GNU
implementation of basic_string most obviously doesn't need the
possibility to extend classes---the proof is that they
implemented it without implementing this ability.
The statement "the encapsulated code isn't part of the real
encapsulation" suggests that you're thinking along the lines of
something like the code in the StringUtils.hh file of
http://kanze.james.neuf.fr/doc/en/Text/html/index.html. (The
actual code can be found at
http://kanze.james.neuf.fr/code-en.html.) But there again, the
possibility to extend a class obviously isn't needed, since the
code exists, despite the lack of this possibility. Allowing the
extension of the class would have two effects on this code:
1. it would allow the user to write s.trim(), rather than
trim(s), and
2. it would allow the actual code of trim() to access the
private implementation of basic_string, and thus violate the
invariants of basic_string.
Point one could easily be handled by a simple extension allowing
the use of member function syntax for free functions (and why
not, the inverse as well); if such a proposal has never been
made, I suspect that it is because no one has really felt that
this was a problem which needed solving.
And point two, of course, breaks all notion of encapsulation.
Allow it, and you might as well go back to using C.
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.
And what about sub-classing, then? Since categories (extended classes)
apparently can be performed via sub-classing alike mechanism - as
Ondrej Novak and I showed earlier - the rationale becomes that C++'s
class hierarchy mechanism also violates against the encapsulation
principles.
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.
--
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! ]