Re: PATCH: TR1 unordered associative containers

Re: PATCH: TR1 unordered associative containers

[Geoffrey Keating]

Matt Austern <austern@apple.com> writes:

Hi Matt,

Looks pretty neat!  However,

> +   tr1_hashtable_define_trivial_hash(float);
> +   tr1_hashtable_define_trivial_hash(double);
> +   tr1_hashtable_define_trivial_hash(long double);

cast-to-int probably isn't a very good hash function for
floating-point values...

> +   #undef tr1_hashtable_define_trivial_hash
> +
> +   template <typename T>
> +     struct hash<T*> {
> +       std::size_t operator()(T* p) const {
> + 	return reinterpret_cast<std::size_t>(p);
> +       }
> +     };
> +
> +   // ??? We can probably find a better hash function than this (i.e.
> one
> +   // that vectorizes better and that produces a more uniform
> distribution).
> +
> +   // XXX String hash probably shouldn't be an inline member function,
> +   // since it's nontrivial.  Once we have the framework for TR1 .cc
> +   // files, this should go in one.

And like this function, there's a problem: once you put this in an
inline function in a shipping compiler, even once, you're stuck with
it forever; that is, you can't change the function after that point.
So I think it'd be best to put them in a .cc file in the first commit.

> + // XXX This is a hack.  prime_rehash_policy's member functions, and
> + // certainly the list of primes, should be defined in a .cc file.
> + // We're temporarily putting them in a header because we don't have a
> + // place to put TR1 .cc files yet.  There's no good reason for any of
> + // prime_rehash_policy's member functions to be inline, and there's
> + // certainly no good reason for X<> to exist at all.

Likewise, this, and that'd be really annoying.  Especially if you
later wanted to extend the list of primes.

Re: PATCH: TR1 unordered associative containers

[Matt Austern]

On 18 Feb 2005 16:49:31 -0800, Geoffrey Keating <geoffk@geoffk.org> wrote:

> And like this function, there's a problem: once you put this in an
> inline function in a shipping compiler, even once, you're stuck with
> it forever; that is, you can't change the function after that point.
> So I think it'd be best to put them in a .cc file in the first commit.

I agree that putting this in a .cc file is a really good idea. 
However, remember that this is TR1 stuff, not standard stuff.  This
means two things.

First, I don't think binary compatibility means as much for this as
for the standard library.  Everything in TR1 is semi-experimental by
definition.

Second, before we have any .cc files, we need to figure out what to do
with them.  They can't go into libstdc++.dylib, precisely because
they're not as solid as the standard library.  Probably this means we
need to come up with some new library just for the TR.

                --Matt

Re: PATCH: TR1 unordered associative containers

[Kai Henningsen]

austern@gmail.com (Matt Austern)  wrote on 18.02.05 in <98604e9d0502181950c6bc69d@mail.gmail.com>:

> Second, before we have any .cc files, we need to figure out what to do
> with them.  They can't go into libstdc++.dylib, precisely because
> they're not as solid as the standard library.  Probably this means we
> need to come up with some new library just for the TR.

Or maybe a library for all non-standard stuff not needed to implement the  
standard stuff - I seem to recall there are a few more things, like ropes?  
Or are they gone already?

MfG Kai

Re: PATCH: TR1 unordered associative containers

[Gabriel Dos Reis]

kaih@khms.westfalen.de (Kai Henningsen) writes:

| austern@gmail.com (Matt Austern)  wrote on 18.02.05 in <98604e9d0502181950c6bc69d@mail.gmail.com>:
| 
| > Second, before we have any .cc files, we need to figure out what to do
| > with them.  They can't go into libstdc++.dylib, precisely because
| > they're not as solid as the standard library.  Probably this means we
| > need to come up with some new library just for the TR.
| 
| Or maybe a library for all non-standard stuff not needed to implement the  
| standard stuff

Among the non-standard stuff, there are things that are kind of stable
and things that are really experimental.  TR1 really *is experimental*. 
We do noone a favour if we put all non-standard stuff in the same
bucket.  

-- Gaby