Hardcoded "juce" namespace in mac specific code

While trying to build the Juce library using another namespace, I encountered compile errors (on the Mac platform only) leading me to think that some “juce::” hardcoded namespace declarations were left over.

See juce_mac_WebBrowserComponent.mm, juce_mac_AudioCDBurner.mm.

See also juce_Memeory.h (and as a consequence juce_amalgamated.h)

BTW, being more PC/Win oriented, I am surprised by the “.mm” file extension used by some source files. What’s the difference with “.cpp” ?


the .mm extension is used by Objective C++ which is required if you want to make Cocoa calls.

I’ve actually considered hard-coding all the juce namespace stuff, on the assumption that there’s no sensible reason anyone would want to change it to anything else… Would be interested to know your reason for doing that?

We’ve already done that for one of our product, I am unsure of all the motivations (this was made before I came, by the guy I am replacing)

What I have found so far is that this product (AnalogFactory) is a kind of integrator for other plugins we made.
One of those plugins (Jupiter-8V) is also built with Juce, but based upon a different version.

Communication goes beyond VST integration, and some source files have access to GUI classes from both products, and so the integrator product is compiled using another namespace for Juce to avoid a complete mess.

This probably could (should) be solved another way, but I don’t really have the time right now to change that.

I am in the process of updating Analog Factory, and to be able to use the new plugin hosting classes, I am upgrading from Juce version (holding breath) 1.30 to version 1.46.
Actual conversion was made rather easily on the Windows platform. On the other hand deploying the changes to Mac OSX is kind of a nightmare…

Hmm - that does sound like something that should be done differently. But for consistency you’re right - I should remove the hard-coding where I’ve used “juce::”.

Has any progress been made on this? I’m experiencing the same problem. I was able to fix some errors by putting the juce namespace prefix on the offending variables, but others couldn’t be fixed for some reason. Perhaps someone can suggest to me the correct way to address this?

It’s all currently ok as far as I know…

Atfer poking around a bit more, perhaps my issue isn’t related to mixing other namespaces with Juce. However, I’m still having major issues. Perhaps it’s my error.

I’m assuming that typedefs like uint8 and uint16, etc. are intended to be publicly available since they’re used in public methods. However, the Mac is complaining about those being undefined. If I explicitly prepend them with the juce:: namespace they then compile. Oddly, others like int16 are fine regardless. Any ideas?

Yes, that’s just a symbol clash - some mac stuff uses the same tokens, so if you’re including mac headers you might need to use an explicit namespace like you said. (You might be able to get around it with a ‘using’ statement).

Ah yes. I see the duplicate def now in some mac framework. The using directive doesn’t seem to fix it, but at least its working now. Thanks.

Resuming this post because I enconuntered the same problem.

The offending typedef seems to be located in “cssmconfig.h”, which is a system file that gets somehow included (through a nested inclusion I didn’t dare to follow) within the CommonPluginHeaders.pch file, which is configured in the Mac target as the prefix header file for building RTAS plugins.

My question is: what about putting uint8, uint32 and the like among the #defines in juce.h for avoiding clashes with other types with the same name?

MemoryBlock, Component and some others are there already:

  /* On the Mac, these symbols are defined in the Mac libraries, so
     these macros make it easier to reference them without writing out
     the namespace every time.

     If you run into difficulties where these macros interfere with the contents
     of 3rd party header files, you may need to use the juce_WithoutMacros.h file - see
     the comments in that file for more information.
    #define Component       JUCE_NAMESPACE::Component
    #define MemoryBlock     JUCE_NAMESPACE::MemoryBlock
    #define Point           JUCE_NAMESPACE::Point
    #define Button          JUCE_NAMESPACE::Button

I think I seem to remember trying that before, but found that it caused other problems…

I see… how did you manage to safely use uint8 in your amalgamated version of JUCE when compiling the RTAS format, without adding JUCE_NAMESPACE:: ?

For example, the uint8 (without namespace prefix) is used within the Colour class for specifying colour components. By including JUCE in your own demo plugin, it should clash with the “system defined” uint8 since the “polluting” type gets included by the prefix header needed for the RTAS build…

Well using prefix headers is asking for trouble… The juce headers work well if you include them after system headers, but if you do it the other way round there’s no guarantee it’ll work.