[v3] annex D 8 and 9 for C++0x

Benjamin Kosnik bkoz@redhat.com
Fri Oct 26 22:29:00 GMT 2007

> But I am worried that you are being much too aggressive about
> deprecation. 550 broken Debian packages is not a good sign.  Have you
> checked with your colleagues about just how big a job you're handing
> them, getting Fedora or RHEL6 to work with 4.3?

I appreciate the concern you show for me and my colleagues. However,
your lack of faith is a bit depressing.


There are a couple issues that are separate, but have been linked by
unfortunate error in some of your posts. Here, I'll try to straighten
them out.

1) Debian has 550 build issues right now due to header/include
streamlining. All the packagers, irregardless of distro, are fixing
this stuff up. This issue preceded any patch of mine, but for the
record, I am in support of this streamlining work and consider it a
good thing. 

2) The pre-iso C++ include issue is easy to fix, the changes are largely
mechanical and well documented, and has been warned about for six

3) The hash extensions are used, no doubt, but there is a way forward
here as well. (See my emails). The point is not usage, but clearly
communicating from the maintainers to the users what is considered
deprecated now and in the future: the fact that you've been taken so
completely by surprise when the file is marked as it is, documented
as such, and the alternatives so obvious, indicates the depth of the
challenge here and the possible advantages of my approach. These changes
were made in a way that was consistent with other changes, like the
split of extensions into namespace __gnu_cxx. 

Perhaps you would be willing to document or explain some of these issues
for the gcc online docs? Your last post about montone was helpful, and
if you combine it with Jonathan Wakely's musings (very interesting as
well) about typedef templates and backward compatible typedefs, my
details about compat we'd really be getting somewhere. It would
probably make more sense if somebody besides me can explain the
approach taken and outline alternative approaches.
I've been trying to be clear and accurate but am unimpressed with the
job I've been doing so far.

gotta go,

More information about the Libstdc++ mailing list