Troubles with T

General JUCE discussion
1

I’m having a nasty trouble with the T macro.

Some of the third-party code that I’m including uses T as a variable name…

It’s pretty typical in code to write template (here are examples) and since T is a macro, it simply breaks that code, scattering cryptic errors as it goes. (Well :smiley: I’d anticipated this occurring from when I was evaluating JUCE so I guessed it in a second - from reading the forum, others haven’t been so lucky!)

The new JUCER doesn’t have a spot to define JUCE_DONT_DEFINE_MACROS, which prevents T from being defined. It’s easy enough to define JUCE_DONT_DEFINE_MACROS in my configurations - but then I get hundreds of errors because it seems as if T is heavily used all over the code. :frowning:

I read through the solution proposed in juce_WithoutMacros.h but in order to achieve this I’d have to rewrite my code for IMHO the worse. Rather than having all my source files include all my header files I only include those header files I need, as I think a lot of developers do - it’s not just neater and makes it easier to see dependencies but reduces compilation times.

C++ does in fact have a convention for doing this sort of system thing - it’s that you preface your macro with two underscores. Variables that start with __ are generally belonging to the compiler or development system and the application developer uses them at risk. (Guards start with two underscores and end with one…)

It would actually be pretty easy (yes, I am volunteering! :-D) to fix this without breaking anyone’s code… simply go into the JUCE codebase and replace all the Ts with _Ss and then add a new

#define T __S

which is defined by default for legacy applications but that could be turned off. You recommend people use this setting for new projects, set it up that way in JUCER, and in a year or two, obsolete T().

(why not __T? well, I found quite a few examples of macros called __T on the net, but not a single __S - and these are, in fact, “Strings” and not, er, whatever Ts are…)

2

If it’s a 3rd party header that’s using T, then all you’d need to do is include it before juce.h

If it’s your own code that uses T, then you could just #undef T immediately after your #include “juce.h”. Then you’d need to alter your own strings to use JUCE_T instead of T (or just use standard c-strings or L"" directly), but that’s not a big deal.

No need to suggest a new symbol for it, because the library already has JUCE_T to do exactly that, and all the juce headers use that instead of T to avoid clashes. In the juce .cpp files it doesn’t matter because no other 3rd party code will be getting compiled at that point.

In the long-run, I’ll probably phase-out T() altogether - since Strings can be created from either normal char* literals or wide char literals, it’s not particularly useful, and I tend to not bother using it in new code.

3

So I brutally edited the third party stuff! :smiley: Because I’m lazy.

It’s very basic things - basically just google’s basictypes.h which I mainly use for the excellent arraysize operator that means I never have to use zero terminated arrays (hint, hint, hint :-P) and I doubt I’ll ever have to change it.

“If it’s a 3rd party header that’s using T, then all you’d need to do is include it before juce.h”

As I pointed out, that won’t work, because I include just what I need in each file:

file1.h:

#include "SomethingThatUsesT.h" #include "somejucething.h"
file2.h:

#include "SomethingElseThatUsesT.h" #include "someotherjucething.h"
file1.cpp:

#include "file1.h" #include "file2.h"
The brutal, undisciplined solution turned out to be pretty good, so I’m fine now. Let me know if you need help with that change, though - I’m a big believer in not complaining about things I’m not willing to fix myself!

4

Ah, I see. I’ve always found that doing it like that ends up being a headache, so I stick to the “all external includes go in a single header file” rule these days.

5

… you realise that juce has the numElementsInArray() function? :wink: