SGI STL

SGI STL

[Anand Raman]

Hi 

I am trying to compile some code using the SGI STL with egcs 1.01.

In particular I am using hash_map from the STL which is not part of
the standard library in egcs.  Unfortunately, it comes up with a whole
lot of errors and template functions that the loader is unable to
find.

Can someone help me please.  Here is a simple program that doesn't
compile:

#include <iostream.h>
#include <string>
#include "hash_map"

struct eqstr {
  bool operator()(string s1, string s2) const {
    return s1 == s2;
  }
};

main() {
  hash_map<string ,int,hash<string>,eqstr> ords;

  ords["one"] = 1;
  cout <<ords["one"] <<endl;

  return 0;
}

However, if I replace string by "const char *" it works.  Why isn't
the hash function overloaded for string, which I would have guessed
would pretty much be a basic type?

Also, how come I get the following two warning messages:

/usr/local/include/g++/stl_hashtable.h:150: warning: decimal integer constant is so large that it is unsigned
/usr/local/include/g++/stl_hashtable.h:150: warning: decimal integer constant is so large that it is unsigned

when the constants are in fact declared already as unsigned long!

Any help in this regard will be greatly appreciated.

Many thanks.

- &

Re: SGI STL

[Joe Buck]

I responded to this earlier but I should say a couple more things:

> I am trying to compile some code using the SGI STL with egcs 1.01.
> In particular I am using hash_map from the STL which is not part of
> the standard library in egcs.

egcs ships with hash_map from SGI.  Are you downloading it again
separately?  That isn't necessary (and could cause problems if you
mix older/newer versions, though currently it's probably the same
file).

Also in your example program you don't use defaults; given a proper
hash<string> you can just write

---------------------
#include <iostream.h>
#include <string>
#include <hash_map>

main() {
  hash_map<string,int> ords;

  ords["one"] = 1;
  cout <<ords["one"] <<endl;

  return 0;
}
---------------------

Finally, the sample implementation of hash<string> I supplied,

template<> struct hash<string> {
    size_t operator()(const string& s) const {
	return __stl_hash_string(s.c_str());
}};

doesn't deal with null characters, which are allowed in strings.
In principle this is OK for a hash function; they aren't that commonly
used and it just means that all strings with nulls in them hash based only
on what precedes the null.  It would be easy enough to write one that
uses s.length() instead of a trailing null.

To support hash<string>, the above definition, together with

#include <stl_hash_fun.h>

could be added to <string>.  (Or it could be more general, to support
wide strings too).  I won't supply a patch because Ulrich or Jason
may have some feelings on how to organize it.

Re: SGI STL

[Joe Buck]

On Thu, Feb 12, 1998 at 11:02:07AM -0500, Anand Raman wrote:

> I am trying to compile some code using the SGI STL with egcs 1.01.
> 
> In particular I am using hash_map from the STL which is not part of
> the standard library in egcs.  Unfortunately, it comes up with a whole
> lot of errors and template functions that the loader is unable to
> find.

There is only one function missing (which ideally should be provided).
Fortunately it is very short.

Add the following to your code:

template<> struct hash<string>
{
    size_t operator()(const string& s) const {
	return __stl_hash_string(s.c_str());
    }
};

It will then work, using the same hashing function for string as for
const char * .

By the way, you can make a hashtable of any type by writing something
like the above, defining a specialization of the hash template for your
type.  It should map the object into a size_t .

Re: SGI STL

[Martin v. Loewis]

> 	Is it a painless retrofit to put
> 	the current STL on a current egcs?

The current STL is in the egcs development tree. It's just binary
compatibility that prevents it from getting into 1.1.2 - we don't
want everybody to recompile everything after a subminor release.

> The STL is quite important to me, and I'm willing
> to do what I can to make it play friendly with
> egcs.

If you absolutely want to use the current STL with 1.1.2, instead of
using development versions until 1.2 is released, you could certainly
have a look at the changes Jason made when he updated the STL version.
CVS knows all about it.

> I'm looking more at hacking the SGI STL, as opposed
> to jumping into the GNU (?) standard-library effort
> which seems to be building a conforming STL/Standard Lib
> from scratch.

libstdc++ v3 will be based on SGI STL, as a literal copy. Changes made
to it are integrated back into the SGI code base. I think there was
some formal agreement between SGI people and egcs people about doing
it that way.

Regards,
Martin

SGI STL

[Bob McWhirter]

Howdy--

Since someone said that the latest STL from SGI
probably won't be in egcs-1.1.2, I was wondering
a few things:

	Is it a painless retrofit to put
	the current STL on a current egcs?

	If not, is someone working on it, and
	how do I volunteer to help?

The STL is quite important to me, and I'm willing
to do what I can to make it play friendly with
egcs.

I'm looking more at hacking the SGI STL, as opposed
to jumping into the GNU (?) standard-library effort
which seems to be building a conforming STL/Standard Lib
from scratch.

Thanks!

-Bob M.

Re: SGI STL

[Martin v. Loewis]

> 	Is it a painless retrofit to put
> 	the current STL on a current egcs?

The current STL is in the egcs development tree. It's just binary
compatibility that prevents it from getting into 1.1.2 - we don't
want everybody to recompile everything after a subminor release.

> The STL is quite important to me, and I'm willing
> to do what I can to make it play friendly with
> egcs.

If you absolutely want to use the current STL with 1.1.2, instead of
using development versions until 1.2 is released, you could certainly
have a look at the changes Jason made when he updated the STL version.
CVS knows all about it.

> I'm looking more at hacking the SGI STL, as opposed
> to jumping into the GNU (?) standard-library effort
> which seems to be building a conforming STL/Standard Lib
> from scratch.

libstdc++ v3 will be based on SGI STL, as a literal copy. Changes made
to it are integrated back into the SGI code base. I think there was
some formal agreement between SGI people and egcs people about doing
it that way.

Regards,
Martin

SGI STL

[Bob McWhirter]

Howdy--

Since someone said that the latest STL from SGI
probably won't be in egcs-1.1.2, I was wondering
a few things:

	Is it a painless retrofit to put
	the current STL on a current egcs?

	If not, is someone working on it, and
	how do I volunteer to help?

The STL is quite important to me, and I'm willing
to do what I can to make it play friendly with
egcs.

I'm looking more at hacking the SGI STL, as opposed
to jumping into the GNU (?) standard-library effort
which seems to be building a conforming STL/Standard Lib
from scratch.

Thanks!

-Bob M.