C++Talk.NET

Guest · Posted: Fri May 11, 2007 4:46 am Post subject: C++ private/protected hack

Hey all. I would like some comments on yet another C++ "hack" that I
have employed in some work I have done (http://www.ischo.com/xrtti).
I had to employ this hack to "work around a limitation of the C++
language. I realize that I am doing something "dangerous" that is not
permitted by the language specification. However, I have a hard time
thinking of how a compiler could make what I am doing *not work*.
Here is the hack:

I needed for some generated code to have access to private members and
methods of a class. So I did the following at the top of my generated
code (before including the header that defines the class in question):

#define private public
#define protected public
// #define class struct

#include "ClassDefinitions.h"

The goal here is to compile my generated code such that it can call
methods of, and reference fields of, classes/structs defined in
ClassDefinitions.h.

Turns out that this works just perfectly, at least using g++. It's as
if every class in ClassDefinitions.h has been laid wide open for my
generated code to manipulate as I need it to.

I know that this is disallowed by the C++ standard - I have read that
specifically the C++ standard says that no macros are ever to be
defined that replace a C++ keyword with a different C++ keyword, or
something like that.

But the thing is - the preprocessor, unless it's be specifically coded
to enforce this C++ rule, will happily replace "private" with "public"
and "protected" with "public" before feeding the resulting code to the
compiler itself. So the compiler will never know that the classes
defined were ever specified with private or protected access. So I
can't see how a compiler, unless via the preprocessor having logic to
specifically disallow what I am doing, could ever *prevent* this hack
from working.

The only danger I can think of is that some compilers might lay out a
class's in-memory representation differently for public fields versus
private or protected fields. If the compiler does the obvious thing
of just considering each field in turn and putting it in sequence in
the class in the order in which they are enumerated in the class
definition, then it doesn't matter what access rights each field is
declared to have. However, there is nothing to prevent a compiler
from putting all public member variables at the "top" of the in-memory
layout of a class and all of the private member variables at the
"bottom" or something like that.

I just can't think of a good reason for a compiler to ever go through
the trouble of implementing extra logic to do this.

Also - if the compiler mangled the names of methods differently for
private methods versus public methods (including, say, the access
rights of the method in the mangled method name) then my technique
would not work for calling methods int he class in question either. I
don't see any reason why it would ever help a compiler to put the
access rights into the mangled name (since access rights cannot be
used in C++ to differentiate between two methods with the same name,
it doesn't help anything to encode these rights in the mangled name),
but I guess a naive or wasteful implementation could do this.

And - you'll notice that I commented out "#define class struct". This
was to try to give access to members of classes that never declared
access rights explicitly and just left the default of private access
on member variables and methods. In this case my #define macros
wouldn't help because they wouldn't change the class at all. But
#define class struct does help because it turns the class into a
struct, which is only different in that it has default public access
to members instead of default private.

The problem is, even though doing so should theoretically have zero
effects on the defined classes/structs, I found that some header files
produced errors when included in this way (notably, some of the C++
STL headers included with the GNU C++ compiler). I didn't investigate
too much to figure out what the actual error was and why it was
happening, I intend to do that later.

First - does anyone have any comments on this technique? I thought of
it myself but then in searching about this problem much later on found
that others have tried it too, and no one has said that it didn't work
for them (although I read something troubling once that seemed to
suggest that some of Microsoft's compilers produce different code
somehow when these macros are invoked - leave it to Microsoft to be
the one to break something that otherwise works for everyone else! -
but I haven't researched this thoroughly either).

Second - if you want to see if this technique works for your compiler,
here is a program to test it:

foo.h:
------------------------------------------------------------

class Foo
{
public:

Foo(int _a, int _b, int _c) : a(_a), b(_b), c(_c) { }

virtual ~Foo() { }

int GetC();

int a;

protected:

int GetCProtected();

int b;

private:

int GetCPrivate();

int c;
};
------------------------------------------------------------

foo.cpp:
------------------------------------------------------------
#include "foo.h"

int Foo::GetC()
{
return this->GetCPrivate();
}

int Foo::GetCProtected()
{
this->GetCPrivate();
}

int Foo::GetCPrivate()
{
return c;
}
------------------------------------------------------------

main.cpp:
------------------------------------------------------------
#include <stdio.h>

#define private public
#define protected public

#include "foo.h"

int main()
{
Foo f(10, 20, 30);

printf("f.a: %d\n", f.a);

printf("f.b: %d\n", f.b);

printf("f.c: %d\n", f.c);

printf("f.GetC(): %d\n", f.GetC());

printf("f.GetCProtected(): %d\n", f.GetCProtected());

printf("f.GetCPrivate(): %d\n", f.GetCPrivate());

return 0;
}
------------------------------------------------------------

Compile foo.cpp and main.cpp into a program and run it. If you get
the following output then this hack works for your compiler:

f.a: 10
f.b: 20
f.c: 30
f.GetC(): 30
f.GetCProtected(): 30
f.GetCPrivate(): 30

I'd be interested in knowing if this does or doesn't work for your
compiler. So far I have tried it only on g++ 4.1.1.

Thanks!
Bryan

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Ulrich Eckhardt · Guest

bji-ggcpp (AT) ischo (DOT) com wrote:

Daniel T. · Guest

bji-ggcpp (AT) ischo (DOT) com wrote:

Guest · Posted: Sat May 12, 2007 4:27 am Post subject: Re: C++ private/protected hack

On May 12, 11:43 am, Daniel Krügler <daniel.krueg...@googlemail.com>
wrote:

Guest · Posted: Sat May 12, 2007 4:28 am Post subject: Re: C++ private/protected hack

On May 11, 2:55 pm, bji-gg...@ischo.com wrote:

Guest · Posted: Sat May 12, 2007 4:30 am Post subject: Re: C++ private/protected hack

On May 12, 3:04 pm, "Daniel T." <danie...@earthlink.net> wrote:

Guest · Posted: Sat May 12, 2007 9:10 am Post subject: Re: C++ private/protected hack

On May 12, 4:28 pm, c...@mailvault.com wrote:

Bo Persson · Guest

bji-ggcpp (AT) ischo (DOT) com wrote:
:: On May 12, 11:43 am, Daniel Krügler <daniel.krueg...@googlemail.com>
:: wrote:
::: On 11 Mai, 22:48, John Moeller <fishc...@gmail.com> wrote:
::
:::: Actually, I believe that every access section has to have its data
:::: in contiguous memory. But don't quote me on that. (Can anyone
:::: confirm/clarify/correct?)
:::
::: The essence is given by 9.2/12:
:::
::: "Nonstatic data members of a (non-union) class declared without an
::: intervening access-specifier are allocated so that later members
::: have higher addresses within a class object. The order of
::: allocation of nonstatic data members separated by an
::: access-specifier is unspecified (11.1). Implementation alignment
::: requirements might cause two adjacent members not to be allocated
::: immediately after each other; so might requirements for space for
::: managing virtual functions (10.3) and virtual base classes (10.1)."
::
:: Do you have any idea what the rationale is for making "the order of
:: nonstatic data members separated by an access-specifier" unspecified?
:: I can't even fathom that. Why specify that the order of fields
:: without an intervening access specifier, but not fields with an
:: intervening access specifier? What is the benefit of allowing re-
:: ordering of fields which have different access specifiers? And -
:: does anyone know of a compiler that actually bothers to do this?

It is actually the other way round. C++ has to define the order of public
members (of structs specifically), because the C language does so. As soon
as we get to the C++ specific part of the language, we can cast away the
compatibility burden.

The general idea is to leave as much room as possible to the compiler, by
not imposing unnecessesary restrictions. Some of us rather have well
optimized code, than a predictable layout of the private member variables.

Bo Persson

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Guest · Posted: Sat May 12, 2007 9:10 am Post subject: Re: C++ private/protected hack

On May 12, 3:03 pm, John Moeller <fishc...@gmail.com> wrote:

Bo Persson · Guest

bji-ggcpp (AT) ischo (DOT) com wrote:
:: On May 12, 3:04 pm, "Daniel T." <danie...@earthlink.net> wrote:
::: bji-gg...@ischo.com wrote:
:::: Hey all. I would like some comments on yet another C++ "hack"
:::: that I have employed in some work I have done
:::: (http://www.ischo.com/xrtti). I had to employ this hack to "work
:::: around a limitation of the C++ language.
:::
::: I don't see any limitation of the language which this hack would
::: work around (even if it did work.) Could you be more specific?
::
:: Well calling it a "limitation" of C++ is somewhat overstating the
:: case. It's more that the compiler is "limiting" me from being able
:: to break the access specifier mechanism. I think of it only as a
:: limitation of C++ in that C++ does not provide a mechanism for
:: deciding that although access specifiers are useful, in this one
:: case, I want my code to be able to ignore them.

You can, if the classes involved decide to let you do it. You just cannot
force it upon everyone!

::
:: But you are right in the fundamental point that you are making, and
:: that is that there really is no limitation of C++ per se. It's kind
:: of like how in C++, you can't modify members of a const class
:: instance, but you can cast the const class to a non-const class and
:: then modify that. If C++ disallowed this casting-away the constness
:: of a pointer or reference, then it would be "limiting" in the same
:: way, although it would be technically correct and there certainly
:: could be an argument that this is the way it should be, and that
:: allowing casting away const-ness is broken.

You can't cast away constness on a class that is actually const. You can
cast away the constness of a pointer of reference only if the object
referred to is not actually const in itself. You are just modifying the
access, not the real object.

::
:: I guess the limitation I am talking about is the absence in C++ of a
:: "cast away private or protected access" mechanism, as there is for
:: const-ness. But once again, this really isn't a limitation per se,
:: it's just a strict feature of the language.

There is such a feature, the friend concept. The difference is that each
class has to define who are its friends, that is not up to the wannabe
"friends" to decide.

Think about it - if I write a class with some private data, I want to be in
control of all the updates of this piece of information. That might be
crucial to be able to guarantee the consistency of the object. Now, if some
other object could decide that it should have access to my data, how am
I to
handle that?

Bo Persson

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

Daniel T. · Guest

bji-ggcpp (AT) ischo (DOT) com wrote:

Guest · Posted: Sat May 12, 2007 7:01 pm Post subject: Re: C++ private/protected hack

On May 12, 3:15 am, bji-gg...@ischo.com wrote:

Seungbeom Kim · Guest

bji-ggcpp (AT) ischo (DOT) com wrote:

Sebastian Redl · Guest

On Fri, 11 May 2007 bji-ggcpp (AT) ischo (DOT) com wrote:

Sebastian Redl · Guest

On Sat, 12 May 2007 bji-ggcpp (AT) ischo (DOT) com wrote: