what about this new way of opening file

[nrk]

Hello
Allright! I have learnt my mistakes. I will be downloading a new compiler
and avoid the use of shortcuts in my posts.
Many thanks to you All.

You're definitely showing the right attitude. Good for you. If you
disregard the harsher words of the regulars who responded, but pay
attention to the technical details that they point out, you are bound to
learn a lot of things that will stand you in good stead for the future.
Before you post further questions to this group, please do take the time to
read through the fine FAQ, available at:

http://www.eskimo.com/~scs/C-faq/top.html

One thing that you've not yet learnt is the art of bottom-posting. What
this means is that when you reply to an article, your reply goes beneath
what you quote. For instance, I am replying to you here, and my reply is
below what you said before. This way, someone who reads my response can
proceed logically from the top and not lose track of the conversation.
Most of the regulars prefer this form of posting and IMHO, it is good
usenet etiquette to do so. Along with that, learn to snip out parts of the
article you're quoting that's not relevant to your response. This keeps
the lengths of your articles to manageable limits.

-nrk.

<snip>

 

[David M. Wilson]

what about this nice way to open a file in single line rather than using
if and else.

if the file exists condition to right of OR will not be executed and if it
doesnt exists it returns 0 and cause the second
condition to be executed. printf always returns nonzero on success.

Hi there,

This is indeed a neat little trick. However, what do you gain from it?
The answer is practically nothing, however you do loose syntax
clarity, readability, etc.

I think one of the most important principles in programming is
maintaining clarity in your expressions in preference to speed or
time. In other words, it might take you a few more seconds to type the
full if statement, but instantly other C programmers can understand
your code, and if you need to expand the 'failure' printf to two
statements in the future, you can do so easily.

Consider the readability of:

if (some_op() == FAIL)
{
/* handle failure. */
}
else
{
/* handle success. */
}


versus:

(some_op() == FAIL) &&
(/* handle failure */) ||
(/* handle_success */)


The only benefit I can imagine in the last example is that your
compiler might somehow output improved (or different) asm for the
expression, but this is unlikely. It is also a very bad strategy to
take whilest writing portable code. More importantly, it may screw up
optimisations your compiler could have otherwised performed if the
statement was written in the more traditional style.


David.

 

[Old Wolf]

fopen("c:\\autoexec.bat","r")&&printf("success") || printf("error opeing

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I think you mean (nd = fopen("c:/autoexec.bat","r"). Open without the
assignment is as close to useless as you can get. [Spelling flame for
"opeing" supressed.]

[Spelling flame for "supressed" suppressed.]

^^^^^^^
Non-portable argument to exit() function.

What's all this cruft about EXIT_SUCCESS and EXIT_FAILURE anyhow? if
you have a program that can return N different error codes to the
operating system (eg: many unix tools), then EXIT_SUCCESS isn't
going to help much.

As far as "writing portable code" goes, unless there is an OS
standard that the C standard is aligning itself with, the return
values for main() or exit() are system-dependent (ie. nonportable)
anyway.

 

[Kevin Goodsell]

What's all this cruft about EXIT_SUCCESS and EXIT_FAILURE anyhow? if
you have a program that can return N different error codes to the
operating system (eg: many unix tools), then EXIT_SUCCESS isn't
going to help much.

True. So those programs can't be written in strictly portable C. That's
not a huge surprise.

As far as "writing portable code" goes, unless there is an OS
standard that the C standard is aligning itself with, the return
values for main() or exit() are system-dependent (ie. nonportable)
anyway.

All exit codes other than 0, EXIT_SUCCESS, and EXIT_FAILURE are
non-portable. Those three are portable, and the standard defines their
meaning.

-Kevin

 

[CBFalconer]

.... snip ...


What's all this cruft about EXIT_SUCCESS and EXIT_FAILURE anyhow?
if you have a program that can return N different error codes to
the operating system (eg: many unix tools), then EXIT_SUCCESS
isn't going to help much.

As far as "writing portable code" goes, unless there is an OS
standard that the C standard is aligning itself with, the return
values for main() or exit() are system-dependent (ie.
nonportable) anyway.

No, EXIT_SUCCESS and EXIT_FAILURE (and 0) have already taken into
account any OS peculiarities, and are thus portable. Anything
else is not.

If you need other values to interface with "unix tools" then your
program isn't portable, and should not be discussed here. What
could be simpler>

 

[Bruno Desthuilliers]

Hi there,

This is indeed a neat little trick.

Not even.

 

[A. Sinan Unur]

....


Good advice. But he shouldn't give up using Turbo C++ 3.0, or he will
simply fall into the same trap as before. The more compilers (of
different provenance) that you use, the more lessons you will learn
about writing portable code.

The key point I should have made is to read one's compiler's
documentation of various warning levels, and turn them on.

This is over the top.

It definitely is. My apologies.

The guy is clearly not stupid, merely ignorant.
Ignorance can be cured. The program is pretty stupid, yes; but if you
use that program whilst you have irreplaceable data on the screen,
what does that say about you?

Nothing good.

Any programmer must decide whether a given program's need for
full-screen addressability outweighs the desirability of a keeping the
program portable and non-irritating.

Definitely.

Sinan.

 

[Keith Thompson]

(e-mail address removed) (Old Wolf) writes:
[...]
[attributions missing]

What's all this cruft about EXIT_SUCCESS and EXIT_FAILURE anyhow? if
you have a program that can return N different error codes to the
operating system (eg: many unix tools), then EXIT_SUCCESS isn't
going to help much.

As far as "writing portable code" goes, unless there is an OS
standard that the C standard is aligning itself with, the return
values for main() or exit() are system-dependent (ie. nonportable)
anyway.

If you need to return more than two different status values, you can't
do it portably. But if all you need to indicate is whether the
program succeeded or failed, EXIT_SUCCESS and EXIT_FAILURE are
perfectly portable. exit(1) is not; in VMS, for example, odd status
results denote success.

Go ahead and write non-portable code if you need to, but *only* if you
need to.

 

[David M. Wilson]

Not even.

Unless you have something to add, may I suggest you do not post? My
reply was designed to encourage and direct. Yours was spirit-crushing
condescension.


David.