Re: Memory Layout - Private , Protected and Public member
Jiang wrote:
kanze wrote:
Jiang wrote:
bestbrain@gmail.com wrote:
Sujay,
1. With the kind of pointer power in C++, it is
difficult to prevent developer from accessing sub-parts
of object. It may be difficult but is it impossible?
In my mind this is not possible if we stay with the current
C++ object model. With a raw pointer in hand, you can do
whatever you want.
Even allowing for this, I'm not sure that an implementation
would be allowed to check access completely. I think that
you're allowed to do read an object byte by byte, including any
hidden and private parts; i.e. a hex dump of the object is legal
C++.
Yes, that's the point.
For a carefully designed class:
class my_great_class
{
// public interfaces
int private_state;
};
One can easily do
int *p = reinterpret_cast<int*>(&obj);
*p = 0xDEADBEEF;
to make something happen.
Not legally:-).
Formally, I think an implementation is allowed to incorporate
typing information into its pointers, and for the
reinterpret_cast to int* to fail. If it does this, however, it
still must ensure that something like `static_cast< unsigned
char* >( static_cast< void* >( &obj ) )' returns the address of
the first byte of the object, and that reading through this
pointer from the object works (and writing too, if the original
type is a POD).
Given such requirements, making something like your example fail
would require horrendously fat pointers---not just the bounds,
but pointers to the RTTI information, etc.; in the case of
void*/char*, to the RTTI information of both the pointer type
AND the original type. In practice, even a special debugging
compiler isn't going to go that far.
As far as the language is concerned, of course, your example has
undefined behavior. Which is all the compiler needs to let it
off the hook.
[...]
Also, "trust the programmer" is one of the facets of the
spirit of C language, and C++ inherited it from C language. If
we write well- formed code, the C++ language guarantees the
desired behaviors. If we write ill-formed code, for example,
using low lever method to avoid necessary typing/access
checking, well, it is our problem and it is not fair to ask
the language for help anymore.
It depends. But it's true that the goal has traditionally been
not to impose run-time checks which have a cost in execution
time.
Indeed. If it was an issue in the very beginning, I do not think there
will exist a language called Java.
I don't think that the issue is black and white. Part of the
goal of C++, compared to C, is improved type safety. Beyond
that, it is a price/benefits trade off. Generally, C++ has
considered that any runtime cost is too high a price, where as
compile time cost is perfectly acceptable. In both cases, up to
a point: I think an increase of runtime by, say 0.1%, for an
enormous increase in safety might actually pass; and some of the
cases of undefined behavior are actually detectable, but at a
cost of making compile time O(n^2) or even O(n!) (where n is the
size of the source code)---requiring a compiler to require
thousands of years to compile a non-trivial program is not
acceptable.
--
James Kanze GABI Software
Conseils en informatique orient?e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S?mard, 78210 St.-Cyr-l'?cole, France, +33 (0)1 30 23 00 34
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]