A query : C++

[Chetan Raj]

Hi All,

One of my friend asked this question on C++

Hi,
Can u give an answer to this :

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

--Ankit

<<<

We all know that this will not be possible, beacuse the information
about the private variables will not be available in library (.lib or
..a files) and the linker will complain.

Can any one elaborate on this issue?

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

[Gianni Mariani]

Chetan Raj wrote:

Hi All,

One of my friend asked this question on C++

Hi,
Can u give an answer to this :

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?
More than likely it will work. However it is not required to work by
the standard. The standard requires that the definition of the class
remains identical in all compilation units that use it, so this is a
clear violation of that requirement. However, I don't believe I've
witnessed a compiler ever enforce that requirement.

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

--Ankit

<<<

We all know that this will not be possible, beacuse the information
about the private variables will not be available in library (.lib or
.a files) and the linker will complain.
There is nothing stopping you from resolving those conflicts in another
library/object file. However, you have a problem when a new revision of
the library comes out, it may be that the interface is changed such that
your code may need to be dramatically changed - not fun.

Can any one elaborate on this issue?

If anyone on my dev team were to do this, they would be severly chastized.

[James Daughtry]

Let's just say no and be done with it. If a class wants you to look at
its private parts, they will be protected and you can use inheritance.
Some standard libraries support non-standard functionality that allow
you to do just that. For the iostreams, you can extend them with
inheritance or without inheritance through streambufs, locales,
callbacks, and the xalloc/iword/pword mechanism.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Alf P. Steinbach]

* Chetan Raj:

One of my friend asked this question on C++

Hi,
Can u give an answer to this :

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

--Ankit
<<<

We all know that this will not be possible, beacuse the information
about the private variables will not be available in library (.lib or
.a files) and the linker will complain.

Nope, we don't all know that: you can access the private variables all you
want.

Instead of editing the header files you can duplicate the declarations.

Or whatever, including pointer hacking.

Can any one elaborate on this issue?

It's very simple. 'private' is protection against _inadvertent_ access of
private things, and helps to avoid name collisions. It's not a security
measure. Anyone can access anything if they're really determined.
'private' is not protecting against hacking: it is a design tool.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

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

[bala]

May be...

when u edit the interface, you just change it. The implementation is in
..a or .so files ( whatever). And you can't change it.

And i think, those .h'ss are read only and to be used when u write the
client code.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[ben]

Access control is a language mechanism for organizing large scale software
construction. The sole purpose of access control is to limit the number of
elements that can be affected from code change, i.e. if you decide to change
the implementation of a class, as long as you keep the public interface
unchanged, the only things affected by the change are the member functions
of that class and friend classes.

Yes you can change the header and get access to private member of library
code. But at what price? You don't get privilege doing that, and most
importantly, if you write 10000 lines of code that accesses to the private
member of a class, you'd hope that the class doesn't get updated because
otherwise you will have 10000 lines of code to review.

ben

"Chetan Raj" <hi*****@gmail.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...
[excess quoting deleted -- mod]

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

--Ankit

<<<

We all know that this will not be possible, beacuse the information
about the private variables will not be available in library (.lib or
.a files) and the linker will complain.

Can any one elaborate on this issue?

[excess quoting deleted --mod]

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

[Murali]

Chetan Raj wrote:

We have the .h files for standard library. Consider any class (such as ostream) declared in the .h files. Can I edit the .h file to declare my own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?
Without going into the merits of why you should do this, the answer
would be: Yes, you can edit the .h file and add a friend function
declaration
and access the private members of the class from that function. The
compiler will not complain.
If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.
Yes, but it is a very basic and important issue. Note that C++ access
specifiers are for data encapsulation and are not for preventing
intentional misuse.
We all know that this will not be possible, beacuse the information
about the private variables will not be available in library (.lib or
.a files) and the linker will complain.

If you change an existing class's definition in the header file in such
a way that it becomes incompatible with the one used by the library,
then you could be hit by any number of compilation errors and run-time
errors.
However, adding a friend declaration as mentioned above should not
cause the linker to complain.

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

[Allan W]

Chetan Raj wrote:

We have the .h files for standard library. Consider any class (such as ostream) declared in the .h files. Can I edit the .h file to declare my own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?
The standard doesn't say what will happen here. However, I've never
used a compiler where this wouldn't work (though I've heard of some
where some or all of the standard headers aren't literally text
files -- obviously it wouldn't work there).
If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.
Very destructive! Please don't do this unless you've found a bug in
the library that can be fixed just by editing header files. (Most
template code falls into this category.) Even then, please check for
official "patches" instead of fixing it yourself!
We all know that this will not be possible, beacuse the information
about the private variables will not be available in library (.lib or
.a files) and the linker will complain.

AFAIK, most compilers don't carry public/private information in object
code -- they rely on the One Definition Rule (ODR), and assume that
the header files have NOT been altered. Search the FAQ for "ODR".

Please don't literally edit the header files directly -- you'll find
it hard to get them "back to normal" when you come back to your senses.
(You might have to re-install the entire compiler.) Instead, use a
trick like this:

// Define SANITY when you have come to your senses
//#define SANITY
#if !defined(SANITY)
#define class struct
#define private public
#define protected public
#endif
#include <whatever>
// You now have access to all private members of ALL classes

Obviously UB (Undefined Behavior) is going to be different from one
compiler to the next. Theoretically this type of playing could affect
the way that data members are packed into a structure. But I think
that on many compilers this will do exactly what you probably expect!

So you can do this for toy programs. But, like any other UB, you
can assume that it's going to seem to "work" until it matters most --
probably the day after you've burned CD copies of your finished
programs and started shipping them to paying customers -- and then
it will do something nasty. Therefore you should avoid doing this
in production code!
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Hyman Rosen]

Chetan Raj wrote:

Can I edit the .h file to declare my own function as friend inside
the class declaration and then gain access to private data members
of ostream? Will the compiler allow this?

That's a quality of implementation issue. By having two different
definitions of a class in the same program, you are violating the
ODR (one-definition rule) and that causes undefined behavior.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Francis Glassborow]

In article <11*********************@o13g2000cwo.googlegroups. com>,
Chetan Raj <hi*****@gmail.com> writes

Hi All,

One of my friend asked this question on C++

Hi,
Can u give an answer to this :

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

1) There are no .h files in the c++ Standard (other than those inherited
from C, which do not have any uses of private in them)

2) Any time a programmer alters or inserts anything to namespace std
they need to check that it is one of the very limited cases where that
is permitted.

3) private is not designed to prevent theft or invasion only to help
detect accident.

4) If you really want to steal access just try:

#define private public

Of course the consequences are entirely undefined.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions:
http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Michael Tiomkin]

Chetan Raj wrote:

Hi All,

One of my friend asked this question on C++

Hi,
Can u give an answer to this :

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

--Ankit

<<<

We all know that this will not be possible, beacuse the information
about the private variables will not be available in library (.lib or
.a files) and the linker will complain.

I don't see a problem with this. Recall that the relative offset of
an attribute in an object is known in compile time, and the compiler
can easily create direct access to it.

Notice that you can also gain access to private attributes (data
members) using a debugger!-)

C++ gives you access control only if you follow the guidelines, this
is similar to the road where you can almost always ignore the rules and
drive your SUV in a different way.
If you want to better hide your data, you need to put it on a
different computer and control the traffic on it.

The problems with using private parts of the ostream:
1. Whenever its .h is changed, you'll need to change your "private" .h.
2. If you use private methods, these methods can be hidden in the .dll
- not exported to the outside world.
3. Safety - you can access private attributes when they are in an
inconsistent state, like accessing the file buffer when it's being
updated.

The most accepted way to hide your data is to have different
implementation and declaration files, define a ptr to an object as an
attribute, and avoid publishing it's declaration, e.g.

// declaration file
class C_helper;
class C {
C_helper *helper_attr; // the .h for C_helper is not here
// declare _helper and use helper_attr in the implementation file

I think you can find more detailed examples in almost any design
patterns book.

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

[kerzum]

Yes, this is possible. Friend declarations have no effect on class
layout and are only considered while
compiling friends.

We all know that this will not be possible, because the information
about the private variables will not be available in library (.lib or
.a files) and the linker will complain.

Library files hold no access control information, so public members are
stored exactly the same way
as private. Actually those names will be compiled to offsets, according
to class definition, no matter
public or private.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Vorticity Kappa]

Chetan Raj wrote:

Hi All,

One of my friend asked this question on C++

Hi,
Can u give an answer to this :

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

--Ankit

<<<

We all know that this will not be possible, beacuse the information
about the private variables will not be available in library (.lib or
.a files) and the linker will complain.

Can any one elaborate on this issue?

Restricted access (private & protected) variables provide a way to say
"This is an implementation detail, not part of any contract; if you
ingeniously make yourself dependant on it, you're on your own".

They are not secure. They've never been claimed to be secure.

This has nothing to do with whether unsanctioned access to privates in
some framework could constitute a security breach - but if such is the
case, it's a failure of the framework design, not of C++.

--
VK

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

[thoth39]

The compiler obeys the instructions set in the source code. If you
change the source code, you change the instructions. As long as
everything is valid C++, the compiler will generate code.

Of course, even if you *can* modify the headers of your standard
library implementation to allow access to private data members, you
shouldn't; there's some discussion in the C++ FAQ Lite, around here:
http://www.parashift.com/c++-faq-lit...s.html#faq-7.6

Also, if you want to mess with *protected* data members of a class, you
don't need to modify is declaration in any way; just inherit from it.

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

[Jerry Coffin]

Chetan Raj wrote:

[ ... ]

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

If yes, that means we can gain access to private data members to even
3rd party libraries. How much useful/destructive that is, is a
different issue.

Officially, the standard headers don't necessarily even exist as files
per se, so there's no guarantee that you can do this, and if you do it,
no guarantee that it'll do what you expect.

Unofficially, yes yo can usually do this, and get roughly the results
you'd expect.

Access control in C++ is intended to protect against Murphy, not
Machiavelli.

--
Later,
Jerry.

The universe is a figment of its own imagination.
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Seungbeom Kim]

Chetan Raj wrote:

We have the .h files for standard library. Consider any class (such as
ostream) declared in the .h files. Can I edit the .h file to declare my
own function as friend inside the class declaration and then gain
access to private data members of ostream? Will the compiler allow
this?

Isn't it undefined behaviour? When you say #include <ostream>, the
Standard doesn't even mandate the existence of a real file named such. A
conforming compiler could have all the information built in, and there's
no distinction between the compiler and the standard library files from
the viewpoint of the Standard, so I think trying to modify any part of
the "implementation" yields undefined behaviour.

--
Seungbeom Kim

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

[Chetan Raj]

Hi All,

We have two kinds of linkages : internal and external linkages. In
internal linkages, the scope of the function or variable is limited to
the current translational unit. ( current .cpp file which the complier
is currently compliling to object file ) These functions or variables
cannot be accessed in other translational units.

So, cannot the complier make all private variables and functions
default to internal linkage and limit it accessing from any other
translational unit?

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

[Hyman Rosen]

Murali wrote:

Yes, you can edit the .h file and add a friend function declaration
and access the private members of the class from that function. The
compiler will not complain.

No, you cannot, because you are violating the one-definition rule.
Any program which contains both the old and new definitions has
undefined behavior.

A high-quality compiler implementation should diagnose this, most
likely by incorporating a hash of the class definition into the
typesafe linkage of the class members.

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

[Hyman Rosen]

Allan W wrote:

The standard doesn't say what will happen here.

Yes it does. Unless you recompile all compilation
units which include this class definition then you
are violating the ODR (one-definition rule) and the
program has undefined behavior. The compiler is not
required to diagnose this, but a high-quality
implementation would, presumably by incorporating a
hash of the class definition text into the mangled
name of the class so that the proposed change would
cause link failure.

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

[Francis Glassborow]

In article <11*********************@g43g2000cwa.googlegroups. com>, bala
<bh***********@persistent.co.in> writes

May be...

when u edit the interface, you just change it. The implementation is in
.a or .so files ( whatever). And you can't change it.

And i think, those .h'ss are read only and to be used when u write the
client code.

Yes, but read only can usually be fixed as well. Writing software
requires a sense of responsibility. Hacking original source code is a
mugs game. If absolutely necessary, use a copy. However if you find it
necessary you should ask yourself why you are using such poor quality
3rd party code.

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Thomas Richter]

In comp.lang.c++.moderated Hyman Rosen <hy*****@mail.com> wrote:

Allan W wrote:

The standard doesn't say what will happen here.

Yes it does. Unless you recompile all compilation
units which include this class definition then you
are violating the ODR (one-definition rule) and the
program has undefined behavior.

Does it? Isn't a compiler allowed to pull class definitions
from somewhere else if it sees for example an #include<string>?

In other words, AFAIK editing an include file that describes
components of the standard library might not necessarely
show *any* effect at all because the compiler isn't required
to read the file in first place - it could be just a dummy.

Not that I'm aware of any implementation that does this right
now...

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

[Francis Glassborow]

In article <11**********************@o13g2000cwo.googlegroups .com>,
Chetan Raj <hi*****@gmail.com> writes

We have two kinds of linkages : internal and external linkages. In
internal linkages, the scope of the function or variable is limited to
the current translational unit. ( current .cpp file which the complier
is currently compliling to object file ) These functions or variables
cannot be accessed in other translational units.

So, cannot the complier make all private variables and functions
default to internal linkage and limit it accessing from any other
translational unit?

Among other things, because there is no requirement that the whole
implementation of a class be in the same TU. We really do not want to
mess with this area of C++. The 'experts' looking at issues of
initialisation etc. are finding themselves surprised enough already.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions:
http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Allan W]

> Allan W wrote:

The standard doesn't say what will happen here.

Hyman Rosen wrote: Yes it does. .... program has undefined behavior.
The definition of "Undefined behavior" is: the behavior (what
will happen) is not defined (the standard doesn't say). So by
definition, the standard doesn't say what will happen when you
have UB.
The compiler is not
required to diagnose this, but a high-quality
implementation would, presumably by incorporating a
hash of the class definition text into the mangled
name of the class so that the proposed change would
cause link failure.

I've used compilers that I personally considered high-quality.
Lots (most?) compilers incorporate the types of function
parameters into the "mangled name" of the function to allow for
overloading -- but I've yet to see one that changed any names
based on the number and types of class members, much less the
access specifiers.

Would you please tell me the name of one of the high-quality
implementations that do that?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[kanze]

Michael Tiomkin wrote:

Chetan Raj wrote:

One of my friend asked this question on C++

>

Can u give an answer to this : We have the .h files for standard library. Consider any
class (such as ostream) declared in the .h files. Can I edit
the .h file to declare my own function as friend inside the
class declaration and then gain access to private data
members of ostream? Will the compiler allow this? If yes, that means we can gain access to private data
members to even 3rd party libraries. How much
useful/destructive that is, is a different issue. We all know that this will not be possible, beacuse the
information about the private variables will not be
available in library (.lib or .a files) and the linker will
complain.

I don't see a problem with this. Recall that the relative
offset of an attribute in an object is known in compile time,
and the compiler can easily create direct access to it.
Changing a privat to a public can change the layout of the
class. I don't know of any compiler where it does, of course,
but the standard explictly allows it. Presumably, there could
be a compiler which puts all private members at the start of the
class.

Anytime different compilation units see different versions of a
class, you have undefined behavior. Anytime you change anything
in a class defined by the standard, you have undefined behavior.

Of course, that doesn't mean you can't get away with it in some,
or even in most implementations.
Notice that you can also gain access to private attributes
(data members) using a debugger!-)
If you know the physical layout of a class (and with a bit of
creative dumping, it usually isn't very difficult to figure
out), you can access anything in the class directly in your
program by some creative use of pointer casts and pointer
arithmetic. James Coplien even once explained how to change the
vptr (thus effectively changing the type of the object) on the
fly. He made it very clear, however, that this wasn't something
you could do portably, and that it wasn't for the faint of
heart.
C++ gives you access control only if you follow the
guidelines, this is similar to the road where you can almost
always ignore the rules and drive your SUV in a different way. If you want to better hide your data, you need to put it on
a different computer and control the traffic on it.

That's an interesting idea. An implementation of std::vector
which keeps its data on another machine, with an operator[]
which sends a request, and waits for the answer. I'm pretty
sure that such an implementation wouldn't be conforming, but
even if it were, I doubt that the performance would be
quite what most users expect:-).

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[kanze]

Chetan Raj wrote:

We have two kinds of linkages : internal and external
linkages. In internal linkages, the scope of the function or
variable is limited to the current translational unit. (
current .cpp file which the complier is currently compliling
to object file ) These functions or variables cannot be
accessed in other translational units. So, cannot the complier make all private variables and
functions default to internal linkage and limit it accessing
from any other translational unit? From any other translation unit except the one which includes

the header? I generally expect headers to be included by more
than one translation unit. Even the implementation will
normally be spread out over a number of different translation
units, one per function, if the object is not polymorphic.

Linkage affects names. External linkage means that the same
name (in the same scope) in different translation units refers
to the same thing. If the names within the class didn't have
external linkage, they would have to refer to different things
in different translation units. I don't see how this is
possible.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[kanze]

Thomas Richter wrote:

In comp.lang.c++.moderated Hyman Rosen <hy*****@mail.com> wrote:

Allan W wrote:

The standard doesn't say what will happen here.

Yes it does. Unless you recompile all compilation
units which include this class definition then you
are violating the ODR (one-definition rule) and the
program has undefined behavior.

Does it?
Yes.
Isn't a compiler allowed to pull class definitions from
somewhere else if it sees for example an #include<string>?
Yes.
In other words, AFAIK editing an include file that describes
components of the standard library might not necessarely show
*any* effect at all because the compiler isn't required to
read the file in first place - it could be just a dummy.

Which is one possible behavior of undefined behavior. Undefined
behavior is when the standard doesn't say anything about what
might happen. The code might compile and work correctly. Or it
might reformat your hard disk, or cause your computer to catch
fire. Or just about anything in between. (For some strange
reason, the behavior I've seen most often is that the code
compiles and runs perfectly in all of your tests, and then fails
miserably and very visibly in the demo for your most important
client. But the standard doesn't guarantee this behavior
either.)

One possible thing that can happen with undefined behavior is
that the implementation can define it. An obvious case of this
is Posix, which requires several things (well, at least one) to
work where the standard says that the behavior is undefined.
But I suspect that this is true of most systems, and probably
most compilers as well.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[kanze]

Hyman Rosen wrote:

Allan W wrote:

The standard doesn't say what will happen here.

Yes it does. Unless you recompile all compilation units which
include this class definition then you are violating the ODR
(one-definition rule) and the program has undefined behavior.
But that's exactly what he said. Or do you see a difference
between "the standard doesn't say what will happen", and
"undefined behavior".
The compiler is not required to diagnose this, but a
high-quality implementation would, presumably by incorporating
a hash of the class definition text into the mangled name of
the class so that the proposed change would cause link
failure.

I agree, but by that measure, there are very few high-quality
implementations around.

--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Thomas Richter]

Hi James,

In comp.lang.c++.moderated ka***@gabi-soft.fr wrote:

Thomas Richter wrote:

In comp.lang.c++.moderated Hyman Rosen <hy*****@mail.com> wrote:

Allan W wrote:
> The standard doesn't say what will happen here. Yes it does. Unless you recompile all compilation
units which include this class definition then you
are violating the ODR (one-definition rule) and the
program has undefined behavior.

Does it?

Yes.
That was actually targetted at: "The standard doesn't say what
will happen here". Well, in some sense "Yes, it does say that
it doesn't give you any guarantee about what will happen". In
my understanding, this is rather a "No". But I guess we mean
the same. (-;
In other words, AFAIK editing an include file that describes
components of the standard library might not necessarely show
*any* effect at all because the compiler isn't required to
read the file in first place - it could be just a dummy.

Which is one possible behavior of undefined behavior. Undefined
behavior is when the standard doesn't say anything about what
might happen. The code might compile and work correctly. Or it
might reformat your hard disk, or cause your computer to catch
fire. Or just about anything in between. (For some strange
reason, the behavior I've seen most often is that the code
compiles and runs perfectly in all of your tests, and then fails
miserably and very visibly in the demo for your most important
client. But the standard doesn't guarantee this behavior
either.)

(-: (-: Seems to be a pretty common behaivour for UB, indeed. (Fits
well into my experiences.)

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

[Class that cannot be inherited ... C++]

hi
(with TCLITE)
When u will wanna some friend funtion
u have to declear that function as friend in the class declearation now
ur defination may be at the same point or "YOU WILL DEFINE THAT
FUNCTION IN .CPP FILE WITHOUT RESOLUTION OPERATOR" if u will not so (or
try with resolution) it will give an error at compile time "funtion is
not a part of class.
so its a completely different way to map its calling
and just changing the declearation will never go to work

i have read about virtual memory and vptr theory
if u get some theory for this friend function calling
please let me
thank u
Rahul Agarwal

// friend functions
#include <iostream.h>

class CRectangle {
int width, height;
public:
void set_values (int, int);
int area (void) {return (width * height);}
friend CRectangle duplicate (CRectangle);
};

void CRectangle::set_values (int a, int b) {
width = a;
height = b;
}

CRectangle duplicate (CRectangle rectparam)
{
CRectangle rectres;
rectres.width = rectparam.width*2;
rectres.height = rectparam.height*2;
return (rectres);
}

int main () {
CRectangle rect, rectb;
rect.set_values (2,3);
rectb = duplicate (rect);
cout << rectb.area();
}
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Allan W]

> Class that cannot be inherited ... C++

I suppose this was supposed to be the subject line, not the
"From" name... if I read the message right, your name is Rahul Agarwal.

Rahul Agarwal wrote:

hi
(with TCLITE)
When u will wanna some friend funtion
u have to declear that function as friend in the class declearation now
ur defination may be at the same point or "YOU WILL DEFINE THAT
FUNCTION IN .CPP FILE WITHOUT RESOLUTION OPERATOR" if u will not so (or
try with resolution) it will give an error at compile time "funtion is
not a part of class.
so its a completely different way to map its calling
and just changing the declearation will never go to work

i have read about virtual memory and vptr theory
if u get some theory for this friend function calling
please let me
thank u
Rahul Agarwal
Ouch. I really really don't want to violate moderation guidelines,
but after six times trying to read that, my eyes hurt. At least some
of the misspellings (wanna,u) seem to be on purpose... please don't
do that!

Obviously you're asking some question about the program you attached.
I'll try to critique it.
// friend functions
This is the program name, yes?
#include <iostream.h>
This old-style header will work on some compilers...
better to use
#include <iostream>
using namespace std;
class CRectangle {
int width, height;
public:
void set_values (int, int);
int area (void) {return (width * height);}
friend CRectangle duplicate (CRectangle);
};
I would have used a constructor instead of functin "set_values"
but we'll overlook that for now.
void CRectangle::set_values (int a, int b) {
width = a;
height = b;
}
Fine implementation of set_values.
CRectangle duplicate (CRectangle rectparam)
{
CRectangle rectres;
rectres.width = rectparam.width*2;
rectres.height = rectparam.height*2;
return (rectres);
}
If your class had a constructor, you could have written this a LOT
more simply... even without it, I don't quite understand why you
didn't just use set_values.

I would also recommend changing the parameter to a const reference,
if you're advanced enough to have read about references. (If not,
don't worry about it yet.)

The name "duplicate" makes me think that you wanted to make an
exact copy of the CRectangle. (This would be better as a copy
constructor, but that's a topic for another day.) I wonder why
you multiply the width and height by 2?
int main () {
CRectangle rect, rectb;
rect.set_values (2,3);
rectb = duplicate (rect);
cout << rectb.area();
}

rect is 2 by 3. When you use duplicate, you double both the width
and height by 2... the result is 4 by 6, so the total area is 24.

Still not sure what you were askikng... did I answer it?
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Chetan Raj]

Hi,

James Kanze wrote:

the header? I generally expect headers to be included by
more than one translation unit.
Header files contain the declaration and not the definitions for the
functions or the variables. So header files don't create storage. They
only indicate that storage will be available somewhere else. Now, when
the complier knows that a variable is private from the header file and
then when it comes across its (private variables) implementation in the
translational unit ( in .cpp file ), wouldn't the compiler have
sufficient information to make its linkage names internal.

Also,
Even the implementation will normally be spread out over a > number of different translation
units, one per function, if the object is not polymorphic.

The complier can know that the current translational unit does not have
the complete definition of the class. Now, cannot the compiler flag
this information somewhere, and when it sees another translational unit
which continues the implementation of the class, cannot it use the
flagged information?

Or, For this particular case of different translational units for the
same class, cannot we come up with another linkage scheme where the
variable names will be exposed only to those translational units
implementing a particular class.

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

[Hyman Rosen]

ka***@gabi-soft.fr wrote:

But that's exactly what he said. Or do you see a difference
between "the standard doesn't say what will happen", and
"undefined behavior".

Of course. The former implies that the standard has failed to
address the issue.

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

[Francis Glassborow]

In article <11**********************@z14g2000cwz.googlegroups .com>,
Chetan Raj <hi*****@gmail.com> writes

Or, For this particular case of different translational units for the
same class, cannot we come up with another linkage scheme where the
variable names will be exposed only to those translational units
implementing a particular class.

Yes, of course we can but it is much more than a simple fix by tinkering
with linkage. If you take some time to look at the proposals for the
next version of C++, in particular
http://www.open-std.org/jtc1/sc22/wg...2005/n1778.pdf on
modules which would seem to be a much better solution.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Jerry Coffin]

In article <20*************************@cliffclavin.cs.rpi.ed u>,
hy*****@mail.com says...

ka***@gabi-soft.fr wrote:

But that's exactly what he said. Or do you see a difference
between "the standard doesn't say what will happen", and
"undefined behavior".

Of course. The former implies that the standard has failed to
address the issue.

But the standard fairly specifically says that failing to address
behavior in a particular circumstance means that circumstance gives
undefined behavior.

--
Later,
Jerry.

The universe is a figment of its own imagination.

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

[Hyman Rosen]

Jerry Coffin wrote:

In article <20*************************@cliffclavin.cs.rpi.ed u>,
hy*****@mail.com says...

ka***@gabi-soft.fr wrote:

But that's exactly what he said. Or do you see a difference
between "the standard doesn't say what will happen", and
"undefined behavior".

Of course. The former implies that the standard has failed to
address the issue.

But the standard fairly specifically says that failing to address
behavior in a particular circumstance means that circumstance gives
undefined behavior.

Yes, but there is still a difference between the standard saying that
something causes undefined behavior and saying nothing, allowing that
behavior to be undefined by what you say. It's not a difference that
matters to the program, but it is a factual difference in what the
standard contains. When you say that the standard "says nothing about"
something, it means that there is no bit of text in the standard which
addresses the question. That's different from the standard containing
that bit of text which says something is undefined behavior.

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

[James Kanze]

Hyman Rosen wrote:

ka***@gabi-soft.fr wrote:

But that's exactly what he said. Or do you see a difference
between "the standard doesn't say what will happen", and
"undefined behavior".

Of course. The former implies that the standard has failed to
address the issue.

That's a loaded way of expressing it. While I think you and I
agree that there is a lot of "undefined behavior" which could be
defined, and that the language would be better off for it, the
fact remains that in most, if not all, cases of undefined
behavior and certainly in all where the standard explicitly says
that the behavior is undefined, the authors of the standard did
consider the issue, and decided intentionally that the behavior
should be undefined. This is not "failing to address the
issue"; even if in certain cases, it is "failing to address it
in the way I want".

--
James Kanze mailto: ja*********@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France [phone]

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

[James Kanze]

Chetan Raj wrote:

James Kanze wrote:

the header? I generally expect headers to be included by more
than one translation unit. Header files contain the declaration and not the definitions
for the functions or the variables. So header files don't
create storage. They only indicate that storage will be
available somewhere else. Now, when the complier knows that a
variable is private from the header file and then when it
comes across its (private variables) implementation in the
translational unit ( in .cpp file ), wouldn't the compiler
have sufficient information to make its linkage names
internal.
Private variables can only be member variables. In such cases,
the compiler never creates storage for the individual variable,
only for the class (and that, only when an object of the class
is defined -- a class definition doesn't create any storage).
What it does, however, is define a layout of the class. And
that layout depends on the size and the order of member
variables. Private or public.

It is, of course, possible to conceive of a system where the
layout would only be known at link time. Such a system,
however, is either beyond the capacity of most current linkers,
or imposes undo runtime overhead.
Also, Even the implementation will normally be spread out over a
number of different translation units, one per function, if
the object is not polymorphic.

The complier can know that the current translational unit does
not have the complete definition of the class. Now, cannot
the compiler flag this information somewhere, and when it sees
another translational unit which continues the implementation
of the class, cannot it use the flagged information?
At the very least, the compiler must know how big the object is,
in order for you to define a variable of its type.
Or, For this particular case of different translational units
for the same class, cannot we come up with another linkage
scheme where the variable names will be exposed only to those
translational units implementing a particular class.

One can doubtlessly think of a number of different
alternatives. Are they as simple as the present one? And if
not, are they worth it? I'd have to see the precise
alternative, in detail, to answer that, but I'm sceptical. I
rather suspect that if there had been a solution which is as
simple, but significantly better, someone would already have
thought of it, and presented it.

--
James Kanze mailto: ja*********@free.fr
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 pl. Pierre Sémard, 78210 St.-Cyr-l'École, France [phone]

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

[Jerry Coffin]

In article <QVvme.5230$Ub.4726@trndny09>, hy*****@mail.com says...

[ ... ]

Of course. The former implies that the standard has failed to
address the issue.

But the standard fairly specifically says that failing to address
behavior in a particular circumstance means that circumstance gives
undefined behavior.

Yes, but there is still a difference between the standard saying that
something causes undefined behavior and saying nothing, allowing that
behavior to be undefined by what you say.

Yes, but there is still a difference between "the standard has failed
to address the issue" and "I don't particularly care for the manner
in which the standard addresses the issue."

--
Later,
Jerry.

The universe is a figment of its own imagination.

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

[Chetan Raj]

Hi Francis,

I read about the proposal to use C++ modules. (
http://www.open-std.org/jtc1/sc22/wg...2005/n1778.pdf )

I have the following questions to ask..

1.Is this just a proposal or is it already accepted for the next C++
Standard?

2. When is the next C++ Standard expected to come out?

3. What are the other major features of next C++ Standard?

4. Does it still thrive to support C and hence risk type safety or
would it be more strict about type safety issues?

5. What are the changes/or new features in next C++ Standard Library?
Will boost library be included as a standard?

6. Is there a specific version number or code name for the next C++
Standard? ( By what name should I call the next C++ Standard? )

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

[Francis Glassborow]

In article <11*********************@g14g2000cwa.googlegroups. com>,
Chetan Raj <hi*****@gmail.com> writes

Hi Francis,

I read about the proposal to use C++ modules. (
http://www.open-std.org/jtc1/sc22/wg...2005/n1778.pdf )

I have the following questions to ask..

1.Is this just a proposal or is it already accepted for the next C++
Standard?
No, like almost everything currently on the table, it is just a
proposal.

2. When is the next C++ Standard expected to come out? 2009
3. What are the other major features of next C++ Standard? Browse the papers. But Concepts and a new memory model are among the
more interesting.

4. Does it still thrive to support C and hence risk type safety or
would it be more strict about type safety issues?
Neither C nor C++ will gratuitously add incompatibilities but all that
means is that breaking compatibility is just one of several costs taken
into account when considering changes.

5. What are the changes/or new features in next C++ Standard Library?
Will boost library be included as a standard?
Look at TR1 and check work on TR2 (both Library items) And, no, Boost as
a whole will not be incorporated into the Standard.

6. Is there a specific version number or code name for the next C++
Standard? ( By what name should I call the next C++ Standard? )

We generally code it as C++0X

--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]