This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
[RFC] exports and linkage for TR1
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: libstdc++ at gcc dot gnu dot org
- Date: Wed, 11 Oct 2006 22:36:31 +0200
- Subject: [RFC] exports and linkage for TR1
Hi! Jason has pointed out that some of the anonymous namespace usage in
include files in libstdc++ is sub-optimal. This relates to my patch of
2006-07-27 Benjamin Kosnik <bkoz@wells.artheist.org>
PR libstdc++/19664 round 3
[...]
In looking at this, I tend to agree. A lot of this usage is a linkage
hack: in order to avoid the issue of what to do about linkage for TR1
entities, we're forcing a lot of things into headers that should really
be in source files. To avoid duplicate symbols, these entities are
declared internal, either by static or (now) anonymous namespace
enclosures. All this is legal, but not best practice.
I'm intending to correct this, and am hoping to move parts of random,
hashtable, etc. into source files. Thoughts? Part of my reluctance to
do this in the past was because TR1 was still in flux, and the libstdc+
+ implementations are even more so in flux.
I feel like TR1 is less in flux now. What do others think? Should we
start exporting bits, and thus having to deal with compatibility?
Thoughts about particular bits that should be avoided?
As a separate part of this, I intend to kill cpp_type_traits in the
very near term and start use of TR1's type_traits in libstdc++ include
files. As of Berlin, TR1 is in the WP. People should start getting used
to this.
-benjamin