Ron Natalie <ron@sensor.com> wrote in message news:<3B55E650.FD01AA5F@sensor.com>...
Ron, thank you for your reply!

> > Recently however, I had to dig into the internal workings of link-editors and found
> > out that when building a shared library (I speak about well-behaved platforms where
> > things like "__declspec(dllimport)" are not recognized as C++ keywords) they all take
> > advantage of the keyword static imposing internal linkage on the names of objects.
> > Meaning that such names will not make it into the Dynamic symbol table of the shared
> > library.
>
> [I'll try this again.  The moderators seem to have felt I gave too much
>  implementation specific information in my answer last time.]
I'd love to receive the more complete posting by way of private email
:)

> What you are describing is an implemenation issue now, and will be an implementation
> issue in the future.  However, there is no reason for their to be a distinction
> (I'll agree I did check the LINUX/G++ installation and you are right at least
> that implementation does make the distinction).
It's also the case for Solaris and the other platforms that are using
the GNU linker as their system linker such as FreeBSD, BSDI, OpenBSD,
NetBSD.

> There is no reason why the symbols in the unnamed namespace need be handled
> any different than those declared filescope/static.  The implmenentation is
> responsible now for making sure they don't collide with those in other
> translation units.  Whether it does this by omitting them from the symbol
> table, marking them as not external (as is done with statics in the observed
> implementation), or by decorating the name with some unique gook (as is done
> for the unnnamed namespace in the implemenation), is not mandated at all
> by the standard.

We all see the wide acceptance and the viability of the separate
compilation approach, when relocatable object files are merged and
symbolic references therein resolved not as the final phase of the
translation (as specified in 2.1 of the standard) but as a separate
process performed by a separate program -- the link-editor. And the
link-editor is not tied to a given C++ translator it gets its input in
the form of object files that could be created by C translator,
Assembler and the like. I've yet to see a C++ translator that could do
all the phases of C++ translation by itself, something that the
standard does not require though. Or a link-editor that were tailored
specifically for C++.

The standard requires of conforming implementations to give names that
are members of the unnamed namespace external linkage (unless they are
declared with the depricated keyword "static").

This results in it being impossible that the symbols in the unnamed
namespace are handled in the same way as those declared
filescope/static with today's C++ compilation technology. Because the
link-editor will not carry out any specific checks for synbols with
external names from the unnamed namespace (does C or assembler has
one?) to reduce their visibility from global to local.

I find the second approach you mention "decorating the name with some
unique gook (as is done for the unnnamed namespace" in use and working
today, but it results in bloated Dynamic symols tables ("export
tables" to put it more colloquially) and hence slows down dynamic
linking.

> > But if the keyword becomes forbidden on object declarations in namespace
> > scope, there'll be no portable way of achieving the result
>
> There is no gurantee that it is portable now.  I'm not sure what impact
> the prohibition would have.

I think it's portable, as declaring a name to have internal linkage in
one translation unit shall prohibit the same name in another
translation unit to refer to the same entity. In the case of shared
libraries, I find the approach of not including symbols with internal
linkage into the shared object's interface (its export table) to be
the only one that hews to the lines of the standard. Since otherwise
this fundamental rule is broken.

Kiril

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Kiril Avdeiv wrote:

> It's also the case for Solaris and the other platforms that are using
> the GNU linker as their system linker such as FreeBSD, BSDI, OpenBSD,
> NetBSD.

That's still only one implementation really.

> The standard requires of conforming implementations to give names that
> are members of the unnamed namespace external linkage (unless they are
> declared with the depricated keyword "static").

But there is no reason that it need carry around the relocation baggage
for these.  Despite the concept of external linkage.  Stuff in the unnamed
namespace is given a scope that is unreachable outside the translation unit.
There's no particular reason why the implementation is obliged to carry around
the symbol information for this.

The implementation could treat symbols in the unnamed namespace identically
as it does static filescope symbols with NO violation of the standard.  In
fact, the implemenation you are concerned with puts both in the symbol
table of the modules.  It's just that it marks the one with the EXT bit
that says consider it across modules.

There is even a footnote in the standard that expounds on this
paradigm:  "Although entities in an unnamed namespace might have
external linkage, they are effectively qualified by a name unique to their
translation unit and therefore can never be seen from any other translation unit."

>
> I find the second approach you mention "decorating the name with some
> unique gook (as is done for the unnnamed namespace" in use and working
> today, but it results in bloated Dynamic symols tables ("export
> tables" to put it more colloquially) and hence slows down dynamic
> linking.
>

So complain to the GCC people, or fix it yourself.  There's no reason
to set the EXT bit on these symbols.  They can't be used anyhow.

> > There is no gurantee that it is portable now.  I'm not sure what impact
> > the prohibition would have.
>
> I think it's portable, as declaring a name to have internal linkage in
> one translation unit shall prohibit the same name in another
> translation unit to refer to the same entity. In the case of shared
> libraries, I find the approach of not including symbols with internal
> linkage into the shared object's interface (its export table) to be
> the only one that hews to the lines of the standard. Since otherwise
> this fundamental rule is broken.

But it's not portable.  The concept of symbol tables on modules is not
defined by the standard.  G++ could have just as well implemented the
filescope statics the same way they did the unnamed namespace ones and
resulted in the same bloat.  They could omit the EXT bit and there would
be less bloat.

I still see this purely as an implementation.  Depite the declaration
in ths standard of what "external" versus "internal" linkdage means,
this doesn't constrain what an implementation does with it's symbol
tables.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

In article <3B570E81.FD3D6A33@sensor.com>, Ron Natalie <ron@sensor.com>
writes
>The implementation could treat symbols in the unnamed namespace identically
>as it does static filescope symbols with NO violation of the standard.  In
>fact, the implemenation you are concerned with puts both in the symbol
>table of the modules.  It's just that it marks the one with the EXT bit
>that says consider it across modules.
>
>There is even a footnote in the standard that expounds on this
>paradigm:  "Although entities in an unnamed namespace might have
>external linkage, they are effectively qualified by a name unique to their
>translation unit and therefore can never be seen from any other translation
>unit."


However:

file1.

namespace {
   class X {
// whatever
   };
   vector<X> vx;
}

file2.

namespace {
   class X {
// whatever
   };
   vector<X> vx;
}

Now in the context of export I am not so certain that the compiler can
get away with using unmangled names for X


Francis Glassborow      ACCU
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> Now in the context of export I am not so certain that the compiler can
> get away with using unmangled names for X
>
It may still have to mangle the names, but it doesn't have to mark
the symbols as EXTERNAL in the symbol table (or even put them in the
symbol table at all).

Of course, given the choice, I'd fix linkers to be more C++ savvy
and get rid of all this silly mangling.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

I know the reasons for deprecating the keyword static in object declarations appearing in namespace scope:
1. The keyword has a different meaning for class member declarations.
2. A similar result can be achieved with the use of the unnamed namespace.

Recently however, I had to dig into the internal workings of link-editors and found out that when building a shared library (I speak about well-behaved platforms where things like "__declspec(dllimport)" are not recognized as C++ keywords) they all take advantage of the keyword static imposing internal linkage on the names of objects. Meaning that such names will not make it into the Dynamic symbol table of the resulting shared object.

In fact on most Unix platforms that I'm aware of declaring a name to have internal linkage by means of the word 'static' (are there any other ways if the name does not denote a constant and is not a member of an anonymous union?) is the only way to prevent the name from being part of the shared object's interface.

Such use of the keyword is totally in line with the standard. But if the keyword becomes forbidden on object declarations in namespace scope, there'll be no portable way of achieving the result since the standard has no notion of shared libraries.

I'd love to hear from the implementors of portable C++ libraries (Dinkumware comes to mind) how they are dealing with this now and are going to in the future. That can make a good tip.

What I'm missing?

Kiril


--
Posted from 172.16.27.62, 172.16.17.153 via proxy [212.72.53.70] by way of mx5.port.ru [194.67.23.40]
via Mailgate.ORG Server - http://www.Mailgate.ORG

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

> Recently however, I had to dig into the internal workings of link-editors and found
> out that when building a shared library (I speak about well-behaved platforms where
> things like "__declspec(dllimport)" are not recognized as C++ keywords) they all take
> advantage of the keyword static imposing internal linkage on the names of objects.
> Meaning that such names will not make it into the Dynamic symbol table of the shared
> library.

[I'll try this again.  The moderators seem to have felt I gave too much
 implementation specific information in my answer last time.]

What you are describing is an implemenation issue now, and will be an implementation
issue in the future.  However, there is no reason for their to be a distinction
(I'll agree I did check the LINUX/G++ installation and you are right at least
that implementation does make the distinction).

There is no reason why the symbols in the unnamed namespace need be handled
any different than those declared filescope/static.  The implmenentation is
responsible now for making sure they don't collide with those in other
translation units.  Whether it does this by omitting them from the symbol
table, marking them as not external (as is done with statics in the observed
implementation), or by decorating the name with some unique gook (as is done
for the unnnamed namespace in the implemenation), is not mandated at all
by the standard.

> But if the keyword becomes forbidden on object declarations in namespace
> scope, there'll be no portable way of achieving the result

There is no gurantee that it is portable now.  I'm not sure what impact
the prohibition would have.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]

Wed, 18 Jul 2001 19:39:18 GMT, Ron Natalie <ron@sensor.com> pisze:

> There is no reason why the symbols in the unnamed namespace need
> be handled any different than those declared filescope/static.

What are visible differences between them, other than ability to
use the pointer to the object having external linkage as a template
parameter?

--=20
 __("<  Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZAST=CAPCZA
QRCZAK

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.research.att.com/~austern/csc/faq.html                ]