This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: [v3] annex D 8 and 9 for C++0x


skaller wrote:
On Fri, 2007-10-26 at 22:16 -0700, Joe Buck wrote:

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>,

I hope so!


and drop the tr1 namespace as well?

there's nothing to drop. Tr1 isn't part of any ISO Standard.


And will we
then get another round of deprecation?

Nothing to deprecate.


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.

No one is *making* people use non-standardised features. Unless I'm mistaken, tr1 contains code *recommended* in an ISO Technical Report .. not a Standard.

Anyone who tries this out must be prepared to accept that
the interface almost MUST be changed when it is standardised.
The reason is the committee of experts will use the experience
with it to improve it a bit before standardising it, possibly introducing incompatibilities. They will of course
try to avoid this, I'm quite sure the committee members put
far too much weight on compatibility.. ;(


If you don't want to keep changing your code

* supply your own code, or,
* wait until the official Standard is released

Otherwise accept that the very PURPOSE of 'experimental'
code is to test it out and make changes before standardisation,
and that such changed, standardised code SHOULD be put into a distinct place from the experimental code.


Is there some reason gcc can't continue to support BOTH tr1 AND std versions?
I thought that was the plan. IIUC the standard versions that are available in --c++0x mode actually sort of call the TR1 versions.
There is a area for common std::tr1 and std:: headers so the maintenace burden shouldn't be too bad. The only thing left out of the standard was the special math functions. There might be some API differences in the regex stuff and maybe in a few other places.
IMHO that would be the main gripe, if this were not possible.



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