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

261–270 of 300 posts

Re: Massacring C Pointers

#261

Post by ziotom78 »

ryandrake wrote: post #252
ziotom78 wrote: post #124

Earlier quoted context omitted.

This is some very good advice! I am teaching a C++ class and am struggling with the quality of the code my students are producing. Their programs output the correct answer, yet the style is really lacking. Periodic code reviews of some selected problems would be extremely useful, thank you for the tip!

> I am teaching a C++ class and am struggling with the quality of the code my students are producing. Their programs output the correct answer, yet the style is really lacking. I remember trying to help fellow students with their C and C++ assignments back in undergrad, and reading some of their code I got the distinct feeling that most of it was “random-walked” code. Like they tried writing things that looked like C…

Yes, that's exactly my own experience. Moreover, we are forced to use ROOT [1] to compute histograms and create graphics: its weird use of OOP makes the students think that they have to use classes even to implement simple functions (e.g., printing a list of values).

[1] https://root.cern.ch/

Re: Massacring C Pointers

#262

Post by caf »

simias wrote: post #149
caf wrote: post #131

Earlier quoted context omitted.

It's not broken, but it is misnamed. This is because it is not intended to work with the same kind of string that the other str* functions work with (ie. an ordinary null terminated string). Instead it's supposed to work with fixed-width string fields that pad out values shorter than the field width with nulls. This is how original UNIX directory entries were stored. See how the name is copied into u.u_dbuf here: htt…

I see your point but at this point I think it's just a matter of taste. I don't really see how having a function meant to deal with a special case of character buffers disguised as a general purpose string manipulation routine in the stdlib could be considered reasonable. I understand why it's here, I understand the history, I understand why it made sense at some point to have such a function but you won't be able to…

It seems fairly unlikely that the C standard would add strlcpy() and strlcat() when it already has strcpy_s() and strcat_s() in Annex K.

Re: Massacring C Pointers

#263

Post by btschaegg »

ben509 wrote: post #230
phaedrus wrote: post #211

When I started my CS degree the school was transitioning from teaching C++ to teaching Java, and the state of instruction in C++ was almost as bad as these examples. I had a professor who wanted us to use "new Foo()" everywhere in our code (even local / static variables) because it, "gets the students ready for Java." No matching delete, of course, or mention of RAII. We were supposed to "pretend" we had a garbage co…

> I think he took it with more grace than I deserved. That kind of righteous fury is very common in high school and undergrads. Teachers have to perform in front of a tough crowd.

> Teachers have to perform in front of a tough crowd.

Certainly true. OTOH, there's hardly anything worse than a teacher with Dunning-Krunger syndrome when it comes to conveying the essentials of low-level programming to newcomers, so I would say that such a reaction is justifiable to a certain extent (as long as the tone wasn't too aggressive).

Of course, it doesn't necessarily have to be the teacher's problem. I remember my first programming teacher in high school explaining in the very first lesson that honestly, he didn't have much programming experience (being a math professor) and had just dabbled a bit with pascal, but [sic] "the administration desperately were looking for someone to teach this course" and he didn't really have a say in it.

Re: Massacring C Pointers

#264

Post by laumars »

hoosieree wrote: post #255
laumars wrote: post #78

Earlier quoted context omitted.

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 think it was Alan Kay who said something like "arrogance in computing is measured in nano-Dijkstras", so I agree that there's a nugget of truth packed with a large amount of elitist hyperbole. The nugget of truth is that the paradigm you start with (and the longer you stick with it) influences your problem-solving process, and shapes your way of thinking in ways we don't necessarily notice. If you have a bunch of i…

The mind isn't so inflexible that it can only be shaped by the first language you learn. There are plenty of games developers who started out on BASIC. I've written file systems and I started out on BASIC. Granted some people. Might not have progressed much beyond BASIC but can we not judge those individuals on their own technical competence rather than blaming a language for corrupting them? You wouldn't say "web development destroys ones ability to write back end systems" despite HTML / CSS et al being even further removed from systems languages than BASIC. However equally there are some people who feel more comfortable in markup than writing Java (for example).

It's very easy to blame the language when often it's the teacher or the individual (or a combination of the two) who struggles rather than the paradigm.

Re: Massacring C Pointers

#265

Post by saagarjha »

scatters wrote: post #65
saagarjha wrote: post #29

Earlier quoted context omitted.

> Inconsistent Variable declaration How so? > I would have used strcpy 2 times You can't do this, because strcpy doesn't give you the length of the string you copied, which is necessary to put the trailing null byte.

strcpy writes a trailing zero. > The strcpy() function copies the string pointed to by src, including the terminating null byte ('\0'), to the buffer pointed to by dest.

Yup, I'm aware of that, but the author of that code sure isn't ;)

Re: Massacring C Pointers

#266

Post by saagarjha »

ChrisSD wrote: post #242
slrz wrote: post #236

Earlier quoted context omitted.

Then you probably shouldn't feed it to the str* functions at all. Use the mem* functions instead.

That's the same as saying you should never use the str* functions. Nothing in C guarantees a string must have a null byte. As you're well aware, C-strings aren't a separate type that's distinct from char arrays. Sure you can say that good programmers will always ensure a C-string is a C-string but there's decades of programming history that shows that's not true in practice.

Then use a language other than C that doesn't shoehorn string handling into char , as I've mentioned in other comments. If you're have a char with no terminating null byte and you hand it to a function with "str" and its name, you're going to have a bad time.

Re: Massacring C Pointers

#267

Post by setquk »

j9461701 wrote: post #223
optimuspaul wrote: post #156

Earlier quoted context omitted.

One of the reasons I don't consider a degree anything of value when evaluating candidates. It might be a baseline or it might be a red herring. Best to just assume a degree and no degree are equal and asses based on practical examples.

I would think a degree would be valuable, if for nothing else, then because it indicates a willingness to put in 4 years of work to achieve a challenging goal. Conscientiousness is the word, I believe. A university degree shows you have some minimum level of conscientiousness.

Probably correct. It’s a very expensive way to prove ones motivation however.

Re: Massacring C Pointers

#268

Post by setquk »

ryandrake wrote: post #248
setquk wrote: post #70

This doesn't surprise me really. When I was at university the programming textbooks we had were vile nasty and plainly incorrect. And those of us who dared challenge it by writing correct, robust code were penalised as the staff teaching it didn't understand the domain of what they were teaching properly and didn't have any real experience and assumed we were doing it wrong. We learned quickly to approach education w…

Part of getting through an education program is learning the differences between the right answer and the expected answer. If the book says it is so, then it is so, even if you know it isn’t. Remember both “facts”. Keep one for the test and the other for reality.

Sounds very much like doublethink.

Re: Massacring C Pointers

#269

Post by nwmcsween »

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.

The implementation of std::string is 99.999% of the time struct { char *s; size_t len; }, which has nothing to do with an actual type.

Re: Massacring C Pointers

#270

Post by oselhn »

phaedrus wrote: post #211

When I started my CS degree the school was transitioning from teaching C++ to teaching Java, and the state of instruction in C++ was almost as bad as these examples. I had a professor who wanted us to use "new Foo()" everywhere in our code (even local / static variables) because it, "gets the students ready for Java." No matching delete, of course, or mention of RAII. We were supposed to "pretend" we had a garbage co…

I worked on real program developed this way. It was Android/iOS tablet application with large part done in C++. C++ part was somehow generated from Java prototype and development was than outsourced to India. Those guys probably never seen C++ before, so they assumed program is correct and they used same style to extend the application. US managers were just filling reports with green/yellow/red markers preparing for release and having no clue about real state of the app. I worked for another contractor which was also working on this project (there were about 50 people working on small tablet app). I tried to fix those issues but it was really too much work and some guys just continued to broke the program as they really believed they are doing good job. So I decided to find another job and never work for huge US corporation again.
Post reply on HN