list.front() question
coolchap
I have a query regarding the front() function in list. Lets say
that I have a list of pointers
list <ptr *> aListofPtrs;
Size of aListPtrs is zero
now i get the first element... and call a function in the class ptr..
lets say getSomething()
aListofPtrs.front()->getSomething()
As for me, this should return a nullpointer exception, But instead the
program was compiled and ran too.. getSomething() returned an arbitary
value.
I just want to understand how the front() method works in case the
list has zero elements and we call the front() method.
Regards,
Prashant
Michael Doubez
> Hi,
> I have a query regarding the front() function in list. Lets say
> that I have a list of pointers
>
> list <ptr *> aListofPtrs;
>
> Size of aListPtrs is zero
>
> now i get the first element... and call a function in the class ptr..
> lets say getSomething()
>
> aListofPtrs.front()->getSomething()
>
> As for me, this should return a nullpointer exception,
Assuming that list<ptr*>::front() returns NULL when empty.
> But instead the
> program was compiled and ran too.. getSomething() returned an arbitary
> value.
>
> I just want to understand how the front() method works in case the
> list has zero elements and we call the front() method.
Because list<ptr*>::front() returns a random value when empty. You are
using a uninitialised pointer, this is undefined behavior.
In fact, since front() returns a reference, calling it may be
undefined behavior in itself.
--
Michael
Pascal J. Bourguignon
There's no way to understand how ti works whe the list is empty,
because it is not in the contract.
You must always test whether the list is not empty before using
front(). It is like in C where you must always test whether there
won't be an overflow before using a+b, or whether a pointer is not
null before using *p.
ALWAYS WRITE:
if(not list.empty()){
list.front()->getSomething();
}
if(((a>=0) and (INT_MAX-a<=b)) or ((a<0) and (INT_MIN-a>=b)))
error("overflow");
}else{
int c=a+b;
}
if(p!=0){
(*p)=42;
}
NEVER WRITE:
list.front()->getSomething();
int c=a+b;
(*p)=42;
ALONE.
(Then of course, if your compiler is smart enough, it may determine
that some of these tests are dead code and eliminate them).
--
__Pascal Bourguignon__
prashant
wrote:
thanks for the replies...
As mentioned its an undefined behaviour, but i had expected it to
throw a nullpointer exception which would have led me to detect the
error. anyways somethings need to be checked before using it..
Thanks,
Regards,
Prashant
SeanW
> As mentioned its an undefined behaviour, but i had expected it to
> throw a nullpointer exception which would have led me to detect the
> error. anyways somethings need to be checked before using it..
Standard C++ does not have a "nullpointer exception". That's
Java or Microsoft's SEH C++ extension or something else.
Sean
Joshua Maurice
To be crystal clear, let me add this. De-referencing a null pointer is
undefined behavior according to the standard. In practice, on some
systems, this may throw a Windows SEH exception (not a C++ exception),
and on other systems it will kill the program and produce a core dump.
Undefined behavior means that the implementation can do whatever it
wants, such as die, print an error the console, throw an exception,
send an email to your mother, or format your hard drive. (Note that
your hard drive will almost certainly not be formatted by a null
pointer de-reference. It's just the common [exaggerated] response,
just like "Hello world!" is generally your first program. However, a
mean implementation is still standard compliant if it does format your
hard drive on a null pointer de-reference.)
PS: never do something which is undefined. By the very definition of
undefined, the result is not predictable, so you should not do it.
However, just because it's undefined by the C++ standard does not mean
it's undefined by all standards. Ex: POSIX and reinterpret_cast'ing
the result of a void* to a function pointer for dlsym. Just don't
expect your program to work on all C++ implementations, as POSIX is
now defining some semantics of your program.
Paavo Helde
> Hi,
> I have a query regarding the front() function in list. Lets say
> that I have a list of pointers
>
> list <ptr *> aListofPtrs;
>
> Size of aListPtrs is zero
>
> now i get the first element... and call a function in the class ptr..
> lets say getSomething()
>
> aListofPtrs.front()->getSomething()
>
> As for me, this should return a nullpointer exception, But instead the
Why do you think there should be something like nullpointer exception, if
there is no null pointer anywhere? (No pointers at all, actually.)
In C++, there is this "zero overhead" principle. No null pointer is
magically substituted for a missing pointer (*). If you want such things,
you have to create your own wrappers for that.
(*) Actually, as calling front() on an empty container is undefined
behavior, an implementation could define it somehow, e.g. by returning a
reference to a null pointer. But this would only hide the error in your
program. A more proper response would be to abort the program.
hth
Paavo