String "+" ambiguity error when builting RTAS

Trying to get an RTAS build on the Mac, I encountered this strange error:

MyHeader.h:120: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: note: candidate 1: juce::String juce::operator+(juce::String, const char*) note: candidate 2: operator+(int, char*) <built-in>

It is the only error left in the project. It occurs 240 times, always complaining this ambiguity between a built-in “+” operator and the juce::String “+” operator. This does not happen with any of my other projects, so I wonder where the bad side-effect might be hidden, or if I overlooked some compiler option that could fix this.

Any ideas?

(JUCE v1.54.27)

You’re obviously attempting to write something like 123 + “xyz” and expecting it to produce a String object - obviously that’s going to be ambiguous for the compiler, you’d need to write String (123) + “xyz” to disambiguate it.

Erm, the errors all occur in the Juce code, not in mine.

The typical pattern is “Quoted text” + String, where the quoted text always comes first. There are many uses of this pattern in the Juce library and it normally compiles fine. It seems some code in the PT_80_SDK messes with the operator somehow, causing the precedence to change?

Really strange.

but your original post says the error is in “MyHeader.h”, line 120.

Yes, MyHeader.h includes JuceHeader.h. I replaced the filename by something generic here.

I checked again and the errors do indeed occur everywhere, both in the Juce library and in my code. I grabbed a few code snippets that failed:

[code]return String ((int) commandID) + “_id”;

return categoryName + “_cat”;

desc.containsWholeWordIgnoreCase (“f” + String (i))

if (identifierString.startsWith (thisId + “/”)) …

return s + “/” + getUniqueName().replaceCharacter (’/’, ‘\’);[/code]

Well, there’s nothing wrong with any of that code… I’m really not sure what could have been included that would have that effect, I’m afraid! But yes, it does sound like something in the RTAS headers is causing the problem.

The second candidate mentioned by the message is described as . That does not seem to be something that could have been added by the RTAS files, but honestly, I am just guessing now.

Could it be this is due to a compiler option? Language setting?

As others have successfully built RTAS plugins, the issue must be somewhere in the way I am including the JuceHeader and my files. I will investigate this further and report back.

Could be some kind of pragma, I guess…

BTW: Same errors with the JuceDemoPlugin when building RTAS.

This is how I modified a copy of the demo plugin project: Removed the AU and VST wrappers, copied the RTAS wrapper from a freshly Introjuced RTAS plugin project. Changed the VST/AU/RTAS flags in the plugin characteristics to only RTAS. Included the xcconfig files from the PT SDK.

Has anyone else managed to build a “demo” RTAS plugin and is willing to share it?

Just use the introjucer to create your project - it’ll set-up all that stuff for you. Doing it manually is just asking for trouble.

Yeah. I now built a blank Introjucer project and copied the XCode settings over to mine and it compiles fine now.

I should note that I ditched all the Digidesign definitions (those xcconfig files) and just copied the include paths and library paths from the Introjucer template and otherwise kept my own settings.

As I didn’t change anything else, the cause for the above error must lie somewhere in the xcconfig supplied by Digidesign. That’s really weird. At least it is clear now that “just make your config based on the Digidesign supplied xcconfig” does not seem to work.

I still have to test my build with a PT installation, though. Probably I will have to pick one or more of their settings and add it to mine. Anyway, I am glad I get a clean compile now!

Thanks for your patience, as always.

I ran into this a while ago, it is a compiler setting to do with if strings are read only or not in gcc.

“Make Strings Read-Only” needs to be checked as shown in the screenshot.

Ah , thanks. That’s exactly the detail I was wondering about. Obviously the default ProTools SDK project options include this switch, so it is not wise to just include them as a whole, but rather do some cherry picking (if at all).