Things that Dennis Ritchie got wrong.
-
-
True facts: I was trying to remember if "asp" was a type of snake or not for a joke, and I got nothing but asp.net links on my attempt to google.
-
-
True facts: I was trying to remember if "asp" was a type of snake or not for a joke, and I got nothing but asp.net links on my attempt to google.
Asp:
Asp:
Asp:
-
One of the most important lessons learnt when travelling through the forests around the Marsh Cave.
-
-
OK!
Is that a link now? It should be in the original post too...
OK, so it's a link when quoted, but not in the original post, even though the raw says it's a link.
-
Leading 0 in front of a number means its an octal which is insane.
I have evidence that at the very least Java is carrying this tradition, so it makes the list.
-
I have evidence that at the very least Java is carrying this tradition, so it makes the list.
Only in literals, or if you use the wrong (right?) API call. That such things still exist at all isn't great, but they should not normally be a problem.
-
-
<a href="http://stackoverflow.com/questions/16433781/how-to-set-value-of-octal-in-java">Existing at all is sufficient.</a>
I like how there are seven answers, and they're all essentially identicalAnd I can't be arsed reDiscoformatting, so have a fox instead:
-
The fox seems to have escaped from its thread
-
Casting: Yeah, it would be nice to make them more searchable, though C++ syntax makes them overly verbose. But honestly, in tracking down a crash, more often than not you'd do far better to find out what variable(s) are suspect with a debugger, and search for those variables, rather than casts in general -- especially in any decently sized project. Besides, GCC usually prints warnings about any suspect casts if you haven't told it not to.
Also I have seen more problems from messing up pointers than from messing up casts.
Switch: I'll give you this one 100%. You almost always want the "break" behavior, so make it the default and have a "fallthrough" keyword.
Optional braces: I like optional braces. They simplify 'trivial' uses of if, like "if(x<0) x=0". A syntax that allows you to make poorly formatted unreadable code is not bad. This is not kindergarten, we don't need round-tipped scissors.
-
Optional braces: I like optional braces. They simplify 'trivial' uses of if, like "if(x<0) x=0". A syntax that allows you to make poorly formatted unreadable code is not bad. This is not kindergarten, we don't need round-tipped scissors.
How about optional parentheses?
if x < 0 { x = 0 }
-
C++ syntax makes [casts] overly verbose
If the C++ syntax is actively discouraging casting, then I'm in favour of it.
Optional braces... "if(x<0) x=0"
You could still have your trivial example with optional parentheses, and it's even the same length:
if x<0 { x=0; }
EDIT: or, uh, what Ben said...
-
why do all the conditions have to be compile-time constants?
Because switch in C is a jump table, not a cascading if/else.
-
Personally I have moved to Egyptian style braces
Ew. You don't like the braces that start and end a block to line up vertically?
if (condition) action;
Evil. You're a bad person.
if (condition){ action; }
And so are you.
if( condition )
{ action; }And you! What's with all the terrible people here?
if (a == b) doStuff();
if (a == c) doOtherStuff();More terrible people!
There are plenty of instances where I have if (some error condition)goto error_cleanup;
You're the worst of the terrible people.
-
Egyptian braces are solid.
I think you can get away with
if(expression) { statement; }
[i]iff[/i] you are using an environment which supports multiple breakpoints per line. Otherwise yah, you are a terrible person.
-
-
Ew. You don't like the braces that start and end a block to line up vertically?
No, because that takes lots of extra space characters:
if (condition) { action; }
-
Remember, every extra whitespace character means it takes the compiler so much longer to compile your code.
(Taking from a coding standard which prescribes the #defines to only include a file once should be outside the include instead of inside the file. Also mandates a header that starts out at ~20 lines and grows over time.)
-
Or even just:
{ int temp = a; a = b; b = temp; } ```</blockquote> Or even a ^= b ^= a ^= b; </troll> <!--​ a ^= b; b ^= a; a ^= b; Works, but only for ints. -->
-
eeeeeeevil
-
And nasal demon territory....
-
Yeah, you're assigning a twice in the same statement.
-
Yeah, you're assigning a twice in the same statement.
three times.
it does however work correctly with GCC even with -O3 enabled (or so my test shows....)
CLANG on the other hand wants nothing to do with it.
of course that could be unrelated... i don't C often.
-
Not sure what happened to my typing there - I think I accidentally a word or two.
I meant to say "You're assigning the same variable twice in the same statement", which is the undefined behaviour bit.
Multiple assignments in the same statement is OK, and using the old value to compute the new value is OK as well, but you're not allowed to use the value (use or assign) outside the innermost assignment to it.Some other illegal examples:
a = a++; b = a + a++;
-
Because switch in C is a jump table, not a cascading if/else.
That tends to be true in C-derived languages as well.
Having said that, I had to change a switch statement in some Pawn code to an if/else if chain just recently. Mainly because what were compile-time constants got changed to being set at runtime because the values have been volatile lately and people got tired of constantly having to recompile every time this library changed.
(Side note: Control of the values of these is not under control of the library's authors, but of Valve Software who wrote the game said library interfaces with.)
-
a = a++;
b = a + a++;better written as (and this way there's no undefined behavior!):
a += 1; b = a * 2; a += 1;
if available i turn on the rule for all my linter that disallows ++ and -- pre/post increment operators. they obfuscate more than they save on typing.
i've been bitten a few too many times on that.
-
It varies on the occasion. I'll use
i++
as a single satement, typically in a for() update. I'll also use it in loops in the middle of another statement or in a while() condition, but only if it's the only occurrence of that variable in the loop body, or in some cases when all usages of the variable auto-increment as well.
-
I'll use i++ as a single satement, typically in a for() update
if the statement is literally
i++;
then i don't have that big an issue with it. but to make my life easier and the lint rule simpler i'll just rewrite those to be
i += 1;
it's a few more characters, btu it doesn't show up that often, is explicit in what i want and means that i can simply look for ++ or -- in my code and flag instances as invalid when doing my lint check without having to do more complex heuristic checking.
-
-
++a += a++
/me ignored nasal demons and pulls apart order of operations
a = ((a + 1) * 2) + 1;
there. much clearer.
longer, but more maintainable.
-
That one's definitely just undefined. I'd end at 2a+1 as expected outcome, but there's really no saying. Nasal demons aside anything between 2a and 2*a+4 is probably defendable.
-
That one's definitely just undefined
no argument there. hence my ignoring of the nasal demons.
Nasal demons aside anything between 2a and 2a+4 is probably defendable.
we are firmly in UD territory. anything from 0000000000000000 and FFFFFFFFFFFFFFFF is allowable, and it's not just limited to that!
granted most compilers will either throw a error or end up calculating something between 2a and 2a+4 (in fact if you simplify I calculated 2a+3, i didn't simplify because i was going for clarity, also why there's an extra set of parens that's not technically needed by order of operations)
-
I'm just glad C++ does at least disallow
++a++
-
I'm just glad C++ does at least disallow ++a++
hmm... as cromulent as the syntax is.....
nope can't defend it.
see, THIS is why i won't allow the use of ++ or -- in my personal projects. it's EVIL!
-
Well, unary operators are evaluated to the right first, and (a++) definitely is not an lvalue, so ++(a++) is illegal because of that alone.
++a is probably also not an lvalue, but I'm not 100%.
-
You don't like the braces that start and end a block to line up vertically?
This is one of those things, like women's pants with pockets that sounds like it should be a good idea but isn't.
-
This is one of those things, like women's pants with pockets that sounds like it should be a good idea but isn't.
ahem
pockets are good. we need pockets too.
i'm not carrying my $700 phone in the same bag i keep the bricks in that i use to clunk would be thieves on the head to teach them a lesson via concussion about the value of not trying to mug people!
-
pockets are good. we need pockets too.
i'm not carrying my $700 phone in the same bag i keep the bricks in that i use to clunk would be thieves on the head to teach them a lesson via concussion about the value of not trying to mug people!
Yes, women always say stuff like this. But they want big pockets to carry stuff that also look just like pants that don't have big pockets. Especially when the pockets are full. And we all know which side of that wins the fashion argument.
-
But they want big pockets to carry stuff that also look just like pants that don't have big pockets.
what? you mean cake and eat it too? -sigh- yeah that's probably more accurate than i would like it to be....
-
++a is probably also not an lvalue, but I'm not 100%.
I am pretty sure that you are wrong and it is. Maybe... 80% sure.
As for the general topic, hmmm... I think the biggest mistake they made at the time (as opposed to thing s that became undesirable with increased computing power and are problems now with C's ubinquity) is pointer/array conflation. The fact that
foo(int* x)
andfoo(int[] x)
are basically (and maybe actually?) identical I think is very unfortunate... you have no idea whatx
is doing in the first. Is it a single element passed by pointer for some reason (e.g. if you changeint
to a struct, for efficiency)? Is it an array? Is it being used as an out parameter?Some other complaints:
- NUL-terminated instead of Pascal strings (maybe okay at the time, but very unfortunate)
- Declaration syntax for things much beyond basic types
- Probably lots more that I am not thinking of
-
Phablets need to DIE. Not all men's pants are endowed with UberPockets of Holdingâ„¢, especially in front, where you really want your phone to be.
Filed under: I want a Nexus 4, small is beautiful
-
Phablets need to DIE. Now.
#AGREE
Filed under: I want a Nexus 4, small is beautiful
i found the 4 just a little to small for comfort. i love my nexus 5 and wish the chocoalte foactory had kept that form factor for the 2014 redesign.
i was....
-
Overloads for the pre-increment operator should follow the form
T& T::operator++();
Which is how they behave for
int
s. So long as you follow that,++a
is an lvalue, and you can chain them together:++++++++++a
is valid and well defined, which means++(++(++(++(++a))))
which is the same asa += 5
.
-
++++++++++a is valid and well defined, which means ++(++(++(++(++a))))
EEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEEVIL!
http://static2.fjcdn.com/thumbnails/comments/Aw+man+this+++_e7869da2e5d8e950dee1614fb30fb225.gif
-
The fact that foo(int* x) and foo(int[] x) are basically (and maybe actually?) identical I think is very unfortunate...
Speaking for C++ here, they're not the same at the call site, but they become the same once inside the called function. This doesn't mean anything for regular functions, but it does mean that you can use templates that accept static arrays and know the length of the array without passing it as an additional parameter.
-
Google returns http://www.quora.com/Why-does-the-pre-increment-operator-in-C++-gives-lvalue-instead-of-rvalue-as-in-C, which indicates pre-increment and decrement are lvalues in C++, but rvalues in C.
-
Yeah, you're assigning a twice in the same statement.
That would be OK, except there's no sequence point in-between.
it does however work correctly with GCC even with -O3 enabled (or so my test shows....)
The nasal demons are being kindly there. Do not trust them!
NUL-terminated instead of Pascal strings (maybe okay at the time, but very unfortunate)
Much better. At the time, Pascal strings were hard-limited to being at most 255 characters long… unless you used wide characters! Which weren't really a thing at the time.