Re: [sv-bc] Query related with the visibility of enum member.

From: David Jones <djones@xtreme-eda.com>
Date: Fri May 14 2010 - 16:19:24 PDT

On Fri, May 14, 2010 at 2:57 PM, Steven Sharp <sharp@cadence.com> wrote:

> Since the feature and most of its syntax and semantics came from C, we
> can also compare this aspect to C. I did some testing with gcc to check
> that my understanding of this was correct. In C, different structs can have
> members with the same name. However, a struct is not a scope. If this
> same kind of anonymous enum declaration is done in C, the enum constants
> are visible outside the struct.

Oh, what fun we have with languages.

The very first C compilers indeed put all struct members in a global
namespace. Such compilers predated even "K&R" C, not to mention ANSI
C. However, if you look at old C sources, and in particular, the Unix
sources (look at some FreeBSD kernel source for example) you can see a
style where each struct member was prefixed to make its name globally
unique. A good example is the "struct stat" found in any POSIX system,
whose members are prefixed with "st_".

Moving on to ANSI C, each struct declaration had its own member
namespace, so you can indeed use the same names in different structs
without collision. However, as far as I can tell from the grammar in
my second edition K&R book, the only thing you can put in a struct is
a member declaration.

C++ is a different beast. Structs and classes in C++ are equivalent,
the only difference being the initial member access (public for
structs, private for classes). Both can contain pretty much any kind
of declaration, and therefore indeed are scopes in their own right.

Section 2.3 of K&R 2nd ed. states that "names in different
enumerations must be distinct". Section A8.4 further clarifies that
this applies within a scope. Scopes are created inside functions.

And the entire C language grammar takes up only five pages. Those were
the days...

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Fri May 14 16:19:40 2010

This archive was generated by hypermail 2.1.8 : Fri May 14 2010 - 16:22:25 PDT