Are we finally getting to the point we will drop the ball convict of old compilers legacy C++98 support that is preventing juce to be the advanced framework we deserve or it will remain stuck in the nineties stink ?
3 Likes
The limiting factor is the need to build reasonably portable binaries on Linux. Unlike Windows and Mac OS, toolchains on Linux have no support for targeting older platforms at all. So if you want to compile a portable binary, you have to keep a really old distribution around, and that really old distribution will come with a really old compiler.
It may or may not be OK to require C++11 (since GCC 4.8 can be made to work on quite old distros), but anything later will definitely be problematic. When you’re compiling on Linux, 6 years old is called “the bleeding edge”.
Please not, there a lot of dependencies and legacy software products which need active support. Also I don’t see the point that the compatibility prohibit the use of advanced c++ features, which can be implemented optionally and can live in peacefully coexistence with existing code.
1 Like
super nice. let’s continue on the bleeding edge of terminally broken gcc versions only to support people still using ubuntu 12 
i have been using an old ubuntu 14 to compile decent binaries with a partially “broken” c++11 support (thanks to gcc 4.8 and 4.9) and got no complain so far, so i suppose that people is still using recent enough distros.
it seems it’s the same problem as the EOL windows xp, but musicians (and banking corporations!) still use that, and will for the future to come: so let’s make those people happy.
at least please ifdef a bunch of lambdas all over the place for the sake of my brain sanity when dealing with gui callbacks in the juce components.
Who moved my cheese ?
That’s to easy. I have the feeling what ever good arguments I will write, why it’s good to have an consistent abstraction layer, and that this is a very important feature in itself, you will come with your cheese argument after.
I would be very carefully about API changes.
it’s good to be consistent, i’m not saying we need to rewrite everything from scratch using variadic templates and tuples. but roli should consider leveraging the usage of lambdas throughout the library, as i saw some movement in that direction lately: one patch of mine has been merged after 7 or 8 months, and there are new patches around to simplify the api with backward compatible ifdeffed lambdas. if we are not ready to jump in, then at least allow some of us to move forward. consistently, not small bits here and there.
@kraken The main issue is with companies running entreprise level distributions, like Redhat and CentOS. These can be many years behind the more customer-oriented distros like Ubuntu. And old versions are supported for ages. At present the most recent version of glibc you can target without too much compatibility issues is 2.12. Compiling on Ubuntu 14 → not a chance for at least another couple of years. At least these days you can upgrade GCC to 4.8 . We were stuck, as late as 2016, with GCC 4.1, with no C++0x support at all.
On Windows this point is moot, because Windows supports targeting older versions. You can run the latest Visual Studio 2017 on the latest Windows 10, and still compile a binary which will run on Windows versions all the way back to Windows XP.
I am in full agreement with @kraken, I think there’s a lot of places JUCE could be taking advantage of C++11 to either expand functionality and/or simplify its guts via features like lambdas and new STL objects (looking at you, ReferenceCountedObject).
For people targeting ancient OSes and compilers which require C++98, they have JUCE 3.x and 4.x (likely with perpetual licenses already) which have tons of features for making just about any application imaginable.
There have been a few times now where the JUCE team seems to have implicitly stated that the main force behind major JUCE features is to fulfill the needs of ROLI first (anecdotal evidence by the number of feature request posts that are answered with either “added to backlog” vs “we need this too, we’ll add it”), and they’re a company making products for musicians, not Redhat workstations.
I’m curious as to what the JUCE team is planning for the future.
1 Like
i don’t see juce as the tool for making enterprise applications, i hardly see the need of having fancy audio features and gui components on distros that still have Tk as the main development framework. i doubt those “enterprise apps” are even sold, so they are used internally and not paying roli a cent.
if you desperately need that you can still use the current juce 4. but i would expect juce 5 to move forward.
Kraken’s comments in this thread pretty much sum up our opinion!
We need to move on, it’d be ridiculous if JUCE 5 didn’t move to C++11. Only a really really small minority of our users are still using older tools, and they don’t have to upgrade yet if they don’t want to.
We’ve avoided updating for a long time already, and the industry as a whole has moved on, I think even Qt started mandating C++11 before we did. Resistance is useless!
6 Likes
@kraken Yes, JUCE is indeed not geared towards writing enterprise software. But I’m not talking about that, I’m talking about the OS people may be using.
The typical use case of JUCE is write software which users can download or buy and run on their own computers. In that case you need it to run on a wide variety of platforms. If you have any users using your software at work, there’s a good chance they’re using a distribution like Redhat, openSUSE, or CentOS. These tend to use quite old but well-tested versions of various software libraries, mainly to avoid breaking stuff every other update.
Actually, the really hard case is when you’re writing a plug-in. Then, if you don’t use that ancient toolchain, your plug-in will simply fail to link to the host application. Game over. And there’s a lot of people on this forum writing plug-ins.
The industry has moved on, but only slightly. Qt lists openSUSE 13.1 (64-bit) with GCC 4.8.1 as a supported platform on Linux. That seems to be a common baseline at the moment.
So we are pretty much ahead of the industry. C++11 support in gcc 4.8, even if broken in some parts (bad reentrant mutexes implementation for example) it is nearly complete https://gcc.gnu.org/gcc-4.8/cxx0x_status.html
And i don’t know any multimedia user using a distro any older than rhes6. Going older you don’t even find support for xorg drivers with decent vsync.
You will be happy with juce 4.x
Resistance is futile
I guess that one uses glibc version 2.12. As I said above, that’s the baseline these days. So GCC 4.8 it will be.
nothing prevents upgrading glibc even in rhes6 to a more recent one.
again, you will be happy with 4.x for years to come.
Its needs only one OS update (apple), that makes an old (non-supported) JUCE-version broken for active development. (Because the software should of cause also compatible to current OS)
I wouldn’t rely on that.
Than the developer is caught in a trap, if there is no easy upgrade path, which may introduced bugs (which can be also in new juce code)
These are practical problems, not theoretical.
I see, a smooth transition to new c++ features is much more extensive, and i can understand jules. But thats the “no-fun” part of developing a framework (like testing etc.). But its worthy.
Most important features of a multi-platform framework for me is
- stability (zero bugs)
- reliability (consistent api, no undefined behavior, which is the reason of vulnerability)
Vive la résistance
2 Likes
But somebody please tell Travis CI to add C++11 support to their build servers 
I have to #ifdef-out every regex function to get CI for my project and when JUCE makes this step I am out of luck there…
Shouldn’t be the only reason to stay on ancient C++98 though
what’s the problem? been using it without any hassle. yes you need to tinker a bit and some trial and error too but it’s definately possible.
take a look here, you will find some tips to get started http://genbattle.bitbucket.org/blog/2016/01/17/c++-travis-ci/
or jenkins up your life
@kraken is right. You should be able to use C++11 code with Travis CI without having to modify any of your JUCE source. I did myself a few days ago. Travis is passing ever since.
Somehow the libstdc++ library was throwing some linker errors and I got tired of polluting my commit history with “one last fix for Travis CI” commits so I might have not gotten to the root of the problem.
But back to topic since this is not a showstopper then