...Back to an interesting set of examples now...

//what seems like a memset equivalent:
void* memset(void *p, int c, size_t n)
{
...
some undocumented code with no defined purpose

Nope, one does not read code to divine it's purpose.

YOU state the purpose and meaning then one might proof your code.

 

Without going back there then, in today's computer it wont make a smidget of a difference in execution speed and you dont have to agree with that, but before you reject it i suggest you look into time profiling on modern machines. Modern CPU's are very different than the old ones were.

I think I'm seeing where the disconnect might be coming from. If I'm correct, you are coming from a position that basically says, "Well, even if it made sense then, it may not make sense now, and so it should change to something that does." Thus, when we point out why things were (or might have been) done the way they were, you think we are claiming that they way they were done then was and still is the best way to do things.

But we are coming from the position that says, "It doesn't matter whether the decisions they made were good or bad. Nor does it matter whether what made sense back then still makes sense today, because it CAN'T be changed." For instance, we are stuck with memset() taking the arguments that it takes. To change it would break way too much code for that ever to happen. So it makes little sense to talk about whether memset() should be different, because it isn't different and it's not going to be different -- the only thing you can do is learn what it IS and accept it (or, of course, not use it). What CAN happen (and does happen) is NEW libraries are created with NEW functions with NEW names. Just look at the safer versions of printf() and most of the string library functions as an example. The old functions are still there so that existing code will still compile and run, but the push is for the newer, safer versions to be used for new code development.

 

I think I'm seeing where the disconnect might be coming from. If I'm correct, you are coming from a position that basically says, "Well, even if it made sense then, it may not make sense now, and so it should change to something that does." Thus, when we point out why things were (or might have been) done the way they were, you think we are claiming that they way they were done then was and still is the best way to do things.

But we are coming from the position that says, "It doesn't matter whether the decisions they made were good or bad. Nor does it matter whether what made sense back then still makes sense today, because it CAN'T be changed." For instance, we are stuck with memset() taking the arguments that it takes. To change it would break way too much code for that ever to happen. So it makes little sense to talk about whether memset() should be different, because it isn't different and it's not going to be different -- the only thing you can do is learn what it IS and accept it (or, of course, not use it). What CAN happen (and does happen) is NEW libraries are created with NEW functions with NEW names. Just look at the safer versions of printf() and most of the string library functions as an example. The old functions are still there so that existing code will still compile and run, but the push is for the newer, safer versions to be used for new code development.

Hi there,

Yes that sounds like a decent summary. The only small difference is that i never believed that we would be able to change it for everyone everywhere. It appears that they have been there and done that already in the form of some new functions and that is usually the only way to go.

The secondary issue was the best way to explain this to a student getting into C programming for the first time. I guess there's only so much we can do here though anyway.

Thanks for your input.

 

For the student just getting into C, tell them read the documentation about the function and don't try to guess what it does based on the prototype or declaration. Teaching a student to read the help files / man pages / etc.. is probably one of the best lessons they could ever learn.

 

Hi there,

Yes that sounds like a decent summary. The only small difference is that i never believed that we would be able to change it for everyone everywhere. It appears that they have been there and done that already in the form of some new functions and that is usually the only way to go.

The secondary issue was the best way to explain this to a student getting into C programming for the first time. I guess there's only so much we can do here though anyway.

Thanks for your input.

I always emphasize to students that the primary purpose of a prototype is so that the compiler can perform type checking and type coercion when a function for which it hasn't seen the definition is called. I also emphasize that it can be a useful memory aide for programmers PROVIDED they have first learned what the function does and what it's interface is. If they haven't done that, then they are guessing -- and engineering is not about guessing.

Of course, given the way many people, especially students, write code or try to solve problems in general, the "random guessing" model appears to be alive and well. I can't believe the number of people (not all students) that don't give any thought at all to how to fix a problem once the problem is pointed out -- they just change some code and try again. It's problem-solving-via-happening -- you make random changes and hope that, at some point, something good will magically happen.