which tutorial to use?

[polas]

hello all,

google listed the links below for search "c tutorial".

http://www.cprogramming.com/tutoria...tutorial/http://cprog.tomsweb.net/cintro.html

but which one to use? any recomendations? the course is for ANSI C, so
UNIX info is useless.

sorry if this is off topic but there was no other group for C...

Personally, initially I used http://www.space.unibe.ch/comp_doc/c_manual/C/cref.html
which I found quite useful. Also the C Faq by this group (http://www.c-
faq.com) has always been a source of interest and help (they aren't
called frequently asked questions for nothing!)

In the end I bought The C Programming Language by K&R as suggested by
another poster and have found this resource invaluable.

Nick

 

[Ioannis Vranos]

Personally, initially I used http://www.space.unibe.ch/comp_doc/c_manual/C/cref.html
which I found quite useful. Also the C Faq by this group (http://www.c-
faq.com) has always been a source of interest and help (they aren't
called frequently asked questions for nothing!)

In the end I bought The C Programming Language by K&R as suggested by
another poster and have found this resource invaluable.

His first program is "unfortunate":

#include <stdio.h>

main()
{
puts ("your first C program");
}




implicit int of main() with no return statement.

 

[polas]

His first program is "unfortunate":

#include <stdio.h>

main()
{
puts ("your first C program");

}

implicit int of main() with no return statement.

Yup, your quite right - which is strange, Ive always thought (quite
possibly wrongly) that the first edition of the book was used as the
unofficial reference/standard text before the C language got
standardised.

Why in the 2nd edition would the authors make such a simple error?

Nick

 

[Eric Sosman]

Ioannis Vranos said:


3.14 is an example.

You Know You've Been Here Too Long when your first
reaction is "What does ``region of data storage in the
execution environment, the contents of which can represent
values'' have to do with double constants?"

 

[Ioannis Vranos]

Yup, your quite right - which is strange, Ive always thought (quite
possibly wrongly) that the first edition of the book was used as the
unofficial reference/standard text before the C language got
standardised.

Why in the 2nd edition would the authors make such a simple error?

I was talking about the on line tutorial, while it looks like you are
talking about K&R2.

In K&R2, Kernighan wrote the main() function the way he liked, rather
than what the standard required.

 

[Richard Heathfield]

Ioannis Vranos said:

In K&R2, Kernighan wrote the main() function the way he liked, rather
than what the standard required.

Half-right. He wrote it the way he liked, yes (or at least we presume he
did)... but it's perfectly legal under C90. It wasn't until C99 (published
ten or eleven years *after* K&R2) that implicit int was dropped from the
language definition - and of course most people still use compilers that
don't conform to C99 anyway.

It isn't *wrong*. It is considered poor style nowadays, but it was
perfectly normal thenadays. Claiming it to be "wrong" is a little like
claiming that people who failed to wear seat belts in the 1970s in the UK
should have been prosecuted for a breach of the Motor Vehicles (Wearing of
Seat Belts) Regulation Act (which came into effect on 31 January 1983).

 

[Ioannis Vranos]

Half-right. He wrote it the way he liked, yes (or at least we presume he
did)... but it's perfectly legal under C90. It wasn't until C99 (published
ten or eleven years *after* K&R2) that implicit int was dropped from the
language definition - and of course most people still use compilers that
don't conform to C99 anyway.

It isn't *wrong*. It is considered poor style nowadays, but it was
perfectly normal thenadays. Claiming it to be "wrong" is a little like
claiming that people who failed to wear seat belts in the 1970s in the UK
should have been prosecuted for a breach of the Motor Vehicles (Wearing of
Seat Belts) Regulation Act (which came into effect on 31 January 1983).

He wasn't wrong, it is poor style indeed. But I think it is poor style
for C90 too.

 

[Ioannis Vranos]

He wasn't wrong, it is poor style indeed. But I think it is poor style
for C90 too.

More specifically, I consider poor style for its time, not returning a
value in main(), and returning specific non-zero values (like 1 and 2)
in main() in some pages, instead of returning 0 or EXIT_SUCCESS in
normal cases, and EXIT_FAILURE in the abnormal ones.

 

[Richard Heathfield]

Ioannis Vranos said:

He wasn't wrong, [implicit int for main] is poor style indeed.

But it wasn't poor style when the book was written. It came to be
considered poor style /later/. It's not fair to criticise someone's
writings on the basis of knowledge that they could not possibly have had
at the time of writing. It's like claiming that a C++ book written in the
1980s portrays poor style because it uses <iostream.h> rather than

But I think it is poor style for C90 too.

It is *now* considered so. It was not considered so when the book was
written.

(Aside: C99 has of course outlawed implicit int, so if K&R2 is used on a
C99 course, this change needs to be pointed out early in the course.)

 

[Bartc]

Bartc wrote:

[stuff about underlying concepts]

My point: it's best to think about this stuff too much.

Or perhaps not.

 

[Ioannis Vranos]

Ioannis Vranos said:

He wasn't wrong, [implicit int for main] is poor style indeed.

I meant [not returning value in main()]

 

[Richard Heathfield]

Ioannis Vranos said:

Ioannis Vranos said:

He wasn't wrong, [implicit int for main] is poor style indeed.

I meant [not returning value in main()]

Oh, okay. The same argument applies, however.

 

[Harald van Dijk]

Ioannis Vranos said:

That may or may not be true. I suggest you check it in comp.lang.c++.
But in C, it is not true.

struct S {
int array[1];
} f(void) {
struct S result = { 0 };
return result;
}

f().array can be converted to a pointer value, and what that pointer
points to must necessarily be an object. The description of this
conversion also refers to the array object.

Of course, this is new in C99, and in C90/C95, functions never return
objects in any way.

 

[lawrence.jones]

Ioannis Vranos said:

He wasn't wrong, [implicit int for main] is poor style indeed.

But it wasn't poor style when the book was written. It came to be
considered poor style /later/.

I disagree. Omitting the return type in the definition of a function
that actually returned a value (or was supposed to return a value) was
always considered poor style. Omitting the return type was how one
declared (to other people, not the compiler) that the function returned
no value before "void" was added to the language. K's declaring main
with no return type and no return statement was the moral equivalent at
the time of declaring it as returning void today except that the former
was just poor style whereas the latter is just plain wrong.

-Larry Jones

It's clear I'll never have a career in sports until I learn
to suppress my survival instinct. -- Calvin

 

[Ioannis Vranos]

I meant [not returning value in main()]

Oh, okay. The same argument applies, however.

Why? The main() return type was int. When he didn't return any values,
it was poor style, when he was returning values other than zero (like 1
and 2) he was non-portable.

 

[Richard Heathfield]

Ioannis Vranos said:

I meant [not returning value in main()]

Oh, okay. The same argument applies, however.

Why?

Because it isn't always immediately clear how best to use a new technology.
Consider, for example, the world's first cast-iron bridge, at
Coalbrookdale, Shropshire. The design is based firmly on previous designs
for /wooden/ bridges, right down to the mortise and tenon joints, and even
dovetails. A bridge designer who produced such a design today would be
ridiculed. Nevertheless, it would be uncharitable to criticise the
technologists of the day, who were still experimenting with this new idea.

Likewise, in the early 1970s (when C was first designed), what constituted
"good style" was still far from settled. It takes time to develop a feel
for good style within a given language.

The main() return type was int. When he didn't return any values,
it was poor style, when he was returning values other than zero (like 1
and 2) he was non-portable.

I still think you're judging bwk a little harshly, although I must admit
I'd like to see a 3rd edition of K&R, with such archaisms eliminated.

 

[Ioannis Vranos]

I still think you're judging bwk a little harshly, although I must admit
I'd like to see a 3rd edition of K&R, with such archaisms eliminated.

Of course that doesn't mean I consider him a bad programmer. The man is
a Coder.

 

[Ioannis Vranos]

I still think you're judging bwk a little harshly, although I must admit
I'd like to see a 3rd edition of K&R, with such archaisms eliminated.

Well, they may provide the correct return statements as errata to their
book publishing company, so as next printings fixes them. The same
happens with TC++PL3 book and its errata, they are being provided to the
next printings of the book.

 

[CBFalconer]

polas wrote:
.... snip ...


I was talking about the on line tutorial, while it looks like you
are talking about K&R2.

In K&R2, Kernighan wrote the main() function the way he liked,
rather than what the standard required.

No, Ritchie published an error summary. Look on his page.

 

[Micah Cowan]

Ioannis Vranos said:

He wasn't wrong, [implicit int for main] is poor style indeed.

But it wasn't poor style when the book was written. It came to be
considered poor style /later/.

I disagree. Omitting the return type in the definition of a function
that actually returned a value (or was supposed to return a value) was
always considered poor style.

Obviously not true in general, since K&R was long the default
source for coding "style" for many (it being, in its first edition at
any rate, the definitive source for anything C).

Note, too, that in this specific example, main() _didn't_ return
anything (explicitly), and it's (implicitly) expected that the program
would not be used in any way that depends on the return value.

Omitting the return type was how one
declared (to other people, not the compiler) that the function returned
no value before "void" was added to the language. K's declaring main
with no return type and no return statement was the moral equivalent at
the time of declaring it as returning void today except that the former
was just poor style whereas the latter is just plain wrong.

That statement is true for the first edition; not so true for the
second edition, when the first standard had been published, and K&R
obviously had the void return type available to them (which, of
course, could not be used portably for main() in any case).