C++ private/protected hack - C++ Language (Moderated)

C++Talk.NET
C++ language newsgroups

Archives

FAQ

Memberlist

Usergroups

Profile

C++ private/protected hack
Goto page Previous 1, 2, 3 Next

C++Talk.NET Forum Index -> C++ Language (Moderated)

View previous topic :: View next topic

Author

Message

Guest

Posted: Sun May 13, 2007 2:49 am Post subject: Re: C++ private/protected hack

On May 13, 7:00 am, "Daniel T." <danie...@earthlink.net> wrote:

Quote:

bji-gg...@ischo.com wrote:
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 though, that this might explain why you have started to "sense
some hostility" in some people's responses. To call a mechinism designed
to help ensure safety a "limitation" is somewhat unkind IMHO.

But my point is this: the language and its constructs are just tools
to help programmers write good code more easily. If there were no
such thing as protected and private access specifiers in C++, one
could still write programs with all of the existing benefits of C++;
you could define exactly the same classes with exactly the same
properties and behaviors. The *only* benefit that protected and
private access specifiers give is that they let you tell the compiler
some things that it can use to prevent you from doing things that you
didn't mean to do. You define a field private in a class. Why do you
do this? You are making a note there that says, "I don't intend for
this field to be accessed directly by anybody outside this class;
using this field is more complex than simply setting and getting the
value, and I want all manipulation of this field to happen via methods
that this object is responsible for, because I only expect it to
understand how to safely manage this field." You could instead of
putting a private access specifier on the field, just put some nice
documentation around the field saying, "this field is not intended for
any other class to access, so don't." Now, as long as you obey the
contract that you yourself specified, and never access the field from
anywhere else, you'll get the exact same code behaving in the exact
same way as if you *had* put the private access specifier in.

What the private access specifier does, is allow you to tell the
*compiler* that you want *it* to help you enforce the access
mechanisms you want to be available for the field in question. Now
*it* can help you, the programmer out, by reminding you - via error
messages and by refusing to compile such code - that you broke the
contract that you set up, when you access this private member variable
outside of the class definition (and ouside of any friends).

All I am saying is, as the programmer, I would like to be able to have
more fine grained control over this. I would like to be able to tell
the compiler, yes, I know what I am doing; I know that I said that
nobody should access this field. But I have a need right here in this
other place to violate that, and trust me, I know what I am doing.
Please let me do it without giving me an error.

I am the programmer; why *shouldn't* I be allowed to tell the compiler
to do whatever I want it to do in this case? It's just helping me
enforce the rules, and in the rare circumstances where I need to do
something unusual, I don't want the compiler to prevent me from doing
it. I certainly don't mind having to annotate what I am doing very
heavily, so that it can be very clear to the compiler that I know that
I am violating what I said earlier when I made the field private; but
still I want to be able to do it.

An analogy would be, if I were some rich and famous person with a
bodyguard, and I gave the bodyguard a rule to follow: "no one is
allowed to ask me for my autograph." And 99.9% of the time, this
worked just how I wanted it to; as people tried to approach me in
public to ask for an autograph, the bodyguard (politely of course)
prevented them from doing so, on my behalf. But then one day, what if
I saw someone I really wanted to give my autograph to came up to me?
Do you think that I would like it if when I told my bodyguard, "hey, I
know I told you before that I didn't want anyone to ask for my
autograph - but this guy over there, he's ok. Let him through", he
responded, "nope, sorry - you told me before that no one can have your
autograph. I don't trust you to change your mind. I won't let him
come to you." No, I would not like that at all! I want the bodyguard
to work *for me*, not *against me*. I want to be able to give him
orders to follow as standing rules so that I don't have to be
instructing him all the time of exactly what to do. But I also want
to be able to override those orders in special circumstances.

This is how I am looking at the C++ compiler; it is an assistant which
helps me by following sensible standard rules, but in the rare cases
where I need to override it, I don't appreciate it outright refusing
to let me be the master.

Quote:

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.

The basic problem here is that the designer of the class found the
specifiers useful but you are deciding for him that he was wrong.

But I am the programmer. I have every right to decide that I can
refine previous rules that I gave (i.e. turning no one can access this
field, into "no one can access this field except this code over
here").

I know that "friend" is one mechanism to allow me to do this - but it
requires that the defining class declare the friendship. I just want
a mechanism where a different class gets to declare the friendship.
Yeah, I would have to use this with care because it would allow me to
easily violate rules about the class - but I am the programmer, I am
in charge - I think I should be allowed to do that!

And, I fully understand that my desire to do this is very, very much
the corner case instead of the rule. So I don't fault the C++
developers for not providing this mechanism that 99.9% of people would
never use. I'm just trying to explain what I meant when I said it was
a limitation for me.

Quote:

I personally don't think that there is any "extended runtime"
information that you could provide that would both be useful, and
require the breaking of access specifications. Maybe an example of use
would help?

Here is what I am trying to do:

* Provide a tool which parses C++ header files and for the class
definitions that it finds, generate "tables" (static C structures)
which can be fed to a runtime initialization routine to produce C++
objects which fully describe these classes. When I say "fully
describe", I mean give every knowable detail about the class. And
also - provide generic accessor methods for accessing all of the
fields and methods of a class.

* Use this information in a variety of ways, the first and foremost
being, to implement a serialization library. This library could be
implemented *one time*, as a library that could be linked into any
application willing to use the tool that I mentioned above, and that
would be able to serialize *any* class (note 1) given a pointer to an
instance of that class, and the extended type information that the
tool generated.

(note 1: it can't really work for *any* class. There are some rules
about how the class could be defined that would have to come into
play; I wish it weren't so, but it is)

I personally think that this would be a compelling tool; it would
allow me to never again have to even *think* about writing
serialization logic for any class that I ever define. I just have to
use the tool, and the library, and viola, I have serialization support
for any class I would ever care to write.

The alternative would be for the tool to generate custom serialization
logic for each class in question; the developer would have to declare
some method signature in their class (a serialize method of a known
signature), and the tool would simply generate the implementation
thereof. The benefit of this is that this method would naturally have
complety unfettered access to all data members of the class since it's
a method *of* the class. The disadvantage is that instead of
generating simple description tables, I have to generate custom code,
which I would expect would take much, much more code space.

Perhaps a hybrid approach would be best? What if the class had to
define a method called "getDescriptionTable" that would return exactly
the table that I said that the tool would generate? And instead of
generating a static table for each class, generate the implementation
of this method for each class, which would build up the table at
runtime? Basically I am suggesting a slight variation on the
technique that another poster suggested ("just make the class definer
put Load/Store method declarations in their class definition, and have
your tool generate the Load/Store method implementation") - instead of
generating the load/store code, I would generate the
"getDescriptorTable" code, and put all of the load/store/whatever
logic based on these tables in the library. So that instead of
generating custom load/store logic for every class, I would generate
custom "get all of the details about this class" logic that I could
use for whatever purpose I wanted to in whatever libraries I cared to
write.

I think this is a fantastic idea, except that it violates one rule
that I was hoping *so hard* to not have to violate: it requires
developers to decorate their class definitions with special method
declarations to support this. I would so much prefer to implement a
tool which could somehow make this happen without requiring the
developer to decorate their class definitions at all. But I guess it
is not possible ...

Thank you,
Bryan

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

Guest

Posted: Sun May 13, 2007 2:51 am Post subject: Re: C++ private/protected hack

On May 12, 9:14 pm, "Bo Persson" <b...@gmb.dk> wrote:

Quote:

bji-gg...@ischo.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.

But that's not what the paragraph that we are talking about says. It
isn't talking just about public members. It is talking about members
with any access specification for any class that have intervening
access specifiers. So it encompasses private and protected members
also, if they have access specifiers intervening.

It looks to me like what it says is, that each "group" of methods in
between access specifiers, regardless of what that access specifier
is, has to be lined up in increasing order in memory, but that the
groups themselves can be put in any order by the compiler.

I'm just wondering what the point of that is.

Quote:

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.

Fair enough; but the concept of what is a worthile restriction versus
what is better to be left up to the compiler to optimize, is the whole
question of what C++ should be.

It seems to me that the C++ standards body has decided that C++ should
be "highly optimizable", not "highly portable". Leaving these sorts
of things up to the compiler means that C++ code is not portable
between compilers. It seems ridiculous to think that the same code
compiled by two separate compilers for the same platform cannot
interoperate, but I guess that more people find optimization more
useful than interoperability.

Perhaps the C++ standard could give us the best of both worlds by
specifying a "compatibility" ABI that all compilers must support, and
allowing the compiler to also define its own ABI that is best
optimized for that platform, and leaving it up to the developer to
select which they want when they compiler their code.

Then the compatibility ABI could be so well-specified that people like
me could depend upon C++ object layout in memory and could implement
whatever cool "hacks" (these ones being perfectly legal instead of
illegal like the ones I proposed) we could think of to do wonderful
things with the language.

Thanks,
Bryan

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

Daniel T.
Guest

Posted: Sun May 13, 2007 6:36 pm Post subject: Re: C++ private/protected hack

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

Quote:

I am the programmer; why *shouldn't* I be allowed to tell the compiler
to do whatever I want it to do in this case?

You can. Simply declare a friend or make everything public. Of course if
you are *not* the programmer of the class in question, you shouldn't be
allowed to decide for him whether you can break his contract.

Quote:

An analogy would be, if I were some rich and famous person with a
bodyguard, and I gave the bodyguard a rule to follow: "no one is
allowed to ask me for my autograph." And 99.9% of the time, this
worked just how I wanted it to; as people tried to approach me in
public to ask for an autograph, the bodyguard (politely of course)
prevented them from doing so, on my behalf. But then one day, what if
I saw someone I really wanted to give my autograph to came up to me?
Do you think that I would like it if when I told my bodyguard, "hey, I
know I told you before that I didn't want anyone to ask for my
autograph - but this guy over there, he's ok. Let him through", he
responded, "nope, sorry - you told me before that no one can have your
autograph. I don't trust you to change your mind. I won't let him
come to you." No, I would not like that at all! I want the bodyguard
to work *for me*, not *against me*. I want to be able to give him
orders to follow as standing rules so that I don't have to be
instructing him all the time of exactly what to do. But I also want
to be able to override those orders in special circumstances.

Your analogy is apt. If *you* wanted that one person out of a thousand
to come to you, then *you* should be able to tell *your* bodyguard to
let him through. It should not be up to strangers to decide for you that
they are special. You have effectively described the "friend" mechanism.

Your basic problem is that you are assuming that only one programmer is
working on the project. If I'm the only one on the project, then I can
dispense with access specifiers (and in fact do... Python doesn't have
them.)

Quote:

No, you are *not* the programmer who wrote *my* class. It is not up to
you to summarily decide that *my* contract is void.

Quote:

What you want can't be done without the explicit help of the designers
of the classes. Even you admit that in your "note" above. So you want
the designers to obey a whole host of rules about how the class can be
defined but you don't want one of those rules to be "let so-and-so class
be a friend." What you are asking for is silly.

Quote:

I personally think that this would be a compelling tool; it would
allow me to never again have to even *think* about writing
serialization logic for any class that I ever define. I just have to
use the tool, and the library, and viola, I have serialization support
for any class I would ever care to write.

You have that all wrong. The tool would *require* you to constantly
think about writing your classes such that they will be compatible with
the tool.

Quote:

I think this is a fantastic idea, except that it violates one rule
that I was hoping *so hard* to not have to violate: it requires
developers to decorate their class definitions with special method
declarations to support this.

But, by your own admission above, your tool already requires developers
to conform to a whole host of rules in order to be compatible with it
*even if everything is public*!

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

Zeljko Vrba
Guest

Posted: Sun May 13, 2007 11:13 pm Post subject: Re: C++ private/protected hack

On 2007-05-13, bji-ggcpp (AT) ischo (DOT) com <bji-ggcpp (AT) ischo (DOT) com> wrote:

Quote:

I personally would not be interested in using debugging information
for reflection because of the drawbacks mentioned on that page
(program has to be built with debugging symbols, there are many
debugging formats used by different compilers, etc). But still it is
a very interesting idea nonetheless.

Yes, the diversity of debugging formats _is_ a problem. However, my
impression is that DWARF is pretty much standard on UNIX [which might
again be too limiting for you]. As for diversity of debug formats, you
can make a plugin interface so that new debugging formats can be
supported after the fact.

If you don't need reflection in run-time, then you can:

1. Compile with debug symbols
2. Use your tool which generates serialization/deserialization code for
each class in the program.
3. Compile once again, with same flags, but this time including your
(de)serialization code, but with no debug info.

Personally, I think that this is the most reliable approach, as you have
complete bit-level information about class layout. But you still may
encounter problems with eg. self-referencing classes which weren't designed
to be constructed from their bit-level representations, eg:

struct smth {
char *data;
char d[16];

smth() { data = d; }
};

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

Guest

Posted: Mon May 14, 2007 12:11 am Post subject: Re: C++ private/protected hack

On May 14, 6:28 am, Daniel Krügler <daniel.krueg...@googlemail.com>
wrote:

Quote:

This is a somewhat funny and contradictory point of view.
If you don't like selected feature of a language - simply
don't use them!

Well the problem is, that it is hard to avoid these features of the
language when everyone is using them so extensively. You end up
completely isolated and having to do everything yourself if you
require that only certain features of the language be used, because
you will then be unable to use the vast libraries of functionality
that others are providing.

This is what is disheartening; the realization that the standard usage
of C++ is moving in a direction that I don't like, and that if I want
to program in C++ and be a part of the global world of C++ developers
(which I do), then I will have to accept and work with the way that
the majority of developers are working. The very first comments I got
on my very first release of C++ code (just recently I released my
first version of the tool that I have been talking about) were, "why
aren't you using Boost and other standard C++ tools?", and "I won't
use your tool unless you make it more like mainstream C++".

I expect that if I try to fight the trends, these are the comments
that I will hear endlessly ...

Quote:

And if you really think that this language is too complex
for you, you should not use it. Please note that this is *not*
meant as an affront, I simply repeat your own description
without any form of degrading implication.

Now that is a form of reasoning that I simply cannot understand. If I
can find a way to use C++ that works great for me and that allows me
to do what I want to do, I still shouldn't use it? Because you think
that I must accept the entire language and subscribe to all of its
features before I should use any of them?

For what it's worth, I have written much, much C++ code using my own
paradigms for C++ programming, and I have found it all to be very
useful and worthwhile. You are saying that I should give up on this
because I don't like the features of the language that I am not
using? I think that the fact that it is working for me is proof that
it is a valid approach. It is true that I will have some difficulty
when it comes to trying to incorporate other tools into my software
that use styles of C++ that I don't like; but in each case, there will
be a tradeoff. I will still use external libraries and coding
techniques that I don't like, if I get signifcant benefit from them.

As an example of the type of C++ programming that I don't like, I just
randomly picked some example code off of the Boost web site:

//
// iter_swap:
// tests whether iterator is a proxying iterator or not, and
// uses optimal form accordingly:
//
namespace detail{

template <typename I>
static void do_swap(I one, I two, const boost::false_type&)
{
typedef typename std::iterator_traits<I>::value_type v_t;
v_t v = *one;
*one = *two;
*two = v;
}
template <typename I>
static void do_swap(I one, I two, const boost::true_type&)
{
using std::swap;
swap(*one, *two);
}

}

template <typename I1, typename I2>
inline void iter_swap(I1 one, I2 two)
{
//
// See is both arguments are non-proxying iterators,
// and if both iterator the same type:
//
typedef typename std::iterator_traits<I1>::reference r1_t;
typedef typename std::iterator_traits<I2>::reference r2_t;

typedef boost::integral_constant<bool,
::boost::is_reference<r1_t>::value
&& ::boost::is_reference<r2_t>::value
&& ::boost::is_same<r1_t, r2_t>::value> truth_type;

detail::do_swap(one, two, truth_type());
}

I realize that some may see this as a beautiful use a powerful feature
of C++ - templates - but I see it as gibberish. It is not the kind of
code I would ever want to use in my program. The amount of code that
has to be written, and the terseness and unreadability of so much of
it, just to get some type-safe swapping operation, is to me
unacceptable. Yeah I know, this code has many amazing properties when
considered in the larger context of C++: you can use types that have
overridden the operators involved and know that as long as your types
satisfy a certain contract, then *anything* can be swapped with the
correct operators invoked in the correct ways. Fantastic. But to me,
this is just far too much complexity for the result. You may look at
this one piece of code and say, this isn't so bad, I can understand
and use this, I just have to keep in mind all of the minute details
that aren't really called out explicitly here, but that I am always
aware of because I know the ins and outs of C++. But the problem is
that when you combine this with a thousand other similar such pieces
of code, you get a system in which the complexities are magnified a
thousandfold.

Yes, if you spend much time learning the complex details of such a
system, you can work within it just fine. Many, many C++ developers
do. But I start from the outset rejecting coding principles that
involve so much complexity. I follow some principles (only use
operator overloading in a very few select places, don't rely on copy
constructors except in a very few places, don't use templates except
in a relatively simple manner (which would never include something as
complex as type_traits!), don't use diamond-shaped inheritence
patterns - in fact don't use multiple inheritence at all unless
absolutely necessary, etc) that are just so diametrically opposed to
the "use every feature of the language to its fullest extent" approach
that I just cannot even begin to accept things like the example code I
have shown.

Now you may say, you are just inventing a complexity of your own; you
are just creating a set of rules about what you can and can't do which
are just as complex as the rules of how to use template programming
correctly, or operator overloading correctly, etc. I don't really
agree with that; I see my approach as fundamentally simpler, but I
don't mind that you and I don't agree on this. I am happy to let you
program your way if I can be left to program my way. The only thing
that is unfortunate (for me, not for you!) is that if my way is so
outside the norm, then I will be isolated and it will be difficult for
me to share my work with others and for them to share their work for
me, because although we are all using C++, I am using a different
"dialect", if you will, then the majority.

Quote:

It was a long time ago, in college, when a friend and I discussed C++
and we agreed that it was a language that gives you more than enough
rope to hang yourself. It seems like over the years the rope has
gotten longer and longer - so long in fact, that it's hard not to trip
and fall into a noose even with the greatest of care. It doesn't help
that everyone else's libraries, tools, and methodologies for C++ seem
to be getting better and better at making really hard-to-see and ever-
more-pervasive nooses :)

Taking this position you also forbid car-driving, street-walking
and similar stuff, because any inproper form of doing that can
lead to harm or possible early death.

I am only talking about restricting what *I do* with the language, not
what everyone else does. So I would only forbid car-driving, street-
walking, etc for *myself*, not for everyone else. I think this is
perfectly reasonable. The problems would then be similar to the
problems I am talking about with integrating with the C++ developer
community; if I decided that cars were too dangerous, then I would
find many situations awkward and difficult when dealing with others.
For example, if a group of friends wanted to go on a road trip I would
have to decline because by principle I refused to ride in cars. I
might suggest, hey let's walk there, I know it will take a few hours
but it is safer! But I would be foolish to expect that trying to get
everyone else to comply with my way of doing things would be
possible. So I would end up isolated and unable to participate in
many things.

I feel this way about C++ also, and in fact many aspects of modern
programming. XML is a good example. I have so many fundamental
problems with it, that I outright refuse to use it except when it is
forced upon me by someone else (for example, my Xrtti tool has to
parse XML because that's what the C++ parser that I use (gccxml)
outputs). If I had to have a configuration file for my program, I
would not use XML. And I *KNOW* that many people would then ask me,
"but why aren't you using XML for this configuration file? Everyone
else uses XML for these sorts of things!". And I would have to stand
alone, tied to my principles and my beliefs, that are outside of the
mainstream. That makes me sad, but honestly, I am a stubborn person
and I would rather be isolated and alone than spend my time fighting
with the uselessness that is XML!

Quote:

I don't consider these as "tricks". I assume that it is possible
to demand an astonishingly little efford on the user-side to
realize that. You already expressed that you don't like boost,
but IMO you should study e.g. its serialization library. It has
astonishingly little requirementson user-code to perform the task.

I have studied Boost's serialization library. I personally would not
use it because it requires me to write the serialization manually.
Yes, it gives me tools and shortcuts (in the form of overloaded C++
operators and template declarations and utility methods and things) to
help me do so, but fundamentally, at the end of the day, I have to be
the one going through every class and writing the serialization
operators for it. I have to be the one who remembers to, every time I
add a field to a class, update the serialize and deserialize methods
to include that method.

This may be a fine approach for many or most people and I would not
hold it against them if that's the way they wanted to do it. But I
thought I had a great idea - make it "just work" with little or no
maintainance on the part of the developer - and that is what I am
striving to do. And in trying to satisfy this principle, I wanted to
avoid the developer having to declare *anything* in their classes -
not even a friend specification. But I am seeing from the responses
to my posts that it's just *not going to work*, and I will have to
reconsider that aspect of it.

Also there is something that Boost serialization and all of the other
serialization libraries I have seen don't do; and that's deserialize
in a "streaming" manner. By which I mean, Boost serialization uses
blocking read techniques to load the contents of the class to
deserialize. It has to read in the entire serialized object in one
go. My approach does not require this; you can add whatever bytes of
the serialized form become available as they become available.

It would be difficult to add this latter feature using the Boost
approach, because it relies on sequential invocations of overloaded
operators that would be hard to concisely make work in this way.

Quote:

Although I have critized you a lot in this answer, I
would like to express that I praise the tone you
choose and this open - but friendly - discussion on
that problem.

Hey no problem. I don't mind the criticism, because I can see that I
deserve it.

Thank you for your response, it is very much appreciated,
Bryan

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

Old Wolf
Guest

Posted: Mon May 14, 2007 8:16 am Post subject: Re: C++ private/protected hack

On May 12, 4:27 pm, bji-gg...@ischo.com wrote:

Quote:

What is the benefit of allowing re-ordering of fields
which have different access specifiers?

Who knows? Who cares? The question you should
be asking, is: what is the benefit of restricting the
compiler to place the members in order in memory?

Without a good reason to restrict, there should not
be a restriction. Somehow I don't think that the
committee foresaw you might want to employ ugly
hacks to make your C++ programs work like Java
ones.

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

Old Wolf
Guest

Posted: Mon May 14, 2007 8:17 am Post subject: Re: C++ private/protected hack

On May 14, 6:29 am, bji-gg...@ischo.com wrote:

Quote:

Anyway, I have been convinced that I am going to have to work within
the bounds of valid C++. While I was somewhat enamoured with the idea
of using fancy tricks and hacks that I thought I was clever enough to
think up, I have been convinced by the clear thinking and good
arguments of people on this forum, that I should stick with valid
features instead of hacks. I was really in love with the idea of
providing a really seamless solution to serialization in C++, and I
will still try to keep it as seamless as I can, but I admit that I
cannot cheat the compiler as I am trying to do.

You may be able to learn from or build on this library, if you
haven't seen it already:
http://www.boost.org/libs/serialization/

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

Ulrich Eckhardt
Guest

Posted: Mon May 14, 2007 8:19 am Post subject: Re: C++ private/protected hack

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

Quote:

On May 11, 9:32 pm, Ulrich Eckhardt <eckha...@satorlaser.com> wrote:
bji-gg...@ischo.com wrote:
I needed for some generated code to have access to private members and
methods of a class.

Make it a friend.

Thank you very much for your response.

The reason that I don't want to make it a friend is that I am trying
to graft functionality onto a class without requiring any changes to
that class. Thus I want to auto-generate code that calls methods of
the class and accesses member variables, but does so "stealthily"
without the original class ever having to declare that it was a friend
of the generated code.

For this reason, I don't want to use friend.

You are aware that you are in fact modifying the code, right?

Quote:

Doesn't work. Firstly, not everything private is prefixed with
'private:', you yourself discovered. Secondly, one popular compiler
mangles the access specifier into the linker symbol.

Do you know what that popular compiler is? Please let me know.

IFAIK it's the whole series of MS' compilers plus at least Intel's in
compatibility mode for that one.

Quote:

That really bugs me. What benefit can it possibly give to the compiler to
include the access specifier in the mangled method names?

*shrug* - no idea.
Maybe they did it because they could, adding another protection against
people invoking UB in one way or the other, or maybe to give better
diagnostics.

Quote:

1.) The rtti hack isn't guaranteed to work for certain types of
virtual inheritence (although I tried everything I could think of, and
it always seems to work for my compiler - so I'm still not convinced
that this hack doesn't work in all cases)

2.) The offsetof hack doesn't work for virtual inheritence

3.) The accessor specifier hack doesn't work for some compilers, and
also messes up some template definitions

Hmmm, all those seem to inspect compiler/implementation specifics that
normally shouldn't matter to the user. What I would suggest is a
precompiler that generates the relevant information from the class
declarations without the need for questionable methods. Maybe it doesn't
fit, but at least it's worth thinking about.

Uli

--
Sator Laser GmbH
GeschÃ¤ftsfÃ¼hrer: Ronald Boers, Amtsgericht Hamburg HR B62 932

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

Sebastian Redl
Guest

Posted: Mon May 14, 2007 4:36 pm Post subject: Re: C++ private/protected hack

On Mon, 14 May 2007, Ulrich Eckhardt wrote:

Quote:

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

That really bugs me. What benefit can it possibly give to the compiler to
include the access specifier in the mangled method names?

*shrug* - no idea.
Maybe they did it because they could, adding another protection against
people invoking UB in one way or the other, or maybe to give better
diagnostics.

The #define private public hack breaks the ODR, because a compilation unit
containing it sees a different definition of the various classes than on
that doesn't contain it.

The standard doesn't *require* compilers to diagnose violations of the
ODR, but surely you cannot blame a compiler for actually doing it in at
least some cases.

Sebastian Redl

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

Guest

Posted: Mon May 14, 2007 10:38 pm Post subject: Re: C++ private/protected hack

On May 13, 6:11 pm, bji-gg...@ischo.com wrote:

Quote:

On May 14, 6:28 am, Daniel Krügler <daniel.krueg...@googlemail.com
wrote:

This is a somewhat funny and contradictory point of view.
If you don't like selected feature of a language - simply
don't use them!

Well the problem is, that it is hard to avoid these features of the
language when everyone is using them so extensively. You end up
completely isolated and having to do everything yourself if you
require that only certain features of the language be used, because
you will then be unable to use the vast libraries of functionality
that others are providing.

This is what is disheartening; the realization that the standard usage
of C++ is moving in a direction that I don't like, and that if I want
to program in C++ and be a part of the global world of C++ developers
(which I do), then I will have to accept and work with the way that
the majority of developers are working. The very first comments I got
on my very first release of C++ code (just recently I released my
first version of the tool that I have been talking about) were, "why
aren't you using Boost and other standard C++ tools?", and "I won't
use your tool unless you make it more like mainstream C++".

I expect that if I try to fight the trends, these are the comments
that I will hear endlessly ...

Sometimes you have to swim upstream. My efforts that way have
been rewarded by efficiency the boost library has, unfortunately,
not been able to match. www.webEbenezer.net/comparison.html

Not all of boost is as you describe. There are some libraries such
as Intrusive that aren't like that. Happily it turns out these
libraries
are more in line with the old school's understanding. You have to
chew the meat and spit the bones.

Quote:

I feel this way about C++ also, and in fact many aspects of modern
programming. XML is a good example. I have so many fundamental
problems with it, that I outright refuse to use it except when it is
forced upon me by someone else (for example, my Xrtti tool has to
parse XML because that's what the C++ parser that I use (gccxml)
outputs). If I had to have a configuration file for my program, I
would not use XML. And I *KNOW* that many people would then ask me,
"but why aren't you using XML for this configuration file? Everyone
else uses XML for these sorts of things!". And I would have to stand
alone, tied to my principles and my beliefs, that are outside of the
mainstream. That makes me sad, but honestly, I am a stubborn person
and I would rather be isolated and alone than spend my time fighting
with the uselessness that is XML!

I don't find much use for XML either. Originally I said your xrtti
would
have a very slow build process. If you ditch xml you will in the long
run be doing yourself a favor. Short term is another matter.
You sound like the prophet Elijah when you say would be isolated
and alone. He said something like that to God and God told him he
wasn't alone but had some 7,000 others who were standing up for
what they believed. Keep up the good work and don't drink the cool
aid.

Brian Wood

"All the world is just a narrow bridge. The most important
thing is
not to be afraid." Rebbe Nachman

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

Allan W
Guest

Posted: Tue May 15, 2007 1:25 am Post subject: Re: C++ private/protected hack

{ Text wrapping corrected manually. -mod }

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

Quote:

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."

Quote:

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.

Quote:

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! ]

Yannick Tremblay
Guest

Posted: Wed May 16, 2007 3:47 pm Post subject: Re: C++ private/protected hack

In article <1179017055.565362.98560 (AT) h2g2000hsg (DOT) googlegroups.com>,
<bji-ggcpp (AT) ischo (DOT) com> wrote:

Quote:

On May 13, 7:00 am, "Daniel T." <danie...@earthlink.net> wrote:
bji-gg...@ischo.com wrote:

All I am saying is, as the programmer, I would like to be able to have
more fine grained control over this. I would like to be able to tell
the compiler, yes, I know what I am doing; I know that I said that
nobody should access this field. But I have a need right here in this
other place to violate that, and trust me, I know what I am doing.
Please let me do it without giving me an error.

Key point: *You* didn't tell the compiler that nobody should access
this field. *I* did. *I* do not want *you* to tell the compiler that
what *I* told it to do is not valid. *I* decide that myself.

Quote:

I am the programmer; why *shouldn't* I be allowed to tell the compiler
to do whatever I want it to do in this case?

Because *you* didn't write the original class. Someone else did. If
you did, then that whole discussion would be pointless since you could
just have declared all these fields public in the first place.

Quote:

Wow! Your analogy is totally broken.

Let me rewrite it correctly:

*I* am the rich guy.
I employ a bodyguard and I told him not to let anybody touch me on
the right arm. I hate strangers touching me on the right arm.

As far as the bodyguard is concern, *you* are just some odd-ball
stranger. You have no right to tell the bodyguard to let you touch me
on the right arm. He is my bodyguard, not yours. The last thing I
want is for my bodyguard to take orders for anyone else than me unless
*I* have explicitely told my bodyguard to do so.

Now, If *I* wish, I can tell my bodyguard that you are my friend and
because of that it is OK if he lets you touch me on the right arm.
But this is my choice to make. Not yours.

Quote:

This is how I am looking at the C++ compiler; it is an assistant which
helps me by following sensible standard rules, but in the rare cases
where I need to override it, I don't appreciate it outright refusing
to let me be the master.

In your code, fine. But in my code, I do not want the compiler to let
you be the master. I want him do what I told him to do not what you
tell him to do.

Please, don't take it as an insult but have you ever worked on a
project where more than 2 or 3 engineers where involved? I feel that
if you had been involved in some large scale project, you would
understand the need for this kind of stuff a lot more.

Quote:

The basic problem here is that the designer of the class found the
specifiers useful but you are deciding for him that he was wrong.

But I am the programmer. I have every right to decide that I can
refine previous rules that I gave (i.e. turning no one can access this
field, into "no one can access this field except this code over
here").

No, you are not *the* programmer. You are not the designer of the
class. You may well be *a* programmer but you are not *the*
programmer. You are a user of the class. There is a very fundamental
difference between the two.

What you want to do is probably impossible anyway without insider
information into the design and implementation of a class.

Let's say I have a File class (please excuse bad design, it's just an
example for this specific purpose and about as simple as I could think
of) here's the header:

class File
{
public:
File(std::string const & filename);
~File();

std::vector<char> read();
// ... blah blah ... other useful public i/f

private:
std::string filename;
int fd;
}

Somewhere in my implementation, I open "filename" and cache the
resulting file descriptor in "fd". Where do I open() the file? Maybe
in the constructor, or maybe elsewhere as just-in-time. Do I close it
immediately? Maybe or maybe not. Maybe I implement that if fd is -1,
I need to open, if not, this means that the file is already open and I
can just read it. Do you know?

Now how do you plan to serialise this only from the headers even if
you have complete access to my private members?

How do you expect for your code to know that "int fd" should be set to
-1 (or whatever other magic number I chose in my implementation) in
your deserialisation rather than to the value it was set to when you
sneekily read my private internals?

Would your answer be the same if instead of calling it "int fd", I'd call
it "int theThing" ?

Yan

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

Guest

Posted: Thu May 17, 2007 1:10 am Post subject: Re: C++ private/protected hack

On May 17, 3:47 am, ytrem...@nyx.net (Yannick Tremblay) wrote:

Quote:

Key point: *You* didn't tell the compiler that nobody should access
this field. *I* did. *I* do not want *you* to tell the compiler that
what *I* told it to do is not valid. *I* decide that myself.

I am the programmer; why *shouldn't* I be allowed to tell the compiler
to do whatever I want it to do in this case?

Because *you* didn't write the original class. Someone else did. If
you did, then that whole discussion would be pointless since you could
just have declared all these fields public in the first place.

I've gotten this same sort of response in other emails. I guess it
highlights a difference of how I view code from how other people view
it. Did you realize that once you give me your class definitions and
your libraries, you are no longer in total control of them? Did you
know that there is no law against me using your classes in ways that
you did not intend? Did you know that I could write a "proxy" class
with the same exact structure, but with different access specifiers,
cast a pointer to your class to mine, and then modify the members of
your class, and that there's nothing you can do to stop me?

I find it interesting that people have repeatedly expressed this
concept of "ownership" of their classes. Once you release it, it's
not yours. It's not even your original header file in fact; it's a
copy of the header file. I could modify my copy directly and replace
"private" with "public" if I wanted to.

My point here is that this barrier you are speaking of, that I can't
try to get access to internals of classes that someone else has
defined, is wrong on the face of it; I most certainly can, and *will*,
if it solves my problem in the best way. If that leaves you feeling
violated, or that your intentions have been subverted for something
evil, then I most sincerely apologize. But don't take it personally.
And besides - my goal was not to subvert your classes; it was to
provide a tool that allowed *you* to subvert *your own* classes, in a
way that I thought might be useful to you.

Quote:

Please, don't take it as an insult but have you ever worked on a
project where more than 2 or 3 engineers where involved? I feel that
if you had been involved in some large scale project, you would
understand the need for this kind of stuff a lot more.

Yes I have. And let me respond with a question in turn: have you ever
tried to push the boundaries of a problem to try to come up with a
unique solution - or do you always just follow the rules that others
have set out for you?

And for what it's worth, I *do* understand the need for access
specifiers. Note that I repeatedly talked about how this was
something I wanted to do for a very special case, not something that I
would expect to be routine. The thing I am trying to do
(serialization of C++ classes) might actually best be accomplished by
adding some functionality to the compiler; but I am trying to find a
creative way to do it without having to modify the compiler. Note
that when I say "best accomplished" I fully recognize that there is no
single "best"; there is only "best given a set of requirements". I
believe that my requirements may best be served by some of the things
I am talking about; but I don't expect that yours necessarily, and I
would never argue that my approach is always the best way. I
therefore don't understand why other people think it is valid to argue
that my approach could never be the best way.

Quote:

There is something you need to understand: the compiler doesn't care
who wrote the code. I don't care either when it comes to the purposes
of my tool. Your code, my code, it doesn't make a difference in the
end. All that matters is that the resulting application work, and
that the code itself is maintainable. With every single approach you
can ever mention for anything programming-related, there are
tradeoffs, and my tool would be no different. It will make some code
easier to maintain and some code harder. It becomes a matter for the
developer to decide how and when to best apply it.

Quote:

What you want to do is probably impossible anyway without insider
information into the design and implementation of a class.

I realize that this is true, and I have already backed off of my
approach and said so in other posts here. I will use a C++-compliant
approach. I knew *from the start* that my approach was inherently
subject to portability issues because it made assumptions about how
the compiler would lay out C++ classes in memory, and how it would
generate code to access them, that might not be true for all
compilers. The thing is: it might also turn out to be true for all
compilers I care about. I would have to fully accept that I could at
any time have to alter my approach (or give up on it completely)
because the compiler could be changed at any time to foil what I am
doing. But what's wrong with taking calculated risks about these
things?

Anyway, don't get too hung up on this one particular hack because like
I said, I gave up on it (and all of the others). For my own personal
project, I wouldn't mind using these hacks. But for code which is
meant to be shared, I can certainly respect others' opinions that they
would not want such hacks to be used in code that they relied on.

Quote:

Let's say I have a File class (please excuse bad design, it's just an
example for this specific purpose and about as simple as I could think
of) here's the header:

class File
{
public:
File(std::string const & filename);
~File();

std::vector<char> read();
// ... blah blah ... other useful public i/f

private:
std::string filename;
int fd;

}

Somewhere in my implementation, I open "filename" and cache the
resulting file descriptor in "fd". Where do I open() the file? Maybe
in the constructor, or maybe elsewhere as just-in-time. Do I close it
immediately? Maybe or maybe not. Maybe I implement that if fd is -1,
I need to open, if not, this means that the file is already open and I
can just read it. Do you know?

Now how do you plan to serialise this only from the headers even if
you have complete access to my private members?

Look, I'm not stupid; I fully realize that there are going to be cases
where not all member variables make sense when serialized. I will
provide mechanisms for allowing the programmer to tell the serializer
what to do. My approach is one that will make serializing "trivially
serializable" classes completely and utterly trivial. But it will
still require programmer effort for "non-trivially serializable"
classes. Will this be a better or worse approach than something like
Boost, where every class to serialize requires progammer effort? I
don't know. Heck, it would be easily possible to have a tool which
generates Boost serialization methods automatically for those classes
that the programmer specifies, and thus get the benefits of
"serialization for free" along with the ability to manually manage
serialization where desired using the Boost approach. And if I wanted
to use a Boost-like serialization mechanism (which I don't), then this
would probably be the best way for me to implement such a tool.

By the way, I don't take offense at any of your posting.

Thank you,
Bryan

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

Stephen Howe
Guest

Posted: Thu May 17, 2007 8:19 am Post subject: Re: C++ private/protected hack

Quote:

And besides - my goal was not to subvert your classes; it was to
provide a tool that allowed *you* to subvert *your own* classes, in a
way that I thought might be useful to you.

But if we are using your tool and we have some 3rd-party class libraries,
your tool may subvert the use of 3rd-party class libraries when we did not
sign up to your design philosophy. Your approach means it is impossible to
use _both_ your tool and 3rd-party class libraries as your tool subverts
their header files.
And it would interesting to read the small print of whatever license is in
effect for the 3rd-party class library.

Quote:

You mean, I can push boundaries like overwriting memory I dont own,
dividing
by 0, reading and writing to the NULL pointer, writing an assignment
operator in terms of calling a destructor and copy constructor, those kind
of rules - all meant to be broken?

There are respectable "moral" C++ books by Scott Meyers, Marshall Cline,
Steve Dewhurst and generally if you go against the advice, your code
will be
less robust and you will get burnt. But they usually explore other choices
and point out why they are better - so it is not just laying down rules.

Quote:

Note that when I say "best accomplished" I fully recognize that there is
no
single "best"; there is only "best given a set of requirements". I
believe that my requirements may best be served by some of the things
I am talking about; but I don't expect that yours necessarily, and I
would never argue that my approach is always the best way. I
therefore don't understand why other people think it is valid to argue
that my approach could never be the best way.

It is not a case of "best". Many others offer solutions.
But the difference is they dont try and subvert the language.
I would not use any 3rd-party library that subverted the language even
if it
claimed it was the best.

Quote:

But work within the guidelines of the language.
Suppose you create a hack that "gets past" a compiler.
Your "hack" is still broken because as soon as the deficient compiler is
strengthened, your hack may no longer "work".
I regard any solution that stays within the guidelines of the language as
superior to your hack.

Stephen Howe

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

Guest

Posted: Thu May 17, 2007 8:20 am Post subject: Re: C++ private/protected hack

On May 14, 10:38 am, Sebastian Redl <e0226...@stud3.tuwien.ac.at>
wrote:

Quote:

On Sun, 13 May 2007 bji-gg...@ischo.com wrote:

I don't think the majority does. Quite on the contrary, we see it as a
workaround for a limitation of templates, but a necessary one because we
are not willing to sacrifice the performance or even the correctness of
the program. (Just because an object is swappable doesn't mean it's
copy-constructible. Without the template magic, the code wouldn't work for
objects that are the former, but not the latter.)

I read that professor Stroustrup thinks there are around 3 million C++
programmers out there. Are you sure you can speak for the majority?

Quote:

That makes me sad, but honestly, I am a stubborn person
and I would rather be isolated and alone than spend my time fighting
with the uselessness that is XML!

OT, but XML is overhyped, not useless.

It isn't OT IMO. One of the few ways to get meta/about information
in C++ uses gccxml. IMO he was rightly complaining about his
options.

Quote:

Right, but that doesn't mean there isn't a place for the "just works"
approach. There should be a way to indicate that you will write the
marshalling code for a given class by hand. The "just works" way
would still be used in many cases and it's use may increase as the
technology matures.

Quote:

I just don't think your "just works" approach is feasible or a good thing.

CORBA and others prove it is feasible. I enjoy not working with CORBA
so won't comment about the goodness part.

Quote:

Even Java requires developers to, at the very least, mark that their
classes are expected to be serialized.
Java has a long and complicated specification for object serialization. It
is trivial only for trivial objects and trivial serialization needs.http://java.sun.com/j2se/1.5.0/docs/guide/serialization/spec/serialTO...
This specification contains several things that affect the core language,
such as the ability of the serialization mechanism to bypass access
restrictions.

Also there is something that Boost serialization and all of the other
serialization libraries I have seen don't do; and that's deserialize
in a "streaming" manner. By which I mean, Boost serialization uses
blocking read techniques to load the contents of the class to
deserialize. It has to read in the entire serialized object in one
go. My approach does not require this; you can add whatever bytes of
the serialized form become available as they become available.

Again, I really don't think that's a good thing. A class is usable only
when all its invariants are fulfilled. A partially deserialized class is
worse than useless: it's dangerous.

I disagree, but acknowledge your point. Think in terms of messages
instead of objects. "I went tk prayr meeting. Be nacl around" is
better than nothing as long as you understand you didn't get the
whole thing. Sometimes you have to limp along and trust things
will work out.

Greetings from Saint Paul, Minnesota
Brian Wood

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

	C++Talk.NET Forum Index -> C++ Language (Moderated)	All times are GMT Goto page Previous 1, 2, 3 Next
Page 2 of 3