stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Teleman <>
Subject Re: [disscuss] Retirement of stdcxx to the 'Attic'?
Date Thu, 02 Feb 2012 23:52:02 GMT
On Thu, Feb 2, 2012 at 17:57, William A. Rowe Jr. <> wrote:

> The much larger issue is that the ASF is designed as a collaboration
> hub where multiple consumers can be represented.  It is designed to
> avoid the need for forks except in radical divisions within communities
> where two or more groups want the code to proceed in different directions.
> In order to remain a project, the ASF requires a PMC composed of the
> contributors to the project (committers) which represent active user -
> developers of the project's code, and are willing to both incorporate
> all reasonable changes and draw in new individuals who are frequently
> offering those changes.
> As a standards body implementation, we would /hope/ there aren't huge
> fractures in the direction of the code :)
> If there are multiple forks at this point, the questions are why, and
> what can be done to bring it all back together into a single community
> where no one company or individual is shouldering the burden of
> entirely maintaining the code on their own.
> Feel free to chime in here on these questions.

Speaking for the Solaris/Sun Studio C++ "fork":

To begin with, it's not a fork. Or at least it was never intended to
be a fork (and still isn't). It's simply a very large collection of
patches, based on stdcxx 4.2.1. This was the last "official" stdcxx
release published at the ASF, and that's the release we used as a
starting point in Solaris.

There are three categories of patches:

1. Patches specific to Solaris and Sun Studio. These affect stdcxx's
GNUmakefiles*, sunpro.config and gcc.config. The GNUmakefile* patches
can probably be ignored for a general-purpose relase. The
sunpro.config and gcc.confnig patches are useful for building on

2. Patches pertaining to a specific set of Solaris SPARC
idiosyncracies. You can find more details about these patches here:

3. Patches for stdcxx issues which were discovered while running the
stdcxx test harness, and for which there was no canonical resolution.
For example:

Turns out that std::numpunct<> and std::moneypunct<> are thread-unsafe
(because of the std::basic_string's copy constructor and shared buffer

3. Patches for issues discovered during C++2003 validation testing:

I wrote the patches based on failures or violations discovered while
running the Perennial CPPVS 8.1 (which is what we use internally) and
some other simple, trivial tests on stdcxx with Sun Studio C++.

These are "general-purpose" patches, they address problems independent
of platform or architecture. This is the largest set of patches.
Caveat: some (a few) of these patches break BC with the existing
stdcxx 4.2.1 implementation. This may be a problem at ASF; for Solaris
we had the advantage that stdcxx was new, and we could afford to break
BC (because there was nothing to maintain BC with in the first place).

Why did these patches never make it into stdcxx: because by the time I
started submitting them here, stdcxx was already on its way to
becoming dormant. Or at least very sleepy. A small set of very simple
patches made it into the yet-unreleased 4.2.2, but the big set of
complex patches never made it.

At any rate, you can find the complete set of Studio C++ patches here:

The README.Solaris file is out-of-date and very obsolete. Please ignore it.

This set of patches generates a stdcxx identical to that available
with Solaris 10 and 11, with two exceptions:

ios_base.failure.90.diff and

aren't part of the Solaris canonical stdcxx release. Strictly
technically speaking, std::ios_base::failure should be a class, and
not a typedef (and making it a typedef, as it is in the stdcxx
implementation causes a failure on a very specific and otherwise
obscure CPPVS test case). However, making it a proper class (as it is
declared in has a noticeable performance impact) so we
decited to leave it as is.

svn co should work anonymously. If it doesn't please let me know.

"what can be done to bring it all back together into a single community":

1. Don't retire it to the Attic. :-) The Attic pretty much guarantees
that it will never be brought back all together.

2. Someone with stdcxx commit privileges should be part of this
reunification (for obvious reasons). It is very discouraging to submit
patches knowing full well and ahead of time that they will never make
it anywhere. Perhaps the process of submitting patches could be
somewhat less of a "process".

Just my 0.02.


Stefan Teleman
KDE e.V.

View raw message