This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ 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: On extension headers and ease of use


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


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