This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [v3] annex D 8 and 9 for C++0x
> > 3) The hash extensions are used, no doubt, but there is a way
> > forward here as well. (See my emails).
>
> Here is where I disagree with you, and am puzzled by your "no doubt".
> For a decade, they were the only STL-compliant hash classes widely
> available. Thanks to STLport, they work with many compilers. They
> are *very* widely used. By having them in ext/, we clearly flag that
> they are an extension.
>
> In the past, when we have deprecated code, the user gets a warning but
> the code still builds. By deprecating them *and* moving the headers,
> the code simply breaks. I don't understand why this is a good thing.
> That is not the way we normally do deprecation.
Hmm. OK.
I'm willing to concede on this one. There was no compile warning in a
previous release for this item. Gerald has also asked about this as
well.
How about I symlink backward/hash_map to ext/hash_map,
and backward/hash_set to ext/hash_set?
Then, everybody is happy. Eventually, the symlink (n+2, say 4.5) can be
killed.
> If not, are we really doing people a service by pushing them to TR1
> before it is stable?
I'll correct the docs.
best,
-benjamin