Michael Veksler wrote:
>The behavior of the second run does not look right. What does it mean?
>1. Is it forbidden by tr1 to define unordered_set<double> ?
>2. Is it a bug in the tr1 document (which should have forbidden this).
>3. Is it OK to have repetitions in unordered_set?
>4. Is it a bug in gcc, for handling double the way it does?
>5. Is it a bug in the implementation of tr1 in libstdc++ ?
> Maybe handling of double should move to a different
> translation unit, to avoid aggressive inlining. Or maybe
> there should be a specialization for equal_to<double>,
> where error bands will be used.
>
>
I can see two possibilites here. Either:
1. You know the answer. Then you should probably discuss it,
preferably comparing gcc to other compilers and mentioning specific
sections of the Standard, TR1, LIA*, and so on.
2. You don't know the answer. In that case you are supposed to file
a PR and trust bug-masters and maintainers about the issue.
> std::tr1::hash<dobule> is implemented in a very bad way.
> it casts double to size_t, which of course does a very poor job on big
> values (is the result of 1.0e100 cast to size_t defined ?).
>
>
Thanks. Patches welcome, as usual: contributions are certainly
encouraged, especially so from IBM - I would say - generally committed
to the project in a constructive, high quality, and friendly way.
Paolo.
