Re: Symbol tables and scopes

"David R Tribble" <david@tribble.com>
24 Feb 2006 09:43:02 -0500

          From comp.compilers

Related articles
[15 earlier articles]
Re: Symbol tables and scopes alexc@TheWorld.com (Alex Colvin) (2006-02-14)
Re: Symbol tables and scopes nathan.moore@cox.net (Nathan Moore) (2006-02-17)
Re: Symbol tables and scopes alexc@TheWorld.com (Alex Colvin) (2006-02-17)
Re: Symbol tables and scopes david@tribble.com (David R Tribble) (2006-02-24)
Re: Symbol tables and scopes david@tribble.com (David R Tribble) (2006-02-24)
Re: Symbol tables and scopes david@tribble.com (David R Tribble) (2006-02-24)
Re: Symbol tables and scopes david@tribble.com (David R Tribble) (2006-02-24)
Re: Symbol tables and scopes DrDiettrich@compuserve.de (Hans-Peter Diettrich) (2006-03-05)
Re: Symbol tables and scopes henry@spsystems.net (2006-03-05)
| List of all articles for this month |

From: "David R Tribble" <david@tribble.com>
Newsgroups: comp.compilers
Date: 24 Feb 2006 09:43:02 -0500
Organization: http://groups.google.com
References: 06-01-10106-02-027 06-02-045 06-02-056 06-02-063 06-02-086 06-02-100
Keywords: design, symbols
Posted-Date: 24 Feb 2006 09:43:02 EST

>> Depends on the language and programming style. It may be true for
>> C, Pascal and similiar languages, but i question the validity on a
>> typical C++ program for example. Definitely a reasonably well designed
>> program will attempt to minimize the # of global variables, if the
>> language allows it.
>


Alex Colvin wrote:
> My experience is that a typical C++ program consists almost entirely
> of names with global scope. Note that this includes types, constants,
> members, etc. Pretty much everything in a header file.
>
> I almost never see #include... anywhere but a top-level scope. And my
> experience with C++ is that most of the program moves into the header
> file.


True, but it doesn't have to be that way. Outlawing inline member
functions and using public base classes with only public members
and functions, and hiding the actual implementation within hidden
derived classes, works pretty well for isolating the implementation
details from the client. But it takes a lot of work to do it right,
which is the reason why most C++ programmers don't do it.


-drt


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.