RFC: Deprecate libstdc++ Policy-Based Data Structures

Oleksandr Kulkov adamant.pwn@gmail.com
Tue May 20 11:45:43 GMT 2025


Hi Jonathan!

There was actually a patch by Xi Ruoyao posted in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81806 on 2020-01-08 that
should fix the issue with split function that I reported back in 2017.

Oleksandr

On Tue, May 20, 2025 at 1:37 PM Jonathan Wakely <jwakely@redhat.com> wrote:

> On Wed, 24 Jul 2019 at 12:40, Jonathan Wakely <jwakely.gcc@gmail.com>
> wrote:
> >
> > On Wed, 24 Jul 2019 at 12:36, Tadeus Prastowo <tadeus.prastowo@unitn.it>
> wrote:
> > >
> > > On Wed, Jul 24, 2019 at 1:01 PM Jonathan Wakely <jwakely.gcc@gmail.com>
> wrote:
> > > >
> > > > On Wed, 24 Jul 2019 at 11:52, Tadeus Prastowo <
> tadeus.prastowo@unitn.it> wrote:
> > > > >
> > > > > On Wed, Jul 24, 2019 at 12:40 PM Jonathan Wakely <
> jwakely.gcc@gmail.com> wrote:
> > > > > >
> > > > > > [Removing gcc@gcc.gnu.org from the CC list]
> > > > > >
> > > > > > On Wed, 24 Jul 2019 at 10:11, Tadeus Prastowo <
> tadeus.prastowo@unitn.it> wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > Knowing that Alex has stepped forward, I am interested in
> helping out
> > > > > > > in this matter as well if you think that will help.  My
> experience in
> > > > > > > maintaining a C++ library can be seen at
> > > > > > > https://savannah.nongnu.org/projects/tice
> > > > > >
> > > > > > Would you be any more or less willing to help if the code lived
> in a
> > > > > > separate repository, either on sourceware.org or
> savannah.gnu.org?
> > > > >
> > > > > I would be less interested because then the library is just another
> > > > > C++ library out there.  In particular, if the library is no longer
> > > > > part of libstdc++, maintenance and deployment would be harder
> because
> > > > > the library is no longer compiled, tested, and deployed as it is
> now;
> > > > > marketing would also suffer.  In other words, being part of
> libstdc++,
> > > > > the library receives additional contributions from GCC maintainers
> as
> > > > > well as marketing channels.
> > > >
> > > > But it doesn't.
> > >
> > > I think it does for marketing channels as the PBDS is available
> > > automatically whenever libstdc++ (that is, g++) is installed.
> > >
> > > The library also indirectly receives additional contributions from GCC
> > > maintainers through the compile-testing-deploy cycle of GCC.
> > >
> > > > It's bit-rotting and nobody knows about it.
> > >
> > > At least Alex and his community know it.  As for the bit-rotting, Alex
> > > has stepped forward as its user to maintain it.  I can help him with
> > > the technical stuff by proposing myself to be a co-maintainer.  Alex
> > > and his community then can provide the needed tests and criticisms
> > > (well, bug reports) from the user's point of view.  But, being part of
> > > the libstdc++ will provide the needed feedback from the technical
> > > point of view through GCC compile-test-deploy cycle (e.g., ABI
> > > compatibility, deployment on different machines).
> > >
> > > > > > I'm not trying to delete all the code, I'm trying to move it out
> of libstdc++.
> > > > >
> > > > > And, being part of libstdc++ really means something.
> > > >
> > > > In this case it means we're expected to carry around all this code
> for
> > > > questionable benefit.
> > >
> > > Alex says that it has some benefits, and he has proposed to maintain
> > > it.  I propose to co-maintain it since I also see that it has some
> > > merits now that I have read its online documentation to understand why
> > > it is called "policy-based" and Alex and his community use it.
> >
> > OK, since you two are willing to help I will drop my suggestion to
> > deprecate it - thanks!
> >
> > Please feel free to ask any questions here on this mailing list, or
> > reach out to me directly (but preferably on the mailing list as there
> > are others who can help you here too).
>
> It's been six years and nobody has contributed a single fix to the
> pb_ds code (except for me, when important changes elsewhere in the
> library forced me to maintain this code just to keep its tests
> passing).
>
> I'm going to deprecate it for GCC 16 and will remove it for GCC 17.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://gcc.gnu.org/pipermail/libstdc++/attachments/20250520/48112648/attachment.htm>


More information about the Libstdc++ mailing list