Hi, getting this since pulling latest today:
Reference to Point is ambiguous
That is probably a duplicate of this thread:
TL;DR it is fixed on develop
EDIT: sorry, I cannot readā¦ you said you are using ādev tipā
yes, using dev - not fixed thereā¦
Iām on XCode 11.2, which seems to be the latest available on Mohave
Please can you include the full error text so that I can see where the issue is coming from?
Also, are you able to repro this on any of the example projects, or does this only happen in your own code?
that is all the text, in the image.
iāll try some example projects.
hi, ok so demorunner builds ok.
so it must be my projects.
any ideas? all I did was pull the latestā¦
I had this too. Some new Apple library seems to have a Point class as well. I now use juce::Point instead of Point. This works fine.
i donāt actually directly use the Point class in any of my code so Iāve got none to change to juce::Point.
Ah, maybe there was even a juce class, where I had to change it. Sorry, I canāt look this up, now. But youāre right this is not niceā¦
This is why I always set the DONT_SET_USING_JUCE_NAMESPACE macro in my projects.
āusing namespaceā should be banned.
For future reference, you can view the logs in a bigger window by clicking the āspeech bubbleā button in the left toolbar (this is what it looks like with an artificial error):
Then, if you click the ālinesā button on the right, you can see the full compiler invocation, and all the command output, in a selectable/copyable view.
To fix your problem, look for any places in your code where youāre including Mac framework headers, or other third-party headers before JuceHeader.h, and make sure JuceHeader.h is included first. If changing the include order doesnāt work, just add a juce:: prefix to all the Point uses that the compiler complains about.
As @masshacker said, if you have some free time and want to avoid this kind of thing in the future, set DONT_SET_USING_JUCE_NAMESPACE=1 in the preprocessor defs of your project and add explicit juce:: namespaces everywhere.
adding JuceHeader.h everywhere where thereās a problem doesnāt work:
Not sure where I can change Point to juce::Point as this is just doing header preprocessing that causes the problemā¦
My best guess is that thereās a using namespace juce; somewhere before the include of CoreMidi.h, perhaps in lmh_audio_app.h, lmh_midi.h, or lmh_Processor.h. You could try grepping for using namespace juce in your custom modules and remove any uses that occur at global scope in headers.
ok, so I have a number of āusing namespace directivesā in my module header files.
So I should remove from the module header file and then go and individually add to every single header file I have? Thatās obv alot of work so just want to make sure that thatās what youāre suggesting?
Yep, the most robust solution would be to remove using namespace juce from your module (or other) headers, and then to explicitly qualify any functions/types from juce headers with juce::.
It might also be that itās possible to āfixā this issue by adjusting your include order, so that CoreMIDI.h is included before any using namespace juce uses. This is not such great practice though, and if Apple or other third-party libraries add more identifiers at global scope in other headers, you might run into the same situation again.
Using using namespace before an #include will always lead to pain, and you should definitely avoid doing that. Relevant Core Guidelines rule here.
ok, just so Iām getting this right, from now on I have to qualify every use of any juce class with juce::, so I canāt write String anymore, I have to write juce::String everywhereā¦???
Thatās the best approach. Itās what I do in my non-juce projects.
But like Reuben said: the problem is that youāve got a using namespace followed by including some random system header. Thatās never going to be safe. If you really really have to use using namespace then it MUST only be followed by your own code, and not by other 3rd party code that it could easily screw up.
And itās not really possible to do this in a module header, because the modules get included in an unknown order in JuceHeader.h, and using statements in one module header might āleakā and adversely affect the following headers.
So yeah, avoid using namespace in module headers.
what do you mean by non-juce projected? anything that isnāt core juce?
so any project I do is a non-juce project, and every time i ever use a juce class, enumeration or anything i need write an extra 6 characters of juce:: onto everything ? i thought namespaces were supposed to help use reduce the amount of typing we do as well as partition spaces, not cause us to write extra characters everytime we wanāt to use anythingā¦