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âŠ
2 Likes
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.
â
Roeland
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.
3 Likes
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.