Re: Is it an undefined behavior in C++ Standard?

From: aka (akademecia_at_hotmail.com)
Date: 03/13/05

  • Next message: Jon Slaughter: "Re: Classses of each other"
    Date: Sun, 13 Mar 2005 16:03:11 +0800
    
    

    I'm learning Visual C++ 2005. I want to know how it implement ISO C++
    standard, such as undefined behavior.

    "Peter Koch Larsen" <pklspam@mailme.dk> дÈëÏûÏ¢
    news:zRgYd.104094$Vf.3990245@news000.worldonline.dk...
    >
    > "aka" <akademecia@hotmail.com> skrev i en meddelelse
    > news:d0s4l9$kdm$1@news.yaako.com...
    > > // classA.cpp : Defines the entry point for the console application.
    > > //
    > >
    > > #include "stdafx.h"
    > >
    > > #include <iostream>
    > >
    > > using namespace std;
    > >
    > > static unsigned int count = 0;
    > >
    > > class A
    > > {
    > > public:
    > > A() {
    > > p = this;
    > > }
    > >
    > > ~A() {
    > > if (p) {
    > > cout << count++ << endl;
    > > delete p;
    > > p = 0;
    > > }
    > > }
    > >
    > > private:
    > > A *p;
    > > };
    > >
    > > int _tmain(int argc, _TCHAR* argv[])
    > > {
    > > A a;
    > >
    > > return 0;
    > > }
    > >
    > > /* compiler: MSC++ compiler in visual c++ 2005 express edition beta
    > > command: cl /nologo /EHsc classA.cpp
    > > */
    > >
    > > /* result:
    > > 0
    > > 1
    > > 2
    > > ...
    > > 23485
    > > press any key to continue
    > > */
    > >
    > > /*
    > > question: Is it an undefined behavior in C++ Standard?
    > What is? What you do is calling the destructor of an object more than once
    > and that causes undefined behaviour.
    > >
    > > details: p is a point of class A, when destructor call 'delete p',it
    will
    > > cause destructor again.
    > > Is there any limit calling destructor recursively?
    >
    > No. You can do as long as you please. Almost! Your program
    > Not in your program - it has endless recursion.
    >
    > Also I fail to sees what youre attempting to do.
    >
    >
    > /Peter
    >
    > > */ÿÿÿ
    > >
    > >
    >
    >


  • Next message: Jon Slaughter: "Re: Classses of each other"

    Relevant Pages

    • Re: usage of size_t
      ... that this rule is already implicit in the current standard.) ... -- A VLA type whose size exceeds SIZE_MAX bytes cause the program's ... Once you allow undefined behavior, there can be no guarantees of ... that support objects bigger than SIZE_MAX are not conforming? ...
      (comp.lang.c)
    • Re: size_t overflow
      ... The ISO standard seems to permit segmented memory models in that way. ... Since it's not strictly conforming, implementations are free to reject it; but is there a general rule that makes its behaviour completely undefined even on implementations that accept it? ... Something that wouldn't exclude implementation defined and unspecified behavior, as far as they're not relied on in a way that would make the program expose undefined behavior later on. ... With this new wording, excluding unspecified and implementation defined behavior from the list of things that a "portable" program mustn't do, the concept of "portable" program would *still* be bogous because of implementation limits. ...
      (comp.std.c)
    • Re: second fclose() should not segfault
      ... quoted the section of the standard that says it's undefined behavior ... At the time you wrote that, the relevant sections of the standard ... calling fclose() twice with the same FILE* argument invokes undefined ... it does specify that the value of the pointer that used to point to ...
      (comp.std.c)
    • Re: Buffer overflows and asctime()
      ... I agree with that, it doesn't require implementations ... discussion by disagreeing about what the standard says about asctime? ... There are numerous other library functions that have undefined behavior ... You seem to be ignoring proposals to leave it undefined, ...
      (comp.std.c)
    • Re: Yet another binary search tree library
      ... Some information in this wikipedia page is wrong. ... if there is undefined behavior or not (not counting ... As far as the Standard is concerned, ... kind of struct by means of member access (ie, ...
      (comp.lang.c)