Now that's 2017... are we dropping C++98?

@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 :slight_smile:

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 :slight_smile:

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 :slight_smile:

Ha, my commit history is littered with these too :joy: 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 :frowning:
  • 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.