Re: No. of 'ab' or specific word in a text file
On Apr 23, 10:13 pm, Keith Thompson <k...@mib.org> wrote:
James Kanze <james.ka...@gmail.com> writes:
On Apr 22, 5:58 pm, "Army1987" <please....@for.it> wrote:
[...]
Anyhow, I'd write FILE *f rather than FILE* f, or else when you
write FILE* f, g you'll be surprised by results.
Every coding guideline I've ever seen has forbidden defining
more than one variable per statement. It's just bad programming
practice. Other than that, it's mostly a matter of taste. I
find it cleaner to separate the type from what is being defined.
How do you manage that for arrays?
std::vector< int > v ; // :-)
Seriously, I do it when I can, but when the language doesn't
allow it, obviously, I do have to write code which the compiler
can understand. As a general rule, I like to keep the type
separate from the name of what is being defined. As a general
rule, I like to make declarations distinctive from expression
statements. Neither are always possible.
[...]
On the DS9K,
exit(2) makes the program securely erase the whole disk on exit.
The standard way to do that is exit(EXIT_FAILURE);
And the Unix way is exit(2).
It is?
<OT>
On Unix-like systems, EXIT_FAILURE is typically defined as 1. exit(0)
denotes success, and exit(1) commonly indicates some generic failure.
I know of no widespread convention for exit codes other than 0 and 1;
they tend to be defined individually for each command. One command,
curl, documents 76 distinct error codes.
</OT>
Try "man grep":-).
The C standard's exit(0), exit(EXIT_SUCCESS), and exit(EXIT_FAILURE)
are quite compatible with Unix conventions.
With one of the Unix conventions:-). Back when I was regularly
implementing such things, I got in the habit of using 2 for real
errors, because a certain number of programs (e.g. grep) used 1
for special non-error conditions. So I've gradually developped
the habit of using 2 for most errors.
The only more or less enforced convention is, of course, 0 if
there is no error. A number of programs do use 1 for special
non-error or half-error conditions (grep not finding anything),
and 2 for real errors. And of course, anything greater than 127
should be avoided, as it normally indicates that the program was
killed from the outside. I've gotten into the habit of
distinguishing even more: 1 is a "half-error", 2 a real error, 3
a fatal error (the program stopped immediately on detecting it);
internally, I also use 4, but that will trigger a call to abort,
so the invoking code won't see it. In my production code, these
are mapped to the system defined error return codes, with all
but 0 mapping to EXIT_FAILURE by default, but with the Unix and
Windows mappings just passing them through. It allows
propagating extra information on systems which support it.
Still, 99% of my programming is under Unix, so I sometimes slip,
and just write the error codes directly. Even though I know
that they don't work everywhere.
--
James Kanze (GABI Software) mailto:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34