Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Massacring C Pointers

wozniak.ca

Post reply on HN
Print view View original

81–90 of 300 posts

Re: Massacring C Pointers

#81

Post by bitL »

C'mon, viewing a book from 1990 with the lens of 2018 must be funny of course; almost nothing in programming languages aged well, baring some theoretical principles. Many of the things the book author tried to avoid (like not using integer indexes) were necessary for writing fast code on 4MHz processors with 256kB of RAM in primitive compilers back in the day...

Can you please add some xBase book review to the mix for more outdated fun and facepalming from the heightened point of view on a hill of three decades next? /s

Re: Massacring C Pointers

#82

Post by gumby »

azernik wrote: post #80

Bad reviews are always so much more fun to read than good ones.

To review your comment: "The author's well meaning and accurate comment is that well-written negative reviews are typically far more fun to read than positive ones of any quality -- in the positive case you usually want to simply read the book, while the implication of the comment is that the pleasure of reading the negative ones is a delicious Schadenfreude.

"Regrettably, this insight was obscured by a regrettable poor choice of terminology ("bad" and "good"). The comments, azernik, has enough HN karma to suggest that this error ought be assigned to the casual, off-the-cuff nature of internet commenting, and that this comment is not up to the usual work (i.e. comments) of the author.

Re: Massacring C Pointers

#83

Post by gumby »

It's books like this that lead to inventions like Java and Go, with explicit aims of avoiding certain difficult constructs.

Not that pointers are particularly difficult in the scheme of things, but if someone who doesn't understand them tries to teach them, pointers inevitably do become "difficult"

Re: Massacring C Pointers

#84

Post by GlitchMr »

leodeid wrote: post #17
the_lurker wrote: post #4

Yesterday I encountered a similar program on a HN comment chain as shown in this link. I am genuinely confused as to why this program is bad. I am a student and I do not know the best practices regarding pointers, but it is how I would write a program to combine two strings. Can someone please elaborate why it is bad? Are their any good resources to fill gaps in my knowledge? Thanks in advance. Edit: Thank you guys f…

I haven't touched C in years, but here's my descending "wtf" list: 1. Returns pointer to stack-allocated data, which immediately becomes invalid. Instead, it should be using some sort of allocation (e.g. 'malloc'), or taking in a destination pointer. 2. 'r' is arbitrarily set with length 100. Smaller strings don't need all that space, and larger strings definitely will overrun. 3. The function signature is really awk…

strncpy is not safe strcpy, for any value of safe. Period. str in the name is really misleading as it's not really a string function to begin with.

Re: Massacring C Pointers

#85

Post by AmericanChopper »

laumars wrote: post #78
AmericanChopper wrote: post #54

Earlier quoted context omitted.

I think there’s some truth lurking in there somewhere. I was an Oracle DBA for years, and recently started working on a NoSQL serverless project. I think I’ve been doing a pretty good job of it, but it took a huge amount of effort to get my mind around the new principles. The reason being just about everything I’d learned about RDBMS was a total footgun when it came to NoSQL design. My low level knowledge of how RDBM…

The fact you got there in the end disproves your point. You'd expect any first attempt at a new language, let alone paradigm, to be less than perfect. You can't expect people to be experts before they've even studied a subject. But to argue that any one particular language damages beyond repair ones ability to learn another is simply elitest hyperbole.

I said there was some truth to it. Its obviously an absurd overstatement, but my point was my RDBMS experience made a fair few things more difficult. I initially designed myself into a few corners by applying my experience to solve problems in ways that ended up being hilariously wrong.

Re: Massacring C Pointers

#86

Post by maskros »

huhtenberg wrote: post #79
jmts wrote: post #27

Earlier quoted context omitted.

Most of these points are covered by the other comments. As a C programmer professionally, I'll go into a little more depth, and offer an alternative implementation for comparison. The function in question: char *combine(s, t) char *s, *t; { int x, y; char r[100]; strcpy(r, s); y = strlen(r); for (x = y; *t != '\0'; ++x) r[x] = *t++; r[x] = '\0'; return(r); } 1. The array 'r' is allocated on the stack, and returned fr…

if (NULL == s) Ouch. I haven't seen a single case where this abomination actually helped catching the fearsome 'if (s = NULL)' typo. One needs to be a sloppy typist, not paying attention to what they write, not proof-reading the code before committing and ignoring compiler warnings for this disaster of a notation to be even remotely justified.

Better yet, just use the fact that NULL is false and get shorter, cleaner, and safer code.

  if (!s)

Re: Massacring C Pointers

#87

Post by bitL »

stinos wrote: post #60
narag wrote: post #51

When I was learning C in the eighties, I bought a book about 3D programming, the worst programming book I've read. I believe that examples worked, at least the ones that I typed did, but the style was atrocious. The concept of function parameters seemed to be totally alien to the author. The idiot created x1, X1, x2, X3, x, xthis, xthat... variables instead. He was a former BASIC book author too. I can't warn you bec…

He was a former BASIC book author too Hmm, I'm starting to see a pattern. Is it possible BASIC, plus lack of internet back in the day, plus attrocious books are the reasons for truning poeple into terrible programmers? I happen to know only a couple of seniors but without exception their code, no matter what language written in today, is horrible on all fronts. I used to think it was a lack of attention to detail, th…

Replace BASIC with JavaScript and book about Scala language on Spark for a contemporary topic adjustment. You'll see the same there.

Re: Massacring C Pointers

#88

Post by gmueckl »

saagarjha wrote: post #45
nwmcsween wrote: post #40

Earlier quoted context omitted.

Well to be pedantic C++'s type system doesn't check for that either it just passes around a size_t and char *.

I was referring to std::string, which is what you should be using if you're handling textual data natively.

And it's even possible to use std::string as a buffer for binary data including NULs. I won't recommend it, but it works.

Re: Massacring C Pointers

#89

Post by faceplanted »

eesmith wrote: post #73
nwmcsween wrote: post #39

Earlier quoted context omitted.

The issue with really learning computer science outside top well known schools is that you're basically on your own for education (or worse if taught wrong). Open source software somewhat teaches you things but usually by trial by fire.

Really? I went to a non-top school and putting aside the formal education component, I felt like I also had plenty of co-learning. That is, I remember many study groups where we helped each other learn, including for programming. I certainly didn't feel like I was on my own.

Similar experience here, my university helped people form study groups near final exams and had a "homework club", where final year and grad students were paid to help first and second year students with their assignments for a couple hours a week, and people were encouraged to meet each other in that club and find "study buddies" (but no-one actually called it that, because ugh)

Covered everything from the programming to the multivariable calculus and data science (much harder to find students confident enough to teach others for those last two though)

Re: Massacring C Pointers

#90

Post by pjc50 »

bitL wrote: post #81

C'mon, viewing a book from 1990 with the lens of 2018 must be funny of course; almost nothing in programming languages aged well, baring some theoretical principles. Many of the things the book author tried to avoid (like not using integer indexes) were necessary for writing fast code on 4MHz processors with 256kB of RAM in primitive compilers back in the day... Can you please add some xBase book review to the mix fo…

No, all of that example was malpractice in the 80s when it was written. Note the context: it's highlighted as malpractice in a talk by Brian Kernighan!
Post reply on HN