«

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
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

On 29 sep, 13:35, coolchap <b.prash...@gmail.com> wrote:
> 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

coolchap <> writes:

> 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
> 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.

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__

On Sep 29, 2:20*pm, p...@informatimago.com (Pascal J. Bourguignon)
wrote:
> coolchap <b.prash...@gmail.com> writes:
> > 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
> > 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.
>
> 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__

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

On Sep 29, 8:33*am, prashant <b.prash...@gmail.com> wrote:
> 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

On Sep 29, 11:38*am, SeanW <sean_in_rale...@yahoo.com> wrote:
> On Sep 29, 8:33*am, prashant <b.prash...@gmail.com> wrote:
>
> > 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.

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.