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

Learn C The Hard Way by Zed Shaw

udemy.com

Post reply on HN
Print view View original

51–60 of 100 posts

Re: Learn C The Hard Way by Zed Shaw

#51

Post by aphyr »

Goladus wrote: post #50
aphyr wrote: post #45

Earlier quoted context omitted.

Huh, really? I always figured piano had an unambiguous mapping from pitch to keys, whereas guitar typically has 2 or 3 possible fingerings for a given pitch. I find it pretty easy to get stuck with awkward positions on my first few times through a guitar piece--except those in which transitional notes are annotated with fret positions. Is that what you mean by "arranged for guitar"?

The mapping from pitch to keys is (generally) clear, but what isn't clear unless you are fairly skilled is the mapping from keys to fingers. eg: Beat 1: root-position C-Major triad (C,E,G) fingers: (1,3,5) Beat 2: first-inversion a-minor triad (C,E,A) fingers: (1,3,?) If the pattern is legato or fast and you can't lift up your hands, playing both G and A with the 5th finger will be difficult for most players. The eas…

Oh, of course! Thanks for the explanation. :)

Re: Learn C The Hard Way by Zed Shaw

#53

Post by jheriko »

I did look at this book a while ago, I was unable to make amendments to the code examples. early versions made common C gotcha mistakes, although of the more subtle and less disasterous kinds... starting with non-standard entry-point function signature and generally relying on non-standard features of particular compilers. fortunately someone else seems to have gotten there in the end... i'd be wary, simply because the author is (as much as I am a fan of much of his work) clearly not an experienced C programmer.

Re: Learn C The Hard Way by Zed Shaw

#54

Post by jheriko »

Locke1689 wrote: post #49
zedshaw wrote: post #32

Earlier quoted context omitted.

memcpy is just fine because it has a size parameter. I think you mean strcpy(), which does cause defects.

Nah, memcpy shouldn't exist (just not for buffer overflow reasons). memcpy is there because someone got their knickers in a twist over possibly being a few cycles faster than memmove, even though the chances that actually matters is tiny, while the chances that you'll accidentally use memcpy when your memory overlaps is much larger.

actually that justification for memcpy is quite poor. usually, performance wise, it is quite easily beatable once you start using the hardware. most implementations I've seen loop byte copies in the most naïve way possible... almost every architecture supports 32-bit copies, most support more... :)

incidentally I've saved some .2-.8ms per frame in a "AAA" (I use the term loosely and with disgust) game title by replacing compiler generated assignment operator in one struct with an explicit 128-byte copy. copying individual bytes is slow, and the compiler is never as sufficiently smart as people claim.

in analagous cases involving memcpy, the fact that memcpy is not memmove saves much less than actually copying the data in a way that squeezes everything out of the data buses. :)

Re: Learn C The Hard Way by Zed Shaw

#55

Post by esbwhat »

zedshaw wrote: post #37
skrubly wrote: post #10

I'm excited - Learn Python the Hard Way completely jumpstarted me into what has become a large internal django site, and I refer back to it often. I really enjoy python, and I thank Zed for the straightforward aproach. So even though I love python I want to see if the same technique can introduce me again to C, a language I never felt comfortable with.

Try going through the HTML version, and drop comments when you hit problems. That'll help me make the book solid.

Are guest comments ever going to be an option? I don't really want to make a disqus account. I understand if not, but I figured I'd ask anyway.

Re: Learn C The Hard Way by Zed Shaw

#56

Post by jheriko »

Symmetry wrote: post #34
mkr-hn wrote: post #25

Earlier quoted context omitted.

That page has examples and detailed explanations to support the criticism.

The problem is that the examples and explanations don't justify the level of castigation. Yes, you should always use strncpy() instead of strcpy() for instance, but that doesn't protect you from all bugs. The example of a safercopy() still relies on the assumption that the pointers given to it are valid, and that assumption is just as impossible prove as the assumption that copy()'s input strings are valid. Safercopy…

"Yes, you should always use strncpy() instead of strcpy() for instance, but that doesn't protect you from all bugs."

I agree with your argument, but I don't enjoy encouraging programmers to use strncpy and co... the reason is simple, I don't want to encourage programmers to stop thinking about their code. Not having to think about something is great, when laziness is acceptable (RAD, web development etc.) but not in the general case...

Most of the time, the programmer should be smart enough to not fall foul of the problems strncpy avoids. The argument against the copy function in "learn C the hard way" implies that the programmer doesn't understand the code, language, or platform particularly well...

Mine is a fundamentally flawed argument though... as much as I want to live in a world where people can write code properly, the truth is idiots will always be out there. Although, as such, I would rather my code did shoot them in the foot if they were stupid enough to load it up and point it that way before firing... :)

Re: Learn C The Hard Way by Zed Shaw

#57

Post by jheriko »

zedshaw wrote: post #41
Jabbles wrote: post #36

Earlier quoted context omitted.

Yes I guess that would be more appropriate. Again, it comes down to the "give it the right inputs" argument. At some point you have to trust the user of the function to call it correctly.

Well I explain all the many reasons this is the wrong way to think about it in the end.

Your argument with permutations of inputs is wrong IMO - this argument can be used to claim that any functionality which calls user code (through callbacks, inheritance, whatever, functors) is also defective. Strictly it may be so, but the defectiveness is massively outweighed by the convenience - the most obvious example is calling a late-binding function - but it extends to easier to grasp examples like the C qsort function or EnumWindows in Win32.

Should we not make library calls because the programmer who wrote the library might have, maybe, possibly, screwed us over in some way perhaps, or because the mechanism can be broken with faulty input?

You trust, potentially, the same programmers every time you trust an executable loader to start running your code... which is pretty much every single time.

Re: Learn C The Hard Way by Zed Shaw

#58

Post by johnohara »

Sambdala wrote: post #23
johnohara wrote: post #18

Earlier quoted context omitted.

If the video course were free, what would you be willing to pay for additional course materials? (i.e. the book, exercise solutions, exclusive live sessions, etc.) I'm not trying to be confrontational here. Online education/coursework/learning needs a pricing structure that makes sense. One that enables thousands of qualified instructors to participate without going broke in the process. I think I understand Zed's "f…

What you're talking about is rebuilding the status quo in a different form. Disruption is taking a $100,000/year teacher from teaching 30 students a year to teaching 30,000.

Generally, a teacher making $100,000 teaches about 125. That's $800.00 per student per year (aprox. $5.00 per student per day). Teaching 30,000 requires a completely different infrastructure. @ $29.00 each, that's $870,000 per year -- roughly 6 teachers plus support staff.

5,000 students per instructor.

My point in all of this is that free is not free and that those who are willing to build courses and content at this scale need to be compensated somehow for their time.

Being able to make a living will draw more people. More instructors, more classes, more choices, better classes, better content, etc.

This is important point that seems to be missing from the online education discussion.

Re: Learn C The Hard Way by Zed Shaw

#59

Post by Sambdala »

johnohara wrote: post #58
Sambdala wrote: post #23

Earlier quoted context omitted.

What you're talking about is rebuilding the status quo in a different form. Disruption is taking a $100,000/year teacher from teaching 30 students a year to teaching 30,000.

Generally, a teacher making $100,000 teaches about 125. That's $800.00 per student per year (aprox. $5.00 per student per day). Teaching 30,000 requires a completely different infrastructure. @ $29.00 each, that's $870,000 per year -- roughly 6 teachers plus support staff. 5,000 students per instructor. My point in all of this is that free is not free and that those who are willing to build courses and content at thi…

"Generally, a teacher making $100,000 teaches about 125."

Only if you count all the classes they teach every day. However, kids don't come to school for just one class a day. Each teacher gets 15 to 30 kids 8 times a day for 1/8th of the day (assuming 8 classes a day). Not that that's really the important point here...

"My point in all of this is that free is not free and that those who are willing to build courses and content at this scale need to be compensated somehow for their time."

He is getting compensated though. At $29.00 a pop. The fact that he puts free material out there will almost definitely raise his compensation, not lower it.

"More instructors, more classes"

You don't necessarily need or want this. If one teacher can teach xx,000 people in a given subject, the teaching market will start to resemble a more 'winner take most' market, allowing those who aren't as good at teaching to find use elsewhere.

It will also allow everyone to learn from the best instead of only 125 people who happen to be in the right school district.

Re: Learn C The Hard Way by Zed Shaw

#60

Post by yxhuvud »

Symmetry wrote: post #34
mkr-hn wrote: post #25

Earlier quoted context omitted.

That page has examples and detailed explanations to support the criticism.

The problem is that the examples and explanations don't justify the level of castigation. Yes, you should always use strncpy() instead of strcpy() for instance, but that doesn't protect you from all bugs. The example of a safercopy() still relies on the assumption that the pointers given to it are valid, and that assumption is just as impossible prove as the assumption that copy()'s input strings are valid. Safercopy…

No, you should NOT use strncpy instead. It can create broken strings that are not NULL terminated.

I would suggest using strlcpy.

Post reply on HN