C
chitu
Hi pals,
Hope u all of r intersted in C programming.Let start
from d basics.
Hope u all of r intersted in C programming.Let start
from d basics.
I
Ian Collins
Basic English is a good start.chitu said:
V
Vladimir Oka
chitu said:
What's the point of starting with the basics of D (look up Digital
Mars) if you want to learn C? It would be off topic here, anyway.
Also, we use English here, not E or text speak.
K
Keith Thompson
chitu said:
Yes, we're all interested in C programming. We started from the
basics when this newsgroup was created several decades ago.
If you have any specific questions, feel free to ask them. Before you
do that, please read these links:
<http://www.c-faq.com/>
<http://clc-wiki.net/wiki/Introduction_to_comp.lang.c>
If you really want to start from the basic of C, this newsgroup isn't
the best place to do it. K&R2 (Kernighan & Ritchie, _The C
Programming Language_, 2nd Edition) is an excellent book; see if you
can buy or borrow a copy. If that's not feasible, there are probably
some good online tutorials -- and a lot of bad ones. Perhaps someone
else can help you find a good one.
And please don't use abbreviations like "u", "r", and "d" for "you",
"are", and "the".
K
Kenny McCormack
Good advice. And be sure to check out these links as well:
Useful clc-related links:
http://en.wikipedia.org/wiki/Clique
http://en.wikipedia.org/wiki/Aspergers
As well as:
http://en.wikipedia.org/wiki/C_programming_language
0
01
S
spibou
Keith said:
"d" is not an abbreviation for "the" , it's an abreviation for "da".
Like
ur da man.
F
Flash Gordon
01 said:
The first example I came across is somewhat broken:
| #include
|<stdio.h>
|
|int main()
|{
| printf( "I am alive! Beware.\n" );
| getchar();
| return 0;
|}
The #include directive needs to be all on one line. So at the very least
that site needs a bit of proof reading. However, I did not spot any
other obvious problems in the tutorial I looked at.
R
Richard Heathfield
01 said:
That site is broken. If you're serious about learning C properly, ignore the
site completely.
When I go looking for the C tutorial, I eventually find it at: "Lesson 1:
The basics of C++", which claims "to be a stand-alone introduction to C".
I then see a bunch of adverts, right there after the introductory paragraph,
as if the lesson were now over. Poor design, and it really, really makes me
want to write down the product names being advertised there, so that I can
remember to boycott them.
As someone else has already pointed out, the very first example program is
broken (the include directive is split onto two lines). Also, the program
exhibits poor style, as it fails to provide a full prototype in the
function declarator, uses printf where puts would have been better suited
to the task, and has a completely useless getchar call.
"By including header files, you an gain access to many different functions.
For example, the printf function requires getchar." I never heard such
nonsense in all my born days.
"The printf function is the standard C way of displaying output on the
screen." No. The printf function is the standard C way of writing formatted
output to the standard output stream. The Standard does /not/ specify that
printf writes to a screen, and indeed often printf does not do that.
"The actual effect of '\n' is to move the cursor on your screen to the next
line." No. The actual effect of '\n' is - none whatsoever! It's just a
value. It doesn't have an effect. The effect is produced not by '\n' but by
printf. Furthermore, C doesn't require that you have a screen, or a cursor,
so the statement is clearly wrong in that regard also.
"Again, notice the semicolon: it is added onto the end of all lines, such as
function calls, in C."
This is very misleading. Firstly, a function call is not a line. Secondly,
the novice C programming student reading this "tutorial" is not in a
position to know which lines are included in the "such as" and which are
not.
"The next command is getchar()." No, getchar is not a command. C doesn't
have commands.
"This is another function call: it reads in a single character and waits for
the user to hit enter before reading the character." No, it doesn't. It
reads a character from the standard input stream and returns as soon as one
is available or as soon as it becomes evident that no further characters
will be available on that stream. It does not "wait for the user to hit
enter". The operating system might or might not, but getchar doesn't; it
waits for the character to become available (or for a report that this
ain't ever gonna happen).
"This line is included because many compiler environments will open a new
console window, run the program, and then close the window before you can
see the output." Stupid stupid stupid. Just teach them how to use a console
properly instead, FCOL!
Over 30 lines of crit, and I'm still on the first section of the first page.
There simply isn't enough time to list all the problems with that tutorial.
C tutorials at www.cprogramming.com - Just Say No.
That site is broken. If you're serious about learning C properly, ignore the
site completely.
When I go looking for the C tutorial, I eventually find it at: "Lesson 1:
The basics of C++", which claims "to be a stand-alone introduction to C".
I then see a bunch of adverts, right there after the introductory paragraph,
as if the lesson were now over. Poor design, and it really, really makes me
want to write down the product names being advertised there, so that I can
remember to boycott them.
As someone else has already pointed out, the very first example program is
broken (the include directive is split onto two lines). Also, the program
exhibits poor style, as it fails to provide a full prototype in the
function declarator, uses printf where puts would have been better suited
to the task, and has a completely useless getchar call.
"By including header files, you an gain access to many different functions.
For example, the printf function requires getchar." I never heard such
nonsense in all my born days.
"The printf function is the standard C way of displaying output on the
screen." No. The printf function is the standard C way of writing formatted
output to the standard output stream. The Standard does /not/ specify that
printf writes to a screen, and indeed often printf does not do that.
"The actual effect of '\n' is to move the cursor on your screen to the next
line." No. The actual effect of '\n' is - none whatsoever! It's just a
value. It doesn't have an effect. The effect is produced not by '\n' but by
printf. Furthermore, C doesn't require that you have a screen, or a cursor,
so the statement is clearly wrong in that regard also.
"Again, notice the semicolon: it is added onto the end of all lines, such as
function calls, in C."
This is very misleading. Firstly, a function call is not a line. Secondly,
the novice C programming student reading this "tutorial" is not in a
position to know which lines are included in the "such as" and which are
not.
"The next command is getchar()." No, getchar is not a command. C doesn't
have commands.
"This is another function call: it reads in a single character and waits for
the user to hit enter before reading the character." No, it doesn't. It
reads a character from the standard input stream and returns as soon as one
is available or as soon as it becomes evident that no further characters
will be available on that stream. It does not "wait for the user to hit
enter". The operating system might or might not, but getchar doesn't; it
waits for the character to become available (or for a report that this
ain't ever gonna happen).
"This line is included because many compiler environments will open a new
console window, run the program, and then close the window before you can
see the output." Stupid stupid stupid. Just teach them how to use a console
properly instead, FCOL!
Over 30 lines of crit, and I'm still on the first section of the first page.
There simply isn't enough time to list all the problems with that tutorial.
C tutorials at www.cprogramming.com - Just Say No.
K
Keith Thompson
Richard Heathfield said:
Certainly splitting the include directive is an error. (I suspect the
author was having trouble writing the HTML correctly, but of course
that's no excuse.) And I agree that a full prototype should have been
used for main.
As for using printf rather than puts, I don't see the problem. For a
beginner, remembering a single output function is easier than
remembering a multitude of them; that can come later. I even tend to
use printf() myself where simpler functions like puts() or fputs()
would suffice, and least in quick-and-dirty code (and sometimes the
compiler will replace printf() with puts()).
(Note: "quick-and-dirty" doesn't mean I don't bother to make sure the
program is correct; it just means I tend to favor simplicity over some
other factors.)
After all, even K&R uses printf() for the classic "hello, world"
program.
As for the "completely useless getchar call" ...
[...]
Why should a C tutorial teach how to use a (presumably Windows)
console properly? I'm not even sure how to do so myself (what little
Windows programming I do is under Cygwin, and I use an xterm window,
not a Windows console).
P
pete
Keith said:
I think printf should be used until after
the tutorial chapter on the string library.
The final getchar call, suggests that the
code's author doesn't know how to use a console properly.
The way I do it with MSVC,
I found out where the linker's output goes to,
and I wrote a batch file called vc.bat
to change the working directory to where the linker's output goes to
and I put the batch file in the directory
that the dos prompt opens up to.
Then when I open the dos prompt, I enter vc, and I'm there.
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.
C:\Documents and Settings\pete>type vc.bat
cd\Program Files\DevStudio\SharedIDE\bin\debug
C:\Documents and Settings\pete>vc
C:\Documents and Settings\pete>cd\Program
Files\DevStudio\SharedIDE\bin\debug
C:\Program Files\DevStudio\SharedIDE\bin\Debug>new
This machine uses: Two's complement.
C:\Program Files\DevStudio\SharedIDE\bin\Debug>
R
Richard Heathfield
Keith Thompson said:
The problem is that it introduces too many concepts in one go. The beginner
has enough weirdities to fathom in a C program without having to worry
about \n. That can come later.
And whilst K&R is an excellent book, I don't think it's perfect by any
means. When I get around to writing a better one, I'll let you know.
Why should a C tutorial assume you're using a (presumably Windows) GUI? It's
the same only backwards. Do you put a getchar call at the end of your C
programs? I certainly don't. Nor does any serious C programmer I know. Why
teach people a lame way to do things?
From memory, assuming a vanilla XP install:
Start/Programs/Accessories/Command Prompt
or just:
Windows-R to bring up a run dialog, and type: cmd
Then cd to wherever your program is, and type in the program name. Hardly
rocket science.
The problem is that it introduces too many concepts in one go. The beginner
has enough weirdities to fathom in a C program without having to worry
about \n. That can come later.
And whilst K&R is an excellent book, I don't think it's perfect by any
means. When I get around to writing a better one, I'll let you know.
Why should a C tutorial assume you're using a (presumably Windows) GUI? It's
the same only backwards. Do you put a getchar call at the end of your C
programs? I certainly don't. Nor does any serious C programmer I know. Why
teach people a lame way to do things?
From memory, assuming a vanilla XP install:
Start/Programs/Accessories/Command Prompt
or just:
Windows-R to bring up a run dialog, and type: cmd
Then cd to wherever your program is, and type in the program name. Hardly
rocket science.
K
Keith Thompson
Richard Heathfield said:
Ok. Personally, I think that introducing \n at this point isn't a
problem; the student doesn't have to understand yet how it works, just
that it's a code that says "this is the end of the line". For
example, it's nice to know that this:
printf("hello, world\n");
and this:
printf("hello");
printf(", ");
printf("world");
printf("\n");
are equivalent.
But then I've never taught C to beginners (except in this newsgroup),
so I don't claim to be an expert on how much information is too much.
I guess I'm trying to say that I disagree without claiming that I'm
right and you're wrong.
And whilst K&R is an excellent book, I don't think it's perfect by any
means. When I get around to writing a better one, I'll let you know.
Yes, please do!
}Ok, that's a fair point. The getchar() call is there specifically to
allow you to see the output in one specific context, running the
program under Windows. Teaching how to do this properly *shouldn't*
need to be part of a C tutorial, but I suppose it would be appropriate
to have a sidebar.
Well, yes, I know about that. I was thinking there might be a way to
run the program through the Windows GUI without having the window
vanish as soon as the program terminates.
I know a lot of Windows programmers invoke the compiler from some kind
of GUI. There *should* be a way to run a generated program sensibly
from that GUI, rather than having to fire up a separate command prompt
window and find the right directory manually -- and perhaps there is.
Since I'm a command-line guy myself, I'm just displaying my ignorance
in this area.
A
Al Balmer
Generally, I would expect such a GUI (probably called an IDE) to
provide a way to execute the program and capture the output, and
probably even to run it under a debugger.
It doesn't need to be a special-purpose interface - my editor can
invoke commands to build and execute, while capturing the output in a
separate window. In fact, it (or other versions of it) can do the same
thing under several different operating systems, not just Windows.
But these are questions about tools, not the language.
R
Richard Heathfield
Keith Thompson said:
Fair enough. I suppose we all have different approaches. I'm very much in
favour of the "explain as little as possible, but as much as necessary, at
a time" philosophy, and I think it constructive to defer discussion of
printf until a little later.
I don't know of a Win32 GUI technique for doing this, but if the student
programmer is using an IDE it is generally possible to tell it to keep the
program window open. It's certainly possible in Visual C++. With my
keymappings, it's Ctrl-F5, which runs the program outside the debugger, and
which has its own "Press a key to continue" code, so that you needn't
pollute your own program with it. If you want to run /with/ the debugger,
great! Just set a breakpoint on return 0; in main. Easy.
Depends on the GUI, obviously, but yes, I've never had a problem finding a
way to do that in the IDEs I've used.
The command line is the way to go, especially since so many early C tutorial
programs work best when you redirect input from a file, which is a bit
tricky in some IDEs.
Fair enough. I suppose we all have different approaches. I'm very much in
favour of the "explain as little as possible, but as much as necessary, at
a time" philosophy, and I think it constructive to defer discussion of
printf until a little later.
I don't know of a Win32 GUI technique for doing this, but if the student
programmer is using an IDE it is generally possible to tell it to keep the
program window open. It's certainly possible in Visual C++. With my
keymappings, it's Ctrl-F5, which runs the program outside the debugger, and
which has its own "Press a key to continue" code, so that you needn't
pollute your own program with it. If you want to run /with/ the debugger,
great! Just set a breakpoint on return 0; in main. Easy.
Depends on the GUI, obviously, but yes, I've never had a problem finding a
way to do that in the IDEs I've used.
The command line is the way to go, especially since so many early C tutorial
programs work best when you redirect input from a file, which is a bit
tricky in some IDEs.