4 ms·
For my money it is the only IO API one need ever learn. Good point on signed/unsigned. I think in most cases char is unisgned, i.e., in most environments, so t
by Allocator2008 18y ago
For my money it is the only IO API one need ever learn.
Good point on signed/unsigned. I think in most cases char is unisgned, i.e., in most environments, so this is not a problem. But can't you do something like:
char c
while( (c = getchar() & 0xff) != EOF) { //Do something }
if you are in a signed environment?
I think really stdio is rather like my experience with mexican food. I live in Austin, Texas now, and I love mexican food, the hotter the better, but as a kid I lived in eldritch New England, not far from the Miskatonic river, and felt I didn't "like" spicey food, being more used to lobster, clam chowder, and so forth. Now they can't put enough jalepenos in a burger for my liking. Similarly, being 27, and thus living in the "java age", I first taught myself to program with the Java SDK, which spares one from alot of these "pitfalls". But now I like the control, and also the relative simplicity of the API, that stdio gives one, arguably more intuitive and easier to remember than in Java, and given a choice between Java and C, I would go with the later. It is an acquired taste.
To paraphrase Charleton Heston:
"They will take my [stdio] away out my cold, dead hands!"
:-)
- mooism2 18y agoThe correct way is int ch; while ((ch = getchar()) != EOF) { // ... } If ch is declared as a char, it's buggy regardless of whether it's signed or not, it's just the failure modes are different.
- jpd 18y agoFrom K&R: We also declare 'c' to be an int, not a char, so it can hold the value which getchar returns. As we shall see in Chapter 2, this value is actually an int, since it must be capable of representing EOF in addition to all possible 'char's.