I did a search for "namespace std version" and found nothing like what
I thought of today; and I haven't read anything like "Design and
Evolution of C++". So, here goes.

There are concerns in changing API of standard classes. But what if the
standard classes (as they are defined today) actually lived in
namespace std::iso_1998?

Such that a future version of the standard library, free to break API,
lived in namespace std::iso_200x?

The user would be able to configure the desired version with a

  namespace std = std::iso_1998;

statement. Or perhaps some other configuration mechanism would be
offered to the user, that could be implemented like that.

Maybe that should be the default; maybe there should be no default, as
it seems relatively easy to add some command-line defined macro like
"-Dstd=std::iso_1998" to support legacy code.

The only disadvantage I see so far is for an implementation to have
possibly doubled size; but maybe it doesn't have to, and that's left up
to her. I don't know how such a thing would be spelled out in
standardese though.

Just some thoughts.

--
 Pedro Lamar   o


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"thoth39" <pedro.lamarao@gmail.com> writes:

> I did a search for "namespace std version" and found nothing like what
> I thought of today; and I haven't read anything like "Design and
> Evolution of C++". So, here goes.

http://www.gotw.ca/publications/mill20.htm
http://www.gotw.ca/publications/mill21.htm

might be of some interest.

> There are concerns in changing API of standard classes. But what if the
> standard classes (as they are defined today) actually lived in
> namespace std::iso_1998?
>
> Such that a future version of the standard library, free to break API,
> lived in namespace std::iso_200x?
>
> The user would be able to configure the desired version with a
>
>   namespace std = std::iso_1998;
>
> statement. Or perhaps some other configuration mechanism would be
> offered to the user, that could be implemented like that.
>
> Maybe that should be the default; maybe there should be no default, as
> it seems relatively easy to add some command-line defined macro like
> "-Dstd=std::iso_1998" to support legacy code.
>
> The only disadvantage I see so far is for an implementation to have
> possibly doubled size; but maybe it doesn't have to, and that's left up
> to her. I don't know how such a thing would be spelled out in
> standardese though.

It's been considered.  There are some problems with it, the most
obvious one being that you can't write a template specialization
through a namespace alias.  That is, the following is illegal:

  namespace foo
  {
     template <class T> struct bar;
  }

  namespace baz = foo;

  namespace baz
  {
      template <> struct bar<int> {};
  }

So user specializations (e.g. of std::iterator_traits), would fail to
compile.  Of course, I support making it legal ;-)

--
Dave Abrahams
Boost Consulting
www.boost-consulting.com

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

I see, the second article discusses this problem.

Is there a reason why reopening an alias like that shouldn't be
allowed?

This versioning technique would be really useful, even if the committee
decides not to use it.

--
 Pedro Lamar   o


---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]