C++26: The Oxford Variadic Comma
sandordargo.com
sandordargo.com
At least they managed to kill `auto_ptr`.
Regular variadic arguments in general aren't used very often in C++ with exception of printf like functions. Not rare enough for majority of C++ programmers to not know about them, but definitely much more rare than their use in python. Main reason people know about it at all is printf. The "new" C compatible form has been supported since the first ISO standardized version of c++ if not longer. There haven't been a good reason to use the "old" form for a very long time. Which means that the amount of C++ code using deprecated form is very low.
Being deprecated means that most compilers and linters will likely add a warning/code fix suggestion. So any maintained project which was accidentally using C incompatible form will quickly fix it. No good reason not to.
As for the projects which for some reason are targeting ancient pre ISO standard c++ version they wouldn't have upgraded to newer standard anyway. So if new standard removed old form completely it wouldn't have helped with those projects.
So no you don't need to know the old form to read C++ code. And in the very unlikely case you encounter it, the way for accessing variadic arguments is the same for both forms through special va_list/va_arg calls. So if you only know the "new" form you should have a pretty good idea of whats going on there. You might lookup in references what's the deal with missing coma, but other than that it shouldn't be a major problem for reading code. This is hardly going to be the biggest obstacle when dealing with code bases that old.
Unless you have a massive legacy code base that is never updated, C++ has become much simpler over time. At a lot companies we made a point of slowly re-factoring old code to a more recent C++ standard (often a couple versions behind the bleeding edge) and it always made the code base smaller, safer, and more maintainable. It wasn’t much work to do this either.
To some extent with C++, complexity is a choice.
There've been a few cases where code was unsound and should never have compiled, but did due to compiler bugs, and then they fixed the bugs and the code stopped compiling. These were handled through deprecation warnings with timelines at least several months long (Rust releases a new version every six weeks), but usually didn't have automated migration tooling, and didn't fracture the language mostly because they were rare edge cases that most programmers didn't encounter.
This is allegedly because in the 80s companies would write software, fire the programmers, and throw the source code away once it compiled.
I don’t know what you’re counting as “3% of the issues” but if those are the 3%, they sound like massive productivity and safety wins that’s not existed in a language with a similar performance profile to C/C++.
I think the way forward is multiple backends (LLVM + GCC) to improve platform support, but a single unified frontend that works correctly on all platforms is a good thing.
Turns out, these two are equivalent in practice (but UB in the C++ standard):
double solve(double a, double b, double c, double d) {
return a + b + c + d;
}
double solve(double a ...) {
return a + 1[&a] + 2[&a] + 3[&a];
}Not in the x86-64 SysV ABI they aren’t. The arguments will be passed in registers (yes, even the variadic ones), so how your compiler will interpret 1[&a] is anybody’s guess. (For me, x86_64-unknown-linux-gnu-g++ -O2 yields, essentially, return a+a+a+a; which is certainly an interpretation. I’m also getting strange results from i686-unknown-linux-gnu-g++ -O2, but my x87 assembly is rusty enough that I don’t really get what’s going on there.)
Clang does the sensible thing with UB and just returns poison (a form of undefined value) in both cases, which manifests as do nothing on x86-64 and load a zero value on i386, because you need to push something on the stack and fldz is one of the cheapest ways to push something. Meanwhile, gcc is in both cases for the UB variant returning a + a + a + a;
FWIW, going back through older gcc versions, it seems i386 gcc stops implementing 'add the arguments' in version 11.1, although it's not until 15.1 that it has a sensible assembly for 'a + a + a + a'. The x86-64 gcc version is broken in 4.0 (where it stops copying the register arguments to the stack when va_start isn't called, I guess). Then it's adding xmm0 to the top 3 values on the stack until 11.1, when it's adding 'a + a + a + a', although not sensibly until version 15.1.
Zero is the only valid index of &a, so I presume the compiler just assumes that all the indexes in 1[&a] + 2[&a] etc must be zero. Even though they're in this case compile-time constants – the optimizer could check but why bother given that it's UB anyway. I assume modern C/C++ compilers have some flag to diagnose indexing that's known to be OOB at compile time.
test.cpp: In function ‘double solve(double, ...)’:
test.cpp:4:20: warning: array subscript 1 is outside array bounds of ‘double [1]’ [-Warray-bounds=]
4 | return a + 1[&a] + 2[&a] + 3[&a];
| ~~~~^
test.cpp:3:58: note: at offset 8 into object ‘a’ of size 8
3 | extern "C" __attribute__((noinline)) double solve(double a, ...) {
| ~~~~~~~^
[repeat twice more for the other two accesses] double solve(double a,double b,double c,double d){return a+b+c+d;}
double solve(double a...){return a+1[&a]+2[&a]+3[&a];}
double solve(a,b,c,d)double a,c,b,d;{return a+b+c+d;}Err no; https://gcc.godbolt.org/z/sW3ea58oc
They're equivalent on GCC.
double solve(double a[]) {
return 0[a] + 1[a] + 2[a] + 3[a];
}
solve((double[]){1, 2, 3, 4});
I guess that's a preview how C++ require a lifelong commitment.
The difference being that P1219R2 was actually a revised proposal from 2019 not 2021.
I've been using C++ for more than 30 years (I added thread_local to Cfront back in the early 90s), and while the language has grown dramatically in that time, there is fundamentally nothing that would prevent me from writing "C with classes" using the modern version.
I don't do that because I also like RAII, and polymorphism, and operator overloading and ...
I've never used .NET and could not imagine any scenario under which I would. The libraries that matter to me are mostly written in C or C++ and there are more of them than I'd ever need, mostly.
Or indeed "C without classes", just with some extra type-checking.
And of course K&R used Stroustrup's C++ compiler to build and test the code for TCPL 2nd Ed.
I sometimes wonder if the comments that say nothing more than "C++ is too complicated" are from people who use it regularly, much less people who are even commenting on TFA
I'm also not totally convinced that someone not using a language regularly means their view on it being too complicated must be invalid; I would fully expect someone who views it as too complicated to try to avoid using it, and there are enough people doing that, it might be a cause for concern. That doesn't necessarily mean they're right, but without further context it also doesn't mean their opinion isn't relevant.
In my opinion anyway. C++ feels so bloated these days.
I have no idea where you get this idea from. I expect gcc v28 to be able to compile C++ from 2008, and I'm not alone in that.
That said, I wish code written for gcc v28 didn't have to be binary compatible with C++ that was last compiled in 2008...
The 2000's and C++ were a clusterfuck largely for this very reason.
All languages have some spikier edges, there are no languages I know where I think "Well, even if we could start over I have no idea how to improve this". What's notable about C++ is just how rich that "could do better" seam is, so very many of their defaults are wrong, so many of their keywords are the wrong word, so many of their standard library features are allowed, sometimes even mandated to be crap.
* "C sharp" as in "C but higher",
* C with four pluses, and
* a homophone of "see sharp"
I love C, but C++ has worthwhile advantages even if you heavily restrict which features you use.