std::tr1::* will remain in std::tr1, right?
Scott Meyers
Google in nearly 3 days. I apologize if this appears twice. --Scott]
One of the questions that comes up repeatedly when I talk about TR1 is, "will
the stuff in std::tr1 remain in tr1, or will it be moved up into namespace std
when it's officially added to the standard?" Actually, the form of the question
is usually, "But std::tr1 will eventually go away, and the stuff in it moved
into std, right?" I keep saying that what's in std::tr1 will remain in
std::tr1, but now that I think of it, I don't know if I've seen that stated
explicitly anywhere. 1.3/3 of TR1 suggests it, but since the question comes up
so often, I'd appreciate it if people here would reassure me that the plan is
for functionality in std::tr1 to remain in that namespace forever. For whatever
reason, lots of people seem to assume that namespace std::tr1 is temporary.
Thanks,
Scott
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Pete Becker
>
> One of the questions that comes up repeatedly when I talk about TR1 is,
> "will the stuff in std::tr1 remain in tr1, or will it be moved up into
> namespace std when it's officially added to the standard?" Actually,
> the form of the question is usually, "But std::tr1 will eventually go
> away, and the stuff in it moved into std, right?" I keep saying that
> what's in std::tr1 will remain in std::tr1, but now that I think of it,
> I don't know if I've seen that stated explicitly anywhere. 1.3/3 of TR1
> suggests it, but since the question comes up so often, I'd appreciate it
> if people here would reassure me that the plan is for functionality in
> std::tr1 to remain in that namespace forever. For whatever reason, lots
> of people seem to assume that namespace std::tr1 is temporary.
>
TR1 says what it says: Any implementation of TR1 will put the
appropriate things in std::tr1. There are no plans to change what TR1
says when and if parts of it go into the standard.
There is no guarantee that things from TR1 that go into the standard
will not be changed, so some things will have to move into a namsepace
other than std::tr1 (i.e. std) to avoid conflicting with the way they're
defined in TR1. Things that go into the standard unchanged from TR1
should also be moved, to avoid confusion about where things come from.
In short (and in my opinion) standardizing things from TR1 will have no
effect on TR1. It will continue to be merely advisory. <g>
--
Pete Becker
Roundhouse Consulting, Ltd.
Dietmar Kuehl
> One of the questions that comes up repeatedly when I talk about TR1 is,
> "will the stuff in std::tr1 remain in tr1, or will it be moved up into
> namespace std when it's officially added to the standard?"
The answer to this is actually rather unclear! As Pete already pointed
out, TR1 says what TR1 says. It is no a mandatory part of the standard
and we expect changes to TR* components before they become mandatory
parts of the standard and in this case it makes sense to move them to
another namespace to avoid breaking code.
However, this is actually related to a much bigger issue: versioning
of library components. We occasionally discussed how to deal with
[relatively] major library changes without breaking existing code.
One take on this is to simple have no major library change thereby
avoiding the issue of versioning alltogether. Another idea would use
different namespaces for different versions of the standard library
(e.g. 'std1998' and 'std200x') and users would select their primary
version with a namespace alias ('namespace std = std200x;') which
would have an appropriate default (probably 'std1998' in the above
scenario). With such an approach, the current namespace 'std' would
remain unchanged and the new namespace 'std' would accommodate the
current libraries (probably changed in various forms) plus new
libraries which may include components from TR1.
Since library vendors are pretty sensitive to user needs, they will
almost certainly retain implementations of TR1 in namespace
'std::tr1'. However, the next standard will probably not address
the contents of this namespace and the standard versions of the TR1
components will go into the same namespace as the rest of the
standard C++ library.
--
<mailto:dietma...@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
Francis Glassborow
<dietma...@yahoo.com> writes
>However, this is actually related to a much bigger issue: versioning
>of library components. We occasionally discussed how to deal with
>[relatively] major library changes without breaking existing code.
>One take on this is to simple have no major library change thereby
>avoiding the issue of versioning alltogether. Another idea would use
>different namespaces for different versions of the standard library
>(e.g. 'std1998' and 'std200x') and users would select their primary
>version with a namespace alias ('namespace std = std200x;') which
>would have an appropriate default (probably 'std1998' in the above
>scenario). With such an approach, the current namespace 'std' would
>remain unchanged and the new namespace 'std' would accommodate the
>current libraries (probably changed in various forms) plus new
>libraries which may include components from TR1.
But namespace aliases are inadequate for the job unless we manage to
change them so that it is possible to actually use them interchangeably
with the original name.
--
Francis Glassborow ACCU
Author of 'You Can Do It!' see http://www.spellen.org/youcandoit
For project ideas and contributions: http://www.spellen.org/youcandoit/projects
Dietmar Kuehl
> But namespace aliases are inadequate for the job unless we manage to
> change them so that it is possible to actually use them interchangeably
> with the original name.
I know. However, I consider the primary problem (you cannot use a
namespace alias to declare anything within the namespace) more or
less an error in the current specification. I'm confident that this
will get fixed if we decide that namespace aliases is the path to
address library versioning.
The more interesting problem about using namespaces for versioning
is that you would need to replicate classes in all namespaces in
which they appear even if they are actually unchanged. This does
not only duplicate work but also inhibits using the types together.
This is an issue caused by the name lookup rules and rather unlikely
to be solved.
--
<mailto:dietma...@yahoo.com> <http://www.dietmar-kuehl.de/>
<http://www.eai-systems.com> - Efficient Artificial Intelligence
---