Re: On extension headers and ease of use

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Jonathan Wakely <cow@compsoc.man.ac.uk> writes:

[...]

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

And in fact, that some implementations made the mistake to put their
extensions in std:: is now causing serious grief.  Not only hash_map
won't be standardized with the exact interface, but the name hash_map
won't be standardized at all.  For reality check, the original poster
might want to consult the docs at the committee sites to see why Matt
Austern's proposal to add hash tables went through at least four
iterations with the outcome that the data structure is no longer named
hash table.

The original poster said GCC is not the only compiler out there.  That
is true.  And that is precisely why putting our extensions in std:: is
wrong.  Other implementations out there put their extensions in
different namespaces.

The logic of putting vendor-locked extensions in std:: might be good
for proprietary software.  It is *not* for free software.

-- Gaby