Re: what is wrong here?

Re: what is wrong here?

[Alexandre Oliva]

On Jul  1, 1999, dvv@dvv.ru (Dima Volodin) wrote:

> namespace N {
> class C {
>         friend void ::f ();

> bug.cc:4: parse error before `('

Thanks for your bug report.  I'm installing a simplified version of
your testcase in the testsuite.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: what is wrong here?

[Dima Volodin]

I guess this one is closely related:

void f ();

namespace N {

using ::f;

class C {
        friend void f ();
        int  m;
} c;

}

void
f () {
        N::c.m = 0;
}

> g++ bug1.cc

bug1.cc:8: `void N::f()' conflicts with previous using declaration `void
f()'
bug1.cc: In function `void f()':
bug1.cc:9: `int N::C::m' is private
bug1.cc:16: within this context


On 02 Jul 1999 01:37:08 -0300, you wrote:

>On Jul  1, 1999, dvv@dvv.ru (Dima Volodin) wrote:
>
>> namespace N {
>> class C {
>>         friend void ::f ();
>
>> bug.cc:4: parse error before `('
>
>Thanks for your bug report.  I'm installing a simplified version of
>your testcase in the testsuite.
>
>-- 
>Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
>{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
>oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
>*** E-mail about software projects will be forwarded to mailing lists
>
>

Re: what is wrong here?

[Alexandre Oliva]

On Jul  2, 1999, dvv@dvv.ru (Dima Volodin) wrote:

> I guess this one is closely related:

> namespace N {
> using ::f;
> class C {
>         friend void f ();

> bug1.cc:8: `void N::f()' conflicts with previous using declaration `void f()'

Yup.  In fact, I had met this bug while trying to find a work-around
for you, but I had forgotten to add it to the testsuite too.  Thanks
for reminding me of that.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: what is wrong here?

[Alexandre Oliva]

On Jul  3, 1999, "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> wrote:

>> > namespace N {
>> > using ::f;
>> > class C {
>> >         friend void f ();

>> > bug1.cc:8: `void N::f()' conflicts with previous using declaration `void f()'

>> Yup.  In fact, I had met this bug while trying to find a work-around
>> for you, but I had forgotten to add it to the testsuite too.  Thanks
>> for reminding me of that.

> Why is this a bug? I believe the error message is correct.

IMHO, the using declaration causes the name `f' to be found in N, so
the friend declaration shouldn't introduce a new declaration, just
bind to the one it finds.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: what is wrong here?

[Alexandre Oliva]

On Jul  4, 1999, "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> wrote:

> However, if that was the case: Why is it allowed that two using
> declarations introduce two functions with identical parameter lists?

This is just a guess: Maybe because functions can be overloaded, and
there's no way fro a using declaration to select a subset of the
declarations of an overloaded function.  If it was forbidden to have
using declarations just because there is potential for conflict,
introducing one more declaration of an overloaded function could
gratuitously break source code that used that name, but not that
particular declaration.  So the committee decided it was ok to have
conflicting using declarations for the same function, as long as you
don't use the conflicting overloads.

> Do you think that the following is well-formed?

> namespace X{ void foo(); }
> namespace Y{ using X::foo; class Bar{ friend void foo(){} }; }

> Following your line of reasoning, this should define X::foo. I hope
> this is not the case, though.

According to my line of reasoning, this would be invalid because
X::foo can only be defined in namespace X or in some enclosing
namespace.  However, I can't seem to find the restriction that a
non-member function can only be defined in enclosing namepaces in the
Standard at this very moment; am I mistaken?

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
{oliva,Alexandre.Oliva}@dcc.unicamp.br  aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
*** E-mail about software projects will be forwarded to mailing lists

Re: what is wrong here?

[Alexandre Oliva]

On Jul 11, 1999, "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de> wrote:

> You seem to assume that a using-declaration makes the functions
> denoted members of the namespace.

Nope, I assume that, after a using-declaration, name lookup finds the
``used'' name in the namespace in which the using-declaration
appeared, and thus doesn't consider it `undeclared' in the friend
declaration.  Same for:

namespace A {
  class B {};
}
namespace C {
  using A::B; // arranges that C::B -> A::B
  class D {
    friend class B; // doesn't this find C::B, i.e., A::B ?
  };
}

> If that was the case, then you would get violations of the odr.

Nope, I'm not talking about definitions, only declarations.  WRT
definitions, see below.

> Otherwise, is the following text well-formed?

> namespace A{void foo(){}}
> namespace B{void foo(){}}
> namespace C{using A::foo;using B::foo;class Bar{friend void foo();};}

> My interpretation is: Yes, it is, but C::foo is not defined, yet.

IMHO, no, because of ambiguity.

>> I can't seem to find the restriction that a non-member function can
>> only be defined in enclosing namepaces in the Standard at this very
>> moment; am I mistaken?

> It is in 7.3.1.2, [namespace.memdef]/2. However, this rule does not
> strictly apply: the member is not defined by explicit qualification.

Yup, I had found that one, but indeed it didn't apply.  Now the issue
is which restriction is missing in the Standard.  If your
interpretation is right, it should be made clear that friend
declarations in class bodies do not accept names introduced with using
declarations when checking whether a function had already been
declared in the namespace or not.  If mine is, the Standard should be
ammended to make it clear that friend declarations may match previous
using-declarations in the enclosing namespace.

In any case, it should be made clear that a definition cannot be
provided for an unqualified name declared by a using declaration.

Could you and/or some Cygnus employee take this issue to the C++
committee?


Cheers,

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

Re: what is wrong here?

[Martin v. Loewis]

> Could you and/or some Cygnus employee take this issue to the C++
> committee?

Ok, I'll try.

Regards,
Martin
>From martin@mira.isdn.cs.tu-berlin.de Tue Jul 13 01:14:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: bauhaus@uni-duisburg.de
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: internal compiler error 109
Date: Tue, 13 Jul 1999 01:14:00 -0000
Message-id: <199907130810.KAA00681@mira.isdn.cs.tu-berlin.de>
References: <199907122308.BAA18729@sonnenregen.uni-duisburg.de>
X-SW-Source: 1999-07/msg00477.html
Content-length: 522

> 
> //  #include <string> "results" in an internal compiler error 109
> //  (only saying that this doesn't happen if #include <string> is
> //  omitted; this is funny somehow; i filed a report having the opposite
> //  premis resulting in the same error only few days ago. the code *is*
> //  erroneous, i think. :)

Thanks for your bug report. gcc-2.95 19990701 says

a.cc:13: in-class initialization of static data member of non-integral type `const string'

so it appears that the bug has been fixed.

Regards,
Martin
>From martin@mira.isdn.cs.tu-berlin.de Tue Jul 13 01:14:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: calkinsc@www.protospace.com
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: EGCS 1.1.2 compiler error
Date: Tue, 13 Jul 1999 01:14:00 -0000
Message-id: <199907130812.KAA00689@mira.isdn.cs.tu-berlin.de>
References: <Pine.SGI.3.93.990712193539.11A-101000@www.protospace.com>
X-SW-Source: 1999-07/msg00478.html
Content-length: 865

> 	I have checked the list of known bugs and it does not appear to fit
> any of the cases, so attached is a gzip-compressed, tar archive of the
> original source (timer.cc), the .ii file as per requested on that web page,
> and the screen output of g++ -v --save-temps (info.txt).

Thanks for your bug report. gcc-2.95 19990701 says

timer.cc: In method `void TimerTest::Run()':
timer.cc:57: taking the address of a non-static member function
timer.cc:57:   to form a pointer to member function, say `&TimerTest::OnTimer'
timer.cc: In method `char Timer<TimerTest>::Start(int, void (TimerTest::*)())':
timer.cc:57:   instantiated from here
timer.cc:41: no matches converting function `thread_start' to type `void * (*)(void *)'
timer.cc:24: candidates are: template <class T> void * thread_start(void *)

so it appears that the bug has been fixed.

Regards,
Martin
>From martin@mira.isdn.cs.tu-berlin.de Tue Jul 13 01:24:00 1999
From: "Martin v. Loewis" <martin@mira.isdn.cs.tu-berlin.de>
To: kunert@physik.tu-dresden.de
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: -pendantic & overload resolution
Date: Tue, 13 Jul 1999 01:24:00 -0000
Message-id: <199907130821.KAA00731@mira.isdn.cs.tu-berlin.de>
References: <378A0C8D.A843CEA3@physik.tu-dresden.de>
X-SW-Source: 1999-07/msg00479.html
Content-length: 388

> In the following exampl, `-pedantic' changes the overload resolution
> rules badly. 

Yes. There is an extension in egcs, which is documented (in the
source) as

/* Extension: If the worst conversion for one candidate is worse than
   the worst conversion for the other, take the first.  */

With -pedantic, this extension is disabled, and the code becomes
ill-formed.

Regards,
Martin
>From oliva@dcc.unicamp.br Tue Jul 13 02:44:00 1999
From: Alexandre Oliva <oliva@dcc.unicamp.br>
To: Tudor Hulubei <tudor.hulubei@ecora.com>
Cc: egcs-bugs@egcs.cygnus.com
Subject: Re: Internal compiler error 754867
Date: Tue, 13 Jul 1999 02:44:00 -0000
Message-id: <org12sg9zf.fsf@cupuacu.lsd.dcc.unicamp.br>
References: <14210.21023.579148.885787@data.ecora.com>
X-SW-Source: 1999-07/msg00480.html
Content-length: 702

On Jul  6, 1999, Tudor Hulubei <tudor.hulubei@ecora.com> wrote:

> The following C++ code triggers an internal compiler error under
> RedHat 6.0 with the stock egcs (1.1.2):

>     (((void) (cout)) ? 1 : 0);

> t.cc:7: Internal compiler error 754867.

Thanks for your bug report.  The ICE is fixed in the upcoming gcc
2.95, but it still produces a weird error message.  I'm installing a
new testcase in the testsuite.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them

Re: what is wrong here?

[Martin v. Loewis]

> > namespace N {
> > using ::f;
> > class C {
> >         friend void f ();
> 
> > bug1.cc:8: `void N::f()' conflicts with previous using declaration `void f()'
> 
> Yup.  In fact, I had met this bug while trying to find a work-around
> for you, but I had forgotten to add it to the testsuite too.  Thanks
> for reminding me of that.

Why is this a bug? I believe the error message is correct. The friend
declaration introduces a new function in the enclosing namespace,
which is hidden except for Koenig lookup. This function conflicts with
the using-declaration.

Am I missing something?

Regards,
Martin

P.S. Unfortunately, there is no work-around for making globally-scoped
functions friends, except for making the fields access in the function
public.

Re: what is wrong here?

[Martin v. Loewis]

> IMHO, the using declaration causes the name `f' to be found in N, so
> the friend declaration shouldn't introduce a new declaration, just
> bind to the one it finds.

This should be one of these comp.std.c++ things, which I continue to
discuss on egcs-bugs, violating the netiquette :-)

According to 7.3.1.2, [namespace.memdef]/3, the friend declaration
introduces a new declaration if that is the 'first declaration'. Now,
does the using-declaration introduce f(void) as a member of N? 7.3.3,
[namespace.udecl]/2 would make us think so.

However, if that was the case: Why is it allowed that two using
declarations introduce two functions with identical parameter lists?
(see Note in [namespace.udecl]/11)? Clearly, if the functions *where*
declared in the namespace that contains the using declaration, it
would violate the odr: a function would have two definitions.

Also, according to 11.4, [class.friend]/5, a friend can be defined in
the class. Do you think that the following is well-formed?

namespace X{
  void foo();
}

namespace Y{
  using X::foo;
  class Bar{
    friend void foo(){}
  };
}

Following your line of reasoning, this should define X::foo. I hope
this is not the case, though.

Regards,
Martin

Re: what is wrong here?

[Martin v. Loewis]

> > However, if that was the case: Why is it allowed that two using
> > declarations introduce two functions with identical parameter lists?
> 
> This is just a guess: Maybe because functions can be overloaded, and
> there's no way fro a using declaration to select a subset of the
> declarations of an overloaded function.

That was a rhetorical question, sorry. A declaration of a friend
function is only a re-declaration if there was a prior declaration of
that function as a member of the enclosing namespace.

You seem to assume that a using-declaration makes the functions
denoted members of the namespace. If that was the case, then you would
get violations of the odr. So the logical consequence is that
using-declarations do not declare the functions as namespace members.

Otherwise, is the following text well-formed?

namespace A{void foo(){}}
namespace B{void foo(){}}
namespace C{using A::foo;using B::foo;class Bar{friend void foo();};}

My interpretation is: Yes, it is, but C::foo is not defined, yet.

> > namespace X{ void foo(); }
> > namespace Y{ using X::foo; class Bar{ friend void foo(){} }; }
> 
> > Following your line of reasoning, this should define X::foo. I hope
> > this is not the case, though.
> 
> According to my line of reasoning, this would be invalid because
> X::foo can only be defined in namespace X or in some enclosing
> namespace.  However, I can't seem to find the restriction that a
> non-member function can only be defined in enclosing namepaces in the
> Standard at this very moment; am I mistaken?


It is in 7.3.1.2, [namespace.memdef]/2. However, this rule does not
strictly apply: the member is not defined by explicit qualification.

I still think that the original example

void foo();

namespace B{
  using ::foo;
  class X{
    friend void foo();
    int x;
  };
}

void foo(){
  X x;x.x=3;
}

is ill-formed in standard C++.

Regards,
Martin

what is wrong here?

[Dima Volodin]

267_dv@lazybones: cat bug.cc
namespace N {

class C {
        friend void ::f ();
        int  m;
} c;

}       // namespace N

void
f () {
        N::c.m = 0;
}
268_dv@lazybones: g++ -S bug.cc
bug.cc:4: parse error before `('
bug.cc: In function `void f()':
bug.cc:5: `int N::C::m' is private
bug.cc:12: within this context
269_dv@lazybones: g++ -v
Reading specs from
/usr/local/lib/gcc-lib/sparc-sun-solaris2.6/gcc-2.95/specs
gcc version gcc-2.95 19990629 (prerelease)

Re: what is wrong here?

[Martin v. Loewis]

> > namespace N {
> > class C {
> >         friend void ::f ();
> 
> > bug.cc:4: parse error before `('
> 
> Thanks for your bug report.  I'm installing a simplified version of
> your testcase in the testsuite.

This is a know bug (at least to me). g++ does not support
globally-scoped friends. I tried changing that, but that broke another
test case where globally-scoping is used to disambiguate declarations
and expressions.

Anyway, I believe this can't be fixed with the current parser; the
rewrite is urgently needed... If anybody can come up with the
appropriate bison magic to fix this, please let me know.

Regards,
Martin