Conference hydra::axp-developer

From:	HYDRA::LNARAYAN     "R Lakshminarayan, Software Partner Engg" 14-APR-1997 12:57:03.27
To:	US4RMC::"[email protected]"
CC:	LNARAYAN
Subj:	 porting/C++ problems

John Wood

Thanks for contacting Alpha developer support. As you said this is the
right place to report Partner porting issues. I have few answers, But
need example code. Our C++ team wants to know whether you would be 
interested in becoming field test site to field test C++ Version 6.0? 
(starting this summer) Please note that the reference number for this 
call is #3400 dated 25-MAR-1997 and quote this number when communicating
wrt to this call.

Thank You
-Nari
Alpha Developer Support

Answers from our C++ group for your questions:

item 1)

>    while (size) {		// destroy each element of the array
>       array[--size].~T();
>    }
>
>    Produces an infinite loop if T is int:

If the size is a negative number, then it shall run into loop.
However, you also mentioned that the following workaround:

>    while (size) {		// destroy each element of the array
>      --size;
>       array[size].~T();
>    }

It more likely a bug somewhere then.
We would like to look into this case, please provide us a small test that
could demonstrate this loop problem.
--------------------------------------------------------------------------------
>2) templates parameter names must match exactly

The workaround is as stated.  This is fixed in V6.0.

--------------------------------------------------------------------------------
item 3)

>+ cxx -DBUG -w0 -g -nocleanup -O0 -inline none InheritanceBug.cc -o
>InheritanceBug 
>+ InheritanceBug 
>Assertion failed: !l5, file InheritanceBug.cc, line 45
>
>
>	WORKAROUND:
>	In this case, moving operator= down a level solves the problem.
>	Unfortunately, we don't know why this happens, so the cure is
>	magic and may not be a general remedy.  The above example was
>	derived from SafePtr<T> (tSafePtr originally demonstrated the
>	problem).

I could not reproduce the same problem from your source posted at item 3)
on both compiler: 
	DEC C++ V5.5-004 on Digital UNIX (Alpha)
	DEC CXX X5.6-130 on Digital UNIX (Alpha)

shijun.zko.dec.com> cxx -DBUG -w0 -g -nocleanup -O0 -inline none cpp3531c.cxx
ld:
Unresolved:
f(FooPtr)
shijun.zko.dec.com> $CEXE/deccxx_driver -DBUG -w0 -g -nocleanup -O0 -inline none
cpp3531c.cxx
ld:
Unresolved:
f(FooPtr)

After I provided the definition to the "f(FooPtr)" as {return b;},
the code ran fine from both compilers.
shijun.zko.dec.com> a.out
copy constructor called
copy constructor called
destructor called
destructor called
destructor called

Please provide us a test that can show this problem.
--------------------------------------------------------------------------------
>4)  -O0 doesn't seem to turn off all optimzation.
>
>    The copy constructor/destructor calls for x3 are optimized out even
>    when -O0 is on the command line.  This lead us down a wild goose chase
>    looking for bug #3.

This was done to provide a consistent semantic meaning with and without
optimization.  I've noted a suggestion to provide a way to disable
optimization of copy ctor/dtor calls.
--------------------------------------------------------------------------------
>5) templates must be in header files, along with any classes or
>   definitions that template relies on.
>
The workaround is as stated.  Yes, this is a documented restriction of the
automatic instantiation implementation for V5.n.  We plan to lift this
restriction in V6.0.
--------------------------------------------------------------------------------




    

From:	US6RMC::"[email protected]" "John Wood" 14-APR-1997 17:05:04.43
To:	hydra::lnarayan
CC:	
Subj:	porting/C++ problems/ call #3400


reference call #3400 dated 25 MAR 1997

> 
> >    while (size) {		// destroy each element of the array
> >       array[--size].~T();
> >    }
> >
> >    Produces an infinite loop if T is int:
> 
> If the size is a negative number, then it shall run into loop.

Obviously, but size is not a negative number.  This code works on all
other compilers we use.  

>            please provide us a small test that could demonstrate
> this loop problem.

Happy to:

#include <stdio.h>
#include <new.h>
#include <assert.h>

template <class T>
class List {
    int max_size;
    int size;
    T   *array;  
public:

    int length() { return( size ); }
    T &elem( int i ) { assert( i < size ); return( array[i] ); }
    void *operator new( size_t, void *place ) { return( place ); }

    void append( const T &x ) {
        assert( size < max_size );
        new (& array[size]) T( x ); 
        ++size;
    }

    List() : max_size( 8 ), size( 0 )  { 
        array = (T *) new char[sizeof( T ) * max_size];
    }

    ~List() {
        while( size > 0 ) 
            array[--size].~T();
    }
};

int
main()
{
    printf( "List start\n" );
    {
        List<int> li;
        int i;
        for( i = 0; i < 4; ++i )
            li.append( i * i );
        for( i = 0; i < 4; ++i )
            printf( "%d => %d\n", i, li.elem( i ) );
    }
    printf( "List end\n" );
}
        
> item 3)
> 
> >+ cxx -DBUG -w0 -g -nocleanup -O0 -inline none InheritanceBug.cc -o
> After I provided the definition to the "f(FooPtr)" as {return b;},
> the code ran fine from both compilers.

Try: { return new foo(0); }

#include <stdio.h>
#include <assert.h>

struct foo {
  foo(int y) : x(y) {};
  int x;
};

class FooPtr_Base {
public:
  
#ifdef BUG  
  int operator!() const { return p == 0; }
#endif
  
  ~FooPtr_Base() { printf( "destructor called\n"); delete p; }
  FooPtr_Base() : p(0) {}
  foo* p;
};

class FooPtr : public FooPtr_Base {
public:

#ifndef BUG  
  int operator!() const { return p == 0; }
#endif
  
  FooPtr(foo* pf) {
    p = pf;
  }
  
  FooPtr(const FooPtr& src){
    p = src.p;
    printf("copy constructor called\n");
    (foo* &)src.p = 0;
  }
};

extern FooPtr f( FooPtr b );

int main (int , char **argv) {
  FooPtr l5(new foo(2));
  FooPtr q( f(l5 ));
  
  assert(!l5);
  return 0;
}


FooPtr 
f( FooPtr b )
{
    return new foo(0);
}



___

Regards,

John Wood

% ====== Internet headers and postmarks (see DECWRL::GATEWAY.DOC) ======
% Received: from mail13.digital.com by us6rmc.mro.dec.com (5.65/rmc-17Jan97) id AA00611; Mon, 14 Apr 97 16:58:52 -0400
% Received: from mail-oak-1.pilot.net by mail13.digital.com (8.7.5/UNX 1.5/1.0/WV) id QAA02058; Mon, 14 Apr 1997 16:54:02 -0400 (EDT)
% Received: from cogit.com (unknown-79-101.ergosum.com [206.189.79.101]) by mail-oak-1.pilot.net with SMTP id NAA18068 for <[email protected]>; Mon, 14 Apr 1997 13:48:22 -0700 (PDT)
% Received: from reficio.cogit.com by cogit.com (SMI-8.6/SMI-SVR4) id MAA20059; Mon, 14 Apr 1997 12:34:49 -0700
% From: [email protected] (John Wood)
% Received: by reficio.cogit.com (SMI-8.6/client-1.3) id MAA01431; Mon, 14 Apr 1997 12:36:09 -0700
% Date: Mon, 14 Apr 1997 12:36:09 -0700
% Message-Id: <[email protected]>
% Subject: porting/C++ problems/ call #3400
% To: hydra::lnarayan
% Mime-Version: 1.0
% Content-Type: text/plain; charset=us-ascii
% Content-Transfer-Encoding: 7bit
% Content-Md5: jn08D0IzBZwSyURbuaw+Xw==
    

    The problem reported in the previous mail is a bug and C++ notes conf
    confirms this. see note 3531 in c++ for more info.

From:	DECC::KAO "Shi-Jung Kao  15-Apr-1997 1058 -0500" 15-APR-1997 11:00:32.72
To:	HYDRA::LNARAYAN
CC:	
Subj:	Item 3 has been fixed in V5.6 C++ field test release, and will be available soon.

        <<< TURRIS::DISK$NOTES_PACK:[NOTES$LIBRARY]C_PLUS_PLUS.NOTE;2 >>>
                                    -< C++ >-
================================================================================
Note 3531.7                     C++ questions...                          7 of 7
DECC::KAO                                            12 lines  15-APR-1997 10:58
                     -< Problem item 3 has been fixed... >-
--------------------------------------------------------------------------------
Thanks for your tests.
Since August already noted the problem into the bug tracking system,
I just want to clarify the following:

Your workaround on item 1, the loop problem is correct.

Item 3:

>Assertion failed: !l5, file InheritanceBug.cc, line 45

This problem has been fixed in our next release of DEC C++ V5.6
compiler.  Its field test release for UNIX will be available in a week or so.