>> I suppose you could write a validator to make sure that this worked

No need to write it:

https://clang.llvm.org/extra/clang-tidy/checks/bugprone/argu...

Efb

That's great, I wish I'd known about this ages ago

C++20 added designated initializers, so they're also an option.

    my_func({.arg1 = val1, .arg2 = val2});

Oh I thought that was a C99 addition? It's been a while since I've used them.

Edit: struggling to find a source, though this GCC doc suggests it's C99 (but maybe that's only GCC?) - https://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html

It was C99. It took C++ 21 years to copy it.

It's been the primary and most annoying interop issue for us when we have to integrate C++ code into our primarily C codebase (= build some pieces of our code in C++, which necessarily has to interact with at least our header files).

(Second place: differences in available GCC/clang compiler extensions between C and C++ [our software does not support Windows/MSVC], third place: differences in what casts are permitted/how they are done)

My number one issue are VLA parameters

int foo(int N, char buf[N]);

which I like to use because they improve warning messages, but they are not accepted in C++.

Well, C is not the same as C++. It even says in that doc that “this extension is not implemented in C++”.

Yeah sorry in my head I assumed that it would have been adopted

Even though you need to declare a struct for this (or other) functions to receive these fields, I feel like this is the cleanest approach. What I'm not sure about is if reference, value, or pointer is the best way to let the compiler optimize this.

> And I suppose you could write a validator to make sure that this worked.

Like this one!

https://clang.llvm.org/extra/clang-tidy/checks/bugprone/argu...

Wow I had no idea, that's great!

at that point why not just pass in a struct as your argument

depending on the platform this may cause things to be pushed / poped on the stack instead of being passed as registers

I suppose it depends on your application. I worked in embedded devices where stack was limited and the compiler was .... less than reliable about how it would manage passing a large struct to your function, which is why I mentioned passing in a pointer instead

yes a pointer to struct would be acceptable as well

In 1998 perhaps. It wouldn't be acceptable to today's C++ value-semantics crowd. Are you sure that you want to take the indirection penalty? or that the compiler will optimise it away?

C++ is already so reliant on optimizing `const&` parameters that I can't imagine why you wouldn't use them if you happen to be stuck with a shitty embedded toolchain (or MSVC) that can't be relied on to pass struct parameters efficiently.

If stack space usage is an issue, then it means that the struct is already being passed by hidden pointer (as opposed to using a register passing calling convention). Making the pointer explicit won't have any effect on performance (but it will on semantics).