Re: Dereferencing a null-pointer allowed?
On May 11, 11:13 pm, W Karas <wka...@yahoo.com> wrote:
On May 8, 1:53 pm, l...@gmx.li (Lutz Richter) wrote:
given the following code:
-----------------------------
class B
{
public:
B(): Value(99) {}
int Get() { if (this) return Value; else return -1; }
private:
int Value;
};
int main()
{
B* b = 0;
cout << b->Get();}
-----------------------------
I wonder if this is allowed. I did not have any problem with any
compiler yet. It works! But is this guaranteed?
This question touches on a broader issue: the C++ Standard is
often much more strict than the de facto standard that can be
inferred from the widely- used C++ implementations.
That's partially true. Sometimes, it is because C++ tries to
remain implementable on more exotic architectures. Thus, you
will have no problems on most common architectures copying a
pointer after it has been used as the operand to delete, but
there are some exotic (and in the past not so exotic)
architectures where this might be more difficult to implement,
so C++ declares it undefined behavior. In other cases, the
standard's committee does end up standardizing existing
practice, once it becomes clear that it really is universal: the
next version of the standard will require the memory in
std::string to be contiguous, for example, and that <iostream>
actually include <istream>, <ostream>, etc. (When the last
version of the standard was adopted, no one had sufficient
experience with these issues to be sure that there might not be
cases where it was reasonable to do otherwise. Time has shown,
however, that there aren't.)
I would guess that the above code would compile and run
properly with any widely-used C++ compiler.
Unless, of course, the compiler was serious about optimization.
I can't imagine it running "correctly" (assuming that outputting
-1 is "correct") with any decent optimization. And of course,
even on compilers where it currently runs "correctly", it is
just a special case. Throw in multiple inheritance or virtual
functions, and it will do strange things with a lot of
compilers.
On the other hand, de facto C++ (in order to avoid
breaking old C code I would guess) can be restrictive
in perhaps undesirable ways. For example, if I write:
class X { char a; int i; char b; };
I've not seen any compilers that would store b
before i in the structure, even though this seems
to be ok under the Standard (?), although it
perhaps shouldn't be for POD.
It's forbidden. I think there is a DR concerning this, however.
Formally:
struct A { char a; int i; char b; } ;
// Order guaranteed.
struct B { public: char a; public: int i; public: char b; } ;
// Order not guaranteed.
In the latter case, however, B is still a POD.
--
James Kanze (Gabi Software) email: james.kanze@gmail.com
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
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]