"which I believe is the worst C programming text book ever written *sigh* Almost every single example in that book was wrong in some way or other" (talking about "Mastering C Pointers" by Robert J. Traister). Thank you Brian for calling this out.
Far be it from me to disagree with a God like BWK, the worst C textbook I have ever come across was "The Big Red Book of C" by Kevin Sullivan. Even 25 years on, its fundamental awfulness is still seared into my brain. A C textbook that didn't cover pointers, structs...
>who fixes this bug on the other side? for anyone interested I've patched out the alarm of the original youtube encoding (ffmpeg is magic, really), idk how to make a pull request on yt so here's a link to the branch www.dropbox.com/s/hsjdzcakl8h8yyc/Elements%20of%20Programming%20Style%20-%20Brian%20Kernighan%20%28No%20Alarm%29.mp4?dl=0
We learn many things by making attempts, making mistakes, and iterative improvement. Text books and other learning resources tend to show us the "final product" rather than all the ways something could have been done but wasn't. This makes it hard to learn the wisdom of others. Prof Kernighan does a great service in calling out and explaining these bad examples. More please! If there was a series called Breaking Bad (Code), I would watch.
I just naturally assumed that the alarm was to warn people that reading the next code example could risk permanent mental health issues for seasoned programmers. 🙂
Fantastic presentation! Kernighan really is a very intelligent man. What this made me realize, on the topic of whether or not you need to know algebra or maths to be a good programmer, is that you do not need to be good at them, though it can be of great value to have a good understanding of the reasoning and deduction done in mathematics and algebra. I'm referring to the situations around the 40:00 mark, when he explains how he 'tests his edge cases'. Very simple, yet so clever.
04:00 - one reason why UNIX evolved and survived till this very day is that it was cleverly written in simple fashion, like the below code. Not like the above code.
"It's a good thing we are programmers and techies making this video, so we can do everything ourselves and don't need to hire a sound technician", they thought.
If you are out of memory or sth, you will probably still get a non-null pointer back. If you get a null pointer back, it probably is way too late to handle it in a meaningful way. On top of that, segfaults are particularly easy to debug, especially if they happen in a place like this, where the core dump points you right at the problem. There are different completely valid practices.
Linux won't even give you a null pointer, you'll get a pointer to an uncommitted page that will segfault if you try to use it. (Or the os will kill a random process for you.)
And the MOST important thing is that these rules become a deep part of your psyche. You don't even think about them...you know them at an instinctual level. Even little things make the hairs on the back of your neck stand up. In the "blink-comparator" part of the talk - the fact that one line of code is indented differently says "Someone got into this code and changed it AFTER it was copy-pasted." - so you wonder which is the original and which was messed with later. You think: What ELSE did they change - and why? My favorite bad code example is this one: void write_string_overheat() { output_string[0] = 'o'; output_string[1] = 'v'; output_string[2] = 'e'; output_string[3] = 'r'; output_string[4] = 'h'; output_string[5] = 'e'; output_string[6] = 'a'; output_string[7] = 't'; output_string[8] = '\0'; write_output_string(); } Although the code itself is bad on MANY levels, that's not the problem. The problem is that I'm reliably informed that it comes from a nuclear reactor monitoring system...but hey - I'm sure that all the rest of the code will be really nicely written. OK? ...Probably?...Maybe?!
remove_trailing_asterisk (37:52) should be renamed truncate_after_first_asterisk, as the loop does not break upon first non-asterisk, thus will truncate the string on every asterisk, which means it also doesn't need to be a trail loop (with a prior forward loop in the strlen) but could just forward loop and truncate on the first asterisk found.
I always despise being ridiculed for not being able to determine the function of FORTRAN code which I have NOT yet been shown, even when it was written for a lecture in 1973 AD. Your editor is a
At 44:32 this actually can fail in so many ways that's I'm not gonna bother listing them all. Just don't do it that way. If you don't know how to do it then use a library.
Why idioms matter (3) -- very interesting...definitely a better reason to be shy of them than "we like to see the condition at the top" even when a loop will always be executed at least once.
When he mentions "the worst book on C ever written", I thought it was going to be a joke and the book in question would be "Kernighan and Ritchie".... but having seen some examples of "The Horror Book", I want to know the title and author so I can see the horror for myself.
Has anyone ever read the book he's talking about at 5:30? The Elements of Programming Style? I ask because Strunk & White is chock block full of nonsense.
Yes, I received a copy as a gift. Strunk & White was written for its time. Everything ages, especially when "unwashed laypeople" begin to publish with greater ease than the dedicated craftspeople of yore. Both books are pleas from persons seeking to keep systems from falling apart in the hands of the rabble. both o' 'em, like... y'know... tryina like keep like myself from like spressin' wot i like think how I like... like, y'know... :D
At 25:32, the line labelled '6' KR = KB - KB/KA*KA ... Mulpiclication and division should be the same priority, carried out left to right. There should be parens around KA*KA to keep both in the denominator, otherwise there's one KA in the numerator and one in the denom, which cancel out, so the right hand becomes KB - KB, which is zero
I would disagree at 51:36. The more repetitive version shows more clearly what's happening. However, I assume Brian meant the latter variant was better when the actual code is more than the few number of lines we saw in the example (can't fit any larger code on one slide perhaps)
... and on this video, not to let the obviously brilliant camera operate also, in a word....sucks. I just do not think I can take any more of this slop on TH-cam. Not to even try to frame up the screen as well............I must go as my head is ready to explode and I don't want to mess up the wallpaper in this room.
That last naming example looks like a throwback to the pathology of the old UK computer manufacturer ICL, whose trainees were prone to naming variables after people. (They had an OS called George III.) Did someone get hold of a really old textbook?
Most code that I see suffers from not verifying return values. If you check return values and string lengths before using them then you can catch 99.9% of errors without thinking about them. Always always check your return values!
Thank you so much for sharing this -- and another reason to be thankful of Prof. Kernighan existence. 1:06:04 That's so damn true. And because of that, utterly shitty programming is everywhere in Physics, starting from the disease commonly known as ROOT. I'm just waiting for something horrible happening just because programs aren't properly and clearly written. Oh, well, we actually lost a mars lander (ESA's Schiapparelli) to what really looked like an integer underflow, so... Yeah, there you are.
I used to write my multiway decisions like the one at 48:18. At some point I decided to do it like presented here because readability is much better - not just for yourself but also everyone else who might look at your code
i struggled a bit with this one - it seems to fall into the "too clever" category not only because the conditionals have side effects (assignments) but side effects that are expected to be false for "proper" behavior (continued assignments in ELSE IFs). Perhaps i haven't written/read enough C or grown too accustomed to programming with Exceptions to see this as idiomatic (even in 2009), but it took a triple take before i realized what was going on here.
I guess I'm just too clever for my own good, but the first example in C++ is a ternary operator inside the Boolean check part of an if statement, it's an if statement in an if statement. While the readability improvement given in the example works, it's not actually what's happening. Unfolded it should look like: if (Armed){ if ( Vcnt >= Threshold) { // do stuff } } else { if ( Vcnt
Re: why idioms matter -- in Accelerated C++, Koenig and Moo consistently use the i !=n idiom instead, which tests for equality rather than less-than-ness. While that can break if someone messes with the index variable in the loop, i.e. they can miss their stop, you shouldn't be doing that anyway, and it extends to cases where == and != are defined but not necessarily < or
36:57 You wouldn't write it like that in Python! You could just do stdout.write(stdin.read()) and the EOF gets handled by the read call. This is a problem with trying to translate C idiom into Python, like other examples misapplied Fortran idiom to C.
"....or install bad software on your Windows machines..." The original Internet Worm, which ran on Unix, exploited exactly the kind of bug he's talking about here...
A huge number of examples have to do with manipulation of zero-terminated strings in C. I just don't do that these days. Use std::string in C++ or implement something equivalent if you don't have access to it.
Example at 19:27 will be incorrect if `a` has side effects, e.g. `a++`. Function macros should behave like functions. If you wrap the expression in a do-while(0) loop, set a to some variable inside the loop, and compute the expression using the new variable you should achieve the desired behavior.
That's correct but sort of tricky and still kind of macro abuse. All of the character classification functions are now just that, functions, I checked on cplusplus.com and wrote a quick test program to verify it...I'm sure some people are still using implementations somewhere at least in C where they may be macros. Inline functions are a better solution for most programmers than carefully crafted macros.
The second flip macro doesn't give the wrong result for me. I did get a larger number but it was because the compiler converted the short to an int so the extra bits made the number larger (maybe that's why the original example &'d after a left shift), but the original 16 bits are flipped like it's supposed to.
On the "if, if, if bad, bad, bad" I never understand why the "}" are put at the end of the line in every sentence, something as: If (A >= 32) { A--} I can understand becose all start at end on the same line, but it the code was longer you need to search ( if is too long don't highlight if the cursor move) and is really hard to see it but if the "{" start on a new line even if the code is huge or with a lot of {} is much more easy to follow it, only place the cursor when the "{" or "}" is and move it up or down and you will see and can check it is much more easy and fast to read it. I think is the most bizarre think who someone to help programers Curiosity this thick is used as "} else {" and I used it but only becouse } and { are very close and only used 1 line instead 3. A bizarre thing than I do is join } on the same line, the only problem is in this case the first } don't match the column but if are a lot of "}" on the same line is much more compact and still easy to read it
C is a shitty language. You have to rely on idioms!!! Full of pitfalls if you don’t know all the intricacies of the language. Having said that this is the language I use the most because it was advocated by so called useless software engineers and not real engineers.
Honestly, I expected more of him for that topic. Maybe the title was chosen a little bit off but this is not a lecture about the elements of programming style. It is, in my opinion, a rant on other peoples decisions how to code a certain task. It would have been better to start right off with a list of common pitfalls and then give some solutions, rather than going down every mistake by itself. Also, programming style is not just about making mistakes. Commenting alone would have deserved a much larger part of the whole presentation. Am I the only one who is irritated by the things I said??
You have the Bell Lab greats. Ritchie, Thompson etc.. But good ol Kernighan will always be the official orator and grandfather face of C and Unix to me.
I feel like you didn't actually watch the video, or understand what it was about. On the other hand If you would like to learn programming, C is not necessarily (probably not) the best place to start in the current era unless you want to write hardware drivers. Java/Python/JavaScript are some the most popular languages currently which means that they a lot of support and help available. Pick a language that is popular in the industry you are more interested in. Java is usually server side, Python - AI/machine learning/data science etc., JavaScript frontend stuff and now backend (Node.js). Theres loads more but it is good to understand that most iindustries have languages that have become defacto (but that doesn't mean they cannot be interchanged)
Example at 31:52 bothers me. Calls calloc then disects issue in the loop that zeroes out the allocated memory, but never mentions that calloc returns memory that is already zero filled.
It's not setting the value to zero, it's setting the value to the index. The assignment is "= i", not "= 0". It's superfluous for the first element, but excluding that causes an extra boundary condition.
The fact that calloc returns zeroed memory is completely irrelevant which is probably why it isn't mentioned. The code you're referring to is setting each element in the array (array) to the current value of the iterator (i) in the range 0
I don't get a lot of thse examples, this is the old-school "blame the programmer" instead of the friggin' language designer who put so many possibilities of shooting yourself in the foot. Why don't we have a typed for loop in C after 45+ years?
Yes. I saw his page of different for loops and was aghast he didn't realise that it was Ken Thompson's fault that he designed it to support multiple idioms. I found this C++ lecture to be similarly entertaining: th-cam.com/video/WRQ1xqYBKgc/w-d-xo.html Rather than require guidelines for the proper use of your language, make it so the compiler issues warnings, or better yet make it so you can only follow good practise as the language design prohibits writing it any other way. C++ is justly criticised, but it didn't help by starting off being based on C.
You're kidding, right? The first 'C' compiler was written in assembler on a machine that had 8kb of memory. How big's your IDE? You wouldn't have an internet today to whinge and complain on if not for the utility of 'C' leading to its uptake. You may, if you're a coder, be writing in COBOL or Fortran '17. (ugh!) Perhaps you'd feel better moving over to VB, a language that provides the "training wheels" you feel are appropriate. A craftsman doesn't blame his tools; he learns to use them with competence.
Hmm this is the R dude of K&R lint style but is now clueless about f77? sucks getting old, lots of real engineering from banking, finite elements all still use it. fortran is the Supreme Ruler of numbering crunching. he needs to optimize his loops and use openmp or mpich, this approach is too generic and outdated
His comment that people are more likely to use Fortran 9x than either IV nor 77 isn't correct, then? When I was a kid in the 80's I was a big fan of Fortran 77, but I thought that the 88 and 99 revisions of Fortran really did catch on -- is that not true? At 27:33 he remarks that Fortran has evolved enormously since Fortran 77...he is not ignorant of modern Fortran, apparently.
In the 1978 edition of the book the talk is based on, they actually say the new version of Fortran 77 will make a lot of his examples look silly, by giving you better ways to write things, but nobody has that compiler yet. They suggested people use Ratfor, which was invented by Kernighan, tho improved a bit by others afterwards: en.wikipedia.org/wiki/Ratfor The problem with RATFOR was just the problem with any pre-processor, the compiler, and these days, the debugger is still working with the actual messy generated FORTRAN anyway. The argument would be with all the structured programming control structures available, you are so much less likely to need to look at anything in the debugger anyway. I think I remember him referencing FORTRAN 88 or 99 as what people would probably be using now early on in the video. Some of the criticisms are probably merited, but many fall in the realm of "Why would you ever even be using that language when you could do it in C or C++ or languages both dependent on C or C++ to even run and that were designed by C or C++ programmers who had used the languages for years and then built something nicer on top of them?" Which is a rather backhanded insult to one of the two parents of C where it was developed on machines with 1 ten thousandth the computing power of your phone. C strings are a true health hazard, on the other hand, as are any buffers being handed around from function to function without an accurately discoverable size...people's opinions vary on how well recent updates to the C standard address these problems, but few C++ programmers directly interact with them anymore. The safest way to deal with them is probably to avoid them wherever possible.
Alarm goes off at 56:15. 😲
Lecture resumes at 56:54 🤓
Christ
"which I believe is the worst C programming text book ever written *sigh* Almost every single example in that book was wrong in some way or other" (talking about "Mastering C Pointers" by Robert J. Traister). Thank you Brian for calling this out.
27:47 that is...
Far be it from me to disagree with a God like BWK, the worst C textbook I have ever come across was "The Big Red Book of C" by Kevin Sullivan. Even 25 years on, its fundamental awfulness is still seared into my brain. A C textbook that didn't cover pointers, structs...
Don’t comment bad book- -rewrite them.
@@HighestRank He kinda did.
Loud noise at 56:12 .
OMG ...
Too late. Mawp...mawp...
who fixes this bug on the other side?
>who fixes this bug on the other side?
for anyone interested I've patched out the alarm of the original youtube encoding (ffmpeg is magic, really), idk how to make a pull request on yt so here's a link to the branch
www.dropbox.com/s/hsjdzcakl8h8yyc/Elements%20of%20Programming%20Style%20-%20Brian%20Kernighan%20%28No%20Alarm%29.mp4?dl=0
lol, it's like "TIME UP!!"
We learn many things by making attempts, making mistakes, and iterative improvement. Text books and other learning resources tend to show us the "final product" rather than all the ways something could have been done but wasn't. This makes it hard to learn the wisdom of others. Prof Kernighan does a great service in calling out and explaining these bad examples. More please! If there was a series called Breaking Bad (Code), I would watch.
To the guy who edited the sound for this, please take a slap for around 56 mins. Thanks for the talk otherwise.
I can listen to this guy all day long.
I've realized white hair and bald is more cool than a 6 pack abs by seeing this guy
The part about macro functions with parameters that have side effects was very eye opening. Fascinating stuff.
Thank you IAS for nearly giving me a heart attack. I'd edit out that alarm. ;)
4 years later, headphones on while listening to this and I'm almost positive my heart skipped a beat
I just naturally assumed that the alarm was to warn people that reading the next code example could risk permanent mental health issues for seasoned programmers. 🙂
Fantastic presentation! Kernighan really is a very intelligent man.
What this made me realize, on the topic of whether or not you need to know algebra or maths to be a good programmer, is that you do not need to be good at them, though it can be of great value to have a good understanding of the reasoning and deduction done in mathematics and algebra. I'm referring to the situations around the 40:00 mark, when he explains how he 'tests his edge cases'.
Very simple, yet so clever.
04:00 - one reason why UNIX evolved and survived till this very day is that it was cleverly written in simple fashion, like the below code. Not like the above code.
Wow. Pragmatic with just enough humor. Great video.
He wore me out in 6 minutes, what with the flailing of arms and rambling speaking.
"It's a good thing we are programmers and techies making this video, so we can do everything ourselves and don't need to hire a sound technician", they thought.
33:30 Unless you enjoy playing with segmentation faults, check for NULL pointers before using dynamically allocated arrays.
If you are out of memory or sth, you will probably still get a non-null pointer back. If you get a null pointer back, it probably is way too late to handle it in a meaningful way. On top of that, segfaults are particularly easy to debug, especially if they happen in a place like this, where the core dump points you right at the problem.
There are different completely valid practices.
Linux won't even give you a null pointer, you'll get a pointer to an uncommitted page that will segfault if you try to use it. (Or the os will kill a random process for you.)
And the MOST important thing is that these rules become a deep part of your psyche. You don't even think about them...you know them at an instinctual level.
Even little things make the hairs on the back of your neck stand up. In the "blink-comparator" part of the talk - the fact that one line of code is indented differently says "Someone got into this code and changed it AFTER it was copy-pasted." - so you wonder which is the original and which was messed with later. You think: What ELSE did they change - and why?
My favorite bad code example is this one:
void write_string_overheat()
{
output_string[0] = 'o';
output_string[1] = 'v';
output_string[2] = 'e';
output_string[3] = 'r';
output_string[4] = 'h';
output_string[5] = 'e';
output_string[6] = 'a';
output_string[7] = 't';
output_string[8] = '\0';
write_output_string();
}
Although the code itself is bad on MANY levels, that's not the problem. The problem is that I'm reliably informed that it comes from a nuclear reactor monitoring system...but hey - I'm sure that all the rest of the code will be really nicely written. OK? ...Probably?...Maybe?!
remove_trailing_asterisk (37:52) should be renamed truncate_after_first_asterisk, as the loop does not break upon first non-asterisk, thus will truncate the string on every asterisk, which means it also doesn't need to be a trail loop (with a prior forward loop in the strlen) but could just forward loop and truncate on the first asterisk found.
Fixing the bug by renaming the function so it carefully describes what's wrong with it!! Yeah! Way to go!!!!
This silence after 1:03:22 joke though, feels bad
I assume that the Dick Hamming he mentions in the beginning is the numerical analysis guru.
I always despise being ridiculed for not being able to determine the function of FORTRAN code which I have NOT yet been shown, even when it was written for a lecture in 1973 AD.
Your editor is a
cretin.
2:49 take out your earphone. OR even better don't use earphone to watch this video.
Thanks, saw this comment just 10 secs before it happened.
As relevant today as it was 45 years ago.
I was always told, and I always follow, it is easier to fix a crock than it is to try and explain it.
This guy talked about idioms being important and then made AWK arrays be 1 indexed
Is this audience humorless?
The audio is likely just recorded from the podium microphone, which are quite directional, not picking up any of the audience reactions.
At 44:32 this actually can fail in so many ways that's I'm not gonna bother listing them all.
Just don't do it that way. If you don't know how to do it then use a library.
Why idioms matter (3) -- very interesting...definitely a better reason to be shy of them than "we like to see the condition at the top" even when a loop will always be executed at least once.
When he mentions "the worst book on C ever written", I thought it was going to be a joke and the book in question would be "Kernighan and Ritchie".... but having seen some examples of "The Horror Book", I want to know the title and author so I can see the horror for myself.
"Mastering C Pointers: Tools for Programming Power" by Robert J. Traister
Has anyone ever read the book he's talking about at 5:30? The Elements of Programming Style? I ask because Strunk & White is chock block full of nonsense.
I've read it - fairly interesting short book. As Kernighan says rules (available on linked wikipedia page) haven't changed much -
Yes, I received a copy as a gift.
Strunk & White was written for its time. Everything ages, especially when "unwashed laypeople" begin to publish with greater ease than the dedicated craftspeople of yore.
Both books are pleas from persons seeking to keep systems from falling apart in the hands of the rabble.
both o' 'em, like... y'know... tryina like keep like myself from like spressin' wot i like think how I like... like, y'know... :D
i cant hear you
22:00
Avoid macros TO DO COMPUTATIONS
I still can do,
#define fucking
And,
int fucking main(){}
I've used PL/1 and far, far preferred it to COBOL.
I love CoBOL... It's like Assembler with English instead of Mnemonics.
At 25:32, the line labelled '6' KR = KB - KB/KA*KA ... Mulpiclication and division should be the same priority, carried out left to right. There should be parens around KA*KA to keep both in the denominator, otherwise there's one KA in the numerator and one in the denom, which cancel out, so the right hand becomes KB - KB, which is zero
I would disagree at 51:36. The more repetitive version shows more clearly what's happening. However, I assume Brian meant the latter variant was better when the actual code is more than the few number of lines we saw in the example (can't fit any larger code on one slide perhaps)
... and on this video, not to let the obviously brilliant camera operate also, in a word....sucks. I just do not think I can take any more of this slop on TH-cam. Not to even try to frame up the screen as well............I must go as my head is ready to explode and I don't want to mess up the wallpaper in this room.
These videos help with developing the common sense of programming. Thank you all
i used to call out the style issues in code reviews by their number.in the back of the book. big fan. .
Allman style is still the most readable and therefore the best coding style.
that is passion , how awesome to have passion to your field , not like all those who major computer science for money.
That last naming example looks like a throwback to the pathology of the old UK computer manufacturer ICL, whose trainees were prone to naming variables after people. (They had an OS called George III.) Did someone get hold of a really old textbook?
Of course King George III was the insane one...just saying.
I cant see the program on screen ... first 2 mims...
one of the great wizards
Most code that I see suffers from not verifying return values. If you check return values and string lengths before using them then you can catch 99.9% of errors without thinking about them. Always always check your return values!
Thank you so much for sharing this -- and another reason to be thankful of Prof. Kernighan existence.
1:06:04 That's so damn true. And because of that, utterly shitty programming is everywhere in Physics, starting from the disease commonly known as ROOT. I'm just waiting for something horrible happening just because programs aren't properly and clearly written. Oh, well, we actually lost a mars lander (ESA's Schiapparelli) to what really looked like an integer underflow, so... Yeah, there you are.
I used to write my multiway decisions like the one at 48:18. At some point I decided to do it like presented here because readability is much better - not just for yourself but also everyone else who might look at your code
i struggled a bit with this one - it seems to fall into the "too clever" category not only because the conditionals have side effects (assignments) but side effects that are expected to be false for "proper" behavior (continued assignments in ELSE IFs). Perhaps i haven't written/read enough C or grown too accustomed to programming with Exceptions to see this as idiomatic (even in 2009), but it took a triple take before i realized what was going on here.
Finally I've got the right and authentic pronunciation of the mysterious char keyword by the author (the K of the K&R). It's at 28:30.
Don't listen to him. He can't format his code correctly. So-called K&R style is an abomination.
I guess I'm just too clever for my own good, but the first example in C++ is a ternary operator inside the Boolean check part of an if statement, it's an if statement in an if statement. While the readability improvement given in the example works, it's not actually what's happening. Unfolded it should look like:
if (Armed){
if ( Vcnt >= Threshold) {
// do stuff
}
} else {
if ( Vcnt
ignore. 33:52
This video should have more views
gets, sprintf, etc., should simply be deleted from libc. No code should still be using them.
and printf with non-constant first argument
Gets has been deleted 🥳
*nice* **work**
Only the podium mic is on, even after the sound man checked. Sound people have to prove how dumb they are to become sound people. Sound people suck.
Re: why idioms matter -- in Accelerated C++, Koenig and Moo consistently use the i !=n idiom instead, which tests for equality rather than less-than-ness. While that can break if someone messes with the index variable in the loop, i.e. they can miss their stop, you shouldn't be doing that anyway, and it extends to cases where == and != are defined but not necessarily < or
36:57 You wouldn't write it like that in Python! You could just do stdout.write(stdin.read()) and the EOF gets handled by the read call. This is a problem with trying to translate C idiom into Python, like other examples misapplied Fortran idiom to C.
Luckily, Python finally supports assignment expressions (PEP 572) so we can now directly use this beautiful C idiom. ;-)
"....or install bad software on your Windows machines..."
The original Internet Worm, which ran on Unix, exploited exactly the kind of bug he's talking about here...
A huge number of examples have to do with manipulation of zero-terminated strings in C. I just don't do that these days. Use std::string in C++ or implement something equivalent if you don't have access to it.
A very short book: "elements of style for regular expressions"
Example at 19:27 will be incorrect if `a` has side effects, e.g. `a++`. Function macros should behave like functions. If you wrap the expression in a do-while(0) loop, set a to some variable inside the loop, and compute the expression using the new variable you should achieve the desired behavior.
That's correct but sort of tricky and still kind of macro abuse. All of the character classification functions are now just that, functions, I checked on cplusplus.com and wrote a quick test program to verify it...I'm sure some people are still using implementations somewhere at least in C where they may be macros. Inline functions are a better solution for most programmers than carefully crafted macros.
it would be nice to see the slides?
That's great. After I posted this while it was playing I started seeing slides. :)
audio too quiet.
19:00 Both flip macros gives wrong result.
The second flip macro doesn't give the wrong result for me. I did get a larger number but it was because the compiler converted the short to an int so the extra bits made the number larger (maybe that's why the original example &'d after a left shift), but the original 16 bits are flipped like it's supposed to.
coldgatorademan Either...gives. You’ve been trolled by the OP’s bad English.
@@HighestRank lol
Javascript???
I am sad to hear the my PL/1 book is now a relic of a dead language. :)
On the "if, if, if bad, bad, bad" I never understand why the "}" are put at the end of the line in every sentence, something as:
If (A >= 32) { A--}
I can understand becose all start at end on the same line, but it the code was longer you need to search ( if is too long don't highlight if the cursor move) and is really hard to see it but if the "{" start on a new line even if the code is huge or with a lot of {} is much more easy to follow it, only place the cursor when the "{" or "}" is and move it up or down and you will see and can check it is much more easy and fast to read it.
I think is the most bizarre think who someone to help programers
Curiosity this thick is used as "} else {" and I used it but only becouse } and { are very close and only used 1 line instead 3.
A bizarre thing than I do is join } on the same line, the only problem is in this case the first } don't match the column but if are a lot of "}" on the same line is much more compact and still easy to read it
C is a shitty language. You have to rely on idioms!!! Full of pitfalls if you don’t know all the intricacies of the language. Having said that this is the language I use the most because it was advocated by so called useless software engineers and not real engineers.
Honestly, I expected more of him for that topic. Maybe the title was chosen a little bit off but this is not a lecture about the elements of programming style. It is, in my opinion, a rant on other peoples decisions how to code a certain task. It would have been better to start right off with a list of common pitfalls and then give some solutions, rather than going down every mistake by itself. Also, programming style is not just about making mistakes. Commenting alone would have deserved a much larger part of the whole presentation. Am I the only one who is irritated by the things I said??
You have the Bell Lab greats. Ritchie, Thompson etc..
But good ol Kernighan will always be the official orator and grandfather face of C and Unix to me.
Did he mentioned which recently published books are good for learning C?
I feel like you didn't actually watch the video, or understand what it was about. On the other hand If you would like to learn programming, C is not necessarily (probably not) the best place to start in the current era unless you want to write hardware drivers. Java/Python/JavaScript are some the most popular languages currently which means that they a lot of support and help available. Pick a language that is popular in the industry you are more interested in. Java is usually server side, Python - AI/machine learning/data science etc., JavaScript frontend stuff and now backend (Node.js). Theres loads more but it is good to understand that most iindustries have languages that have become defacto (but that doesn't mean they cannot be interchanged)
Maybe his own book on C
No need for recent books, just get "the c programming language" by him and Dennis ritchie
C programming by Stephen
Cs50 recommended
I've learned that if the code looks like a mess it's most likely a mess, so change it. If it looks pretty, clean and tidy it's the best solution.
_Okay!_
Example at 31:52 bothers me. Calls calloc then disects issue in the loop that zeroes out the allocated memory, but never mentions that calloc returns memory that is already zero filled.
It's not setting the value to zero, it's setting the value to the index. The assignment is "= i", not "= 0". It's superfluous for the first element, but excluding that causes an extra boundary condition.
The fact that calloc returns zeroed memory is completely irrelevant which is probably why it isn't mentioned.
The code you're referring to is setting each element in the array (array) to the current value of the iterator (i) in the range 0
I don't get a lot of thse examples, this is the old-school "blame the programmer" instead of the friggin' language designer who put so many possibilities of shooting yourself in the foot. Why don't we have a typed for loop in C after 45+ years?
Yes. I saw his page of different for loops and was aghast he didn't realise that it was Ken Thompson's fault that he designed it to support multiple idioms.
I found this C++ lecture to be similarly entertaining: th-cam.com/video/WRQ1xqYBKgc/w-d-xo.html
Rather than require guidelines for the proper use of your language, make it so the compiler issues warnings, or better yet make it so you can only follow good practise as the language design prohibits writing it any other way. C++ is justly criticised, but it didn't help by starting off being based on C.
You're kidding, right?
The first 'C' compiler was written in assembler on a machine that had 8kb of memory. How big's your IDE?
You wouldn't have an internet today to whinge and complain on if not for the utility of 'C' leading to its uptake. You may, if you're a coder, be writing in COBOL or Fortran '17. (ugh!)
Perhaps you'd feel better moving over to VB, a language that provides the "training wheels" you feel are appropriate.
A craftsman doesn't blame his tools; he learns to use them with competence.
Too much rambling and excessive waving of arms, etc. This style of speaking quickly wears the listener out.
Hmm this is the R dude of K&R lint style but is now clueless about f77? sucks getting old, lots of real engineering from banking, finite elements all still use it. fortran is the Supreme Ruler of numbering crunching. he needs to optimize his loops and use openmp or mpich, this approach is too generic and outdated
His comment that people are more likely to use Fortran 9x than either IV nor 77 isn't correct, then? When I was a kid in the 80's I was a big fan of Fortran 77, but I thought that the 88 and 99 revisions of Fortran really did catch on -- is that not true? At 27:33 he remarks that Fortran has evolved enormously since Fortran 77...he is not ignorant of modern Fortran, apparently.
_"Hmm this is the R dude of K&R ..."_
No, he's the K in K&R. Dennis Ritchie, the R, died in 2011.
In the 1978 edition of the book the talk is based on, they actually say the new version of Fortran 77 will make a lot of his examples look silly, by giving you better ways to write things, but nobody has that compiler yet. They suggested people use Ratfor, which was invented by Kernighan, tho improved a bit by others afterwards: en.wikipedia.org/wiki/Ratfor
The problem with RATFOR was just the problem with any pre-processor, the compiler, and these days, the debugger is still working with the actual messy generated FORTRAN anyway. The argument would be with all the structured programming control structures available, you are so much less likely to need to look at anything in the debugger anyway.
I think I remember him referencing FORTRAN 88 or 99 as what people would probably be using now early on in the video.
Some of the criticisms are probably merited, but many fall in the realm of "Why would you ever even be using that language when you could do it in C or C++ or languages both dependent on C or C++ to even run and that were designed by C or C++ programmers who had used the languages for years and then built something nicer on top of them?" Which is a rather backhanded insult to one of the two parents of C where it was developed on machines with 1 ten thousandth the computing power of your phone.
C strings are a true health hazard, on the other hand, as are any buffers being handed around from function to function without an accurately discoverable size...people's opinions vary on how well recent updates to the C standard address these problems, but few C++ programmers directly interact with them anymore. The safest way to deal with them is probably to avoid them wherever possible.
SenorQuichotte he is K of K&R