My answer to a lot of these questions is "If you write code like this and check it in to our corporate repository, I will cut out your heart and make you eat it."
LOL, yeah, multiplying the space character by 13. I gritted my teeth when I saw that.
So you think you know C? (2016)
291–300 of 344 posts
Re: So you think you know C? (2016)
#292Earlier quoted context omitted.
As someone who was introduced to programming via map/filter/reduce, for loops are incredibly more complicated. I don’t think I’ve ever written one correctly on first try.
Unfortunately, loops still seem to be the easiest way to iterate over two collections simultaneously.
“#zip”?
Or maybe I’m misunderstanding the use case?
Re: So you think you know C? (2016)
#293Earlier quoted context omitted.
There's explanations at the bottom after you click the button.
I read it but I still don’t understand. Isn’t it 0 + 2 vs 1 + 1? How would it produce something other than 2?
So for the left-to-right operand evaluation order I thought it’s this: look at the left operand, take zero. Then post-increment, now it’s one. Move on to the right operand. Pre-increment what is 1, so now it’s 2. Take 2. So it 0 + 2?
Re: So you think you know C? (2016)
#294Earlier quoted context omitted.
>which is supposed to be the point of the exercise. I don't think that assumption is justified. Someone could say the point of the exercise is to illustrate that C is confusing.
You don't think the claim is justified because some might say otherwise. Some is irrelevant. Some might say lots of mutually exclusive interpretations. It's the author's intent that matters, and the context of the Author's post indicates the some interpretation isn't the author's intent. His post begins with the question "So you think you know C?". He then goes on to present a test that is, by his own words, intended…
Showing how people misunderstand the intricacies of C is much closer to "C is confusing" than "distinguishing who is honest about their limitations".
Re: So you think you know C? (2016)
#295> And at this point, I only have to apologize. The test is clearly provocative and may even be a little offensive. I’m sorry if it causes any aggravation. [...] It was a research project in nuclear power plant automation, where absolutely no underspecification was tolerable.
I appreciate the apology here, and I can totally understand the concern about the spec in a safety critical environment.
Still, all questions on this test except the first are clearly examples of things you should never ever do in production code, which might undermine the message a bit? Yes, you can write bad code, and that’s true in every language I’ve ever used.
I’m guessing it would be hard to find a modern compiler on Windows, Mac or Linux that produced padding other than rounding up to nearest 4 bytes?
Sizeof(a+b) is obviously a weird thing to do.
char a = ‘ ‘ * 13 produces an overflow warning in gcc.
(((((i >= i) > i) return i++ + ++i; Not doing exactly this was drilled into us in CS 101. Still, I’d be interested to hear about a compiler that doesn’t return 1, since many people rely on the fact that ++i is pre-increment and i++ is post-increment. I don’t doubt one is out there, I’m curious to know which.
There probably weren’t much better choices 20 years ago... what would be the best choices today for a branch new nuclear power plant?
Re: So you think you know C? (2016)
#296Earlier quoted context omitted.
Unfortunately, loops still seem to be the easiest way to iterate over two collections simultaneously.
“#zip”? Or maybe I’m misunderstanding the use case?
Which only works if the sequences align perfectly. Handling misaligned collections is more awkward with functional constructs.
Functional graph programming is also still a bit of an open problem. There are awkward scenarios in both cases.
Re: So you think you know C? (2016)
#297Earlier quoted context omitted.
Whoa there! You mean “unspecified behavior”. int i = [unspecified] means that i has some value, but the spec doesn’t determine the value. Undefined behavior means that all your secrets might be sold to the highest bidder, your centrifuges might explode, and your computer is now full of ransomware.
Whilst my other comment was intended to be jovial, it is hard to say if that was accurately conveyed. So this one will be serious. The original problem definition, as specified by @pksadiq, read thusly: > Say for example, in question 5, the statement "return i++ + ++i;" is undefined ... This inspired a response by @Filligree of: > Compile it, look at the assembly. You can know. The answer will vary from place to plac…
> Whereas you imply a standards-conformant implementation of "return i++ + ++i;" is unspecified (category #2), it is, in fact, undefined (category #3).
You're misreading things. amluto's assertion is that "The answer will vary from place to place, but it isn't non-existent." is a description of category #2. That assertion is basically correct, depending on how exactly you define "place to place".
An informal definition of category #3 is "The answer can vary from place to place, or not exist at all." ideally followed by "It might crash or run unrelated code or even prevent the preceding code from running." It's flat-out wrong to say a value "isn't non-existent" when it comes to source code exhibiting undefined behavior.
Re: So you think you know C? (2016)
#298Earlier quoted context omitted.
Over time I removed all the C preprocessor tricks from my own code and just wrote ordinary C in its place. Much better. I don't get it. If my macros produce standards-compliant code and they make my code easier to read and understand, why shouldn't I use them? My goal as a developer is to write clean performant bug-free code... not to make life easy for compiler developers.
> If my macros produce standards-compliant code and they make my code easier to read and understand, why shouldn't I use them? The problem is they don't make code easier to read and understand. Worse, the unhygienic nature of C macros makes it hard to contain them. I haven't seen your code, so I'm speaking based on what I've seen of mine and others' code. If you dial it back, the person who has to deal with your code…
I once worked at a place that had a platform specific "DEBUG" log macro.
It worked something like: DEBUG(msg); Except, it was defined in such a way that you actually had to have two closing parens, like DEBUG(msg)); It looked syntactically invalid, but whatever the macro did required it.
The entire code base was littered with WTFs like that...
Re: So you think you know C? (2016)
#299> And at this point, I only have to apologize. The test is clearly provocative and may even be a little offensive. I’m sorry if it causes any aggravation. [...] It was a research project in nuclear power plant automation, where absolutely no underspecification was tolerable. I appreciate the apology here, and I can totally understand the concern about the spec in a safety critical environment. Still, all questions on…
Still, I’d be interested to hear about a compiler that doesn’t return 1
gcc (Ubuntu 8.3.0-6ubuntu1~18.10.1) 8.3.0 returns 2 (executes from left to right... at least the first time I ran it).
Re: So you think you know C? (2016)
#300Went to an IRC chat room when I was learning C in school. Asked if you could return a pointer to something that lives on the stack. Was talked down by an all-knowing dude telling me to go read K&R again. Proceeded to write a code sample [1] that showed it is possible (it's not really stable but works reliably in recursive calls IIRC). I do not like this attitude (then again it was just one random dude). [1] https://w…
> it is possible (it’s not really stable but works reliably in recursive calls IIRC). [...] I do not like this attitude
You might want to listen. You’re getting the K&R comment and the downvotes because this does not work, ever. It’s a really, really bad idea. In recursive calls, it might not crash right away, but you will have bad data, the memory at the pointer address will have been overwritten by the next stack frame that’s placed there.
Don’t ever return pointers to local memory because the memory is “gone” and unsafe to use the moment your function returns. Even if you try it and think it works, it can and probably will crash or run incorrectly in any other scenario - different person, different computer, different compiler, different day...
Your comments about getting a warning and ‘However if you wrap the local’s address... it “works”’ should be clues. The warning is the compiler telling you not to do it. The workaround doesn’t work, it only compiles. By using aliasing, you’re only tricking the compiler into not warning you, but the warning is there for a reason.