I used to slay with this in code golfing competitions from TopCoder, where you had to implement a function to solve a particular problem, thanks to C pointer maths and the gcc generally putting function arguments in order in the stack.
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.)
advael•1h ago
This seems pretty good to me just on the level of trying to read C as someone using C++. Parameter packs and variadic templates are easily the most confusing syntax in C++ and cleaning it up is... very welcome
jkaplowitz•1h ago
Hats off for using "..." in your comment immediately after a valid identifier word and with no comma in between, given the topic of the article.
advael•18m ago
Hats off for noticing. Not to be taken for granted in an increasingly skimming-oriented world
lasgawe•1h ago
learned something new. thanks for the article.
throwaway2027•1h ago
C++ got too complicated after C++23 I went back to C.
Conscat•43m ago
No offense intended to your perspective, but I do find it a little amusing that C++23, which was generally considered a disappointingly small update due to COVID complications, was the breaking point in complexity.
FartyMcFarter•41m ago
You can always restrict yourself to a subset of C++ that takes advantage of RAII (resource handling is extremely painful in C), and get performance benefits like move semantics, without the insanely complex stuff.
I love C, but C++ has worthwhile advantages even if you heavily restrict which features you use.
jjgreen•25m ago
C is the new vinyl.
staplung•1h ago
Of course since the old syntax is merely deprecated and not removed, going forward you now have to know the old, bad form and the new, good form in order to read code. Backwards compatibility is a strength but also a one-way complexity ratchet.
At least they managed to kill `auto_ptr`.
Conscat•44m ago
PyCuda 2024, used fairly often in certain industries, still contains `auto_ptr` ;-;
zlfn•1h ago
C++ seems to be constantly getting complicated. If the major version were to change, there wouldn't be any need for backward compatibility with the existing code, and it would have been okay to delete that syntax while creating an automatic formatter.
dnmc•1h ago
Are you suggesting we move to C++++?
zlfn•58m ago
It's already there. It's called C#
HackerThemAll•40m ago
Well, C# also has its quirks already. Like the crippled finalizers which are never to be used. If the IDisposable interface had been correctly designed, finalizers could become be the "public void Dispose(void)". Or the manual passing of Task in case of async methods, which is... kinda smelly.
m-schuetz•32m ago
Personally I like C+. Picking the nice parts of C++, but skipping all the nonsense. I just wish C++ hadn't deliberately screwed up designated initializers with mandatory ordering. The C version of it that allows out-of-order assignments is clearly superior.
HackerThemAll•43m ago
Yes, but no. I learned C++ in '90s when it was C with classes and some other noise added by Stroustrup. During the some 25 years that followed it had became a mess that's insanely hard to work with. I'm not going back to this language. I prefer plain C or Rust, leaning towards Rust when I fully comprehend the lifetime and borrow checker. Or when I have the luxury of having a GCed runtime, then the .NET with its easiest C# language with wonderful abundance of great libraries is the best choice. Nobody was ever fired for using .NET (for right purposes).
mFixman•1h ago
Turns out, these two are equivalent in practice (but UB in the C++ standard):
camel-cdr•1h ago
mananaysiempre•40m ago
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.)