This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: On extension headers and ease of use
- From: Jonathan Wakely <cow at compsoc dot man dot ac dot uk>
- To: Wu Yongwei <adah at netstd dot com>
- Cc: libstdc++ at gcc dot gnu dot org
- Date: Fri, 9 May 2003 09:14:50 +0100
- Subject: Re: On extension headers and ease of use
- References: <3EBB033D.1030703@netstd.com>
On Fri, May 09, 2003 at 09:24:13AM +0800, Wu Yongwei wrote:
> OK, I know that they do not belong to namespace std. But the current
> solution seems to me worse than non-conformance.
No comment.
> For I now must use an
> unwieldy artificial construct (GCC 3/Libstdc++ is not the only
> compiler/library on this planet, isn't it?) to use slist, like:
>
> #if !defined(HAS_STLPORT) && defined(__GNUC__) && __GNUC__ == 3
> #include <ext/slist>
> using __gnu_cxx::slist;
> #else
> #include <slist>
> using std::slist;
> #endif
The libstdc++ FAQ recommends defining a namespace for the extensions
you use, which hides the implementation-specific details:
http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html#5_4
In your code you would refer to slist as Sgi::slist, and the details of
whether that's really __gnu_cxx::slist or std::slist or something else
are hidden in a header.
> And consider the possibility if one day slist is standardized into the
> std namespace (anyone knows for sure that it won't?). How would
> libstdc++ be? Reverting back to the old behaviour? What a mess!
Because it's possible that slist (or more likely, hash_map) will be
standardized it's important that the libstdc++ hash_map *not* be in std,
because a hypothetical std::hash_map might have a very different
interface.
> Open source software often pays a lot of attention on standards. Surely
> it is not a bad thing, but I want to emphasize that ease of use
> (portability, backward compatibility, etc.) is often as equally
> important. I fail to see the virtue of this change because it makes
> life worse for cross-platform development.
It can be argued that by removing the non-standard names from the std
namespace it makes cross-platform development easier. Since the
extensions are by definition non-standard you can't rely on them being
the same, or even present, in different environments, so carelessly
including them in std is a bad idea.
I have to agree that __gnu_cxx isn't the prettiest name, but that's why
it's called uglification :-)
jon
--
"If you can't say anything good about someone, sit right here by me."
- Alice Roosevelt Longworth