virtual function and segmentation fault

Discussion in 'C++' started by asit, Sep 25, 2011.

  1. asit

    asit Guest

    Look at the following code snippet..


    #include <iostream>

    using namespace std;

    class ex
    {
    int i;
    public:
    ex(int ii=0):i(ii) {}

    ~ex() { cout<<"dest"<<endl; }

    virtual void show()
    {
    cout<<"show fun called"<<endl;
    }

    };

    int main()
    {
    ex *ob = NULL;
    ob->show();
    return 0;
    }


    The output here is segmentation fault.

    If I make show non-virtual, there is no segmentation fault.

    Can somebody explain me the reason ??
     
    asit, Sep 25, 2011
    #1
    1. Advertising

  2. asit

    asit Guest

    Is only one virtual table created for a class or different tables are created for different classes ??
     
    asit, Sep 25, 2011
    #2
    1. Advertising

  3. On 9/25/11 10:58 AM, asit wrote:
    > Look at the following code snippet..
    >
    >
    > #include<iostream>
    >
    > using namespace std;
    >
    > class ex
    > {
    > int i;
    > public:
    > ex(int ii=0):i(ii) {}
    >
    > ~ex() { cout<<"dest"<<endl; }
    >
    > virtual void show()
    > {
    > cout<<"show fun called"<<endl;
    > }
    >
    > };
    >
    > int main()
    > {
    > ex *ob = NULL;
    > ob->show();
    > return 0;
    > }
    >
    >
    > The output here is segmentation fault.
    >
    > If I make show non-virtual, there is no segmentation fault.
    >
    > Can somebody explain me the reason ??


    When show() is virtual, in order to locate the function to call, the
    code needs to access the "vtable" to find the address of the function,
    and since the object pointer is NULL, this will fault.

    When show() isn't virtual, the compiler generally doesn't need to look
    at the object to call the function, and since your implementation of
    show doesn't refer to any member variables, it MIGHT be able to run
    without problems (but it still has invoked "Undefined behavior" (which
    sometimes does what you want).
     
    Richard Damon, Sep 25, 2011
    #3
  4. On 9/25/11 2:04 PM, Leigh Johnston wrote:
    > Do you think that explaining the behaviour of particular undefined
    > behaviour invocations is useful? The advice should be to avoid undefined
    > behaviour, period. Explaining how things work (such as dynamic dispatch)
    > can be done without resorting to explaining it in terms of undefined
    > behaviour. :)
    >
    > /Leigh


    Yes I do. The OP obviously has tried both options and is puzzled by the
    difference in behavior (not noticing that both were undefined behavior).
    By pointing out how some undefined behavior typically operates, it does
    a couple of thing.

    One, it points out that just because something "works" doesn't mean you
    haven't committed undefined behavior (note that my description of the
    non-virtual case doesn't say it WILL work, just why it might).

    Two, understand why some behaviors are defined as "undefined" helps give
    reality to the concept. Things are not undefined behavior just because
    the writers of the standard didn't want to define it, but there is
    almost always a real reason why it is impractical to define the behavior
    on all implementations. Knowing this, it makes it easier to remember
    what is undefined behavior, as well as to understand code that might
    invoke what is undefined behavior in the C++ standard but may be defined
    by another standard or the implementation.

    For example, the code:

    int i;
    i = 30000 + 30000;

    has possibly invoked undefined behavior by possible overflowing signed
    integer arithmetic (if ints are only 16 bits). Knowledge that you are on
    a 32 bit machine, or that (as is common), the behavior of in integer
    arithmetic is reasonably well defined on this platform, allows one to be
    less paranoid in the checks that need to be made to avoid/detect problems.
     
    Richard Damon, Sep 25, 2011
    #4
  5. asit

    Miles Bader Guest

    Leigh Johnston <> writes:
    > Do you think that explaining the behaviour of particular undefined
    > behaviour invocations is useful?


    Sure; concrete examples are often a very useful tool for understanding.

    -miles

    --
    Carefully crafted initial estimates reward you not only with
    reduced computational effort, but also with understanding and
    increased self-esteem. -- Numerical methods in C,
    Chapter 9. "Root Finding and Nonlinear Sets of Equations"
     
    Miles Bader, Sep 26, 2011
    #5
    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. Stefan Strasser

    Segmentation fault when function ends...

    Stefan Strasser, Mar 30, 2005, in forum: C++
    Replies:
    14
    Views:
    1,678
    Victor Bazarov
    Mar 30, 2005
  2. Chris Van Extergem

    Function pointer results in segmentation fault.

    Chris Van Extergem, May 1, 2006, in forum: C Programming
    Replies:
    5
    Views:
    886
    Chris Van Extergem
    May 2, 2006
  3. jtagpgmr

    Segmentation Fault using the srand function

    jtagpgmr, Jun 27, 2006, in forum: C Programming
    Replies:
    11
    Views:
    1,011
    Default User
    Jun 27, 2006
  4. Replies:
    1
    Views:
    435
  5. eliweiq001
    Replies:
    12
    Views:
    842
    Keith Thompson
    Oct 6, 2010
Loading...

Share This Page