Juce ssize_t conflict with libmpg123

General JUCE discussion
1

“ssize_t” in the tip, declared in juce_MathsFunctions.h:

#if JUCE_MSVC
  typedef pointer_sized_int ssize_t;
#endif

Conflicts with a libmpg123 typedef of the same name. Any chance we can rename the Juce one? It is MSVC specific in Juce anyway, and only appears in four other places:

Find all "ssize_t"
  juce_core\native\juce_posix_SharedCode.h(439): ssize_t result = 0;
  juce_core\native\juce_posix_SharedCode.h(503): ssize_t result = 0;
  juce_core\streams\juce_InputStream.cpp(200): ssize_t numBytes
  juce_core\streams\juce_InputStream.h(248): ssize_t maxNumBytesToRead
2

The juce one is inside the juce namespace… What’s the context in which it’s causing you trouble?

BTW it’s not MSVC-specific, but on other platforms it’s already defined in the system headers, that typedef is really just a fallback because MS don’t already provide it.

3

blah

My source file includes mpg123.h and thats where I get the error, since a “using juce” namespace directive is in force.

1>  DecoderMpg123.cpp
1>libmpg123\src\libmpg123\mpg123.h.in(1046): error C2872: 'ssize_t' : ambiguous symbol
1>          could be 'D:\dev\trunk\libmpg123\ports\MSVC++\mpg123.h(14) : long ssize_t'
1>          or       'd:\dev\trunk\juce\modules\juce_core\system\../maths/juce_MathsFunctions.h(95) : juce::ssize_t'
1>libmpg123\src\libmpg123\mpg123.h.in(1057): error C2872: 'ssize_t' : ambiguous symbol
1>          could be 'D:\dev\trunk\libmpg123\ports\MSVC++\mpg123.h(14) : long ssize_t'
1>          or       'd:\dev\trunk\juce\modules\juce_core\system\../maths/juce_MathsFunctions.h(95) : juce::ssize_t'
4

Well, just include mpglib before juce, I guess.

Having “using namespace juce” defined by default has been bothering me a bit recently, because it can lead to subtle annoyances like this. Can’t decide whether I should force people to declare it themselves if they want it, or not. Doing it that way would be a more modern c++ approach, but I’m afraid that if I released a build with it turned off, all the newbies would be bewildered by the fact that none of their code would compile any more…

5

I just remembered that this is MSVC specific on the libmpg123 side. Actually I personally added that typedef for MSVC. I could change it in libmpg123, at least guard it with a #ifndef.

We just need to make sure that pointer_sized_int is compatible to the current typedef of ssize_t in libmpg123 which is long. Juce defines pointer_sized_int differently depending on the plattform and 32/64 bit:

[quote]#elif JUCE_MSVC
/** A signed integer type that’s guaranteed to be large enough to hold a pointer without truncating it. /
typedef _W64 int pointer_sized_int;
/* An unsigned integer type that’s guaranteed to be large enough to hold a pointer without truncating it. /
typedef _W64 unsigned int pointer_sized_uint;
#else
/* A signed integer type that’s guaranteed to be large enough to hold a pointer without truncating it. /
typedef int pointer_sized_int;
/* An unsigned integer type that’s guaranteed to be large enough to hold a pointer without truncating it. */
typedef unsigned int pointer_sized_uint;
#endif[/quote]

These look compatible to long to me. So I could simply add an #ifndef to the libmpg123 typedef.

Patrick

6

There should be no need, each of these things lives in their own namespace and there shouldn’t be a conflict if their headers are kept separate.

But be careful with long, because I seem to remember that long is still 32 bit even in a in 64-bit MSVC build. (I could be wrong about that though…?)

7

See, in my project juce.h is included by a file that is included first in every .cpp file. Its part of the precompile too. So there is no convenient way for me to include the mpg123 header before Juce.

8

The you could turn off the automatic juce “using namespace”, and call that yourself after all the headers?