Reference to 'AudioBuffer' is Ambiguous: OS X 10.9


#1

I'm building my project on a computer running 10.9.5.  here's the error message I get when I try to compile:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreAudio.framework/Headers/CoreAudioTypes.h:147:16: Reference to 'AudioBuffer' is ambiguous

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreAudio.framework/Headers/CoreAudioTypes.h:141:8: Candidate found by name lookup is 'AudioBuffer'

//Line 141 in CoreAudioTypes.h
struct AudioBuffer
{
    UInt32  mNumberChannels;
    UInt32  mDataByteSize;
    void*   mData;
};

typedef struct AudioBuffer  AudioBuffer;

/Volumes/Thunderbay/MyBook2/Dropbox/CharlesShared/JUCE-4.1.0/modules/juce_audio_basics/buffers/juce_AudioSampleBuffer.h:36:7: Candidate found by name lookup is 'juce::AudioBuffer'

template <typename Type>

class AudioBuffer
{
public:
    //==============================================================================
    /** Creates an empty buffer with 0 channels and 0 length. */
    AudioBuffer() noexcept
       : numChannels (0), size (0), allocatedBytes (0),
         channels (static_cast<Type**> (preallocatedChannelSpace)),
         isClear (false)
    {
    }

 

I can't really change the OS X 10.9 header files, and you guys renamed your AudioSampleBuffer class to the name of an OS X 10.9SDK Type, so...

 

Any suggestions?  

I'm including <AudioToolbox/AudioToolbox.h> in my project, and that's what is causing this error.   


#2

Just include the Apple header before the juce headers.

It's good C++ style to choose the best name for something without worrying about name-clashes. That's why we have namespaces.

Unfortunately the Apple headers are C, not C++, so aren't namespace-aware and will splurge all their symbols across the global namespace, so it's usually best to include all your C code before your C++, to avoid this kind of clash.


#3

Unfortunately that doesn't fix it.   that results in about 20 semantic errors of stuff like:

Use of undeclared identifier 'kAudioHardwarePropertyDefaultSystemOutputDevice'

 

The only reason I have to use this AudioToolbox is because of the errors/bug fixes explained in the following post, which were never added into JUCE.  If you guys update your AudioDeviceManager class, this problem will go away. 

http://www.juce.com/forum/topic/getting-systems-default-audio-device?page=1#comment-319000


#4

Yes, we saw that other post and will look at it.

If you got an error, then it's because of where you're including that file.

You can safely include AudioToolbox.h or anything else you like at the start of your own compile-units before incuding the juce headers, and it'll be fine because none of our headers use any Apple symbols at all.

If you got a problem with a symbol like you say here, then you must have somehow got that include file pulled into the juce module compile-units. And obviously we can't write all our internal code in a way that will magically cope with having random 3rd party headers pulled into them,


#5

ok.   I wouldn't consider Apple's AudioToolBox header files as 'third party' tho.   they're pretty intrinsic to the operating system..  I'll dig some more, but I didn't have this problem with JUCE 3.2.  this only appeared after I upgraded to juce 4.1


#6

ok, so what I've narrowed it down to is that the JUCE_MAC macro is what stops it from working.

What changed in v4.1.0 that makes it so I have to include AudioToolbox/AudioToolbox.h before JuceHeaders.h?

I didn't have to do that in 3.2.0

 

my main.cpp includes look like this:

#include "../JuceLibraryCode/JuceHeader.h" 
#include "MainComponent.h" 
#include "MacAudioUtilities.h"

Here's what i've tested inside MacAudioUtilities.h:

Juce 4.1.0: this results in about 20 errors.  Juce 3.2.0:  this results in 0 errors

#ifdef JUCE_MAC
    #include <AudioToolbox/AudioToolbox.h>
#endif

#include "../JuceLibraryCode/JuceHeader.h"

 

Juce 4.1.0:  this results in 2 errors (the AudioBuffer Is Ambiguous error).  Juce 3.2.0: this results in 0 errors

#include "../JuceLibraryCode/JuceHeader.h"

#ifdef JUCE_MAC
    #include <AudioToolbox/AudioToolbox.h>
#endif

 

 


#7

I am discovering that I need to just remove the #ifdef JUCE_MAC #endif compiler directives and it will compile in 4.1.0.   and if I'm trying to build for windows, just don't #include "MacAudioUtilities.h"

 

But I still don't understand what changed from Juce 3.2.0 to 4.1.0 that caused this, other than that you changed the AudioSampleBuffer class to be called "AudioBuffer".


#8

But I still don't understand what changed from Juce 3.2.0 to 4.1.0 that caused this, other than that you changed the AudioSampleBuffer class to be called "AudioBuffer".

Yep, well, that's probably it. Can't think of any other change in JUCE 4 that would be relevant.

I am discovering that I need to just remove the #ifdef JUCE_MAC #endif compiler directives and it will compile

That's because the #ifdef JUCE_MAC will only be defined *after* you include JuceHeader.h, not before. So it seems you're just using that macro in a wrong way, it won't work in the way you use it above.

If you simply include AudioToolbox.h before JuceHeader.h (just as Jules suggested!) then it works, right?


#9

Can you guys change it back?   Everything worked fine until you changed that name which conflicts with Apple's C Headers.  


#10

No, we can't, sorry.

The reason we had to rename AudioSampleBuffer is that we introduced 64-bit audio processing and therefore replaced the AudioSampleBuffer class with a class a template: AudioBuffer<float> for 32-bit and AudioBuffer<double> for 64-bit. The only way to do this without breaking people's code was a new class name, and AudioBuffer seemed nice.

Why doesn't it work for you? It's just a matter of including the right things at the right place. I am sure there are a lot of 3rd party libraries out there which use the same class names as some JUCE classes! How can we possibly prevent that? As long as those 3rd party classes are not used in JUCE itself (like in this case), there should be always a way to prevent a name clash in your code, as Jules pointed out already.

What about this question from my last post:

If you simply include AudioToolbox.h before JuceHeader.h (just as Jules suggested!) then it works, right?


#11

AudioSampleBufferTemplate.....  just sayin' lol

 

those 3rd party classes are C++, not C.   you guys chose the name of an Apple C library for your rewritten C++ class.  

 

I got it working.  but I miss being able to surround "#include AudioToolbox.h" inside a "#ifdef JUCE_MAC #endif" when i try to compile on windows.