Thread: Find if string exist in a vector of structs

Originally Posted by cstryx

My preference would be to write a generic one with a FILE * being specified, then perhaps you could write a macro to call that function with stdin as a parameter:

Code:

#define fgets2_stdin(buf, bufsize) fgets2(buf, bufsize, stdin)

More than one way to skin a cat though.

Sure, there are lots of alternatives. However, IMO a name using "fgets" makes the experienced reader to instinctively assume a certain behavior regarding the resulting string (keeping the terminating '\n', if there's room for the inputted string) while a name using "gets" instinctively implies that the terminating '\n' is always dropped.

Although that might be human nature for some, I would regard that as a mistake for a programmer to be make, especially if the function name is not specifically part of the C standard library. I can see your point though, gets() to me also implies a buffer overflow issue for instance, and 'f' as a prefix to function names for me simply just means that a FILE pointer is explicitly requested in one of the parameters(fscanf, fgets, fprintf, etc...)

Thus, maybe 'f' can be kept, but the suffix should be changed. 'fgetln()'?

Then a macro (or function which calls fgetln()) called getln() can explicitly use stdin.

Originally Posted by cstryx

Although that might be human nature for some, I would regard that as a mistake for a programmer to be make, especially if the function name is not specifically part of the C standard library. I can see your point though, gets() to me also implies a buffer overflow issue for instance, and 'f' as a prefix to function names for me simply just means that a FILE pointer is explicitly requested in one of the parameters(fscanf, fgets, fprintf, etc...)

Thus, maybe 'f' can be kept, but the suffix should be changed. 'fgetln()'?

Then a macro (or function which calls fgetln()) called getln() can explicitly use stdin.

Please note that I was only expressing my own preference, which is by no means mandatory. All approaches are welcome, and most of them are potentially well justified under different contexts.

Regarding interactive-input specifically, I personally find no benefit of passing the input stream as an argument to a custom function made especially for interactive-input from stdin. In that context, I also consider flushing the stdin a feature that may prove quite handy. However, instead of linking the ability to flush or not the stdin stream with an extra function argument, I prefer to have 2 explicit functions, with names that clearly imply the purpose of their existence.

But once again, all those are just my own personal preference.