Mingw/VS WIP

[shenle]

I got the same error on 2 different systems, both of them with freshly installed mingw using the newest installer available. (actually one of them is 11/2/2011, the other is 11/18/11 - but both are updated to the latest packages).

[klauss]

Still, mingw might be coming with old headers.

[shenle]

Possible but I don't know how to fix that.

Actually mingw-gcc comes with both the standard and tr1 namespaces:
/lib/gcc/mingw32/4.6.1/include/c++/unordered_map and
/lib/gcc/mingw32/4.6.1/include/c++/tr1/unordered_map both exist.

Now how to get gcc to use the latter instead of the former without breaking other platforms' builds?

[klauss]

I don't know, it should work out of the box if the headers are there.

[shenle]

Perhaps some changes in gnuhash.h? How about this bit which apparently forces the standard namespace to be used on Windows regardless of compiler?

Code: Select all

#ifdef _WIN32
#ifdef HAVE_TR1_UNORDERED_MAP
#include <unordered_map>  //MSVC doesn't use tr1 dirs

[shenle]

I have changed the bit above to

Code: Select all

#ifdef _WIN32
#ifdef HAVE_TR1_UNORDERED_MAP
#if defined(_MSC_VER) && _MSC_VER >= 1600
#include <unordered_map>  //MSVC doesn't use tr1 dirs
#else
#include <tr1/unordered_map>
#endif

And it seems to get me over this error.

Hopefully it won't break compiling by MSVC. Testing that now. Stay tuned... Compiles and runs fine with VC++ 2008. Phoenix, if you can confirm that it doesn't break the build maybe this can be committed.

[shenle]

Next error on mingw:

In file included from ../vegastrike/src/savegame.h:12:0,
from ../vegastrike/src/networking/client.h:34,
from ../vegastrike/src/networking/lowlevel/vsnet_clientstate.cpp:3:
../vegastrike/src/SharedPool.h:12:46: error: expected type-specifier
../vegastrike/src/SharedPool.h:12:46: error: expected '>'
../vegastrike/src/SharedPool.h:184:43: error: expected template-name before '<' token
../vegastrike/src/SharedPool.h:184:43: error: expected '{' before '<' token
../vegastrike/src/SharedPool.h:184:43: error: expected unqualified-id before '<' token
make[1]: *** [src/networking/lowlevel/vsnet_clientstate.o] Error 1
make: *** [all] Error 2

[klauss]

It's not getting to the definition of vsHashComp that should be in gnuhash.h

[shenle]

It's not getting to the definition of vsHashComp that should be in gnuhash.h

That comes after vshashComp

[shenle]

Well I tried several things in gnuhash.h and nothing seems to work.

[klauss]

You should try g++ -E, which outputs the preprocessed source. It's useful for finding out why something gets or doesn't get defined.

[shenle]

You should try g++ -E, which outputs the preprocessed source. It's useful for finding out why something gets or doesn't get defined.

That gets me 2MB of text... greping through it for vsHashComp I get nothing... same for HAVE_TR1_UNORDERED_MAP

[klauss]

Look for the place where it's supposed to be defined. Use nearby text and the preprocessed output's line and file annotations to guide you.

[log0]

There is an easy solution, although I am not sure if people are going to like it(requires boost > 1.35).
1. Replace the mess in gnuhash.h with

Code: Select all

#include <boost/unordered_map.hpp>
#define vsUMap boost::unordered_map
#define vsHash boost::hash

2. Remove the second template parameter from SharedPool class.

[klauss]

2. Remove the second template parameter from SharedPool class.

That parameter is there for sanity.
You're proposing to remove sanity :p

[log0]

Do you mind to be more concrete?

[klauss]

This parameter will throw an error when the vsHashComp<T> traits type isn't defined. That traits type is defined for hashable/hashcomparable types (like std::string).

vsHashComp is a #define or typedef (can't remember which) of the underlying STL traits type.

It prevents the code from attempting to create hash maps of non-hashable types, and when attempted, it should provide meaningful error messages (vsHashComp not defined, meaning the type isn't hashable).

Removing that parameter won't fix the underlying problem (of the hashmap lacking a hashing function), but will remove the meaningful messages and, in some rare cases, allow creating of useless hash maps.

[log0]

I see. Never used nonstandard hash containers. But I think there is no such thing as std::tr1::hash_compare thus the error @shenle is getting. Maybe forcing stdext would solve his issue.

[klauss]

I don't think so. Because the error shenle is getting is about vsHashComp, not hash_compare.

I would bet vsHashComp (the macro) is not getting #define d, that's his problem.

[log0]

gnuhash.h

Code: Select all

#ifdef HAVE_TR1_UNORDERED_MAP
#define vsUMap std::tr1::unordered_map
#define vsHashComp std::tr1::hash_compare
#define vsHash std::tr1::hash
#else
#define vsUMap stdext::hash_map
#define vsHashComp stdext::hash_compare
#define vsHash stdext::hash
#endif

[shenle]

Well here is where the error occurs, in src/SharedPool.h (first non-comment line below):

Code: Select all

//Need reference counted strings, or we'll eat memory like crazy
template < class T, class RefcounterTraits = vsHashComp< T > >
class SharedPool
{
public:
    typedef vsUMap< T, unsigned int >        ReferenceCounter;
    typedef SharedPool< T, RefcounterTraits >PoolType;

private:
    ReferenceCounter referenceCounter;
    static PoolType *ms_singleton;

This is what it looks like after preprocessor (in context):

Code: Select all

template < class T, class RefcounterTraits = std::tr1::hash_compare< T > >
class SharedPool
{
public:
    typedef std::tr1::unordered_map< T, unsigned int > ReferenceCounter;
    typedef SharedPool< T, RefcounterTraits >PoolType;

private:
    ReferenceCounter referenceCounter;
    static PoolType *ms_singleton;

Looks to me like the #defines from gnuhash.h work fine.
Attached (zipped) the complete output of the preprocessor for the file in cause.

[log0]

I've had a closer look at SharedPool.h/cpp and the code there doesn't make any sense. The template parameter class RefcounterTraits = vsHashComp< T > which is ought to be hash_compare is not passed to the actual hash_map. It is used to pass the INITIAL_STRINGPOOL_SIZE to the hash_map constructor. Strange stuff.

[klauss]

It doesn't have to, the hash map knows it already (it's the default).

PS: ran out of ideas