Send the pointer from the pair to 3rd party and not the pair itself. You lose the efficiency in 3rd party, but still retain your gain in your own code. Better than before.
The belief it was created alongside UNIX from the start, when it was used to port UNIX V4 into high level language.
Micro-optimizing each line of code as it is written, "because it is fast", without even bothering to use a profiler.
Even though lint was created alongside C to fix already known programmer faults using the language, in 1979, the belief that only bad programmers need such kind of tooling.
> Micro-optimizing each line of code as it is written, "because it is fast", without even bothering to use a profiler.
With the CPU, MMU and OS architectures of that period, it wasn't particularly hard to infer what was fast without profiling it. The slow rise in complexity at all 3 levels now makes it hard for even extremely experienced close-to-the-metal programmers to understand what will be fast or slow without a profiler. Times do change, in fact.
No, the problem on unix v4 (at least I think that's the version I'm talking about) was that the C compiler did not support passing structs - whether as arguments, return values, or any other expression. So, they didn't do that, because it wouldn't work, and it was less hassle to work around it than fix the compiler. The cargo cult is when people keep avoiding struct passing, even though that compiler deficiency has been fixed for decades now.
That isn't what I was talking about, rather that C only appeared on season 4 of the UNIX movie, when many think it was part of the original cast from the get go.
So it gets a cargo cult status like UNIX was only possible because C was designed to make it happen and other bogus pocus that ignores almost 15 years of previous work in high level languages for systems programming.
Big problem with C is the standards committee just flat out refuses to add an array type to C. It's deranged because if you had first class arrays it'd be a lot easier to generate code that takes advantage of SIMD instructions.
You want to break existing code? If you made that change, you wouldn’t even be able to pass string constants into functions, because string constants are arrays (and not pointers, as some think).
The C standard committee has a general policy of not breaking code. If you want something like C with a better type system and less of the broken stuff (hello, arithmetic conversions) you can try Zig or one of the others. Once you’re okay with breaking code, you call it a different language, and go in trying to fix lots of things.
It's not a cult, its just that the cases where the risks of passing by value would be worth any perceived advantage are so few that it just doesn't make sense to even consider it.
It's not like it's a flimsy tribal based claim, the guidance is solid.
Which is to say, is unrealistic for many programs.