6 ms·
IIRC, if the argument to sizeof is a type, the parentheses are mandatory, anyway, so using it like it was a function is more consistent. I think the reason it
by krylon 11y ago
IIRC, if the argument to sizeof is a type, the parentheses are mandatory, anyway, so using it like it was a function is more consistent.
I think the reason it is not a function from the standard's point of view is that C does not have any builtin functions (unless my memory totally fails me in this case), all functions have to be either defined locally or #included.
- netheril96 11y agoExactly. I heard people arguing on the Internet that you should not add parentheses when sizeof is applied to an expression, only a type. I just cannot understand why they bother. Just add a parenthesis and it is always right. Much less cognitive burden.
- raverbashing 11y agoThis is the same people that find it "better" to write JS without the semicolons.
- deleted 11y ago[deleted]
- Negative1 11y agoI don't believe its equivalent. When I'm writing Scala code in the backend and have to switch to frontend I often find myself omitting the semi-colons but going back and fixing due to self-imposed coding conventions. For Javascript just as in Python or Scala, semi-colons are optional for a good reason.
- raverbashing 11y agoWell, semicolons may be optional in Python but the official python style strongly recommends agains (needing to use them) It's not about forgetting them once in a while, it's about playing a game of "needs a semicolon or doesn't" which increases the (already high) number of things the developer needs to worry about
- bigtunacan 11y agoWe would all be better off if semi colons had just been required in JavaScript. The problem is that semi colons are not actually optional in JavaScript. Instead JavaScript use ASI, automatic semi colon invasion, where the compiler attempts to determine where semi colons should go. Unfortunately the rules are complex, prone to certain errors, and I can't rely on everyone I ever work with understanding all of those rules. For all of these reasons if you are writing JavaScript you should just use semi colons.
- rhaps0dy 11y agohttp://blog.izs.me/post/2353458699/an-open-letter-to-javascript-leaders-regarding http://blog.izs.me/post/2353458699/an-open-letter-to-javascr... Please stop spreading FUD.
- skue 11y agoIf you have an argument to make, then make it. The previous poster didn't say he was unwilling to learn JS semicolon rules, he was saying he couldn't trust everyone he ever works with to learn them. Replying with an accusation of FUD and a link to someone ranting that it's unprofessional for JS devs to not know these rules is unnecessarily inflammatory while missing his point.
- tauchunfall 11y ago>Unfortunately the rules are complex, prone to certain errors, and I can't rely on everyone I ever work with understanding all of those rules. Are they really complex? This recently released version 4.0.0 of the JavaScript Standard Style [1] suggests to never start a line with "(" or "[". This rule looks even simpler than the rules of operator precedence. [1] https://github.com/feross/standard https://github.com/feross/standard Update: Now I learned about the JavaScript Semi-Standard Style [2] which accually enforces semi-colons. Quite hilarious. [2] https://github.com/Flet/semistandard https://github.com/Flet/semistandard
- bigtunacan 11y agoThey are complicated enough; and different enough from other languages that they lead to unexpected behaviors. It is just easier to say, "everyone must use semi-colons". Then I can add linting into our build process and reduce risk of bugs. One quick example is the very contrived example that follows. return {a:1, b:2} That is valid JavaScript. It is evaluated as an empty return and an unreachable expression. Probably not what was intended. I've sent copies of the rules to people and explained them numerous times, but at the end of the day it is more productive to just use them and move on to something else IMHO.
- netheril96 11y agoIn Python you usually don't add semi-colons, and it will bark when your intention is unclear. In javascript you may omit semicolons, but the interpreter will guess your intention when it is ambiguous and it will probably guess it wrong.
- tel 11y agoThe problem is that without a linter there's no punishment for missing semicolons. So really the argument should be that everyone should use a linter.
- rwallace 11y agoI thought about that regarding semicolons, optional braces, newline placement, consistent placing of whitespace in general; then I decided having the machine tell me where I need to do more work is all very well and good, but what I really want is a program that will do the work for me instead. So I wrote one: https://www.npmjs.com/package/jsclean https://www.npmjs.com/package/jsclean
- actsasbuffoon 11y agoAgreed. I spend most of my time writing non-semicolon languages like Ruby, Haskell, Scala, Elixir, Clojure, and Python. As a result, I never developed the semi-colon reflex that a lot of Algol-family language users built up. I constantly forget semi-colons even after all these years, and my own inability to remember annoys me. I used to skip semicolons in JavaScript because I could never remember to include them. Using a linter with Emacs made it a non-issue; I get a warning in my editor immediately when I miss one. PS: I'm really enjoying Rust, so maybe this will be the language that finally forces me to pick up the semi-colon habit.
- mcguire 11y agoOh, there's plenty of punishment. Avoiding the punishment in the difficult part. And you can do that the easy way or the hard way.
- tel 11y agoWell, sure, but it's probabilistic and delayed punishment. This makes learning habits and ensuring them difficult.
- woah 11y agoDo semicolons make the code run faster? What is the advantage exactly? There is no downside to leaving them out.
- Igglyboo 11y agoAFAIK the only "benefit" to semicolons is that you can put multiple statements on the same line.
- eliben 11y ago> it is not a function from the standard's point of view is that C does not have any builtin functions The problem with sizeof is that is should be able to accept a type as an argument. No function in C can do that, according to the standard C grammar. Somewhat similarly, the standard va_arg is a macro, not a function, also because it accepts a type.
- barrkel 11y agoAnother oddity of C that amuses me is the do/while loop without braces: int i = 4; do printf("hey\n"); while (--i > 0); Even though do/while is a keyword bracketing pair in C, it still only lets you use a single statement (because nested whiles). So everybody uses braces, and thus it looks quite disturbing without them.
- cygx 11y agoit looks quite disturbing without them Remove the newline and it looks ok to me: int i = 42; do printf("hey\n"); while (--i > 0); Another possibility would be: int i = 42; do printf("hey\n"); while (--i > 0);
- viraptor 11y agoOohh... this would be so good for the underhanded C contest! Just mix is up with the comments which make the `do` look like (assuming good actor) an accidentally wrapped comment. /* The following code does something, so here's the // explanations of what happens. And here's what we actually */ do printf("hey\n"); /* And now just count down */ while (some_check(--i)); Now spot that in a large file of real code!
- pierrec 11y agoSneaky. Most syntax highlighting would make it stick out like a sore thumb, but still, sneaky.
- gpvos 11y agoJust looking ok is not the point. I would prefer a match between how it looks and what it does...
- dllthomas 11y agoI agree, but I don't see that undermined here.
- 11y ago
- weinzierl 11y agoIn C there are no functions that take a type as argument. So sizeof(type) is a special case anyway. I'm all for using sizeof like a function, but that doesn't make it consistent. sizeof is just a special syntactical construct. I like to think that sizeof is called an operator just for syntactic convenience much in the same way as typedef is a storage-class specifier.
- masklinn 11y agoAnd you really shouldn't use it with a type if you can avoid it anyway, it makes code brittle e.g. int *foo; // code foo = malloc(sizeof(int)); a few months later, change foo to be a double. Code still compiles, no warning, but you're allocating half the memory you need.
- imglorp 11y agoWhich is why it's nice to lift stuff out into typedefs. It centralizes them (DRY principle) and avoids this issue. typedef int thing_t; ... thing_t *foo; // code foo = malloc(sizeof(thing_t));
- crazy2be 11y agoWell, in this (simple) case you can just do int *foo; foo = malloc(sizeof(*foo)); And avoid the brittleness mentioned.
- viraptor 11y agoWhy is that better than just getting `sizeof(* foo)`? Even with typedef, I can see this happening in the future: typedef int thing_t; ... thing_t *foo_internal; thing_wrapper_t *foo; // code foo = malloc(sizeof(thing_t)); If you do: foo = malloc(sizeof(*foo)); That's at least always on the same line.
- userbinator 11y agoThat just makes it more verbose. This, on the other hand, always allocates one object of foo's pointed-to-size, whatever its type: foo = malloc(sizeof(*foo));