Re: use-package & name conflict: why they are not deferred?

On Thu, 30 Oct 2008 17:20:23 +0000 (UTC), Kaz Kylheku
<kkylheku@xxxxxxxxx> wrote:

On 2008-10-28, John Thingstad <jpthing@xxxxxxxxx> wrote:
På Mon, 27 Oct 2008 22:36:31 +0100, skrev Kaz Kylheku <kkylheku@xxxxxxxxx>:


All symbols in C++ are in fact in one global namespace.


Nop. All names are strings in the BSS segment. But each file can have it's
own. If you define a function to be static it is local to that file. Also
C++ offers a namespace construct which allows you to explicitly create
namespaces. (whic allows multiple files to share a namespace)

That is not the view from which I'm looking at this. In the actual C++ language
itself, foo::x and bar::x are not different symbols. They are scope resolution
syntax in which the same name x refers to different entities that are defined
in different named scopes.

Consider:

foo f; // class foo has a member x
bar b; // so does class bar

// look, foo::x and bar::x used in the same expression:
f.x(b.x);

Here, x is resolved not with scope resolution, but with member selection.
This resembles:

(funcall (slot-value f 'x) (slot-value b 'x))

All that stuff about BSS segments has nothing to do with C++. The ISO C++
standard doesn't discuss linkers and BSS. It's merely an implementation
strategy which C++ uses over that kind of linker model.

When C++ compilers generate code for this kind of linkage, they combine
multiple names (and other information such as function argument type
signatures) into a character string, which becomes a symbol at that level.

Partly. Only the base of a data structure is referenced externally
and the string version of the name is used only for linking. Debug
information in an executable is separate and duplicates the link
information where necessary.

Remember that C++ can statically resolve the structural offset of
object members. If there is an external object "foo" which has a
member "x", only "foo" may be referenced in the link segment -
references to "foo.x" in the code will become a static offset to be
added to the resolved base address. I say "may" be referenced because
the compiler might in fact translate an external object reference
directly into an offset from the base of a specific DATA segment - so
there may be no individual entry for the object in the link segment.
I've not seen a C++ compiler that do this, but I have seen compilers
for other languages do it and there's no technical reason a C++
compiler couldn't - it simply requires uniquely identifying data
segments.

With static linking, external names may not even be referenced by the
compiled code. Although it is typical to place an identifiable marker
in the code that refers to the link segment entry for the external
name, the marker is usually just a redundant check - the link entry
normally contains a patch list of code locations to update once the
object's base address is resolved. There are C/C++ compilers that
mark external references with a null or illegal address.

When dynamic linking with dlopen or GetLibrary, etc., the object's
name is needed at runtime and so it does become a DATA segment string.
However, the program's internal name for the pointer to which the
external object's address is assigned is again a statically
linked/resolved object.


In other words, C++ does not have symbol namespaces like Lisp (namespace for
resolving a reference of an identifier to a symbol). C++ has symbol reference
namespaces: spaces for resolving a symbol to an entity such as a type,
variable, class, namespace, aggregate member, goto label, etc.

Probably the most concise, correct explanation I've seen.

George
.

Relevant Pages

  • Re: VS2005 C#: User Testing
    ... The type or namespace name 'Drawing' does not exist in the namespace ... 'System' (are you missing an assembly reference?) ... Run it again, as now it should find it as a resource, and not be trying ... Studio altogether, not knew to programming. ...
    (microsoft.public.vstudio.general)
  • VS2005 C#: User Testing
    ... The type or namespace name 'Drawing' does not exist in the namespace ... 'System' (are you missing an assembly reference?) ... essentially a sizable hint window. ... Run it again, as now it should find it as a resource, and not be trying ...
    (microsoft.public.vstudio.general)
  • Re: use-package & name conflict: why they are not deferred?
    ... All symbols in C++ are in fact in one global namespace. ... There are more quirks in the design. ... If a D object is accessed through a reference R to B, ... Ada doesn't inherit Pascal's WITH statement either. ...
    (comp.lang.lisp)
  • Re: Server Printing using Print Dialog
    ... that is because the namespace is defined within an assembly your ... You can send feedback directly to my manager at: ... normally I do not have to add a reference when using any of the ... Calling a dialog box on the server would pop a dialog box on ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Dot Net team why isnt there a System.Financial?
    ... > in the legacy Microsoft.VisualBasic namespace except upgraded to use ... > - you can do this by referencing the legacy Microsoft.VisualBasic ... > - why rewrite what has already been written you can easily reference ... > only for financial calculations that could be accessed just like the ...
    (microsoft.public.dotnet.languages.csharp)