Re: [wwwdocs] updates to porting_to

[Gerald Pfeifer <gerald at pfeifer dot com>]

Hi Benjamin,

thanks for doing this!  There is one serious regression (from a user 
perspective, mind, not in terms of standards conformance according to
a discussion I've had with Paolo) that's demonstrated by the example
below:

======== snip ========
#include <ext/hash_map>
#include <tr1/unordered_map>
#include <iostream>
#include <cstring>

size_t exthash(const char *s) {
        __gnu_cxx::hash<const char*> hasher;
        return hasher(s);
    };

size_t tr1hash(const char *s) {
        std::tr1::hash<const char*> hasher;
        return hasher(s);
    };

void test( size_t (*hashfunc)(const char*), const char *hashname ) {
  char s[10];

  strcpy(s,"one"); size_t one=hashfunc(s);
  strcpy(s,"two"); size_t two=hashfunc(s);

  std::cout << "one " << (one==two ? "==" : "!=")
            << " two according to "<< hashname << std::endl;
}

int main(int argc, char *argv[]) {
  test(exthash,"__gnu_cxx::hash");
  test(tr1hash,"tr1::hash");
}
======== snip ========

The difference is that ext::hash<> treats a char* as a pointer to a
C string, whereas tr1::hash<> treats a char* like any other pointer.

This can lead to massive loss of performance when all entries in an
unordered_set or unordered_map are stored in one and the same bucket,
and it can also, as in a case that took me hours to debug and that is
shown by the example above, lead to "incorrect" results.

I see this as a high risk and wonder whether any of you have an idea
how to best handle address this and how to best inform our users.

Gerald