list.front() question

Discussion in 'C++' started by coolchap, Sep 29, 2009.

  1. coolchap

    coolchap Guest

    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
    coolchap, Sep 29, 2009
    #1
    1. Advertising

  2. On 29 sep, 13:35, coolchap <> 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
    Michael Doubez, Sep 29, 2009
    #2
    1. Advertising

  3. 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__
    Pascal J. Bourguignon, Sep 29, 2009
    #3
  4. coolchap

    prashant Guest

    On Sep 29, 2:20 pm, (Pascal J. Bourguignon)
    wrote:
    > 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__


    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
    prashant, Sep 29, 2009
    #4
  5. coolchap

    SeanW Guest

    On Sep 29, 8:33 am, prashant <> 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
    SeanW, Sep 29, 2009
    #5
  6. On Sep 29, 11:38 am, SeanW <> wrote:
    > On Sep 29, 8:33 am, prashant <> 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.
    Joshua Maurice, Sep 29, 2009
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Charles A. Lackman

    Bring to Front

    Charles A. Lackman, Dec 6, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    2,364
    Herfried K. Wagner [MVP]
    Dec 6, 2004
  2. tom
    Replies:
    7
    Views:
    5,952
    Luiz Vianna
    Nov 13, 2003
  3. Replies:
    2
    Views:
    389
    Rad [Visual C# MVP]
    Mar 16, 2007
  4. Andy
    Replies:
    3
    Views:
    476
    James Kanze
    Jun 8, 2007
  5. Karen Sundquist
    Replies:
    1
    Views:
    140
    Saurabh Nandu
    Dec 1, 2003
Loading...

Share This Page