Pretty much what the title says. Over the past year I’ve gotten pretty comfortable with JUCE. I started as a pretty amateur programmer with no C++ knowledge, so before I even started JUCE I went and learned the C++ basics. But now that i’ve really only worked with JUCE in regards to C++, I’m wondering if I was to move outside of JUCE for some project would I be dead in the water or does the same concepts apply. My main concern is that I feel like JUCE has a lot of safeguards in place that as a newer programmer I take for granted, but I’m wondering if my assumption of this is wrong.
Also while we’re here, on a general programming basis, how do I go about self determining if I have clear “clean” code. I’m not in school or anything right now so I don’t have a way of someone saying “this is a mess”, or “you should do it like this instead.”. I know how my code works, but if someone else had to look at it I have no idea if they would think its a mess. And while the JUCE Forums are very helpful for small snippets of code, I wouldn’t expect anyone to peer review a whole project lol. How can I go about learning to assess if my code is clean and clear?
Tbh JUCE abstracts away a lot of the challenges in C++ programming (which is why it’s so awesome!) so there’s much, much more to learn once you step away from the cushyness of the framework. The challenges within the framework are more to do with the inherent difficulties of audio dsp programming in general (something SOUL seems it will awesomely solve!), not the C++ language itself.
That said it’s a great framework for easing oneself gently into the language and then stepping off from when you are ready. A next step a lot of audio dsp enthusiasts take, is embedded applications. You might look at finding some embedded environment you’d enjoy programming some audio solution for, where JUCE can’t (yet!) follow. This would have to be more bare metal than even Raspberry Pi, which runs a full OS and JUCE can actually build onto (esp v6).
Or if you wanted to do something in parallel with audio DSP, you might try graphics programming, which is also a pretty fun and rewarding area of programming that needs the performance of C++.
This is an incomplete answer, because I’m only a few steps ahead of you in terms of self development. But for the same reason, maybe it will be useful.
I found that learning JUCE initially held me back from learning STL. I was scared of using STL to begin with, because it’s huge and complicated and because the documentation is dense. So I would initially try to use JUCE classes for everything, because it felt easier. But this is definitely a mistake–there are tons of things that STL can do that JUCE can’t, and there are often very neat STL solutions to problems that would otherwise take lines and lines of ugly code.
I’m not a professional programmer, but I’m sure others will confirm that there is no substitute for learning STL, and that you shouldn’t neglect it while you’re focusing on JUCE.
Agreed. JUCE really does help learning C++ as it smooths off a lot of the rough edges. It also has some great levels of abstraction so you can get a lot done quickly with very little code. It’s also named extremely well and easy to read which can help you learn the structure of code.
Where it falls down is learning to think of things in terms of algorithms and using the STL for this. Many times I’ve written complex loops and logic to modify JUCE containers when a couple of lines of STL would have done.
This isn’t necessarily a bad thing. Learning the STL idioms is not the most intuitive thing and can make for difficult to read code. However, it doesn’t have to be that way and well structured code with good variable names and comments that uses the STL should still be understandable.
I know juce::Array can out perform std::vector in some situations and a lot of the JUCE containers were created before similar things were idiomatic in C++ (e.g. std::unique_ptr, std::shared_ptr didn’t use to exist hence the need for juce::OwnedArray and juce::ReferenceCountedArray) but these days I’d say stick to standard containers unless you know a juce::Array will be faster (and measure for performance differences).
