Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #10470 > unrolled thread

virtual function and segmentation fault

Back to article view | Back to comp.lang.c++

Contents

  virtual function and segmentation fault asit <lipun4u@gmail.com> - 2011-09-25 07:58 -0700
    Re: virtual function and segmentation fault Leigh Johnston <leigh@i42.co.uk> - 2011-09-25 16:30 +0100
      Re: virtual function and segmentation fault Leigh Johnston <leigh@i42.co.uk> - 2011-09-25 18:32 +0100
        Re: virtual function and segmentation fault Leigh Johnston <leigh@i42.co.uk> - 2011-09-25 18:50 +0100
          Re: virtual function and segmentation fault Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-25 13:08 -0500
            Re: virtual function and segmentation fault Leigh Johnston <leigh@i42.co.uk> - 2011-09-25 19:16 +0100
              Re: virtual function and segmentation fault Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-25 14:15 -0500
                Re: virtual function and segmentation fault Leigh Johnston <leigh@i42.co.uk> - 2011-09-25 20:28 +0100
    Re: virtual function and segmentation fault asit <lipun4u@gmail.com> - 2011-09-25 08:43 -0700
      Re: virtual function and segmentation fault Leigh Johnston <leigh@i42.co.uk> - 2011-09-25 16:51 +0100
    Re: virtual function and segmentation fault Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-25 12:45 -0500
    Re: virtual function and segmentation fault Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-25 13:53 -0400
      Re: virtual function and segmentation fault Leigh Johnston <leigh@i42.co.uk> - 2011-09-25 19:04 +0100
        Re: virtual function and segmentation fault Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-25 13:18 -0500
          Re: virtual function and segmentation fault Leigh Johnston <leigh@i42.co.uk> - 2011-09-25 19:22 +0100
            Re: virtual function and segmentation fault Paavo Helde <myfirstname@osa.pri.ee> - 2011-09-25 14:51 -0500
        Re: virtual function and segmentation fault Richard Damon <news.x.richarddamon@xoxy.net> - 2011-09-25 15:12 -0400
        Re: virtual function and segmentation fault Miles Bader <miles@gnu.org> - 2011-09-26 08:49 +0900

#10470 — virtual function and segmentation fault

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

[toc] | [next] | [standalone]

#10472

On 25/09/2011 15:58, 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.

Because you are invoking undefined behaviour.

>
> If I make show non-virtual, there is no segmentation fault.
>
> Can somebody explain me the reason ??

Because you are still invoking undefined behaviour.

Undefined behaviour can do anything which includes crashing and not 
crashing.

HTH.

/Leigh

[toc] | [prev] | [next] | [standalone]

#10476

On 25/09/2011 16:30, Leigh Johnston wrote:
> On 25/09/2011 15:58, 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.
>
> Because you are invoking undefined behaviour.
>
>>
>> If I make show non-virtual, there is no segmentation fault.
>>
>> Can somebody explain me the reason ??
>
> Because you are still invoking undefined behaviour.
>
> Undefined behaviour can do anything which includes crashing and not
> crashing.
>
> HTH.

Of course one can guess as to what precisely is causing the segmentation 
fault for the undefined behaviour specific to a particular 
implementation or even look at the code generated by the compiler and 
find out exactly why there is a segmentation fault but this is probably 
not the place to do so even if I and most other posters do know why; 
instead one should be simply be aware that it is undefined behaviour and 
not do it.  If a program invokes undefined behaviour then that 
invocation is basically a "bug".

HTH.

/Leigh

[toc] | [prev] | [next] | [standalone]

#10478

On 25/09/2011 18:32, Leigh Johnston wrote:
> On 25/09/2011 16:30, Leigh Johnston wrote:
>> On 25/09/2011 15:58, 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.
>>
>> Because you are invoking undefined behaviour.
>>
>>>
>>> If I make show non-virtual, there is no segmentation fault.
>>>
>>> Can somebody explain me the reason ??
>>
>> Because you are still invoking undefined behaviour.
>>
>> Undefined behaviour can do anything which includes crashing and not
>> crashing.
>>
>> HTH.
>
> Of course one can guess as to what precisely is causing the segmentation
> fault for the undefined behaviour specific to a particular
> implementation or even look at the code generated by the compiler and
> find out exactly why there is a segmentation fault but this is probably
> not the place to do so even if I and most other posters do know why;
> instead one should be simply be aware that it is undefined behaviour and
> not do it. If a program invokes undefined behaviour then that invocation
> is basically a "bug".
>
> HTH.

Aside: Microsoft like to ignore the fact (or don't care about the fact) 
that this is undefined behaviour as they allow it in their MFC library 
in the form of CWnd::GetSafeHwnd() non-static member function which 
checks for the "this" pointer being NULL; they are relying on the fact 
that *their* defined behaviour of this particular undefined behaviour 
invocation has no ill effects on their particular implementation.  This 
is poor quality in my opinion; one of the reasons why I am ceasing to 
use MFC after many years in favour of a cross-platform C++ GUI library 
that I am currently working on. :)

/Leigh

[toc] | [prev] | [next] | [standalone]

#10481

Leigh Johnston <leigh@i42.co.uk> wrote in news:
_pKdnd5RV9R19OLTnZ2dnUVZ8lSdnZ2d@giganews.com:
> 
> Aside: Microsoft like to ignore the fact (or don't care about the fact) 
> that this is undefined behaviour as they allow it in their MFC library 
> in the form of CWnd::GetSafeHwnd() non-static member function which 
> checks for the "this" pointer being NULL; they are relying on the fact 
> that *their* defined behaviour of this particular undefined behaviour 
> invocation has no ill effects on their particular implementation.  This 
> is poor quality in my opinion; one of the reasons why I am ceasing to 
> use MFC after many years in favour of a cross-platform C++ GUI library 
> that I am currently working on. :)

The implementation can define (parts of) undefined behavior, there is 
nothing wrong with this. For example, the multithreading behavior of C++ 
programs has been defined by many implementations and this has made it 
possible to write multi-threaded C++ programs long before the 
multithreading behavior was defined by the C++ standard.

If you don't like CWnd::GetSafeHwnd(), then don't use it, it's as simple as 
that. I have (been forced to) use MFC to some extent for many years and I 
have never used GetSafeHwnd(). There are arguably lots of things wrong with 
MFC, and GetSafeHwnd() might be a typical example of the mindset which 
produced those wrong things, but your logic just does not hold here. 

Cheers
Paavo

[toc] | [prev] | [next] | [standalone]

#10482

On 25/09/2011 19:08, Paavo Helde wrote:
> Leigh Johnston<leigh@i42.co.uk>  wrote in news:
> _pKdnd5RV9R19OLTnZ2dnUVZ8lSdnZ2d@giganews.com:
>>
>> Aside: Microsoft like to ignore the fact (or don't care about the fact)
>> that this is undefined behaviour as they allow it in their MFC library
>> in the form of CWnd::GetSafeHwnd() non-static member function which
>> checks for the "this" pointer being NULL; they are relying on the fact
>> that *their* defined behaviour of this particular undefined behaviour
>> invocation has no ill effects on their particular implementation.  This
>> is poor quality in my opinion; one of the reasons why I am ceasing to
>> use MFC after many years in favour of a cross-platform C++ GUI library
>> that I am currently working on. :)
>
> The implementation can define (parts of) undefined behavior, there is
> nothing wrong with this. For example, the multithreading behavior of C++
> programs has been defined by many implementations and this has made it
> possible to write multi-threaded C++ programs long before the
> multithreading behavior was defined by the C++ standard.

If you actually read what I said you will have noticed that I said 
"*their* defined behaviour".

>
> If you don't like CWnd::GetSafeHwnd(), then don't use it, it's as simple as
> that. I have (been forced to) use MFC to some extent for many years and I
> have never used GetSafeHwnd(). There are arguably lots of things wrong with
> MFC, and GetSafeHwnd() might be a typical example of the mindset which
> produced those wrong things, but your logic just does not hold here.

My logic does hold; avoid undefined behaviour, period.  Implementations 
that defy the standard are of poor quality.  Threads were not mentioned 
by the pre C++11 standards however dereferencing null pointers surely was.

GetSafeHwnd() is called internally by MFC implementation even if you 
don't explicitly call it directly.  Think about what happens if you call 
CWnd::CreateEx with a NULL argument for the pParentWnd parameter.

/Leigh

[toc] | [prev] | [next] | [standalone]

#10490

Leigh Johnston <leigh@i42.co.uk> wrote in
news:rtydnY5CyKt78uLTnZ2dnUVZ8u2dnZ2d@giganews.com: 

> On 25/09/2011 19:08, Paavo Helde wrote:
>> Leigh Johnston<leigh@i42.co.uk>  wrote in news:
>> _pKdnd5RV9R19OLTnZ2dnUVZ8lSdnZ2d@giganews.com:
>>>
>>> Aside: Microsoft like to ignore the fact (or don't care about the
>>> fact) that this is undefined behaviour as they allow it in their MFC
>>> library in the form of CWnd::GetSafeHwnd() non-static member
>>> function which checks for the "this" pointer being NULL; they are
>>> relying on the fact that *their* defined behaviour of this
>>> particular undefined behaviour invocation has no ill effects on
>>> their particular implementation.  This is poor quality in my
>>> opinion; one of the reasons why I am ceasing to use MFC after many
>>> years in favour of a cross-platform C++ GUI library that I am
>>> currently working on. :) 
>>
>> The implementation can define (parts of) undefined behavior, there is
>> nothing wrong with this. For example, the multithreading behavior of
>> C++ programs has been defined by many implementations and this has
>> made it possible to write multi-threaded C++ programs long before the
>> multithreading behavior was defined by the C++ standard.
> 
> If you actually read what I said you will have noticed that I said 
> "*their* defined behaviour".
> 
>>
>> If you don't like CWnd::GetSafeHwnd(), then don't use it, it's as
>> simple as that. I have (been forced to) use MFC to some extent for
>> many years and I have never used GetSafeHwnd(). There are arguably
>> lots of things wrong with MFC, and GetSafeHwnd() might be a typical
>> example of the mindset which produced those wrong things, but your
>> logic just does not hold here. 
> 
> My logic does hold; avoid undefined behaviour, period. 

Agreed. However, as GetSafeHwnd() behavior is defined on the Windows/MSVC 
implementation, one does not encounter undefined behavior when using it 
on Windows/MSVC. Copying MFC source to some other random platform and 
trying to use it there might be indeed undefined.

> Implementations that defy the standard are of poor quality.  Threads
> were not mentioned by the pre C++11 standards however dereferencing
> null pointers surely was. 

What is not mentioned is undefined, isn't it so? The 2003 standard is 
based on a sequential abstract machine. For example, it contains a 
requirement: "A conforming implementation executing a well-formed program 
shall produce the same observable behavior as one of the possible 
execution sequences of the corresponding instance of the abstract machine 
with the same program and the same input." I guess many multithreaded 
programs are not well-formed according to this clause, or the 
implementations cannot be considered conforming.

Ok, if the example of threads doesn't appeal to you, take e.g. dlsym(). 
AFAIK using this function invokes undefined behavior as it involves 
casting data pointers to function pointers. Are you sure your favorite 
cross-platform GUI library does not call dlsym() on some POSIX platform?

> 
> GetSafeHwnd() is called internally by MFC implementation even if you 
> don't explicitly call it directly.  Think about what happens if you
> call CWnd::CreateEx with a NULL argument for the pParentWnd parameter.

This does not concern me at the least. If the library ensures it is 
working correctly on the supported platforms then I do not care if the 
features it relies upon are defined by the C++ standard or by the 
platform.

Cheers
Paavo

[toc] | [prev] | [next] | [standalone]

#10491

On 25/09/2011 20:15, Paavo Helde wrote:
> Leigh Johnston<leigh@i42.co.uk>  wrote in
> news:rtydnY5CyKt78uLTnZ2dnUVZ8u2dnZ2d@giganews.com:
>
>> On 25/09/2011 19:08, Paavo Helde wrote:
>>> Leigh Johnston<leigh@i42.co.uk>   wrote in news:
>>> _pKdnd5RV9R19OLTnZ2dnUVZ8lSdnZ2d@giganews.com:
>>>>
>>>> Aside: Microsoft like to ignore the fact (or don't care about the
>>>> fact) that this is undefined behaviour as they allow it in their MFC
>>>> library in the form of CWnd::GetSafeHwnd() non-static member
>>>> function which checks for the "this" pointer being NULL; they are
>>>> relying on the fact that *their* defined behaviour of this
>>>> particular undefined behaviour invocation has no ill effects on
>>>> their particular implementation.  This is poor quality in my
>>>> opinion; one of the reasons why I am ceasing to use MFC after many
>>>> years in favour of a cross-platform C++ GUI library that I am
>>>> currently working on. :)
>>>
>>> The implementation can define (parts of) undefined behavior, there is
>>> nothing wrong with this. For example, the multithreading behavior of
>>> C++ programs has been defined by many implementations and this has
>>> made it possible to write multi-threaded C++ programs long before the
>>> multithreading behavior was defined by the C++ standard.
>>
>> If you actually read what I said you will have noticed that I said
>> "*their* defined behaviour".
>>
>>>
>>> If you don't like CWnd::GetSafeHwnd(), then don't use it, it's as
>>> simple as that. I have (been forced to) use MFC to some extent for
>>> many years and I have never used GetSafeHwnd(). There are arguably
>>> lots of things wrong with MFC, and GetSafeHwnd() might be a typical
>>> example of the mindset which produced those wrong things, but your
>>> logic just does not hold here.
>>
>> My logic does hold; avoid undefined behaviour, period.
>
> Agreed. However, as GetSafeHwnd() behavior is defined on the Windows/MSVC
> implementation, one does not encounter undefined behavior when using it
> on Windows/MSVC. Copying MFC source to some other random platform and
> trying to use it there might be indeed undefined.
>
>> Implementations that defy the standard are of poor quality.  Threads
>> were not mentioned by the pre C++11 standards however dereferencing
>> null pointers surely was.
>
> What is not mentioned is undefined, isn't it so? The 2003 standard is
> based on a sequential abstract machine. For example, it contains a
> requirement: "A conforming implementation executing a well-formed program
> shall produce the same observable behavior as one of the possible
> execution sequences of the corresponding instance of the abstract machine
> with the same program and the same input." I guess many multithreaded
> programs are not well-formed according to this clause, or the
> implementations cannot be considered conforming.
>
> Ok, if the example of threads doesn't appeal to you, take e.g. dlsym().
> AFAIK using this function invokes undefined behavior as it involves
> casting data pointers to function pointers. Are you sure your favorite
> cross-platform GUI library does not call dlsym() on some POSIX platform?

I am writing my *own* cross-platform GUI library and it does not call 
dlsym no. http://neogfx.org  Also:

"Converting a pointer to a function into a pointer to an object type or 
vice versa is conditionally-supported.
The meaning of such a conversion is implementation-defined, except that 
if an implementation supports
conversions in both directions, converting a prvalue of one type to the 
other type and back, possibly with
different cv-qualification, shall yield the original pointer value."

I think there is a subtle difference between behaviour that is undefined 
because it is not mentioned by the standard and behaviour that is 
explicitly labelled as undefined behaviour by the standard.

>
>>
>> GetSafeHwnd() is called internally by MFC implementation even if you
>> don't explicitly call it directly.  Think about what happens if you
>> call CWnd::CreateEx with a NULL argument for the pParentWnd parameter.
>
> This does not concern me at the least. If the library ensures it is
> working correctly on the supported platforms then I do not care if the
> features it relies upon are defined by the C++ standard or by the
> platform.

Dodgy ground; I stand by my claim that MFC is of poor quality. :)

/Leigh

[toc] | [prev] | [next] | [standalone]

#10473

Is only one virtual table created for a class or different tables are created for different classes ??

[toc] | [prev] | [next] | [standalone]

#10474

On 25/09/2011 16:43, asit wrote:
> Is only one virtual table created for a class or different tables are created for different classes ??

You only have one class in your example so it is unclear if by "class" 
you mean "object" and yes only one vtable is created per class (if that 
class contains one or more virtual functions); the number of objects of 
that class is irrelevant.  I have already answered your initial question.

/Leigh

[toc] | [prev] | [next] | [standalone]

#10477

asit <lipun4u@gmail.com> wrote in 
news:15048105.1151.1316962687519.JavaMail.geo-discussion-forums@prng5:
[...]
> {
>         ex *ob = NULL;
>         ob->show();

This is undefined beahvior, don't do that.

> The output here is segmentation fault. 
> 
> If I make show non-virtual, there is no segmentation fault.
> 
> Can somebody explain me the reason ??

Virtual call is resolved at run-time according to the actual type of the 
object. As there is no object there is no way how it could work. A 
segfault is a reasonable outcome.

Non-virtual call is resolved at compile-time, so if it does not attempt 
to access the (non-existent) object data, there is some chance it might 
appear to work. It's still undefined behavior and could abort or segfault 
or whatever. If you want to call a member function without an object, 
make it a static member function and call like ex::show();

hth
Paavo

[toc] | [prev] | [next] | [standalone]

#10479

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

[toc] | [prev] | [next] | [standalone]

#10480

On 25/09/2011 18:53, Richard Damon wrote:
> 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).

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

[toc] | [prev] | [next] | [standalone]

#10483

Leigh Johnston <leigh@i42.co.uk> wrote in 
news:efmdnTFSgPOC8OLTnZ2dnUVZ8nCdnZ2d@giganews.com:
 
> Do you think that explaining the behaviour of particular undefined 
> behaviour invocations is useful?  

Sure, it makes it possible to understand how things are working and why 
something is left undefined. When one bases his/her coding only on the 
blind faith in the Holy Standard, then one is not able to spot defects in 
the standard, for example. This is not Koran or something, after all.

> The advice should be to avoid undefined behaviour, period.  

Without a reasonable explanation this would not work for me.

Cheers
Paavo

[toc] | [prev] | [next] | [standalone]

#10484

On 25/09/2011 19:18, Paavo Helde wrote:
> Leigh Johnston<leigh@i42.co.uk>  wrote in
> news:efmdnTFSgPOC8OLTnZ2dnUVZ8nCdnZ2d@giganews.com:
>
>> Do you think that explaining the behaviour of particular undefined
>> behaviour invocations is useful?
>
> Sure, it makes it possible to understand how things are working and why
> something is left undefined. When one bases his/her coding only on the
> blind faith in the Holy Standard, then one is not able to spot defects in
> the standard, for example. This is not Koran or something, after all.
>
>> The advice should be to avoid undefined behaviour, period.
>
> Without a reasonable explanation this would not work for me.

Then I would have to assume that the code you produce would be of 
dubious quality.  I strive to write bug-free code; I thought we all did.

/Leigh

[toc] | [prev] | [next] | [standalone]

#10492

Leigh Johnston <leigh@i42.co.uk> wrote in
news:rtydnYlCyKvI7OLTnZ2dnUVZ8u2dnZ2d@giganews.com: 

> On 25/09/2011 19:18, Paavo Helde wrote:
>> Leigh Johnston<leigh@i42.co.uk>  wrote in
>> news:efmdnTFSgPOC8OLTnZ2dnUVZ8nCdnZ2d@giganews.com:

>>> The advice should be to avoid undefined behaviour, period.
>>
>> Without a reasonable explanation this would not work for me.
> 
> Then I would have to assume that the code you produce would be of 
> dubious quality.  I strive to write bug-free code; I thought we all
> did. 

I understand that your advice is to follow formal rules without 
understanding why they have put in place. This assumes a) the formal rules 
are complete and 100% correct; b) the implementation follows the rules 100% 
and has no bugs; c) the programmer has the memory capacity for remembering 
all the 1000+ pages of C++ standard and applying them all as necessary at 
any time moment. 

In real life none of those assumptions hold.

Cheers
Paavo

[toc] | [prev] | [next] | [standalone]

#10488

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.

[toc] | [prev] | [next] | [standalone]

#10494

Leigh Johnston <leigh@i42.co.uk> 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"

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c++

csiph-web