«

"No newline at the end of your output" is really a problem? I've never
learned that before.
So I desire to know some tips about writting a program perfectly.Can
anyone give me some tips which are hardly learned from textbook or
easily ignored?
Thank you very much.

Yuri CHUANG wrote:
>
> "No newline at the end of your output" is really a problem? I've never
> learned that before.
> So I desire to know some tips about writting a program perfectly.Can
> anyone give me some tips which are hardly learned from textbook or
> easily ignored?
> Thank you very much.

http://c-faq.com/

--
pete

Well, your output will look much better if you have a practice of
putting \n at the end of a printf argument, etc.
Albert

On Sunday 12 March 2006 06:18, Albert opined (in
< .com>):

> Well, your output will look much better if you have a practice of
> putting \n at the end of a printf argument, etc.
> Albert

Please quote who and what you're replying to. Read and follow advice
from <http://cfaj.freeshell.org/google/>.

Back to your reply... "look much better" really has nothing to do with
this (as we all know, the beauty is in the eye of the be(er)holder).

What has *everything* to do with it is that if you do not terminate your
output with new line, or flush it with `fflush`, the compiler is not
required to provide /any/ output whatsoever. It's in the Standard, if
you're still wondering why.

--
BR, Vladimir

After any salary raise, you will have less money at the end of the
month than you did before.

Albert schrieb:
> Well, your output will look much better if you have a practice of
> putting \n at the end of a printf argument, etc.

Please, quote what you are replying to. If you are using
google to post, have a look at
http://www.clc-wiki.net/wiki/Introdu....c#googleposts
please.

Apart from that, your answer is not at all helpful as the OP
was not asking for aesthetic reasons but for the language
reasons; you could have pointed him or her to FAQ 12.4 or similar.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

"Yuri CHUANG" <> wrote in message
news: oups.com...
> So I desire to know some tips about writting a program perfectly.

There are two assumptions made in that statement:
1) that someone can always determine a method to solve every problem
2) that someone can always write a program which implements a solution
without errors

I'd start by learning how to solve some problems and write some programs
well. After solving and implementing
a few problems, you'll know whether you are better at "top-down" or
"bottoms-up" design. Each person has a
biological preference for each one (FYI, those who prefer "top-down" are N,
and "bottoms-up" are S, in Myers-Briggs personality Type Indicator).

> Can
> anyone give me some tips which are hardly learned from textbook or
> easily ignored?

The following are my opinions for the C language are really are _specific_
to _my_ programming style. Others may not
have problems with the same areas of C that I do, so they probably have
their own list of issues. You'll need to develop
your own list of "problem areas" over time:

1) learn hexadecimal and the bit patterns for each value
2) don't forget your algebra
3) understand binary operations bitshifts, and, or, xor, one and two's
complement, etc...
4) use #define masks to extract bits from variables instead of using unions
5) include all the necessary include files, especially stdio.h and stdlib.h
6) avoid the use casts, except to ensure the type and precision of numerical
conversions and where you know it is necessary
7) avoid the use of type qualifiers (const, volatile, restrict), except
where necessary, because they can hide programming errors
avoid the use malloc(), except for dynamic data, because it leads to
memory allocation errors
8A) corollary: avoid the use pointers in main(), for the same reason
9) typedef structs and give them file scope (i.e., "global"), it can simply
certain problems


Rod Pemberton

Michael Mair <> writes:
> Albert schrieb:
>> Well, your output will look much better if you have a practice of
>> putting \n at the end of a printf argument, etc.
>
> Please, quote what you are replying to. If you are using
> google to post, have a look at
> http://www.clc-wiki.net/wiki/Introdu....c#googleposts
> please.
>
> Apart from that, your answer is not at all helpful as the OP
> was not asking for aesthetic reasons but for the language
> reasons; you could have pointed him or her to FAQ 12.4 or similar.

Note that FAQ 12.4 recommends the use of fflush(stdout), which is a
good idea for prompts, but isn't guaranteed to help if the very last
thing your program writes to stdout doesn't end in a new-line.

What the standard says is (C99 7.19.12p2):

A text stream is an ordered sequence of characters composed into
_lines_, each line consisting of zero or more characters plus a
terminating new-line character. Whether the last line requires a
terminating new-line character is implementation-defined.

It's not clear what happens if the implementation requires a
terminating new-line and the program doesn't provide one; I suppose
it's undefined behavior. The most likely consequence, I suppose, is
that the last line doesn't appear.

I don't know of any implementations that actually require the trailing
new-line, but on systems I use, if a program's stdout is directed to a
terminal and there's no trailing new-line, the last line might be
overwritten by the next shell prompt. Even if it isn't, having the
prompt appear in the same line immediately following the program's
output is ugly:

prompt% ./hello
hello, worldprompt %

--
Keith Thompson (The_Other_Keith) kst- <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

"Rod Pemberton" <> wrote in message
news:dv0uev$2hcl$...
>
> "Yuri CHUANG" <> wrote in message
> news: oups.com...
> > So I desire to know some tips about writting a program perfectly.
>
> There are two assumptions made in that statement:
> 1) that someone can always determine a method to solve every problem
> 2) that someone can always write a program which implements a solution
> without errors
>
> I'd start by learning how to solve some problems and write some programs
> well. After solving and implementing
> a few problems, you'll know whether you are better at "top-down" or
> "bottoms-up" design. Each person has a
> biological preference for each one (FYI, those who prefer "top-down" are
N,
> and "bottoms-up" are S, in Myers-Briggs personality Type Indicator).
>
> > Can
> > anyone give me some tips which are hardly learned from textbook or
> > easily ignored?
>
> The following are my opinions for the C language are really are _specific_
> to _my_ programming style. Others may not
> have problems with the same areas of C that I do, so they probably have
> their own list of issues. You'll need to develop
> your own list of "problem areas" over time:
>
> 1) learn hexadecimal and the bit patterns for each value
> 2) don't forget your algebra
> 3) understand binary operations bitshifts, and, or, xor, one and two's
> complement, etc...
> 4) use #define masks to extract bits from variables instead of using
unions
> 5) include all the necessary include files, especially stdio.h and
stdlib.h
> 6) avoid the use casts, except to ensure the type and precision of
numerical
> conversions and where you know it is necessary
> 7) avoid the use of type qualifiers (const, volatile, restrict), except
> where necessary, because they can hide programming errors
> avoid the use malloc(), except for dynamic data, because it leads to
> memory allocation errors
> 8A) corollary: avoid the use pointers in main(), for the same reason
> 9) typedef structs and give them file scope (i.e., "global"), it can
simply
> certain problems
>

I'd also add:
10) use unsigned types whenever possible

Rod Pemberton

Rod Pemberton schrieb:
> "Yuri CHUANG" <> wrote in message
> news: oups.com...
>
>>So I desire to know some tips about writting a program perfectly.
>
> There are two assumptions made in that statement:
> 1) that someone can always determine a method to solve every problem
> 2) that someone can always write a program which implements a solution
> without errors
>
> I'd start by learning how to solve some problems and write some programs
> well. After solving and implementing
> a few problems, you'll know whether you are better at "top-down" or
> "bottoms-up" design. Each person has a
> biological preference for each one (FYI, those who prefer "top-down" are N,
> and "bottoms-up" are S, in Myers-Briggs personality Type Indicator).

Hmmm, and what am I if I prefer one approach for some kinds of problems
and the other for other kinds of problems and the
midlevel-to-up-and-down and the come-from-top-and-bottom for yet
other classes of problems?

>>Can
>>anyone give me some tips which are hardly learned from textbook or
>>easily ignored?
>
> The following are my opinions for the C language are really are _specific_
> to _my_ programming style. Others may not
> have problems with the same areas of C that I do, so they probably have
> their own list of issues. You'll need to develop
> your own list of "problem areas" over time:
>
> 1) learn hexadecimal and the bit patterns for each value
> 2) don't forget your algebra
> 3) understand binary operations bitshifts, and, or, xor, one and two's
> complement, etc...

If you need them, learn something about floating point numbers
and their shortcomings so you are not in for nasty surprises.

> 4) use #define masks to extract bits from variables instead of using unions

and use functions to wrap the semantics whenever the bit thing
is only an implementation decision...

> 5) include all the necessary include files, especially stdio.h and stdlib.h
> 6) avoid the use casts, except to ensure the type and precision of numerical
> conversions and where you know it is necessary
> 7) avoid the use of type qualifiers (const, volatile, restrict), except
> where necessary, because they can hide programming errors

How can const lead to errors unless you violate (6)?

> avoid the use malloc(), except for dynamic data, because it leads to
> memory allocation errors

.... it _can_ lead ...

> 8A) corollary: avoid the use pointers in main(), for the same reason

Avoid implementing any functionality in main(); main() essentially
just should call functions and assign to temps...
This step usually makes it easier to structure the program and the
tasks.

> 9) typedef structs and give them file scope (i.e., "global"), it can simply
> certain problems

Are you talking about the type definition or about the instance?

@OP: As Rod said, everyone has their own list.
A look at a good textbook and the C FAQ before you start out
implementing something may make you aware of potential problems.

A couple of things which are not strictly C which I would add:
i) Use your compiler in the strictest possible mode, i.e.
a) use only standard C if you can get away with it
b) turn the warning level to maximum
ii) If sensible, use a lint-tool.
iii) If you get warnings or error messages, understand them. Do
not try to make them "go away" with tricks but by making sure
the (potential) problem they point out does not occur or by
changing the code so the problem cannot occur.
If you decide that the warning is not critical and your compiler
offers a #pragma to switch off a warning for a code section,
then switch it off for the smallest possible code section and
write a comment explaining why you switched it off.
iv) If you get beyond one file or beyond a thousand lines of code
or if you know beforehand that you might, then _plan_ahead_:
a) Use make or similar tools to automate the build process
b) Test every function or at least every module thoroughly and
separately -- it is much easier to find bugs this way.
If you design the test before writing the code, this may even
save you some time because you know which pitfalls to avoid.
c) Make tests that test the interaction of different software
components/modules/functions.
v) Do never ever take shortcuts in order to "optimise".
If your code is too slow and you have found out by measuring
which part it is that slows you down, then think about a better
way of implementing it. Keep the slow function/group of functions
so that you test whether the optimised code does the same. And
measure whether the optimised part is actually faster/more memory
efficient.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

Keith Thompson schrieb:
> Michael Mair <> writes:
>>Albert schrieb:
>>
>>>Well, your output will look much better if you have a practice of
>>>putting \n at the end of a printf argument, etc.
>>
>>Please, quote what you are replying to. If you are using
>>google to post, have a look at
>> http://www.clc-wiki.net/wiki/Introdu....c#googleposts
>>please.
>>
>>Apart from that, your answer is not at all helpful as the OP
>>was not asking for aesthetic reasons but for the language
>>reasons; you could have pointed him or her to FAQ 12.4 or similar.
>
> Note that FAQ 12.4 recommends the use of fflush(stdout), which is a
> good idea for prompts, but isn't guaranteed to help if the very last
> thing your program writes to stdout doesn't end in a new-line.
>
> What the standard says is (C99 7.19.12p2):
<snip: explanation>

I admit I was too lazy to search for the appropriate FAQ;
I just assumed that somewhere around there, there should be
an appropriate FAQ entry. Looking there, I don't find one...
Considering that this is something corrected fairly often,
I am surprised that one cannot find that in the FAQ.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.