Subject: Re: [sv-ec] Protection of class types
From: Michael Burns (Michael.Burns@motorola.com)
Date: Fri Mar 21 2003 - 08:07:10 PST
Hi All,
Well, that is rather a mess, isn't it! It looks like there are three
options:
1 leave private nested classes private and report unexpected errors
when users try to do what Arturo demonstrates below
2 make all nested types public (by either disallowing or ignoring
"local" keywords) (Arturo's suggestion)
3 add a weird scoping rule that says the return type of a function
is in the same scope as the function
I think Arturo's suggestion will have the least user impact. I've
been using nested classes in C++ with gcc for two years and never
noticed the bug!
I also recommend disalloowing the local keyword rather than ignoring
it - that way, it's clear to the user what's happening, and we have
the freedom to define whatever semantics we want for local nested
classes at a later time while still preserving backward compatability
to SV3.1.
Mike
>From: "Arturo Salz"<Arturo.Salz@synopsys.com>
>Date: Thu, 20 Mar 2003 17:32:51 -0800
>
>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 =3D 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 : Fri Mar 21 2003 - 08:11:45 PST