6 ms·
It irks me no end when language-lawyering like this uses sizeof in the stupidly obscure way of the first example. sizeof(*(&s)) I mean, wut? Really?? This
by unwind 3y ago
It irks me no end when language-lawyering like this uses sizeof in the stupidly obscure way of the first example.
sizeof(*(&s))
I mean, wut? Really?? This should just be
sizeof s
Since sizeof is not a function, and redirecting by dereferencing a pointer that is just created by taking the address of a local is silly.
Not overly impressed by this.
- flyingcircus3 3y agosizeof still requires parentheses if it's a type and not a variable. To me it's like curly braces' optionality on conditional blocks with one line. If you aren't consistent, you're setting yourself up for heartache.
- jstimpfle 3y agoI think this is the same syntax as the one used for casting -- a "type expression" will only be recognized immediately after an opening paren (or at the start of a statement, in case of a declaration statement). So this is rather consistent.
- flyingcircus3 3y agoConsistency would be using parentheses for all cases of sizeof, because people without 10 years of experience can pick it up.
- jstimpfle 3y agoIf you think something is inconsistent you should ask why and find that what you thought inconsistent are simply 2 different things. The parentheses have nothing to do with sizeof, it's just how you write types (I'm repeating myself).
- mrkeen 3y agoHere's Torvalds on it: > But "sizeof()" really is a function. It acts exactly like a function of it's argument. There is no reason to not treat it that way. https://lkml.org/lkml/2012/7/11/103 https://lkml.org/lkml/2012/7/11/103
- leni536 3y agoI agree with his preference, but I think the reasoning should go like `sizeof` is an operator with possibly unclear operator precedence, while `return` is a statement.
- jstimpfle 3y agoOne of the rare cases where I think he's just not seeing the whole picture. For one, sizeof is not a runtime function but evaluated at compile time. (pretty obvious). More importantly, sizeof is syntactically a unary operator. It isn't syntactically a function call, just like "-a" or "*a" aren't function calls. That's just how it is, and really what's wrong with it? We're not in lisp after all. Let's not pretend it's a function, because otherwise an expression like sizeof(obj).member would be at least confusing.
- unwind 3y agoWhen using variable-length arrays (which I know are being phased out but which still do exist in the language) sizeof is indeed evaluated at runtime. It's weird.
- kazinator 3y agoAddress-of (&) can be resolved at load time, making this possible at file scope: struct node { struct node *next, *prev; } circular_list = { &circular_list, &circular_list }; This requires no initialization code to run; linking resolves it. Very long ago I made a GUI help system for a program, where all the documentation nodes were represented as structures with pointers for their navigation links: next section, previous section, up, children ... I statically declared the entire content with declarations akin to the above circular_list. The help GUI was just a window which displayed the node contents, and the buttons like next and prev just chased the pointers to another node which would replace the displayed content. Worked like a charm. Good luck giving that to internationalization people to translate. Haha!
- Gibbon1 3y agoIn a alternative world where WG14 all got hit by a bus in 1988 sizeof could be a runtime function that the compiler could replace with a compile time constant as an optimization. Lets say Richie won and phat pointers were added to the language. Then sizeof(phat_pointer) would absolutely be a run time function.
- eddd-ddde 3y agoThis is not obscure at all, I have used it commonly when you have a pointer to an object an want to allocate the size its dereferenced object occupies.