For example; `auto OpenFile(const string& filename) using future_coroutine<File> [filename]`. Okay, I get it. Or the operator `[<-]`.
But as the idioms find their way into production code - an entire important segment of the C++ developer base is going to no longer be capable of reading the language. And that might be worse than not having features.
The rate of change seems to be increasing. This is initially a bit shocking until I remember that every single job I had was like using a completely different language because, even ten years ago, every shop used a different subset of C++ and STL!
Add all you want to the language, it's all going to devolve into code-review infighting the same way it did in 2008.
Java 11, C# 8, Python 3.7, Fortran 2018, F# 4.5,.... try to write in a way that everyone will agree with, or do language quiz to see what which one gets right.
Sure there is C that looks so simple, who gets right all the ISO C changes between C89, C90, C11, C17, UB and compiler specific extensions/issues without having to look into the books?
C++ was first standardized in '98. Nothing happened for more 10 year (in particular no new advanced template support) unless you count the very minor bug fixes in C++03. The next revision, C++11, added ranged for loops.
Yeah, you're right. In some respects, things haven't changed.
I'm currently trying to modernize my C++ skills and while I love some of the new features I think they're creating an inconsistent, ugly, beast of a language.
When it comes to C++, there is no magic alternative that is "done right". I think that Rust may be the closest C++ alternative that will get in our lifetime and it's syntax isn't exactly non-ugly either.
That's just a C# idiom, and far from being the right or sane way to handle concurrency.
Meanwhile C++ has active objects and futures and other concurrency design patterns.
> doesn't have a sane way to create simple web servers
Check POCO.
> doesn't have map/find/filter/etc on collections, at least not a version that won't span multiple lines or the whole screen because they require mandatory arguments (begin, end) that are useless 99% of the time because you want to operate on the whole collection anyway, etc.
That's a very silly complaint. You acknowledge that C++ does have map/find/filter (which at this stage is rather obvious to anyone who ever used C++) but somehow you're complaining that C++'s interfaces require programmers to specify where the collections should start and finnish.
I think it is a valid complaint. Most of time you want to apply something like "find" to the whole collection.
I'd also love to have C++ standard maps (esp. unordered_map) where I only pay for what I use. Namely, due to C++ spec I have to pay for the nodes instead of having a flat, CPU cache efficient, buffer. In other words, a different map type where other items are allowed to move in memory when something is inserted or removed.
Oh, while we're at it, it'd be nice if vectors etc. could realloc instead of allocating a completely new memory region and freeing the old one when more space is required.
A more ergonomic allocator story for specifying alternative allocators would also be very nice for some niches, like when you need to avoid fragmentation or require better performance in embedded development.
why would you call this "broken" ? That's one of the most optimal solutions for reallocations if you append values continuously, since it will reallocate only logarithmically.
Also in that case I might want to grow it by a fixed amount, once it grows past a certain threshold.
It's a shame one needs to write another vector implementation just for that.
To implement a growing allocation , you'll have to create a custom vector, pretty much.
frankly, this is a very overstated problem. It's trivial to write a header with such functions (e.g. https://github.com/OSSIA/libossia/blob/master/OSSIA/ossia/de...). And it's already provided by Boost if you use it.
But since it's not in STL, everyone will use a bit different implementations for something this mundane and common.
Not just C#, Python and JS also have it already. And async-await is the first time ever where I've thought that yes, this is a good way to do single-threaded async (event-queue-ish) or even multi-threaded things.
> Check POCO.
Thanks for the hint, I will check it out.
> but somehow you're complaining that C++'s interfaces require programmers to specify where the collections should start and finnish.
Take a look at: http://www.modernescpp.com/index.php/higher-order-functions The c++ functions are unnecesarely verbose compared to other languages.
This
transform(vec.begin(), vec.end(), vec.begin(),[](int i){
return i*i;
});
vec.map([](int i){
return i*i;
});
It’s going to be pretty important for us: http://aturon.github.io/2018/04/24/async-borrowing/
Theoretically you could add helper functions to all suitable containers which calls through to transform (I think this is what you're suggesting). But it would feel very heavyweight and add a lot of cruft to the std library.
You could also add your own utlity free function similar to
template<class T, class F>
void mymap(T &t, const F &f){
std::transform(t.begin(), t.end(), t.begin(), f);
}Conceptually, I hate the word "map" to describe a transform. What does a real-world, paper map do? It associates locations drawn on the paper with real-world, physical places. That doesn't have any commonality whatsoever to morphing a group of objects. The term is misused.
That, however, violates the separation of concerns principle by mangling together data structures and algorithms.
I don't think that's true at this stage. Nowadays, beyond legacy code, C++ is used mainly in embedded, number-crunching, and cross-platform GUI applicationd, and that's about it. Meanwhile the world has moved on to web services and web apps, where C++ is nowhere to be seen, and other competing lower-level programming languages are starting to eat away C++'s lunch.
Go is not an option until they get their story straight with 2.0.
Swift is nice, but really it will never go beyond being an Apple platform language.
Native/Kotlin is doing its baby steps.
D seemed like a nice alternative, but they are such a small community without any big corporation support, that the language might already have lost its opportunity.
Rust would be the best alternative, but it still lacks the tooling integration story regarding IDE, graphical debuggers and OS vendors support.
Yes, no one is doing pure apps anymore in 100% C++, Java and .NET are slowly migrating to bootstrapped runtimes, but the language is not going away for the foreseeable future.
Kids are learning to program on Arduino devices using C++.
Microsoft already has some ongoing Rust projects, but Visual Rust is not yet here.
AAA Games, compilers specially LLVM and GCC, OS, HPC, Fintech, deep learning, GPGPU shaders, GUI composition engines, IoT, medical devices, car infotainment systems, VFX software might be a niche, but it is a very big niche.
One of the good things about polyglot development is that one doesn't need to silo himself/herself as developer X and be worried if language X is suitable for full stack development across all domains of computing.
EDIT: typos
Would you mind expanding on this point? Where I work, we do lot of C++ for the reasons you described but I have started to learn Go to see if its a suitable replacement.
There are other issues regarding tooling, specially for the use cases that I care, like dynamic loading into other platforms (JVM and .NET), GPU programming and graphical debuggers.
So naturally many C++ dev did not felt at home with Go.
https://commandcenter.blogspot.com/2012/06/less-is-exponenti...
Those pain points are the biggest roadmap points on a possible 2.0 version.
I develop some HPC code, and most of them is infeasible without C++.
Other languages' high performance libraries PIL and numPy is written with C & C++.
CppCon 2017: Olivier Giroux "Designing (New) C++ Hardware”
https://www.youtube.com/watch?v=86seb-iZCnI
Assuming another systems language, e.g. Rust, does indeed replace C++'s use cases, it is still a very long path until it gets this adoption level from hardware vendors.
You forgot a couple: your OS, your web server, image and video codecs, and basically any other low-ish level abstraction you rely on. The world isn't built on web apps.
Opinion of mine is what's needed is robust and performant inter-op, and only then a new dialect that fixes some of the deep legacy problems with the language. At least that would provide a clean migration path.
The languages with higher success rate are the ones that build on existing code and practices.
Every language with major market adoption is an inconsistent unless one does a language reboot Perl 6/Python 3 style and is willing to push it forward.
And yes, Swift as well.
Kotlin might eventually be another one, depending how the Java story will evolve past Java 8 on Android.
A C++ ABI requires an OS written in C++, likewise there is no such thing as C ABI per se, rather UNIX ABI, Win32 ABI and so forth.
One per each platform, plus an additional one, agreed by all these guys? And the list is not 100% compliant, e.g. TI is missing.
https://en.m.wikipedia.org/wiki/List_of_compilers#C++_compil...
Not even C has managed to do it, what people conventionally refer as C ABI is actually the OS ABI.
I still remember having to deal with multiple C ABI on MS-DOS and Windows static libraries.
In terms of having one spec that handles arbitrary architectures, maybe it could be defined relative to the C ABI? I don't actually know how what the internal ABIs used by the current crop of C++ compilers looks like, so I don't know if they could be expressed relative to the C ABI or not.
Alternatively, one could come up with a set of configurable values that define what makes one architecture different from another (such as word size, long/pointer size (if different than word size), endianness, etc). You know, the stuff that the compiler already has to know about in order to compile for an architecture (and I'm pretty sure clang at the least already has a way to even define new target triples in terms of a set of configurable values for this sort of thing). I assume existing compilers don't invent entirely brand new ABIs for each new architecture but instead just adapt an internal standard C++ ABI to the new architecture using a similar process already. The same could be done for a public standard C++ ABI.
No, it is age old. The thing is that it is only "a thing" to embedded native developers and library authors.
The general concept is that the programming language "API" doesn't define how the dll/o/a/la/lib/so/dylib "loader" look for "symbols" in the file. If you example, I do:
enum {FOO, BAR};
enum {BAZ, FOO, BAR};
For embedded devs, more problem arise from the fact that the instruction set and C library themselves are not the same for all devices and this also break pre-compilled code.
Many platform will often favor "static binaries" over dynamic ones to avoid the consequences of breaking the ABI.
ABI is ancient since it defines the underlying structure that allows you to link compiled object files and liberals together (the latter both statically and dynamically). Allowing code generated in one module to successfully call functions in another.
That's not quite true. That's already possible without a standard ABI.
What's not possible is to get code compiled by a specific compiler to call modules built by another compiler provided by another vendor. That's the only problem that is addressed by a common ABI.
I would also add that considering MS's interoperability history and how prevalent MSVC++ is, working on a standard ABI would be a waste of time.
Yes, compilers need to agree on the ABI, the platform ABI, that is. Today most platforms already have a de-facto or de-jure standard ABI and compilers have the option to implement it.
Even if such a thing was possible, there is no value in the standard committee standardizing an single ABI as most platforms would never break backward compatibility to switch to it.