This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: std random
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: Ed Smith-Rowland <3dw4rd at verizon dot net>
- Cc: libstdc++ <libstdc++ at gcc dot gnu dot org>
- Date: Tue, 9 Dec 2008 11:43:07 -0800
- Subject: Re: std random
- References: <493D1B51.1030409@verizon.net>
> This patch is a tad more aggressive than one would want at this stage
> ;-). This would only go in for 4.5 I think. That leaves the
> question of what we should do for 4.4. I think it may be misleading
> to keep random in std. I think it may be best to simply delete or
> disable include/std/random for now. What do all of you you think?
This keeps coming up. Let's try to figure this out.
I believe that 4.4 includes a lot of C++0x functionality. Some of this
functionality has been included in earlier
gcc/libstdc++ releases via TR1 or extension code: additions and
corrections to these bits I don't consider new features.
Specific areas: traits, atomics, threads, random, move semantics, time,
error.
My preferred goal WRT 4.4 C++0x support in the library should be to
target these areas with interfaces from a specific document, suggested:
n2798. As in, if we are providing experimental support for one of these
new interfaces, the experimental support should be in the form of n2798.
Consistently.
How external linkage is provided for this C++0x support remains an
open-ended question. I am not comfortable exporting C++0x std:: types
at this point as part of a stable interface, as I believe non-trivial
changes are still likely.
One thought is to have -std=gnu++0x/c++0x link in a separate c++0x lib,
with versioned symbols. (Or to version the C++0x symbols as part of
libstdc++.so.)
-benjamin