C++ Envy

C++ Envy

[SBS Engineering]

Tired of hearing about all those things that C++ can do that Ada87 can't?
Then here's a cute trick in C++ that you'll like:

#define private public
#include compromised_class.h
#define private private

Confused?  The above says that when compiling the class header for
compromised_class, all the private stuff will be public, and thus
available to the world.  A friend showed me the above, and quoted the
source as saying that eternal damnation was insufficient punishment...
Hard to argue with.

-- 
Pat Rogers
progers@acm.org

PS: Yes, yes, yes, I know all languages allow one to say silly and
questionable things.  If you're upset by this post, then get a life!

Re: C++ Envy

[Huayong YANG]

SBS Engineering (progers@Starbase.NeoSoft.COM) wrote:
> Tired of hearing about all those things that C++ can do that Ada87 can't?
> Then here's a cute trick in C++ that you'll like:

> #define private public
> #include compromised_class.h
> #define private private

> Confused?  The above says that when compiling the class header for
> compromised_class, all the private stuff will be public, and thus
> available to the world.  A friend showed me the above, and quoted the
> source as saying that eternal damnation was insufficient punishment...
> Hard to argue with.

Tell me how the above trick compromises the following class:

class T
{
  int an_item;
public:
  int another;
};

The data member an_item stays private, it seems to me.

--
Huayong

Re: C++ Envy

[Cyrille Comar]

yang@twain.ucs.umass.edu (Huayong YANG) writes:
: 
: Tell me how the above trick compromises the following class:
: 
: class T
: {
:   int an_item;
: public:
:   int another;
: };
: 
: The data member an_item stays private, it seems to me.
: 

what about using the proposed trick to redefine 'class' to be
'struct'. In which case, 'an_item' will become public, no?
-- 
------------------------------------------------------------------------
Cyrille Comar,                                  E-mail: comar@cs.nyu.edu
Gnat Project                                    US phone: (212) 998-3489

Re: C++ Envy

[Jay Martin]

yang@twain.ucs.umass.edu (Huayong YANG) writes:

:SBS Engineering (progers@Starbase.NeoSoft.COM) wrote
:: Tired of hearing about all those things that C++ can do that Ada87 can't?
:: Then here's a cute trick in C++ that you'll like:

:: #define private public
:: #include compromised_class.h
:: #define private private

:: Confused?  The above says that when compiling the class header for
:: compromised_class, all the private stuff will be public, and thus
:: available to the world.  A friend showed me the above, and quoted the
:: source as saying that eternal damnation was insufficient punishment...
:: Hard to argue with.

:Tell me how the above trick compromises the following class:

:class T
:{
:  int an_item;
:public:
:  int another;
:};

:The data member an_item stays private, it seems to me.

:--
:Huayong

Yeah it won't but for large classes I expect most C++-ers will use:

class T {
 public:
   ...
 private:
   ...
}//T//

style ala Coplien (Advanced C++:Prog Style and Idioms).

This is due to that fact that users of the class do not want
to have to skip over the top secret implementations details
to get to the class interface (public methods) when reading the
class.  Of course the typical C programmers who get orgasms
looking at super efficient implementation details may 
disagree.  Thus, I suspect that this trick will work with most
large classes. Jay

C++ Envy

[R.A.L Williams]

Look chaps, this is getting a bit silly. Assume that I want to change
the functionality of a piece of code that I've picked up from somewhere.
Why should I bother with sma****se tricks like the ones that have been
suggested? Why not dive in and hack the code! This technique also
works in Ada83 and Ada95!

The point about 'private' in C++ or Ada is that it is an indication to 
the user that part of the interface is NOT meant to be mucked about with.
You, the user, still have to have sufficient self-discipline not to
muck around with it. As an added bonus, the compiler will tell you
if you do it by accident. That's what it's for -- to pick up mistakes!

Bill Williams

Re: C++ Envy

[Robert Dewar]

Yes, I typed CFM for CM, sorry, configuration management.

If you don't precompile headers, then I don't see how a CM system easily
stops you using macros to subvert headers that are simply included (that's
what starting this particular thread as I remember).

Re: C++ Envy

[Jay M Martin]

I am confused : "Change the makefile?".  Suppose a programmer
is maintaining a piece of code (file) which includes "blah.h".  Now
the programmer needs to make a change to the code and being a
typical macho C type he thinks that "protection is for wimps" and
is sure that he could save a few pico seconds per hour if he could massage
the insides of the objects of the classes in blah.h directly.  So
he does the define trick in the file he is modifying and configures it.
Note that no changes need to be made to blah.h or the makefile. 
Of course, a year later after the C stud has gone to greener pastures
the classes in blah.h are changed causing all his code to break.

Jay
 

Re: C++ Envy

[David O'Brien]

Jay M Martin (jmartin@kaiwan009.kaiwan.com) wrote:
: I am confused : "Change the makefile?".  Suppose a programmer

: Note that no changes need to be made to blah.h or the makefile. 
: Of course, a year later after the C stud has gone to greener pastures
: the classes in blah.h are changed causing all his code to break.

I believe you are referring to my statement, so I'll respond.  You have
*missed* the point.  The point that was brought up originally is that
Ada would have better protection over this than C because of CM
(configuration management).  I stated that C has the same "protection"
because large C projects also use CM.  In Ada the macho programmer could
also change the file they were editing.  BUT, the point (for either
language) is CM would provide a traciblity that something was changed
and who did it.

Personally I find this example quite stupid.  Like someone else said,
"I'd just go change the class definition if is was pissing me off that
much.".  This is quite a contrived example.  Granted it is quite
interesting in that fact that someone would think of this, and that it
is so simple.  But that is it, period.

From the way you wrote, I'd say you have some hostility toward C++
programmers.

-- David O'Brien	(dobrien@seas.gwu.edu)

Re: C++ Envy

[Jay M Martin]

>Personally I find this example quite stupid.  Like someone else said,
>"I'd just go change the class definition if is was pissing me off that
>much.".  This is quite a contrived example.  Granted it is quite
>interesting in that fact that someone would think of this, and that it
>is so simple.  But that is it, period.

Do you understand configuration management?  You can't just go and
change the header file, it is protected.  Changing it would require
a special form signed by the President, Bozo the Clown,the Pope and their
Moms.

>From the way you wrote, I'd say you have some hostility toward C++
>programmers.

Only incompetent ones (most C programmers).

Re: C++ Envy

[Robert Dewar]

David O'Brien says

  "I'd just go change the class definition if is was pissing me off that much."

Two comments. First this kind of attitude is of course anathema in a well
run environment. Second, it makes me think David doesn't understand what
a CM system does -- I guess a CM system which made it impossible to mess
around because he felt pissed off would really get him mad!

It's fascinating how people argue a point, and their style of argument and
the points they make provide the best possible argument for the opposite
point of view :-)

  "From the way you wrote, I'd say you have some hostility toward C++
  programmers"

No, just hostility to programmers who feel they can break the rules whenever
they get pissed off :-)

Re: C++ Envy

[Jules]

In article <jmartin.790756127@kaiwan009>,
	jmartin@kaiwan009.kaiwan.com (Jay M Martin) writes:
>
>Do you understand configuration management?  You can't just go and
>change the header file, it is protected.  Changing it would require
>a special form signed by the President, Bozo the Clown,the Pope and their
>Moms.

The original point of this thread was that you don't actually have to change
the header file itself to change its meaning in C/C++.
If you want to have access to some private members of a class in C++, you
merely have to write:

#define class struct
#define private public
#include <another.h>

and all the private members suddenly become public.
No changes to the header file. C++'s protection just ain't good enough.


-- 
/* Julian R Hall				csusb@csv.warwick.ac.uk
   
   Flames should be redirected to /dev/null - I don't know what
   I'm saying myself so don't expect it to make sense all the time!         */

Re: C++ Envy

[Charles H. Sampson]

In article <3fui32$q6g@gnat.cs.nyu.edu>, Robert Dewar <dewar@cs.nyu.edu> wrote:
>David O'Brien says
>
>  "I'd just go change the class definition if is was pissing me off that much."
>
>Two comments. First this kind of attitude is of course anathema in a well
>run environment. Second, it makes me think David doesn't understand what
>a CM system does -- I guess a CM system which made it impossible to mess
>around because he felt pissed off would really get him mad!
>
>It's fascinating how people argue a point, and their style of argument and
>the points they make provide the best possible argument for the opposite
>point of view :-)
>
>  "From the way you wrote, I'd say you have some hostility toward C++
>  programmers"
>
>No, just hostility to programmers who feel they can break the rules whenever
>they get pissed off :-)
>
     Rules?  What rules?  Real programmers don't need no rules.  They
just write code to get the job done.  Rules are for wimps who don't
understand their job well enough to do it by themselves.  :-)

				Charlie

Re: C++ Envy

[Robert A Duff]

In article <3g0evo$1h2@borage.csv.warwick.ac.uk>,
Jules <csusb@csv.warwick.ac.uk> wrote:
>The original point of this thread was that you don't actually have to change
>the header file itself to change its meaning in C/C++.

True, but this seems like a minor point to me.  No language can protect
against blatantly irresponsible coding tricks.  Languages should instead
try to prevent problems that happen by accident, as most bugs do.  How
could you accidentally use the trick being discussed?

Anyway, the same is true of Ada: you don't have to change an Ada library
package in order to access its private data, and thereby change its
meaning.  You can, for example, use Unchecked_Conversion for that
purpose.  Or, you can simply write a child unit.  But neither of those
can be done by accident.

- Bob

Re: C++ Envy

[David O'Brien]

In article <3fui32$q6g@gnat.cs.nyu.edu> you wrote:
: David O'Brien says

:: "I'd just go change the class definition if is was pissing me off that much."

: Two comments. First this kind of attitude is of course anathema in a well
: run environment. Second, it makes me think David doesn't understand what
: a CM system does -- I guess a CM system which made it impossible to mess
: around because he felt pissed off would really get him mad!

Ok, I have been mis-understood.  Let me set this up.

A team of us are working on a project.  We have a CM tool.  Assume the
usual C/C++ tools like make.  Ok, since the Makefile is so important to
producing our program, it is under CM just like all the rest of our
source code and headers.  Like any project that is concerned with CM,
there are "official" builds built by a tech lead, QA, CM, who ever.  The
Makefile and source code used for these builds come from the CM tool.
(Correct me if this isn't setup correctly...)

Now, Jim-Bob has written a class and private/protected some member
function or attribute I want to access directly.  So I decide to use the
wrapper header suggested, to get around the type protection.

How am I going to compile the beast now?  I have to edit the Makefile so
that my wrapper header can be added as a dependency to *my* module.  (Or,
I use scandeps/etc. to automaticly look at the includes and do this
for me.)

After all this, I am happy with my module.  Time to check it back into
CM.  This must include my wrapper header, or else the program won't be
compilable by anyone else (especially the "official" person).  BINGO,
what do you have???  Traceability!  You know who the fool was, and when
the change occurred.  The next CM report will tell all.

Someone earlier said that you could remove the protections from Ada by
just editing the source file.  You said that CM protected this from
happening.  How is that different for C ???

:   "From the way you wrote, I'd say you have some hostility toward C++
:   programmers"

: No, just hostility to programmers who feel they can break the rules whenever
: they get pissed off :-)

btw, I didn't say *I* wanted to mess around.  I said that rather than
play all these _games_ to get around the protection, I'd just head
straight to the source and do it in a [slightly] more legitimized way.
My being "pissed off" applies to how ridiculous this thread has become
with "oh, this is _terrible_".

-- David O'Brien	(dobrien@seas.gwu.edu)

Re: C++ Envy

[Robert I. Eachus]

In article <D2xBAz.9pG@world.std.com> bobduff@world.std.com (Robert A Duff) writes:

 > True, but this seems like a minor point to me.  No language can protect
 > against blatantly irresponsible coding tricks.  Languages should instead
 > try to prevent problems that happen by accident, as most bugs do.  How
 > could you accidentally use the trick being discussed?

   Because it was in a .h file that was in a #include in some .h file
you included?

   The problem of conflicts between defines in a C or C++ library is a
serious one, and the convention of all defined names being all upper
case is a help, but in no way solves the problem.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: C++ Envy

[Jay Martin]

C Hackers response:

  "We don't need no stinking "wrapper headers"!

Jay

Re: C++ Envy

[Jay Martin]

The "infinite" powers of C/C++ allows us to guard against the evil
private->public redefinition, by placing the following in every
include file.

#ifdef private
  Warning! Warning! Idiot Alert!  (@)][$#@##$#$@^^^%$#%##!@)
#endif

(Hopefully won't compile or be defined into something that does,
  you never know with C)

Surely the C preprocessor must be the most powerful invention ever
created by mankind!  Snicker Jay.

Re: C++ Envy

[Chris Warack <sys mgr>]

In article <3g4rkd$g07@cronkite.seas.gwu.edu> dobrien@seas.gwu.edu (David O'Brien) writes:
>In article <3fui32$q6g@gnat.cs.nyu.edu> you wrote:
>: David O'Brien says
>
>Ok, I have been mis-understood.  Let me set this up.
>
>A team of us are working on a project.  We have a CM tool.  Assume the
>usual C/C++ tools like make.  Ok, since the Makefile is so important to
>producing our program, it is under CM just like all the rest of our
>source code and headers.  Like any project that is concerned with CM,
>there are "official" builds built by a tech lead, QA, CM, who ever.  The
>Makefile and source code used for these builds come from the CM tool.
>(Correct me if this isn't setup correctly...)
>
>Now, Jim-Bob has written a class and private/protected some member
>function or attribute I want to access directly.  So I decide to use the
>wrapper header suggested, to get around the type protection.
>
>How am I going to compile the beast now?  I have to edit the Makefile so
>that my wrapper header can be added as a dependency to *my* module.  (Or,
>I use scandeps/etc. to automaticly look at the includes and do this
>for me.)
>
>After all this, I am happy with my module.  Time to check it back into
>CM.  This must include my wrapper header, or else the program won't be
>compilable by anyone else (especially the "official" person).  BINGO,
>what do you have???  Traceability!  You know who the fool was, and when
>the change occurred.  The next CM report will tell all.

But, traceability doesn't do anything for you three years later when the
problem would occur -- maintenance changes the rep in the basic abstraction
and your code blows up.  As you point out, where >>your<< code is concerned
the CM system only provides traceability and version control.

>Someone earlier said that you could remove the protections from Ada by
>just editing the source file.  You said that CM protected this from
>happening.  How is that different for C ???

If you aren't supposed to be working on that module, you cannot check it
out.  When its >>Not<< your code, the CM system should require "clearance"
for you to check it out.  In Ada the only way to break the abstraction
is through changing the abstraction's code (or using unchecked conversion*).
In C, that is not true.

*Checking for use of unchecked conversion is extremely easy to automate.
Any module with a dependency on unchecked conversion (a with context clause)
are an inclusive set of the modules using it.  These can be routinely checked
to determine legitimate uses of unchecked conversion (like network comm.) with
illegitimate uses (like the thread discusses).

>:   "From the way you wrote, I'd say you have some hostility toward C++
>:   programmers"
>
>: No, just hostility to programmers who feel they can break the rules whenever
>: they get pissed off :-)
>
>btw, I didn't say *I* wanted to mess around.  I said that rather than
>play all these _games_ to get around the protection, I'd just head
>straight to the source and do it in a [slightly] more legitimized way.
>My being "pissed off" applies to how ridiculous this thread has become
>with "oh, this is _terrible_".

Well, if it never happened, it would be ridiculous... :-/

The bottom line:  In an Ada system with the checks outlined above, if a
programmer wants to change the behavior of an abstraction, they >>have<<
to get the idea through the CM system.  In many other languages, this is
not the case.  If the CM system says no (or the programmer never asks),
they can hack a work-around that would not be noticed until a maintenance
problem occurred.

Caveat:  If the project uses code inspections, then these hacks might be
noticed.  Inspections are a lot more expensive than automation, however.
I'd bet in most critical systems, you'd probably be doing inspections.

Finally, I don't believe cases like this are driven from mischief
either.  If people don't think something (like CM and speed limits) is
important, they tend to ignore it.  It seems that programmers (as a whole)
are more prone to this than other disciplines.

-- 
Christopher A. Warack, Capt, USAF
Computer Science Department, US Air Force Academy

cwarack@kirk.usafa.af.mil                (719) 472-2401

Re: C++ Envy

[Robert I. Eachus]

In article <3ge3ou$t0a@usafa2.usafa.af.mil> cwarack@picard.usafa.af.mil (Chris Warack <sys mgr>) writes:

 > Finally, I don't believe cases like this are driven from mischief
 > either.  If people don't think something (like CM and speed limits)
 > is important, they tend to ignore it.  It seems that programmers
 > (as a whole) are more prone to this than other disciplines.

    I agree with most of what Chris said, but I have to disagree with
this, at least on government contracts.  There are rogue programmers
who only look good because all the other programmers are suffering
from fixing their wild actions, but in general it is the managers who
cause the CM system to get bypassed.  In my experience, if a manager
has a choice between meeting schedule and keeping the configuration
under control, he will "do anything" to aviod the schedule slip.  The
poor programmers feel squeezed--they are the ones who have to deal
with the consequences--but that they have no choice.

    It is my firm belief that on many contracts, the best thing the
SPO can do is to from time to time put a gun to the project managers
head and tell him to take three weeks NOW and get the CM system back
in place.  I have worked projects where there were three or more
different versions of each build, and the software being used by the
programmers had little or no relation to the version the testers were
using.  (But each version had its own check in/check out protocol
enforced...)  All in the name of "meeting schedule."

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...