Ha, my commit history is littered with these too But thankfully it’s done now. Now I’m waiting on a coverity scan to tell me what a bad programmer I am!
We (esp plugin/audio devs) live in a complicated environment. For example:
- User buys an awesome new plugin, “The Awesomizer”.
- On his studio machine he finds that it doesn’t work.
- He contacts awesomizer’s support and they tell him to update his DAW.
- With the updated DAW the awesomizer works!
- But, he finds that his beloved old plug-in “Insanitizer”, from a different company, has stopped working
- He contacts insanitizer’s support and they do have an updated version to work around a bug introduced in the DAW’s update.
- He download’s insanitizer’s update but finds that it doesn’t work on his old system. It doesn’t work because the framework that insanitizer’s developer uses dropped support for his old system, and the devs couldn’t just stay with an old version of the framework because other users need the updates for new OSes and DAWs…
if you take out old enterprise linux systems, adding c++11 support to juce isn’t going to make things worse for the plugin / daw world in that regard.
With enterprise distributions , having old versions around is a feature, not a bug. You can install that on your computers and you have some assurance that it will be supported on your hardware for a while. RHEL6 (which I think is defining the baseline at the moment) will be around for another couple of years. Any big software vendor will make sure that their software works on these systems, and if you write a plug-in for that software you’re tied to the same old toolchains they’re using.
In other words the “resistance” is most of the software industry. Dropping support for those old distributions is not an option.
So what I expect will happen is that JUCE will follow that industry: it will bump the minimum GCC version to 4.8 (which supports most of C++11). That’s old enough to still support these old enterprise distributions (like RHEL6), but not too ancient.
after roli acquisition i see juce currently following win and mac for desktop/daw/plugin development and ios and android for the mobile, the only linux niche i could see it to follow is the embedded industry rather than the enterprise you talk about.
I’m talking about the enterprise level Linux distros, not about writing enterprise software myself. If you release software, at least some folks will end up running it on these distros.
You kind of implied you know multimedia users using RHEL6. You can always ask them why they use such old distros.
because some strange enterprise level autodesk software was not even installing on other distros, and the studio needed some workstations with this software installed. not because of plugin compatibility problems. not talking about the normal indie music artist.
probably now that software installs on newer release of the rhes, so they could have upgraded their systems as we speak. industry is moving forward, as the users.
Another thing to bring up… would a move to C++11 also mean that types like String/Array/every other JUCE container will finally return a proper size_t instead of int?
Yep, that’s a good point, we could probably make that change now anyway.
By “old VS Compiler” you mean VS2005 I guess… Or is this problem also relevant for VS2008? And while we’re at it… do you even still support VS2005? I think that is no longer needed (don’t want to make anybody angry though). I just ask because every now and then I find in the juce code some comments complaining about “idiotic VS2005 bug” as they say…
We’ve generally left support for VS2005 in there when it’s not causing any problems, just because even if there are only a tiny number of people using it, there’s no reason to annoy them if we can help it.
The move to C++11 is really the first big change that means we need to drop some older compilers, but yes, I doubt whether many (or hopefully any) of our users are still on 2005 or 2008. I suspect most people are on 2015 with a few still on 2012.