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

From: John Michael Williams <jwill@BasicISP.net>
Date: Sat May 15 2010 - 09:27:16 PDT

Hi David.

Yes, those WERE the days.

Now, in SV, we have everyone and his or her brother PERL'ing
around, making life impossible for EDA vendors, when what
they should be doing is being Tcl'ed to life!

On 05/14/2010 04:19 PM, David Jones wrote:
> On Fri, May 14, 2010 at 2:57 PM, Steven Sharp<sharp@cadence.com> wrote:
>
>>...
> 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...
>

-- 
         John Michael Williams
         jwill@BasicISP.net
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Sat May 15 09:17:01 2010

This archive was generated by hypermail 2.1.8 : Sat May 15 2010 - 09:20:01 PDT