This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: backwards headers vs. C++0x



If it's not hard to keep these headers, why not do it?  We know that
there are a lot of users that have large codebases and are resistant to
changing them.  The free software codebases (e.g., KDE) are not
representative of industrial codebases.  If maintaining compatibility
makes it hard to move forward and implement new features, that's a good
argument for removing things -- but just tidiness isn't.

Sadly, we won't really know until removal who is still using these headers. It's my suggestion to probe this area a bit: my last suggestion allowed for reinstatement, which I think is completely reasonable. We'll at least get rid of the unused ones this way.


I think there are other good arguments for removal besides just tidiness, or standing in the way of new features.

I think it's foolish to have a standard library that doesn't deprecate weaker interfaces in a meaningful way. In the case of the headers under discussion, some of them have been unused for 10 years or more.

In addition, many of the backwards headers are not really being maintained at the moment (say the hash_set bits), have known issues, and clearly superior alternatives exist (std::tr1::unordered_set). Anything that's actually considered relevant and useful is already available as an extension: see ext/slist and ext/rope for instance.

With C++0x, a substantial number of new interfaces are being introduced, and perhaps a new set of older interfaces will deprecated.(As above, I would propose moving ext/hash_set to backwards/hash_set. Martin clearly thinks that others deserve this treatment, and I would probably go along with the usual suspects.).

The time is now to think clearly about the total set of interfaces that will be supported w/ C++98/03 and C++0x flavors. I think removing the current backwards contents is a reasonable starting point, provided that there exists a mechanism to put back backwards headers that are still actively used.

best,
-benjamin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]