Subject: Re: [sv-ec] Protection of class types
From: Arturo Salz (Arturo.Salz@synopsys.com)
Date: Mon Mar 24 2003 - 10:21:20 PST
Neil,
I had tried it with the Solaris compiler version 4.2 and got this:
"priv.cpp", line 10: Warning (Anachronism): Goo::Nested is not accessible from file level.
But, it does compile correctly with versions 6.1 and 6.2.
Evidently the Forte team has dealt with this issue. However, I don't know if this is
compliant with the C++ standard or its a relaxation plus heuristics that allows this
to work.
Given the timeline, I believe that Michael suggestion is the best approach. I haven't
heard that type protection is a must-have feature for this release.
Arturo
- Original Message -----
From: "Neil Korpusik" <Neil.Korpusik@eng.sun.com>
To: <sv-ec@eda.org>; <Arturo.Salz@synopsys.COM>
Sent: Saturday, March 22, 2003 7:15 PM
Subject: Re: [sv-ec] Protection of class types
Hi Arturo,
The following code compiles using the Solaris forte compiler version 6.2
This is one of the examples that you mentioned wouldn't compile.
class Goo {
private:
class Nested {
int data1;
};
Nested *foo();
public:
int rc;
};
Goo::Nested *Goo::foo() {
return new Nested;
}
Neil
> X-Unix-From: Arturo.Salz@synopsys.com Thu Mar 20 17:30:03 2003
> From: "Arturo Salz" <Arturo.Salz@synopsys.com>
> To: <sv-ec@eda.org>
> Subject: [sv-ec] Protection of class types
> Date: Thu, 20 Mar 2003 17:32:51 -0800
> MIME-Version: 1.0
> X-Priority: 3
> X-MSMail-Priority: Normal
> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
>
> Hi All,
>
> I looked at the issue of protecting types (or nested classes) in C++ and
> whether we should enable that feature in SystemVerilog-3.1.
>
> The first question is straightforward. C++ does allow nested classes and
> other type declarations to be declared private/protected/public. Unlike
> data members, which are private by default, types are public by default.
>
> After examining the issue closer, the ability to protect nested classes does
> create some undesirable complexity. Consider the following C++ class:
>
>
>
--------------------------------------------------------------------------------
>
> class Goo
> {
> private:
> class Nested { ... };
> Nested *foo();
> };
>
> If you don't include the implementation of foo in the declaration, and try to
> define it out-of-body, like this:
>
> Nested *foo() { .... }
>
> Generates a compiler error since Nested is not visible at the top level.
> If we write:
>
> Goo::Nested *foo() { .... }
>
> That doesn't work either since foo is private to Goo.
> If we write:
>
> Goo::Nested *Goo::foo() { ... }
>
> That doesn't work!
> The problem is that class Nested is now private to Goo, thus, only members
> of Goo can access the type! Thus, this function can only be defined inside
> the declaration of Goo, but not anywhere else outside.
>
> In C++, the only way one can get around these restrictions is by changing foo
> from a function to a task that takes a reference to a Nested pointer as a
parameter:
>
> class Goo
> {
> private:
> class Nested { ... };
> void *foo(Nested *&);
> };
>
> Now, foo can be declared out-of-body, thus:
>
> void Goo::foo(Nested *& p) { p = new Nested; }
>
> which, is roughly equivalent to:
> Goo::Nested* Goo::foo() { return new Nested; }
>
> The difference is that Goo::Nested is no longer at file scope, but inside the
> scope of a member of class Goo .
>
>
--------------------------------------------------------------------------------
>
>
> It is this kind of complexity that caused the gnu folks to relax the type
checking
> in gcc and break with the standard by simply making all class-nested types
public.
>
> Therefore, I recommend that class-nested types in SystemVerilog-3.1 remain
> public. No decision that we make today will limit in any way our ability to
add this
> feature in a future release. Right now we can choose to make it an error to
prefix a
> type declaration with the protected or local keywords (the current proposal),
or we
> can allow these keywords and ignore them (as gcc has been doing).
>
> Arturo
>
>
This archive was generated by hypermail 2b28 : Mon Mar 24 2003 - 10:19:17 PST