CAN I HAZ UNNAMED UNUSED PARAM void callback(int x, void *) // VOID STAR UNUZED, SO ANON { foo(x); }
Why is there a second argument which is not used?
To match an API where it is sometimes used.
Tell HN: C Experts Panel – Ask us anything about C
711–720 of 978 posts
Re: Tell HN: C Experts Panel – Ask us anything about C
#712In my opinion C is good as it is. C++ is terrible complicated mess, always have been and adding more and more "modern" functionality isn't helping it much. There are great standard functions, e.g. for strings in C, whereas it is often very inconvenient or complicated to do simple things like uppercase string in C++. I always ended up basically using C with just basic OOP functionality from C++. But I am not writing in C/C++ daily so my opinion is not very important...
Re: Tell HN: C Experts Panel – Ask us anything about C
#713There's a compiler attribute in GCC to promise that a function is pure, i.e. free from side effects and only uses its inputs. This is useful for parallel computations, optimizations and readability, e.g. sum += f(2); sum += f(2); can be optimized to x = f(2); sum += x; sum += x; Would the current motto of the consortium forbid adding a feature such as marking a function as pure, that would not just promise, but also…
No enforcing! This is useful even when it's, strictly speaking, a lie. Suppose I want to add some debug tracing into f(): f.c: 42: f entered f:c: 43: returning 2 that's a side effect, right? But now the pure attribute tells a lie. Never mind though; I don't care that some calls to f are "wrongly" optimized away; I want the tracing for the ones that aren't. In C++ there are similar situations involving temporary objec…
Just offer a -Wpure flag for checking if functions are pure. That way production/test releases can check while you can still use it for debugging.
Also, the problem with eliding breakpoints already exists afaik, since the compilers already check for pure functions.
Re: Tell HN: C Experts Panel – Ask us anything about C
#714Earlier quoted context omitted.
the compiler is allowed to assume the loop terminates precisely because signed overflow is undefined. Just to be sure I understand the fine details of this -- what would the impact be if the compiler assumed (correctly) that the loop might not terminate? What optimization would that prevent?
> …what would the impact be if the compiler assumed (correctly) that the loop might not terminate? Loaded question—the compiler is absolutely correct here. There are two viewpoints where the compiler is correct. First, from the C standard perspective, the compiler implements the standard correctly. Second, if we have a real human look at this code and interpret the programmer’s “intent”, it is most reasonable to assu…
Thanks for the code, this is exactly the kind of concrete example I was looking for!
You're correct about how it behaves with "int" and "unsigned", very interesting. But it occurs to me that on x64 we'd probably want to use 64-bit values. If I change your typedef to either "long" or "unsigned long" that seems to give me the SSE version of the code! (in x86-64 gcc 9.3) Why should longs behave so differently from ints?
I very much agree that getting good numerics performance out of the optimizer seems to be a black art. But does the design of C really help here, or are there ways it could help more? Does changing types from signed to unsigned, or int to long, really convey your intentions as clearly as possible?
I remain skeptical that undefined behaviour is a good "hook" for compilers to use to judge programmer intention, in order to balance the risks and rewards of optimizations. (Admittedly I'm not in HPC where this stuff is presumably of utmost importance!) It all seems dangerously fragile.
If you need good performance out of some tight inner loop, the easiest way to get there is to communicate to the compiler the “obvious” facts about the state of your program and check to see if the compiler did the right thing. If the compiler did the right thing, then you’re done, and you don’t need to use vector intrinsics, rewrite your code in a less readable way, or switch to assembly.
I strongly agree with the first part of this -- communicating your intent to the compiler is key.
It's the second part that seems really risky. Just because your compiler did the right thing this time doesn't mean it will continue to do so in future, or on a different architecture, and of course who knows what a different compiler might do? And if you end up with the "wrong thing", that may not just mean slow code, but incorrect code.
Re: Tell HN: C Experts Panel – Ask us anything about C
#715What are your recommendations on going about learning the C language properly? And How to go about learning all levels of abstraction of the language?
Re: Tell HN: C Experts Panel – Ask us anything about C
#7161. How likely are named constants of any types to be included in C2x? I'm referring to the idea of making register const values be usable in constant expressions. 2. Is there, or was there ever a proposal to make struct types without a tag be structurally typed? This would not break backwards compatibility as far as I can see, and would make these types much more useful as ad-hoc bags of data. Small example: struct {…
I have incorporated the following macro abuse to prepend the number of arguments to a variadic functions into my projects: https://gist.github.com/61131/7a22ac46062ee292c2c8bd6d883d28.... It does introduce some overhead, but it suits my needs for the projects that I am working on.
That being said, I would like it if the default types for variadic functions were promoted from int/float to int64_t/double in order to be more reflective of the wider ranges supported by these types.
Re: Tell HN: C Experts Panel – Ask us anything about C
#717Hmm seems to be an intersting thread.
>Cmd + F >“Rust” >34 results
Nnnnnnope, better close this tab.
Re: Tell HN: C Experts Panel – Ask us anything about C
#718Re: Tell HN: C Experts Panel – Ask us anything about C
#719Earlier quoted context omitted.
I think we are always looking at ways to "clean up C" but that this has to be done very carefully not to break existing code. For example, the committee recently voted to remove support for function definitions with identifier lists from C2x http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2432.pdf At least one vendor was not very happy with this decision. Undefined behaviors tend to be undefined for a reason and sho…
C has strayed very far from the original intent because compiler authors prioritized benchmark results at the expense of real-world use cases. This bad trend needs to be reversed. Consider signed integer overflow. The intent wasn't that the compiler could generate nonsense code if the programmer overflowed an integer. The intent was the the programmer could determine what would happen by reading the hardware manual.…
If most C developers wanted to trade the performance they get from the compiler being able to assume `n+1 > n` for signed integer n, it would happen.
Re: Tell HN: C Experts Panel – Ask us anything about C
#720char effectively behaves as a signed type, making it unsuitable for binary operations (e.g. UTF-8 manipulation). I/O functions deal with char pointers, so using unsigned type like uint8_t requires casting back and forth. Is there any way out of this problem, and am I already breaking the aliasing rules with that cast?
Plain char is either signed (same representation as signed char) or unsigned (same representation as unsigned char), depending on the implementation.
Yes, there are real-world implementations where plain char is unsigned.