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 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.
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…)