Conference turris::c_plus_plus

I've responded to three of your queries.  Others will respond to the
other two.  We would be interested in having this partner field test V6.0.
We plan to start field test this summer.


>2) templates parameter names must match exactly

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

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

Re .0 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.
Thanks.

Re .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 thought it was similar to C_PLUS_PLUS:3361 (Code fixed at 10-Dec-1996).
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, we want to look into it 
if is not the same as 3361.

    Hello
    
    Thank you very much for your help. I have asked the partner to
    provide examples case 1 and 3.
    
    -Lakshminarayan

> 
> >    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);
}

    

I've verified that the small test program in the previous reply reproduces
the problem and have noted it in our internal bug tracking system.

                                August G. Reinig

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.