From owner-freebsd-hackers  Fri Oct 18 18:21:31 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.5/8.7.3) id SAA08047
          for hackers-outgoing; Fri, 18 Oct 1996 18:21:31 -0700 (PDT)
Received: from ocean.campus.luth.se (ocean.campus.luth.se [130.240.194.116])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id SAA08042
          for <hackers@freebsd.org>; Fri, 18 Oct 1996 18:21:28 -0700 (PDT)
Received: (from karpen@localhost) by ocean.campus.luth.se (8.7.5/8.7.3) id DAA05422 for hackers@freebsd.org; Sat, 19 Oct 1996 03:25:14 +0200 (MET DST)
From: Mikael Karpberg <karpen@ocean.campus.luth.se>
Message-Id: <199610190125.DAA05422@ocean.campus.luth.se>
Subject: Re: C++ question
To: hackers@freebsd.org
Date: Sat, 19 Oct 1996 03:25:13 +0200 (MET DST)
In-Reply-To: <199610180454.WAA22620@rocky.mt.sri.com> from Nate Williams at "Oct 17, 96 10:54:07 pm"
X-Mailer: ELM [version 2.4ME+ PL22 (25)]
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
X-Loop: FreeBSD.org
Precedence: bulk


[stuff deleted]
> So, in order to be fully conforming the code could be written as follows:
> class foo {
>   private:
>     struct A {
>       int myint;
>     }
> 
>     // The C++ standard requires the friend stuff
>     struct B;
>     friend struct B;
> 
>     struct B {
>       A *ptr;      // Disallowed in the C++ standard
>     }
> };
> 
> Thanks to all, especially Mike who provided both the validation of the
> Sun compiler and the solution.

I seem to remember having a rather... umm... interesting experience with
Sun CC at work.
---
class A {
  class X {};
};

main() {
  X tmp;
}
---
Yupp... just tested this above code. Goes right through CC, but g++ chokes
on it, (correctly) saying "`X' undeclared". If you put a // before the
definition of class X, you get the correct message from CC too. ;)

Ok, next test:  Change "X tmp;" to "A::X tmp;". Hmm...
Now CC says "Warning (Anachronism): A::X is not accessible from main().",
and g++ happily compiles. So.. suddenly it's g++ (2.7.2) that is mistaken,
and CC that acts correctly. Hmm... More tests, then. Change our program to:
---
class A {
  class X {};
};

class B {
  class X {};
};

main() {
  X tmp;
}
---
Ah... now it works correctly in both compilers. Or rather, it doesn't work,
which is the expected result. Seem like the second class X in B "leaks out"
to global scope, is detected as duplicate and everything is fixed, so the
compiler is "unconfused" again. :-)

Hopefully we'll have the g++ bug fixed, if someone submit it (unless it's
fixed in newer versions?), but... since SUN doesn't WANT bug reports...
Cross our fingers for good luck? :)

However... Exceptions in g++ that WORK and work as they SHOULD, and that,
hopefully, can execute a fairly tricky throw within the timerange of 10
seconds... well... that seems to be somewhere on the other side of year
2000, at least... Very annoying. :(

Now we HAVE to use Sun CC at work, cuz g++ can't handle it. That sucks.
Give me "g++ -Wall" warnings any day instead of "CC +w2" or so...

   /Mikael - crossing his fingers for g++'s future success