JUCE 6: why is a new default plugin project requiring "juce::" in front of everything?

[pflugshaupt]

I now completed upgrading my entire codebase to finally deal correctly with namespaces and in the process of going through six years worth of code that interfaces with JUCE I repeatedly came across some JUCE nasties that would be great if at least they could be deprecated - if not removed. Stuff that copies functionality that is now available in the std namespace and things that smell like c++ from the 90’s.

1. jassert(). It should not be a macro, but a function and be inside the juce:: namespace. Compilers are smart enough to remove the call to an empty function for release builds.
2. jmin()/jmax(). Please move to std::min and std::max
3. jlimit(). std::clamp should be enforced.
4. Macros in general. It’s a drag there are still so many macros in the JUCE codebase. The fewer the better. Some stuff could be const in a global namespace and other stuff should just disappear for good (f.i. forEachXmlChildElement… ). - not that I ever used that. I guess there’s a reason XCode uses a brown color for macros .

P.S.: jmap could also go as there is std::lerp in C++20.

[anthony-nicholls]

@pflugshaupt

1. jassert(). It should not be a macro, but a function and be inside the juce:: namespace. Compilers are smart enough to remove the call to an empty function for release builds.

Wouldn’t it be annoying when the break point is hit you have to go up the stack to find out where it really hit?

@pflugshaupt

2. jmin()/jmax(). Please move to std::min and std::max
3. jlimit(). std::clamp should be enforced.
   …
   P.S.: jmap could also go as there is std::lerp in C++20.

JUCE (as fas as I’m aware) still supports C++11. std::min/std::max are C++14, std::clamp C++17, and as you say std::lerp is C++20

@pflugshaupt

4. Macros in general. It’s a drag there are still so many macros in the JUCE codebase. The fewer the better. Some stuff could be const in a global namespace and other stuff should just disappear for good (f.i. forEachXmlChildElement… ). - not that I ever used that. I guess there’s a reason XCode uses a brown color for macros .

I think we all want less macros but I happen to think the JUCE framework is pretty decent with them (most are at least prefixed with JUCE_). Although I agree the forEachXml… variants could probably be replaced with something much nicer, however I feel for the team because they would have to be careful due to the fact that such a change will be a breaking one.

[pflugshaupt]

@anthony-nicholls

JUCE (as fas as I’m aware) still supports C++11. std::min/std::max are C++14, std::clamp C++17, and as you say std::lerp is C++20

Yes, but just as with std::function, JUCE could provide it’s own std::min/max/clamp/lerp until people move to newer C++ revisions.

[anthony-nicholls]

Yeah fair point didn’t think of that. I guess they would have the keep jmin/jmax/jlimit/jmap for some time for backwards compatibility, but they could potentially just be forwarded onto the equivalent STL functions.

[daniel]

I am missing the jmap with a target and source range in std::lerp though, unless I am missing something.

[RolandMR]

jmin and jmax are nice because they take more than 2 parameters. I wish std::min and std::max did that.

Does Xcode have std::lerp yet?

[pflugshaupt]

@RolandMR

jmin and jmax are nice because they take more than 2 parameters. I wish std::min and std::max did that.

std::min and std::max do that using the initializer list syntax.

std::min({a,b,c,d});