On 14 Sep 2006 19:57:17 -0400, Carlos Moreno
<moreno_at_mochima_dot_com@mailinator.com> wrote in
comp.lang.c++.moderated:
Say that I have a C++ program that consists only of perfectly
valid C++ code (in other words, the program compiles and does
not invoke undefined behaviour).
If I now replace every single instance of the keyword private
with the keyword public (and I change *nothing else*), would
the behaviour of my program change? That is, in practical
terms, should I expect the behaviour of my program to change
when compiled with an *actual* compiler that is reasonably
compliant and reasonably high-quality?
I would not expect the behavior to change.
As a corollary: if I simply add, at the beginning of the
file, the following line:
#define private public
I am pretty sure that using a macro to redefine a keyword is undefined
in C++, but I will admit that I couldn't find that in a quick look at
the standard. But let's assume it does not, or your implementation
ignores it.
And change *nothing else*, would I expect the behaviour of
the program to change?
The behavior of the program should not change for any reason that I
can think of.
As a corollary of the corollary, how about using the compiler
switch -Dprivate="public" to introduce the #defined symbol
without touching the source code? (I guess this is exactly
the same as the previous case, right?)
Ignoring (possible) undefined behavior, and assuming that the compiler
option does what most compilers do with it, since the language does
not define this method of defining a macro, I still agree I would not
expect a change in behavior.
In all of the above: should I expect the generated machine
code to change? (assuming all the compiler switches and
optimization settings are exactly the same)
Here there's a much better chance of seeing a change, especially if
the class initially had public and private members before you changed
them all to public.
An object containing different access types may be laid out in an
implementation-defined manner. Changing the access specifiers may
cause the implementation to change the ordering of the members. This
would likely cause the machine code to change, as some instructions
might well include the offset in an address or as an index to a
pointer.
The answer that my mind gives me is: not sure about the
machine code; but for the behaviour of the prorgam: no,
it does not change -- I can't think of any reason why it
could change; but never say never, and I'm sure with the
armada of experts and gurus out there, if there is any
such reason, I will find out :-)
If necessary, please divide the answer into the following
two cases:
1) private is only used as class-member access specifier
2) private is also used for inheritance.
(I believe the answer NO is valid for both cases, but I'm
mostly interested in case (1), so if the answer is different,
please specify the reasoning for both cases).
Thanks for any comments,
Carlos
My vote is: behavior no; binary image maybe.
implementation defined behaviour. Consider
.....
dependant behaviour (which is OK). The implementation (and hence the
[ comp.lang.c++.moderated. First time posters: Do this! ]