Does GCC 3.4 fix this bug?

Does GCC 3.4 fix this bug?

[Eljay Love-Jensen]

Hi everyone,

Does anyone know if this annoying bug in GCC is going to be fixed in 3.4?
--------8<--------
class Foo
{
public:
  Foo();
};

Foo::Foo()
{
}

class Bar
{
public:
  Bar(const Foo& foo) { }
  void print() { }
};

int main()
{
  Bar quux(Foo()); // -- Bug in GCC 3.2 & 3.3
  //Bar quux((0,Foo())); // -- workaround in GCC 3.2 & 3.3
  quux.print();
}
--------8<--------

(Or if GCC 3.2/3.3 are correct, let me know that I'm mistaken about the ISO 14882 standard.)

Thanks,
--Eljay

Re: Does GCC 3.4 fix this bug?

[Nathan Sidwell]

Eljay Love-Jensen wrote:
> Hi everyone,
> 
> Does anyone know if this annoying bug in GCC is going to be fixed in 3.4?

> int main()
> {
>   Bar quux(Foo()); // -- Bug in GCC 3.2 & 3.3
quux is a function taking a (pointer to function taking no args, returning a
Foo) argument and returning a Bar
>   //Bar quux((0,Foo())); // -- workaround in GCC 3.2 & 3.3
or Bar quux = Bar (Foo ())

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
          The voices in my head said this was stupid too
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: Does GCC 3.4 fix this bug?

[Oliver Kullmann]

Hi,

that's no bug, but the ambiguity in the syntax of C++ regarding declarations and
definitions (which is always resolved as taking the declaration):

Bar quux(Foo());

**declares** a function named quux of type

Bar ()(Foo (*)())

as the error message

test11092003.cpp:22: request for member `print' in `quux(Foo (*)())', which is
   of non-aggregate type `Bar ()(Foo (*)())'

clearly states (think about it(!)). Fortunately, double brackets are not allowed
in a declaration of a function, but are allowed around expressions, which
disambiguates the line

Bar quux(Foo());

via

Bar quux((Foo()));

(and it becomes a declaration of a variable quux of type Bar, using the
one (conversion) constructor in class Bar).

Oliver

P.S. I guess that's a type in

Bar quux((0,Foo()));

?

> 
> Hi everyone,
> 
> Does anyone know if this annoying bug in GCC is going to be fixed in 3.4?
> --------8<--------
> class Foo
> {
> public:
>   Foo();
> };
> 
> Foo::Foo()
> {
> }
> 
> class Bar
> {
> public:
>   Bar(const Foo& foo) { }
>   void print() { }
> };
> 
> int main()
> {
>   Bar quux(Foo()); // -- Bug in GCC 3.2 & 3.3
>   //Bar quux((0,Foo())); // -- workaround in GCC 3.2 & 3.3
>   quux.print();
> }
> --------8<--------
> 
> (Or if GCC 3.2/3.3 are correct, let me know that I'm mistaken about the ISO 14882 standard.)
> 
> Thanks,
> --Eljay
> 

Re: Does GCC 3.4 fix this bug?

[Eljay Love-Jensen]

Hi Nathan,

>quux is a function taking a (pointer to function taking no args, returning a Foo) argument and returning a Bar

I realize that's what the compiler is interpreting it as.  But I believe that the compiler's interpretation of the code is incorrect.

MSVC (that bastion of standards compliance -- NOT!), and CodeWarrior interpret the code as the variable quux using the const Foo& constructor of Bar.

I don't have the EDG compiler at my disposal, and my Comeau C++ compiler is from 1990 (*grin*).

--Eljay

Re: Does GCC 3.4 fix this bug?

[Eljay Love-Jensen]

Hi Oliver,

Even when doing...
  auto Bar quux(Foo());
...it still takes it as a declaration instead of a definition.  That doesn't seem kosher at all.

--Eljay

Re: Does GCC 3.4 fix this bug?

[Nathan Sidwell]

Eljay Love-Jensen wrote:
> Hi Nathan,
> 
> 
>>quux is a function taking a (pointer to function taking no args, returning a Foo) argument and returning a Bar
> 
> 
> I realize that's what the compiler is interpreting it as.  But I believe that the compiler's interpretation of the code is incorrect.
you did not make that clear. the compiler is correct.

nathan
-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
          The voices in my head said this was stupid too
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: Does GCC 3.4 fix this bug?

[Oliver Kullmann]

On Thu, Sep 11, 2003 at 11:46:56AM -0500, Eljay Love-Jensen wrote:
> Date: Thu, 11 Sep 2003 11:46:56 -0500
> From: Eljay Love-Jensen <eljay@adobe.com>
> In-reply-to: <20030911163705.GA19868@swan.ac.uk>
> X-Sender: eljay@iplan-mn.corp.adobe.com
> To: Oliver Kullmann <O.Kullmann@swansea.ac.uk>, gcc-help@gcc.gnu.org
> X-Mailer: QUALCOMM Windows Eudora Version 5.2.1
> X-SA-Exim-Mail-From: eljay@adobe.com
> Subject: Re: Does GCC 3.4 fix this bug?
> X-Spam-Checker-Version: SpamAssassin 2.60-rc1 (1.197-2003-08-21-exp) on mhs
> X-Spam-Level: 
> X-Spam-Status: No, hits=0.0 required=5.5 tests=none autolearn=no version=2.60-rc1
> X-SA-Exim-Version: 3.1 (built Fri Aug 22 12:30:01 GMT 2003)
> X-UIDL: <k!"!(\G"!a@j"!0L("!
> 
> Hi Oliver,
> 
> Even when doing...
>   auto Bar quux(Foo());
> ...it still takes it as a declaration instead of a definition.  That doesn't seem kosher at all.
> 
> --Eljay
> 
>

I'm not sure about the exact syntax regarding storage specifiers like auto, however I'm quite
sure that for the first example you gave as a bug g++ is absolutely correct (and other compilers,
if accepting the construction, are not): Have a look into Section 8.2 of the standard.
(There is also a section in one of Scott Myers books about it, called something like
"C++ most vexing parse").
I would guess adding something like auto shouldn't change much.

The solution using double brackets is not mentioned in the standard, but I believe it's
perfectly correct (I think it's in Myers book), and can be used in other circumstances too:

Always when you see suddenly this function-pointer-brackets showing up in error messages,
then it's a variation of the same old problem! (I experience these problems roughly once
a month.)

Oliver
 

Re: Does GCC 3.4 fix this bug?

[Eljay Love-Jensen]

Thanks for everyone's input!

When these things crop up, I'll put in the extra set of parens to delineate the item as a parameter to a definition, which disambiguates the sitation so that the compiler doesn't interpret it as a declaration.

CodeWarrior and MSVC should digest the extra set of parens without complaint.

Sincerely,
--Eljay

I love this forum!