The boost implementation is certainly showing its age at this point, as is mpl, now we have variadic templates.
Are there any C++14 variant implementations compatible with boost::variant and std::variant which are based on variadic templates? I'd love to move to a more modern implementation if possible.
Well, there is progress on all features, yet nothing is ready to go into C++17.
So either we get no new standard at all, or we get a Standard without the large features.
Also C++14 was a step forward, generic lambdas are a step forward (boost::hana is based on this, and brings though compile times down), I expect similar language features in C++17, that ease the programming and will bring new innovations to C++.
Your boost argument is only valid for library features. Modules or concepts can never be a part of boost in the way they are in the TS.
> So either we get no new standard at all, or we get a Standard without the large features.
No new standard then. The C++ compilers, standard libraries and the ecosystem have barely caught up with C++11, and C++ 17 was now on the horizon. If it doesn't bring much benefit, then it really cannot justify the compatibility nightmares. I for one will skip it.
> Your boost argument is only valid for library features.
That is exactly the point. Library features are not exciting as they can be implemented just fine and better by third parties. Therefore a C++ standard with only library features are hardly useful at all.
>Probably as many millions of lines the C++ standard will use, since its based on boost::filesystem.
Not necessarily. A lot of boost contains workarounds for compilers that don't support certain features. Since the standard library will be expected to be used with a known compiler (or at least a new-ish compiler), it doesn't need workarounds for missing C++11 support, etc.
The biggest problem with Boost isn't simply the number of headers - it's maintaining the built libraries against your compiler.
"Let's upgrade to MSVC 2015!"
"Oh nuts, our code now links against msvcrtp13.dll and our built boost_filesystem.dll still links against msvcrtp12.dll. Time to rebuild all of our libraries!"
This is especially bad on Windows where MS's dev tools team just didn't 'get' that developers just don't care about new CRT optimizations if it means rebuilding all of our 3rd party libraries. But even on OSX there's been the whole libstdc++/libc++ pain.
Anything that can get folded into the standard library and maintained by the same jokers who rev msvcrt*.dll every couple of years (rub their noses in their own mess) is good.
C++ did that in the 2000's, in that time there wasn't much news about standardization, because of this C++ was seen as legacy, people moved to other languages. The new languages such as Rust, Go etc. are also a result of this.
The C++ committee has now a process of ongoing standardization established, which will improve the language further, and make it easier and more efficient to write C++. Also, the standards are usually backward compatible for at least 2 standards. What gets removed is often obscure features like auto_ptr, random_shuffle etc. which are superseeded by better alternatives. Clang modernize can even get your code base automatically updated to a new standard.
I know, that some of you are left behind, as you are stuck with the traditional "almost never update the toolchain" model, but clang and other tools are such a leap forward, that this is not a model for the future anymore.
So, C++ ecosystem evolves to become better, and make you as a programmer more productive and lets you write easier and safer code.
While I appreciate the effort to make things easier, as someone who is trying to move from C++98 to C++11, I'm not sure the new features make the language easier to use so long as you still have to learn the old ways of doing things. Speaking for myself, at least, this just causes interference between competing habits. What would be better for me and maybe others, would be if some of the unsafe or deprecated features in C++ were disallowed or if there were a compiler option to disallow them. I know this would break C89 compatibility but so what if you know you only care about the newer and more efficient features of C++?
If you can, go for C++14 directly, it offers improvements over C++11.
Language features that ease your daily working with C++11/14:
- Lambdas, especially when working with <algorithm>
- ranged for loop
- auto instead of typing long types
- variadic templates increase compilation speed over the previous macro based simulation of this feature.
- the basic support for multithreading which std::thread & co offer.
And also, as always in C++: you only pay for what you use. You still can write code in old styles pretty well with C++14, same will be true for coming standards.
Agreed. Auto looks like a useless bit of syntatic sugar, but it can make working with the standard library (and its impenetrable iterator classes) a whole lot simpler. On top of that, boost has some nice features that make easy-but-annoying tasks like walking a file system and parsing program options easy.
If your last exposure to C++ featured nothing but raw pointers, you should really give it a second look.
Well, that has been done for decades. You just need to link your code with the correct libraries.
Its probably a bit easier with C as it has a common ABI, and C# as it only has one tool chain, and not multiple toolchains from multiple vendors like C++.
I believe maxxxxx is asking about the ability to import and use classes from a DLL directly, without needing a class definition. As far as I know, in standard C++ this isn't possible.
This is the one thing I really like about .NET. C++ would be so much more accessible to beginners if it was easier to integrate other libraries. Even integrating something as common as boost is quite hard with Visual Studio on Windows.
A C++ implementation could provide translated units which encapsulate not only compiled code, but also contain compiled class declarations, such that these units can just be used without any preprocessing, tokenizing or parsing. That would be outside the language.
The C++ language as it stands is defined in terms of a textual representation: everything proceeds from translation units being scanned into preprocessing tokens and so forth.
To use a compiled class declaration, you would still need to see the source code somewhere, in some form, in some documentation. Otherwise, how would you know that the frobozz class has a freakout method which accepts two int parameters.
About the last bit, a long time ago I would use the ctypes library in Python to inspect, list, and call functions defined in .DLLs. All the symbol exports are right there in the object file, so for non-C++ callers you don't exactly need the source code to call functions. It doesn't seem like a large stretch to ask whether the same thing can be done with classes, or to expect that this particular aspect would have changed sometime in three iterations of the standard.
ACCU - https://conference.accu.org/site/index.html
Meeting C++ - https://meetingcpp.com (9-11. Nov) not yet announced
ADC - https://adcpp.de/2017/
code::dive (not yet announced) https://codedive.pl/pl/index/
NDC Oslo - https://ndcoslo.com/
Audio Developer Conference:(not yet announced) https://www.juce.com/adc-2016
emBO++ (embedded C++)- https://www.embo.io/