Juce classes vrs c++ std

Hi folks,

I'm new to Juce and I've been reading through the headers trying to learn what is available to me. I am struck by the number of classes that seem to reproduce functionality that already exists in either std:: or boost. 

I don't mean to malign the juce classes, and they look like good code - undoubtably better than I would write myself - but I don't understand why I would use them. juce_string and juce_array are good examples of classes that don't seem to provide an obvious (to me) benefit.

But, with all that said I bet that there are some good answers to my questions. Is there anywhere where someone has made the case for using juce classes for things like collections and pointers? I searched these forums but was unable to find anything addressing this topic.

Also, I created a stack overflow question on the same topic but didn't get many bites. If anyone feels inclined to answer this question there that would be cool.


Finally, please let me reiterate -- I am not here to knock Juce... I just don't get it and I would like some illumination.




1 Like

I posted a similar topic a while back and there was quite a few replies that might be of use to you. A lot of the classes seem to be from before there were Standard Library equivalents.

Choosing things from JUCE over Standard Library (or vice versa)

1 Like

TL;DR for this question:

Yes, JUCE was written way back in the old days, when the standard containers were really unsatisfactory, and most libraries rolled their own container classes.

Since C++11 became a thing, our advice is that if you can use the new standard, then you should prefer things like std::unique_ptr, std::vector, std::array, etc. The JUCE equivalent classes do their best given the contraints of c++98, and some people will probably always prefer them for various reasons, but the new standard library is probably a better choice in the long-term.

isn't the lazy answer that you don't need to bother with including the std library in your header if you use the juce objects?

I also started to use the std:: library more and in all the new code i write. There are quite some classes that might be redundant now but if you think the std::string class lives up to the juce_String class you might be fooling yourself though. 
The way it handles the different UTF formats is really helpfull and of course all the string formatting methods right at your fingertips make the Juce String class really nice. It's not the fastest but i think the most feature complete class of Juce. 
And of course when all the other classes (especially GUI) rely quite heavy on the String class.


Yes, std::string hasn't really changed since C++98, and has a lot of design flaws. juce::String FTW!

One thing I have come to find over many years is that the so called standards change and break your code.  The reason is simple: the standards people do not actually use the stuff they foist on us.


I bet the Juce stuff is in daily use by the Juce team and any attempt to change it is met with a massive number of errors if not done properly.  This pretty well means the Juce headers will work and the standard headers might or might not.

Well, yes, I hope that our headers work! It's true that we use it every day here at ROLI, and whenever we change something, the first concern is always not breaking anything for anybody.

That being said, I'd be curious to know how the C++ standard can break your code?

I wasn't specifically speaking about the C++ standard.  I am new to C++ so have no long term background.  I have, though, used many other things that were "Standards" and when they change their so called standard you have a lot of work to comply with the new standard.

As I said, the Juce developers use Juce, so if they change something that breaks ALL of their code, you can bet it gets fixed or reverted.,  The end users will never be aware of the sidestep.

Backwards compatability is a huge deal to the standards committee from what I understand. Even if there are new ways to do something, you could anyways use the old way because it'll always stick around. Plus, the Standard Library and its implementations get tested by a lot of people and any bugs will probably be fixed quickly. I don't think you'll really need to worry about the Standard Library breaking your code. If it's in the standards, the general consensus is to use it. There's of course always exceptions. 

“… if they change something that breaks ALL of their code, you can bet it gets fixed or reverted.”

But what really matters is what’s happen if they change something in their code that breaks your code.

JUCE was a nice workaround for users sticked to C++98. C++11 will be required also there, so i don’t see any reason to not use the std library as much as possible.

Think about the huge pain the day when you will need to refactoring large part of your code to remove that dependency (for whatever reason you can not know for now, an extra charge for instance).

OK, I see the light.  As I said I am new to C++ so have no idea on the track record.  My main observations come from Linux where things change and you always seem to be editing "good" code that now does not compile or link into the "new and improved" kernel, memory manager, etc.

By using the standards in C++, whether old or new, it will make my code much more portable.  That removes dependencies on a particular library that "might" not always be available or maybe gets changed to better support some in-house uses.

Programmers want stability so they can move their code forward and not have to be sidestepping all the time.  It wastes mental energy to re-code something only to have it do the same as before.

Just chiming in for another comment:

Yes, nowadays the evolution of the C++ standard works very well and the committee takes great care not to break anything. This is what we do, too, but consider this:  Behind JUCE, there is Jules, the JUCE team, the other ROLI devs, and the JUCE community (= you guys). Behind the C++ standard, you have all the huge compiler vendors, Microsoft, Apple, Google, IBM, etc. So you can be pretty damn sure that the C++ standard is not broken! (There might be the occasional compiler bug but that is very rare in practice: I encounter maybe one of them per year or so.) The days where you couldn't rely on it are definitely over.

So my personal advice is: use JUCE for everything it was designed to do; use the C++ standard for all the generic stuff. Use the STL containers and algorithms, use std::unique_ptr/std::shared_ptr for your smart pointers, use std::atomic for lock-free programming, etc. etc. Consider also that there is already a huge amount of literature about the C++11/14 standard library.

Also, here in the JUCE team it is very much one of the goals for the future to bring JUCE and modern C++11/14/17 closer together. We definitely won't keep using C++98 forever, so I would definitely not see JUCE as a "nice workaround for users sticked to C++98" as someone commented. It's really not what it is or aims to be.