A very stupid bug...

Discussion in 'C++' started by Alf P. Steinbach, May 3, 2010.

  1. At one point I became convinced that the compiler generated incorrect
    destruction code for multiple inheritance.

    Oh well.

    I finally found it:

    virtual ~RawPtrHolder()
    {
    std::auto_ptr< Type >( myPtr ); // Destroy via std::auto_ptr for access.
    }

    Uh oh.

    Can you see what I did wrogn?


    Cheers,

    - Alf
     
    Alf P. Steinbach, May 3, 2010
    #1
    1. Advertising

  2. Alf P. Steinbach

    cpp4ever Guest

    On 05/03/2010 03:50 PM, Alf P. Steinbach wrote:
    > At one point I became convinced that the compiler generated incorrect
    > destruction code for multiple inheritance.
    >
    > Oh well.
    >
    > I finally found it:
    >
    > virtual ~RawPtrHolder()
    > {
    > std::auto_ptr< Type >( myPtr ); // Destroy via std::auto_ptr for
    > access.
    > }
    >
    > Uh oh.
    >
    > Can you see what I did wrogn?
    >
    >
    > Cheers,
    >
    > - Alf


    Tried to free invalid memory because myPtr had not been
    reset/initialised to NULL? That would be nasty.

    Using std::auto_ptr in a constructor to simplify the throwing
    of exceptions, maybe, but I'm not sure I'd ever use std::auto_ptr
    like that.

    JB
     
    cpp4ever, May 4, 2010
    #2
    1. Advertising

  3. On 05.05.2010 00:59, * cpp4ever:
    > On 05/03/2010 03:50 PM, Alf P. Steinbach wrote:
    >> At one point I became convinced that the compiler generated incorrect
    >> destruction code for multiple inheritance.
    >>
    >> Oh well.
    >>
    >> I finally found it:
    >>
    >> virtual ~RawPtrHolder()
    >> {
    >> std::auto_ptr< Type>( myPtr ); // Destroy via std::auto_ptr for
    >> access.
    >> }
    >>
    >> Uh oh.
    >>
    >> Can you see what I did wrogn?
    >>

    >
    > Tried to free invalid memory because myPtr had not been
    > reset/initialised to NULL? That would be nasty.
    >
    > Using std::auto_ptr in a constructor to simplify the throwing
    > of exceptions, maybe, but I'm not sure I'd ever use std::auto_ptr
    > like that.


    Eric J. Holtman had it mostly right (else-thread).

    The problem is that the statement is a declaration, of a variable 'myPtr',
    instead of constructing a temporary std::auto_ptr instance; it's known as "the
    most vexed parse of C++", that anything that syntactically can be treated as a
    declaration is treated as a declaration...

    My fix was to write

    std::auto_ptr<Type>( myPtr+0 )

    :)


    Cheers,

    - Alf
     
    Alf P. Steinbach, May 5, 2010
    #3
  4. Alf P. Steinbach

    cpp4ever Guest

    On 05/05/2010 12:43 AM, Alf P. Steinbach wrote:
    > On 05.05.2010 00:59, * cpp4ever:
    >> On 05/03/2010 03:50 PM, Alf P. Steinbach wrote:
    >>> At one point I became convinced that the compiler generated incorrect
    >>> destruction code for multiple inheritance.
    >>>
    >>> Oh well.
    >>>
    >>> I finally found it:
    >>>
    >>> virtual ~RawPtrHolder()
    >>> {
    >>> std::auto_ptr< Type>( myPtr ); // Destroy via std::auto_ptr
    >>> for
    >>> access.
    >>> }
    >>>
    >>> Uh oh.
    >>>
    >>> Can you see what I did wrogn?
    >>>

    >>
    >> Tried to free invalid memory because myPtr had not been
    >> reset/initialised to NULL? That would be nasty.
    >>
    >> Using std::auto_ptr in a constructor to simplify the throwing
    >> of exceptions, maybe, but I'm not sure I'd ever use std::auto_ptr
    >> like that.

    >
    > Eric J. Holtman had it mostly right (else-thread).
    >
    > The problem is that the statement is a declaration, of a variable
    > 'myPtr', instead of constructing a temporary std::auto_ptr instance;
    > it's known as "the most vexed parse of C++", that anything that
    > syntactically can be treated as a declaration is treated as a
    > declaration...
    >
    > My fix was to write
    >
    > std::auto_ptr<Type>( myPtr+0 )
    >
    > :)
    >
    >
    > Cheers,
    >
    > - Alf


    DOH!!! Of course that's the problem. Serves you right for trying to be
    too clever by half. I'd have probably declared a temporary variable for
    the std::auto_ptr, if only because it's easier to read. Doesn't A.L.F
    stand for alien life form?

    JB
     
    cpp4ever, May 5, 2010
    #4
    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. Raymond Arthur St. Marie II of III

    very Very VERY dumb Question About The new Set( ) 's

    Raymond Arthur St. Marie II of III, Jul 23, 2003, in forum: Python
    Replies:
    4
    Views:
    499
    Raymond Hettinger
    Jul 27, 2003
  2. shanx__=|;-

    very very very long integer

    shanx__=|;-, Oct 16, 2004, in forum: C Programming
    Replies:
    19
    Views:
    1,682
    Merrill & Michele
    Oct 19, 2004
  3. Abhishek Jha

    very very very long integer

    Abhishek Jha, Oct 16, 2004, in forum: C Programming
    Replies:
    4
    Views:
    446
    jacob navia
    Oct 17, 2004
  4. Peter

    Very very very basic question

    Peter, Feb 8, 2005, in forum: C Programming
    Replies:
    14
    Views:
    526
    Dave Thompson
    Feb 14, 2005
  5. olivier.melcher

    Help running a very very very simple code

    olivier.melcher, May 12, 2008, in forum: Java
    Replies:
    8
    Views:
    2,329
Loading...

Share This Page