give me some tips

[Yuri CHUANG]

"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.

 

[pete]

"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/

 

[Albert]

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

 

[Vladimir S. Oka]

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.

 

[Michael Mair]

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/Introduction_to_comp.lang.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

 

[Rod Pemberton]

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
8) 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

 

[Keith Thompson]

Please, quote what you are replying to. If you are using
google to post, have a look at
http://www.clc-wiki.net/wiki/Introduction_to_comp.lang.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 %

 

[Rod Pemberton]

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).


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
8) 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

 

[Michael Mair]

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?

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)?

8) 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

 

[Michael Mair]

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

 

[Rod Pemberton]

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?

For the MBTI, X is used when an individual is balanced between the two
categories. Most people show a dominance for one category or the other.

But, you bring up a very good point: people's preference or natural
abilities can interfere with solving specific problems since certain
problems can only be solved when started from a certain point. Frequently,
both "top-down" and "bottoms up" programmers start having problems
"in-the-middle". The "top-down" programmer didn't allow for any special
cases (too generic) and has problems implementing the details, and the
"bottoms up" programmer has too much unnecessary detail and can't grasp the
"big-picture."


RP

 

[Keith Thompson]

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:
[...]
7) avoid the use of type qualifiers (const, volatile, restrict), except
where necessary, because they can hide programming errors

I don't see how "const" in particular can hide programming errors.

Use type qualifiers whenever they're appropriate. (restrict is
complex and seldom necessary; don't worry about it until you know what
you're doing. restrict is also new in C99, so many compilers don't
support it.)

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

What else would you use malloc() for?

Corollary: avoid the use of any feature X, because it leads to X
errors.

Better advice: use malloc() carefully.

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

Typedefs for structs are usually unnecessary. You can just declare

struct foo {
...
};

and refer to the type as "struct foo"; there's no real need to use a
typedef to create a second name for the type. (This is a somewhat
controversial point; many programmers prefer to be able to refer to
the type using a single identifier.)

 

[Richard G. Riley]

Typedefs for structs are usually unnecessary. You can just declare

struct foo {
...
};

and refer to the type as "struct foo"; there's no real need to use a
typedef to create a second name for the type. (This is a somewhat
controversial point; many programmers prefer to be able to refer to
the type using a single identifier.)

I'm glad this came up : personally I like the more "in your face"
robustness of this as opposed to using the typedef. There seems to be
just something "wrong" about the whole struct definition in
conjunction with typedef : I cant quite place what it is, although if
you look at the two examples below I think this is what has sometimes
led me astray in an "at a glance" read of strange code:

typedef struct point {
int x;
int y;
} Dot;

struct point {
int x;
int y;
} upperLeft;


Could only be me, but I like to see (in C) the struct keyword at the
point of instantiation.

 

[Richard G. Riley]

"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.

Just reading some of the replies which may or may not have got tied ip
on "\n" at the end of each output:

Take a look at the exit(EXIT_SUCCESS) function. Its a start to
understanding some issues/considerations when leaving a program.

 

[Rod Pemberton]

I'm glad this came up : personally I like the more "in your face"
robustness of this as opposed to using the typedef. There seems to be
just something "wrong" about the whole struct definition in
conjunction with typedef : I cant quite place what it is, although if
you look at the two examples below I think this is what has sometimes
led me astray in an "at a glance" read of strange code:

typedef struct point {
int x;
int y;
} Dot;

struct point {
int x;
int y;
} upperLeft;


Could only be me, but I like to see (in C) the struct keyword at the
point of instantiation.

Usually, there is no need for tye type-definition, i.e., 'point', in the
structure declaration when using a typedef:

typedef struct {
int x;
int y;
} Dot;

/*...*/

/*...some function...*/
{
Dot dot_x1y1,dot_x2y2;
}

This has been beaten to death on other threads which was why I posted
"The following are my opinions for the C language ... are _specific_
to _my_ programming style," but Keith ignored...

RP

 

[Rod Pemberton]

Michael

Although there are a number of "Michael Mair" 's, that leads me to:

Professor (FH) Magister Michael Mair of FH-Modul, University of Innsbruck,
and MCI Innsbruck, Wien(Vienna), Austria.

Is that you? I'll assume that it is for the rest of this post.

Which translates roughly as having a PHD and/or Masters with a university of
applied sciences. I'm sure I botched that. But, since your English is very
good for an Austrian, I'll let you correct that. All of which led to two
pictures: one on FH-Modul and one on FH-Wien. Nice ties. FH-Modul appears
to be a tourism and hospitality university (Fachhochschulstudiengänge für
tourismus-management).

You've mentioned teaching in your other posts. Assuming I've got the
correct person: "Doc", what exactly are you degreed in? Tourism management?


Rod Pemberton

 

[Michael Mair]

Although there are a number of "Michael Mair" 's, that leads me to:

Professor (FH) Magister Michael Mair of FH-Modul, University of Innsbruck,
and MCI Innsbruck, Wien(Vienna), Austria.

Is that you? I'll assume that it is for the rest of this post.

No, that is not me.
I have a University Diploma in "Technomathematik" which essentially is
maths sprinkled with computer science and one engineering discipline.
In my case that is engineering mechanics but I also had a look into
electrical engineering. This course appealed to me because you get
to understand the respective "languages" and are open to specialize
as you feel like.
I did some research in numerical mathematics (simulation and
optimization of dynamic mechanical systems) afterwards, in the course
of which I also gave a C course to relieve other people at our chair
and in order to have students who actually learnt the basics of C so
that we could hire them. In addition, I like teaching as it helps me
learn the stuff I thought I knew that much better.

Right now, I am working in an area where I need knowledge about
compiler construction and discrete mathematics -- an area I am more
enamoured with than numerical mathematics.


Cheers
Michael

 

[Rod Pemberton]

No, that is not me.

Darn, and thanks for not taking any offense. Hopefully, it was a cheap
thrill. I found at least five "Rod Pemberton" 's in the US. I could
understand that one was black (must have been a Pemberton slave owner).
But, it was interesting to find a Vietnamese individual with that name! Go
figure...

I have a University Diploma in "Technomathematik" which essentially is
maths sprinkled with computer science and one engineering discipline.
In my case that is engineering mechanics but I also had a look into
electrical engineering. This course appealed to me because you get
to understand the respective "languages" and are open to specialize
as you feel like.

Ah, okay, I thought you seemed a bit more like an EE than a CS.

I did some research in numerical mathematics (simulation and
optimization of dynamic mechanical systems) afterwards, in the course
of which I also gave a C course to relieve other people at our chair
and in order to have students who actually learnt the basics of C so
that we could hire them.

"who actually learnt the basics of C"

I find that comment humorous. I knew quite a few degreed CS majors who
couldn't program. Of course, I knew a few EE who didn't know what an
electron was either...

In addition, I like teaching as it helps me
learn the stuff I thought I knew that much better.

Right now, I am working in an area where I need knowledge about
compiler construction and discrete mathematics -- an area I am more
enamoured with than numerical mathematics.

"compiler construction"

Yes, not coming from a CS background. I could _really_ use a huge amount of
good public information in this area. I've found stuff at a PHD level and
or ideas which perhaps are patented. I can't use information like that. I
need things like: whether it's easier to use stacks or binary trees. How to
identify when to use an optimization in the compiler backend. Is it better
to use tokens (abstract syntax tree) or string processing of text (concrete
syntax tree)? I could really use Necula's et. al. CIL (C Intermediate
Language) if it only had a flex and bison grammar...


Rod Pemberton

 

[Michael Mair]

"who actually learnt the basics of C"

I find that comment humorous. I knew quite a few degreed CS majors who
couldn't program. Of course, I knew a few EE who didn't know what an
electron was either...

There was nothing humorous at the time. We even considered
banning applicants from a certain information technology
course for our job offers as they made up ninety percent of
the applications (with the shiniest certificates) and about
three percent of the knowledge.

"compiler construction"

I am not sure whether this is the correct translation.
Essentially, whatever you can learn from the Dragon Book or
Muchnick's book.

Yes, not coming from a CS background. I could _really_ use a huge amount of
good public information in this area. I've found stuff at a PHD level and
or ideas which perhaps are patented. I can't use information like that. I
need things like: whether it's easier to use stacks or binary trees. How to
identify when to use an optimization in the compiler backend. Is it better
to use tokens (abstract syntax tree) or string processing of text (concrete
syntax tree)? I could really use Necula's et. al. CIL (C Intermediate
Language) if it only had a flex and bison grammar...

Some of the en.wikipedia.org pages are a decent starting point
if it comes to basic concepts.

Apart from that: Have a look at graph theory; there is much nice
stuff on the web and, as discrete maths goes, it is a fun subject
as you can state really deep problems on a sheet of paper within
five minutes so that everyone understands the problem but the
proof took a hundred years to be found and conversely can prove
things in an easily understandable way. If you understand graph
theory and get an intermediate representation of some code, you
are ready to do general (not target specific) optimisations.

I am not actually writing a traditional compiler but am involved
in the optimisation of an intermediate representation of code;
the output of the product is C.
More about that only via PM and only as far as I am allowed to
tell about it.


Cheers
Michael

 

[Rod Pemberton]

There was nothing humorous at the time. We even considered
banning applicants from a certain information technology
course for our job offers as they made up ninety percent of
the applications (with the shiniest certificates) and about
three percent of the knowledge.


I am not sure whether this is the correct translation.
Essentially, whatever you can learn from the Dragon Book or
Muchnick's book.

I've not heard of these, but will look.

Apart from that: Have a look at graph theory; there is much nice
stuff on the web and, as discrete maths goes, it is a fun subject
as you can state really deep problems on a sheet of paper within
five minutes so that everyone understands the problem but the
proof took a hundred years to be found and conversely can prove
things in an easily understandable way. If you understand graph
theory and get an intermediate representation of some code, you
are ready to do general (not target specific) optimisations.

Hmm, graph theory. I'll _definately_ have a look at this. It'll probably
be a big time saver for me since my spatial relationship abilities are
(supposedly) off the charts.

I am not actually writing a traditional compiler but am involved
in the optimisation of an intermediate representation of code;
the output of the product is C.
More about that only via PM and only as far as I am allowed to
tell about it.

Well, you don't have to talk about that. I'm sure you've looked at other
stuff like:

GCC's RTL
TenDRA's ANDF
LCC's DAGs
Necula's CIL

So far, the only "C" compiler I've found that uses both a yacc and lex
grammar is Lutz Hamel's "C Subset Compiler" WCC for VMS.


Rod Pemberton