This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: C++ nested classes, namespaces, structs, and compound statements
- From: Jim Blandy <jimb at redhat dot com>
- To: Gianni Mariani <gianni at mariani dot ws>
- Cc: Daniel Berlin <dan at dberlin dot org>,Daniel Jacobowitz <drow at mvista dot com>, gdb at sources dot redhat dot com,Benjamin Kosnik <bkoz at redhat dot com>
- Date: 08 Apr 2002 19:24:12 -0500
- Subject: Re: C++ nested classes, namespaces, structs, and compound statements
- References: <Pine.LNX.4.44.0204060236110.25262-100000@dberlin.org><3CAF2FBA.5040000@mariani.ws>
Gianni Mariani <gianni@mariani.ws> writes:
> Much of what is discussed here is language and compiler specific. My
> generic approach to solving this kind of problem is to provide an
> abstraction layer where all the facilities are provided for in a API
> (abstract base interface class); the mapping is then language and
> compiler specific. The burden is then on the compiler writer to
> provide the symbol binding mechanism/implementation which is where it
> belongs.
Well, the rules for identifier lookup are part of the language.
They're not compiler-specific, or else the meaning of your programs
would be, too. (That does happen, but it's not generally regarded as
desireable.)
The rules for the correspondence between machine-level objects (bits,
bytes, registers) and source-level objects (variables, functions)
aren't really compiler-specific either: they're given by the ABI.
Many different compilers can (try to) share the same ABI.