This is the mail archive of the
mailing list for the GCC project.
Re: [v3] annex D 8 and 9 for C++0x
I wrote, re hash_set and hash_map:
> > 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.
On Fri, Oct 26, 2007 at 11:52:53PM -0500, Benjamin Kosnik wrote:
> 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
> How about I symlink backward/hash_map to ext/hash_map,
> and backward/hash_set to ext/hash_set?
That would make me happier, but I still have some concerns about the
deprecation (I would have preferred to just leave it, since the user
still has to say "ext/" and use other magic that makes its extension
status clear). I suppose I could live with it.
> Then, everybody is happy. Eventually, the symlink (n+2, say 4.5) can be
Well, maybe not *happy*, but at least, not quite as pissed off. :-)
> > If not, are we really doing people a service by pushing them to TR1
> > before it is stable?
> I'll correct the docs.
You mean, to stop warning people away from TR1?
Also, I had another question: do we expect the TR1 features, or some of
them, to be absorbed into the regular standard, so that some future
standards version will tell people to write <unordered_set> and not
<tr1/unordered_set>, and drop the tr1 namespace as well? And will we
then get another round of deprecation? The reason I ask is that a lot
of long-lived code tries to support being compiled by many compilers,
and I would like to argue in advance that making people keep changing
the code is a bad idea.