strange behavior...

strange behavior...

[Thierry DESCOMBES]

Hi,

I'm using "gcc version 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)". (but same  
thing occurs on a older version).

I fall into an "invalid covariant return type" during a project  
development. I didn't manage to reproduce this error, in a short  
example... But, while trying, I fall into a very strange behavior. I find  
an example which worked or failed at compil time depanding on the way the  
class inherit together (it works when public and fails when private) !!

So, this is working

   class A {};

   class B
   {
      virtual A* getA();
   };

   class D_A : public A {};

   class D_B : public B
   {
     virtual D_A* getA();
   };

and, this is not working:

   class A {};

   class B
   {
      virtual A* getA();
   };

   class D_A :  A {};

   class D_B :  B
   {
     virtual D_A* getA();
   };

and is producing:
test2.cc:23: error: invalid covariant return type for `virtual D_A*  
D_B::getA()'test2.cc:9: error: overriding `virtual A* B::getA()'

Very strange, isn't it ?

Cheers,
T.

Re: Strange behavior

[Jimen Ching]

On 1 Mar 1998, Alexandre Oliva wrote:
> Which version of egcs, on which platform?  Both 1.0.1 and the latest
> snapshot compile that fine for me, even without typename (which, IMHO,
> is wrong)

I've just 'cvs update' to the latest sources and the problem went away.
Now I get the following message:

bug9.cc:13: `__eq<>' does not match any template declaration
bug9.cc:13: confused by earlier errors, bailing out

I think this has already been reported...

--jc
--
Jimen Ching (WH6BRR)      jching@flex.com     wh6brr@uhm.ampr.org

Re: Strange behavior

[Alexandre Oliva]

Jimen Ching writes:

> You cut off the sentence where I said g++ did not warn about a typename.
> I've already tried typename, and it didn't work either.

Which version of egcs, on which platform?  Both 1.0.1 and the latest
snapshot compile that fine for me, even without typename (which, IMHO,
is wrong)

> But my point was that g++ didn't warn about typename and gave an
> error instead.  A parse error at that.  You would think that a
> missing typename would be a semantic error, not a parse error.

Nope, the `typename' keyword is required to tell the parser that what
follows is a type name, not a static member variable or function.  The
C++ Standard states that, if a template-argument-dependent qualified
name is not preceded by the `typename' keyword, it is not to be
considered a type name.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Re: Strange behavior

[Jimen Ching]

On 28 Feb 1998, Alexandre Oliva wrote:
> Jimen Ching writes:
> > 	I get the following behavior.  Is there something wrong with the
> > code or with g++?
> With the code.  You must use the `typename' keyword before any
> template argument-dependent nested type.
> 
> >                 list_type::const_iterator idx = _my_list.begin();

You cut off the sentence where I said g++ did not warn about a typename.
I've already tried typename, and it didn't work either.  But my point was
that g++ didn't warn about typename and gave an error instead.  A parse
error at that.  You would think that a missing typename would be a
semantic error, not a parse error.

--jc
--
Jimen Ching (WH6BRR)      jching@flex.com     wh6brr@uhm.ampr.org

Re: Strange behavior

[Alexandre Oliva]

Jimen Ching writes:

> 	I get the following behavior.  Is there something wrong with the
> code or with g++?

With the code.  You must use the `typename' keyword before any
template argument-dependent nested type.

>                 list_type::const_iterator idx = _my_list.begin();

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Strange behavior

[Jimen Ching]

Hi,
	I get the following behavior.  Is there something wrong with the
code or with g++?  Note, I didn't get a warning about using typename.

--jc
------------------------------------
~/src/bug% /usr/local/bin/g++ -pedantic bug9.cc
bug9.cc: In method `my_class<T>::my_class()':
bug9.cc:13: parse error before `='
[core:ttyp2]
~/src/bug% /usr/local/bin/g++ bug9.cc
bug9.cc:13: `__eq<>' does not match any template declaration
bug9.cc:13: confused by earlier errors, bailing out

-------------------------
#include <list>

template<class T>
class my_class
        {
public:

        typedef T value_type;
        typedef list<value_type> list_type;

        my_class()
                {
                list_type::const_iterator idx = _my_list.begin();
                }
        ~my_class()
                {}

private:
        list_type _my_list;
        };

--
Jimen Ching (WH6BRR)      jching@flex.com     wh6brr@uhm.ampr.org

Re: Strange behavior

[Jeffrey A Law]

  In message < 199711152052.VAA15223@saturn.s-direktnet.de >you write:
  > This patch should fix it.
  > 
  > Sat Nov 15 21:49:04 1997  Manfred Hollstein  <manfred@s-direktnet.de>
  > 
  > 	* Makefile.in (compare, compare-lean): Define $stage for each
  > 	shell command.
  > 	(gnucompare, gnucompare-lean): Likewise.
Thanks for tracking this down.

I've installed the patch.

jeff

Re: Strange behavior

[Manfred Hollstein]

On Sat, 15 November 1997, 14:04:36, manfred@s-direktnet.de wrote:

    On Wed, 12 November 1997, 12:22:55, jackson@msrce.howard.edu wrote:
    
        >None of the possible 'make bootstrap*' rules invoke _any_ compare*
        >targets;
        
        It is true that the gcc/Makefile bootstrap* targets do not 'compare' but, if you 
        look in the top level Makefile, you will see the bootstrap* targets that I _am_ 
        talking about.
        
    Aahh, now I see your problem; shame  on me, as I  made the most recent
    changes to the bootstrap handling :-(
    
    I'm sorry, can  you please tell  me exactly, how  you called make with
    what results?
    
This patch should fix it.

Sat Nov 15 21:49:04 1997  Manfred Hollstein  <manfred@s-direktnet.de>

	* Makefile.in (compare, compare-lean): Define $stage for each
	shell command.
	(gnucompare, gnucompare-lean): Likewise.

*** egcs-971114.orig/gcc/Makefile.in	Wed Nov  5 03:22:37 1997
--- egcs-971114/gcc/Makefile.in	Sat Nov 15 21:48:43 1997
*************** compare compare3 compare4 compare-lean c
*** 2624,2629 ****
--- 2624,2630 ----
  	  fi; \
  	done
  	-rm -f tmp-foo*
+ 	case "$@" in compare | compare-lean ) stage=2 ;; * ) stage=`echo $@ | sed -e 's,^compare\([0-9][0-9]*\).*,\1,'` ;; esac; \
  	if [ -f .bad_compare ]; then \
  	  echo "Bootstrap comparison failure!"; \
  	  cat .bad_compare; \
*************** gnucompare gnucompare3 gnucompare4 gnuco
*** 2652,2657 ****
--- 2653,2659 ----
  	    done; \
  	  fi; \
  	done
+ 	case "$@" in gnucompare | gnucompare-lean ) stage=2 ;; * ) stage=`echo $@ | sed -e 's,^gnucompare\([0-9][0-9]*\).*,\1,'` ;; esac; \
  	if [ -f .bad_compare ]; then \
  	  echo "Bootstrap comparison failure!"; \
  	  cat .bad_compare; \