Avoid function name collision with Objective-C?

I have a big C library (C++ compilable) that i try to use as a JUCE Module.
(It is my fork of Pure Data).
There is a function called “class_addMethod” in it.
It compiles fine but the JUCE application crash.
My function is called instead of the Objective-C’s one here in juce_osx_ObjCHelpers.h.
I put all my C code inside its own namespace.
But it does nothing. Crash again.
Notice that renaming my function is a solution.

Is there a better way to avoid such (silent :scream:) name collisions (instead of renaming everything :crazy_face:)?

If you’re building the file containing the duplicate class_addMethod as C, or declaring that function extern "C" then adding a namespace won’t affect the names of the generated symbols. However, if you’re able to build that code as C++ without extern "C" then I’d expect adding a namespace would resolve the symbol collision. Other than that, renaming the offending function is probably the best option.

I can’t think of a great way to avoid collisions such as this if you must stick to plain C. In “Large-Scale C++ Volume 1” by John Lakos, the author recommends to prepend the package name (normally four characters) to the beginning of each C function name. While this approach would force you to rename every function in the library, you’d be practically guaranteed to avoid naming collisions this way.

1 Like

Yep, the class_addMethod is "extern C" (since it is required to be called from plugins). I’ll make a test ASAP to see if only such "extern C" are subject to collide (as you suggested). In that case only a tiny subset of the functions would have to be renamed (otherwise i have to prepend the name of thousands of functions…). The fact that the collide is silent (no compilation error neither warning) is really weird and naughty. Anyway thanks for the reply.

I confirm that (at least with the current config) it works fine when class_addMethod is not “extern C” (thus properly namespaced).