On 22 May 2016, at 14:57, Norbert Wenzel
wrote: On 05/22/2016 09:53 AM, Rainer Deyke wrote:
On 19.05.2016 11:17, Niall Douglas wrote: The C++ 14 only libraries contributed to date are clearly written first for C++ not Boost. They are the future we should be proactively encouraging into a new clean ground up redesigned fork of Boost, a Boost 2.0, instead of corralling them into legacy and outdated packaging, build, design, documentation and idioms out of some misguided desire for serving the legacy Boost usership before that of the wider C++ community.
What percentage of "the entire C++ community" do you think has access to a C++ 14 compiler anyway?
[...] I'd love to switch to C++ 14, but right now it's just technically viable for me.
I have to agree with that. The company I work for builds devices that run C++ code and Desktop applications to control these devices. While I'm relatively free to use whatever compiler I want on the desktop side (as long as I provide an installable package to the customer, that runs on Windows Vista+) I cannot control what is available on the device. So I have to adapt to whatever compiler version the firmware team decided to provide. The most recent compiler they provide on one of our devices is GCC 4.8. I will have to support this compiler (even when writing new code that will be running on both, desktop machines and on the devices) for years to come.
As a side note, we have to support code written in Visual C++ 6.0, but these versions do not require any new Boost version, so this is not an issue. But of course we have VMs with such ancient compilers around and in use.
But any new library that requires C++14 is of no use to our company, as long as we cannot make sure the code will be running in our desktop applications only (which is the majority of newly written software in our company). And this will not change quickly. A new version of Boost that required C++14 for all their libraries would not be used, even though it might be faster, better tested and have a ton of other advantages. It would be easier to write/port some new code ourselves than to force a change of infrastructure to the entire company.
If the devices are network attached then this sounds like a great usecase for testing the beast http boost library? You could embed a little http server in the device that provided a REST API, ..control it with a browser on the desktop.