Re: C++ private/protected hack
{ Text wrapping corrected manually. -mod }
bji-ggcpp@ischo.com wrote:
I have a question for you: Why should I use your library with my C++
code when you egregiously flout the language's rules? Try making your
code work within the constraints of the language, and you'll probably
have something more powerful.
I cannot add better words!
I explain my position in another post. But to answer the question
directly: I would love to not have to flout the language rules to do
what I am trying to do. I honestly believe that the language rules
are a little pedantic and arbitrary in some areas and that
unfortunately leads to this conflict between what I am trying to do
and what C++ wants to let me do. If you can think of a way for me to
generate code that has access to private and protected members of
unrelated classes, and does NOT require decorating the unrelated
classes in question with friend declarations or macros or somesuch,
and that also complies with the rules of C++, please let me know, I
would be overjoyed to use it.
You described this as a limit in C++.
That is a little bit like describing keys as a limitation in house
technology.
The locks on the doors and windows were specifically designed to keep
out people that don't have keys. Similarly, access specifiers were
specifically designed to keep your tools OUT of my classes, unless
I grant them friendship.
You can't take my analogy too far, of course -- there's a huge difference
between locks and access specifiers. My point is that both of them were
put there intentionally.
In the case of C++ code, if users wanted to allow your tool to gain access,
they either wouldn't have used the keyword "private" -- or they would have
used the word "friend."
Please keep in mind that the ONLY function of access specifiers in C++
is to ASSIST the programmer in designing classes the interactions
between which are well specified and can be checked by the compiler.
I am all for that. But as a means of ASSISTING the programmer, if
there are edge cases (such as what I am trying to do) where the
feature is more of a hindrance than a benefit, then you may agree that
it is unfortunate that there is no way in C++ to work around this
issue.
I've occasionally used macros like yours to turn off access specifiers while
I was debugging code. And then I removed them later on that same day.
Honestly, if C++ had built-in full and complete runtime type
information, and also specified a serialized form for classes and
required compilers to be able to generate code to serialize objects,
then there would be no reason for me to try to bend the language rules
in these ways. I am hoping that if I can demonstrate the value of
such "natural" extensions to the language via my tool, then maybe
there will be some movement towards standardizing these things in the
language.
Maybe. I don't see that value yet, and I'm skeptical.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]