By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,564 Members | 834 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,564 IT Pros & Developers. It's quick & easy.

What are the important parts of C languages?

P: n/a
Daer All:

I have studied C language for just 2~3 months.
I'd like to know the critical parts of C, focusing on these.

Could anyone has many experiences tell me, please.

Thanks and Regards.

Nov 15 '05 #1
Share this Question
Share on Google+
35 Replies


P: n/a

wilson...@hotmail.com 写道:
Daer All:

I have studied C language for just 2~3 months.
I'd like to know the critical parts of C, focusing on these.

Could anyone has many experiences tell me, please.

Thanks and Regards.


everything is important,and the most important part is pointer

Nov 15 '05 #2

P: n/a
On 26 Sep 2005 20:50:51 -0700, wi*******@hotmail.com wrote in
comp.lang.c:
Daer All:

I have studied C language for just 2~3 months.
I'd like to know the critical parts of C, focusing on these.
I have no idea what you mean by "critical parts", and neither does the
C language standard, since it doesn't define anything remotely like
this term.
Could anyone has many experiences tell me, please.

Thanks and Regards.


The most critical part of the use of any programming language is
writing correct programs. That is just as true of C as it is of every
other language.

If you have some special meaning in mind for "critical parts", you had
better post again and define that meaning.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 15 '05 #3

P: n/a
Thank you.

Nov 15 '05 #4

P: n/a
Daer Jack Klein:

I'm sorry for my unclear meaning.
I'd like to know the most important or essentisl portions of C
language, for I could focus on reading these.

Thanks for reply.

Nov 15 '05 #5

P: n/a
<wi*******@hotmail.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...
I have studied C language for just 2~3 months.
I'd like to know the critical parts of C, focusing on these.


Everything. I've been studying it and programming in it for about 5 years
now.
And I'm still far from ideal.

Alex
Nov 15 '05 #6

P: n/a
wi*******@hotmail.com writes:
I'm sorry for my unclear meaning.
I'd like to know the most important or essentisl portions of C
language, for I could focus on reading these.


First, please provide context when you post a followup. We can't
necessarily see the article to which you're replying.

If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.

Second, I don't think you've made your question any clearer. I think
the problem is that you're asking the wrong question. Somebody
mentioned pointers; it's true that pointers play a larger role in C
than in most other languages. But I think what you really need is
advice on how to learn C.

K&R2 (Kernighan & Ritchie's "The C Programming Language", 2nd Edition)
is almost universally considered to be one of the best C tutorials in
existence. Get a copy of the book and work through it. Do the
exercises.

Read the C FAQ, <http://www.eskimo.com/~scs/C-faq/faq.html>. Parts of
it may not make much sense yet, but they should by the time you finish
K&R2. The FAQ also has some advice on books and other resources.

Pick a good medium-sized project and implement it in C. I don't have
any good ideas off the top of my head, but I'm sure others will.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.
Nov 15 '05 #7

P: n/a
Keith Thompson wrote:

<snip>
... I think what you really need is advice on how to learn C.

K&R2 (Kernighan & Ritchie's "The C Programming Language", 2nd Edition)
is almost universally considered to be one of the best C tutorials in
existence. Get a copy of the book and work through it. Do the
exercises.

Read the C FAQ, <http://www.eskimo.com/~scs/C-faq/faq.html>. Parts of
it may not make much sense yet, but they should by the time you finish
K&R2. The FAQ also has some advice on books and other resources.

Pick a good medium-sized project and implement it in C. I don't have
any good ideas off the top of my head, but I'm sure others will.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.


In my opinion (such as it is), this is the best answer and info that
could be given to a new 'C' programmer. It should be used as the
standard template for the question, "How do I get started learning the
'C' Programming Language?" (and other questions of similar ilk).

newby2c

Nov 15 '05 #8

P: n/a
try focus more on pointers & better try out programs, and then study
test ur c skills

Nov 15 '05 #9

P: n/a
Thank you for advice.

Keith Thompson wrote:
wi*******@hotmail.com writes:
I'm sorry for my unclear meaning.
I'd like to know the most important or essentisl portions of C
language, for I could focus on reading these.


First, please provide context when you post a followup. We can't
necessarily see the article to which you're replying.

If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers.

Second, I don't think you've made your question any clearer. I think
the problem is that you're asking the wrong question. Somebody
mentioned pointers; it's true that pointers play a larger role in C
than in most other languages. But I think what you really need is
advice on how to learn C.

K&R2 (Kernighan & Ritchie's "The C Programming Language", 2nd Edition)
is almost universally considered to be one of the best C tutorials in
existence. Get a copy of the book and work through it. Do the
exercises.

Read the C FAQ, <http://www.eskimo.com/~scs/C-faq/faq.html>. Parts of
it may not make much sense yet, but they should by the time you finish
K&R2. The FAQ also has some advice on books and other resources.

Pick a good medium-sized project and implement it in C. I don't have
any good ideas off the top of my head, but I'm sure others will.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <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.


Nov 15 '05 #10

P: n/a
wi*******@hotmail.com wrote:
I'd like to know the critical parts of C, focusing on these.


5. Environment
6. Language
7. Library

N869

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/

--
pete
Nov 15 '05 #11

P: n/a
hi wilson,
i am working on c/c++ since last 4 years. every aspect of any lang., be
it c, c++ java or any else, is important. One should try to learn
maximum ways to do a prog. Especially in C lang. functions, pointers
and libraries are very important. It is said that, no C programmer
without Pointer, hence try to make ur grip on pointer as firm as
possible.
happy C programming

Nov 15 '05 #12

P: n/a
Dear Friend ..

First of all i would like to tell you that all parts of the C
language r important . But if ur looking for a job or planning to work
on a C project then i would prefer that you look into topics like
Pointer, Structures, Union, Recursion
and Files. File is an important concept in C ....

Nov 15 '05 #13

P: n/a
indian <sh********@gmail.com> wrote:
try focus more on pointers & better try out programs, and then study
test ur c skills


How about focusing on the newsgroup for a few nanoseconds and learning
how to attribute correctly using Google groups? Instructions were
posted at least once in this very thread.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
Nov 15 '05 #14

P: n/a
sa*********@gmail.com wrote
(in article
<11**********************@g43g2000cwa.googlegroups .com>):
Dear Friend ..

First of all i [sic] would like to tell you that all parts of
the C language r [sic] important . But if ur [sic] looking for a job or

[rest snipped]

*sigh*

do u rly thnk this is ezier 2 rd?
--
Randy Howard (2reply remove FOOBAR)

Nov 15 '05 #15

P: n/a

wilson...@hotmail.com wrote:
Daer All:

I have studied C language for just 2~3 months.
I'd like to know the critical parts of C, focusing on these.

Could anyone has many experiences tell me, please.

Thanks and Regards.


All parts of the language are equally important; if you're asking for a
roadmap of which concepts should be learned in what order, you're
probably better off getting a copy of "The C Programming Language" by
Kernighan and Ritchie and studying that.

Different parts of the language present challenges to different people,
so I don't know if my personal experiences would be applicable to you.
Having said that, pointers and declarator syntax almost universally
frustrate novice C programmers, so you might want to focus on those.
When you get to the point where you understand what

int *(*(*foo)[10])(double y, void (*blah)(int **x))[30];

means, then you've mastered declarators.

Nov 15 '05 #16

P: n/a
"John Bode" <jo*******@my-deja.com> writes:
wilson...@hotmail.com wrote:
I have studied C language for just 2~3 months.
I'd like to know the critical parts of C, focusing on these.


All parts of the language are equally important; [...]


That statement is absurd. Consider the basic types, such as int
and char. They are used in every C program, so they are
important. Now consider bit-fields. They are not used in many C
programs. Thus, bit-fields are less important than the basic
types.
--
"The way I see it, an intelligent person who disagrees with me is
probably the most important person I'll interact with on any given
day."
--Billy Chambless
Nov 15 '05 #17

P: n/a

John Bode wrote:
wilson...@hotmail.com wrote:
Daer All:

I have studied C language for just 2~3 months.
I'd like to know the critical parts of C, focusing on these.

Could anyone has many experiences tell me, please.

Thanks and Regards.


All parts of the language are equally important; if you're asking for a
roadmap of which concepts should be learned in what order, you're
probably better off getting a copy of "The C Programming Language" by
Kernighan and Ritchie and studying that.

Different parts of the language present challenges to different people,
so I don't know if my personal experiences would be applicable to you.
Having said that, pointers and declarator syntax almost universally
frustrate novice C programmers, so you might want to focus on those.
When you get to the point where you understand what

int *(*(*foo)[10])(double y, void (*blah)(int **x))[30];

means, then you've mastered declarators.


Nonsense. When you have learned to write that in a useful
and understandable form then you've mastered declarators.
Mastering declarators does not mean being able to run cdecl in
your head.

-William Hughes

Nov 15 '05 #18

P: n/a

Ben Pfaff wrote:
"John Bode" <jo*******@my-deja.com> writes:
wilson...@hotmail.com wrote:
I have studied C language for just 2~3 months.
I'd like to know the critical parts of C, focusing on these.


All parts of the language are equally important; [...]


That statement is absurd. Consider the basic types, such as int
and char. They are used in every C program, so they are
important. Now consider bit-fields. They are not used in many C
programs. Thus, bit-fields are less important than the basic
types.


I was thinking a *little* higher-level than that, Ben.

Nov 15 '05 #19

P: n/a
sa*********@gmail.com wrote:
Dear Friend ..

First of all i would like to tell you that all parts of the
C language r important . But if ur looking for a job or planning to
work on a C project then i would prefer that you look into topics
like Pointer, Structures, Union, Recursion
and Files. File is an important concept in C ....


Please post in English. Also, read my sig.
Brian

--
Please quote enough of the previous message for context. To do so from
Google, click "show options" and use the Reply shown in the expanded
header.
Nov 15 '05 #20

P: n/a

"Jack Klein" <ja*******@spamcop.net> wrote
I have studied C language for just 2~3 months.
I'd like to know the critical parts of C, focusing on these.


I have no idea what you mean by "critical parts", and neither does the
C language standard, since it doesn't define anything remotely like
this term.

That's why we need human beings.

I'd say a "critical part" is a part of the language without which it is
impossible to write a real C program.
For instance I could get by without the tenary operator ( ? : ). You cannot
write a C program without the if() statement, however, except by misusing
other constructs in a bizarre way.
Nov 15 '05 #21

P: n/a
<wi*******@hotmail.com> wrote

I have studied C language for just 2~3 months.
I'd like to know the critical parts of C, focusing on these.

Could anyone has many experiences tell me, please.

Like virtually every other language C has statements for arithmetical
operations and flow control (do while for if else etc).

C is a procedural language, so it also has facilities for declaring
subroutines, called "functions", passing parameters to them, and keeping
variables local. Many other languages do this. Again this is something that
needs to be learned, and it is more difficult to design good functions than
it looks at first sight.

C also allows indirection, which usually means writes to a location in the
computer's physical memory. The address is called a "pointer". This is what
makes C different from a lot of other languages, and is really what makes C
the language it is. If I had to write a one sentence description of C, I
would say "A computer language that makes heavy use of pointers for runtime
efficiency".

Pointer are really the thing to focus on and to master, but they don't make
any sense until you are also using flow control and functions.
Nov 15 '05 #22

P: n/a

"William Hughes" <wp*******@hotmail.com> wrote
When you get to the point where you understand what

int *(*(*foo)[10])(double y, void (*blah)(int **x))[30];

means, then you've mastered declarators.


Nonsense. When you have learned to write that in a useful
and understandable form then you've mastered declarators.
Mastering declarators does not mean being able to run cdecl in
your head.

C allows you to write compileable gibberish.

A programmer who writes declarations like the above is undoubtedly a C
programmer, but not a very good one. I don't think anyone would find it easy
to tease that construct apart, but sometimes you have to do such a thing.
Nov 15 '05 #23

P: n/a
"Malcolm" <re*******@btinternet.com> wrote in message
news:dh**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com...
You cannot
write a C program without the if() statement, however, except by misusing
other constructs in a bizarre way.


E.g. complicated expressions and function pointers :) and the latter aren't
used in every program, nor var args, nor floating point and specific parts
of the standard library.

Alex
Nov 15 '05 #24

P: n/a

Malcolm wrote:
"William Hughes" <wp*******@hotmail.com> wrote
When you get to the point where you understand what

int *(*(*foo)[10])(double y, void (*blah)(int **x))[30];

means, then you've mastered declarators.


Nonsense. When you have learned to write that in a useful
and understandable form then you've mastered declarators.
Are you telling me that's not perfectly understandable? :-p~~~
Mastering declarators does not mean being able to run cdecl in
your head.

C allows you to write compileable gibberish.

A programmer who writes declarations like the above is undoubtedly a C
programmer, but not a very good one. I don't think anyone would find it easy
to tease that construct apart, but sometimes you have to do such a thing.


The example was deliberately pathological; my point was that if you
really understood declarator syntax, then the hopefully rare encounter
with such a beast wouldn't leave you totally stumped.

At the very least, you would have noticed the bug. Here's the correct
version:

int *(*(*(*foo)[10])(double y, void (*blah)(int **x)))[30];

Nov 15 '05 #25

P: n/a

John Bode wrote:
Malcolm wrote:
"William Hughes" <wp*******@hotmail.com> wrote

> When you get to the point where you understand what
>
> int *(*(*foo)[10])(double y, void (*blah)(int **x))[30];
>
> means, then you've mastered declarators.

Nonsense. When you have learned to write that in a useful
and understandable form then you've mastered declarators.
Are you telling me that's not perfectly understandable? :-p~~~
Mastering declarators does not mean being able to run cdecl in
your head.
C allows you to write compileable gibberish.

A programmer who writes declarations like the above is undoubtedly a C
programmer, but not a very good one. I don't think anyone would find it easy
to tease that construct apart, but sometimes you have to do such a thing.


The example was deliberately pathological; my point was that if you
really understood declarator syntax, then the hopefully rare encounter
with such a beast wouldn't leave you totally stumped.


The problem is that

1 mastering C declarations

and

2 mastering C declaration syntax

are not the same thing at all. It is quite possible to master C
declarations without knowing all possible quirks of the syntax,
and knowing all the quirks of the syntax does not mean that you
have mastered C declarations.
At the very least, you would have noticed the bug. Here's the correct
version:

int *(*(*(*foo)[10])(double y, void (*blah)(int **x)))[30];


Describing something that does not compile as a bug is a bit
odd. Anyway, what makes you think the above is the correct
fix? Maybe what was needed is

int *(*(*(foo)[10])(double y, void (*blah)(int **x)))[30]

True, at times you may run into some similar monstrosity when
debugging, but this is a good hint that you will probably
be better off trying to rewrite rather than debug. If for
some reason you have to debug, then is the time to consult
the reference books and/or use tools like cdecl or your
complier (after hunting down and terminating with
extreme prejudice the original programmer).

- Willliam Hughes

Nov 15 '05 #26

P: n/a
I really appreciate your reply.
It seems unfamiliar to me with Pointer. I must work more on it.
^^^^^^^

John Bode wrote:
wilson...@hotmail.com wrote:
Daer All:

I have studied C language for just 2~3 months.
I'd like to know the critical parts of C, focusing on these.

Could anyone has many experiences tell me, please.

Thanks and Regards.


All parts of the language are equally important; if you're asking for a
roadmap of which concepts should be learned in what order, you're
probably better off getting a copy of "The C Programming Language" by
Kernighan and Ritchie and studying that.

Different parts of the language present challenges to different people,
so I don't know if my personal experiences would be applicable to you.
Having said that, pointers and declarator syntax almost universally
frustrate novice C programmers, so you might want to focus on those.
When you get to the point where you understand what

int *(*(*foo)[10])(double y, void (*blah)(int **x))[30];

means, then you've mastered declarators.


Nov 15 '05 #27

P: n/a
I really appreciate your reply.
It seems unfamiliar to me with Pointer. I must work more on it.
^^^^^^^

John Bode wrote:
wilson...@hotmail.com wrote:
Daer All:

I have studied C language for just 2~3 months.
I'd like to know the critical parts of C, focusing on these.

Could anyone has many experiences tell me, please.

Thanks and Regards.


All parts of the language are equally important; if you're asking for a
roadmap of which concepts should be learned in what order, you're
probably better off getting a copy of "The C Programming Language" by
Kernighan and Ritchie and studying that.

Different parts of the language present challenges to different people,
so I don't know if my personal experiences would be applicable to you.
Having said that, pointers and declarator syntax almost universally
frustrate novice C programmers, so you might want to focus on those.
When you get to the point where you understand what

int *(*(*foo)[10])(double y, void (*blah)(int **x))[30];

means, then you've mastered declarators.


Nov 15 '05 #28

P: n/a
On Tue, 27 Sep 2005 09:35:10 -0700, Ben Pfaff <bl*@cs.stanford.edu>
wrote:
"John Bode" <jo*******@my-deja.com> writes:
wilson...@hotmail.com wrote:
I have studied C language for just 2~3 months.
I'd like to know the critical parts of C, focusing on these.


All parts of the language are equally important; [...]


That statement is absurd. Consider the basic types, such as int
and char. They are used in every C program, so they are
important. Now consider bit-fields. They are not used in many C
programs. Thus, bit-fields are less important than the basic
types.
--

Agreed. And setjmp/longjmp go to the bottom of my "must know" list.

Oz
--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?
Nov 15 '05 #29

P: n/a
ozbear wrote:
Ben Pfaff <bl*@cs.stanford.edu> wrote:
"John Bode" <jo*******@my-deja.com> writes:
wilson...@hotmail.com wrote:

I have studied C language for just 2~3 months.
I'd like to know the critical parts of C, focusing on these.

All parts of the language are equally important; [...]


That statement is absurd. Consider the basic types, such as int
and char. They are used in every C program, so they are
important. Now consider bit-fields. They are not used in many C
programs. Thus, bit-fields are less important than the basic
types.


Agreed. And setjmp/longjmp go to the bottom of my "must know" list.


They actually taught setjmp/longjmp in my Polytech C course, and
suggested we use it in one of the course assignments.

In fact they taught to use it from a signal handler as a way of
recovering from error conditions. This worked well in MS-DOS
but I'm told it isn't so great in other environments.

Nov 15 '05 #30

P: n/a
On Tue, 27 Sep 2005 09:35:10 -0700, Ben Pfaff <bl*@cs.stanford.edu>
wrote in comp.lang.c:
"John Bode" <jo*******@my-deja.com> writes:
wilson...@hotmail.com wrote:
I have studied C language for just 2~3 months.
I'd like to know the critical parts of C, focusing on these.


All parts of the language are equally important; [...]


That statement is absurd. Consider the basic types, such as int
and char. They are used in every C program, so they are
important. Now consider bit-fields. They are not used in many C
programs. Thus, bit-fields are less important than the basic
types.


Frankly, I disagree with your viewpoint. It is impossible to define
the most important parts of the C language/library without specifying
a problem domain. C is so widely used, from low level and system
programming to large, complex applications that would often be better
programmed in a different language.

Some of the code you've done and made public, on the web and in C
Unleashed, makes extensive use of dynamic memory. To you, malloc(),
calloc(), realloc(), and free() are probably far more important than
bit-fields.

On the other hand, almost all of my C programming is in
safety-critical real time embedded systems, where dynamic allocation
is never used. Most of these systems use integer math only, no
floating point at all. And the smaller ones often have severe memory
constraints.

So I use bit-fields much more than I use malloc() and friends, and
even quite a bit more than I use float, double, and long double.

For my work, bit-fields are much more important than the floating
point basic types, at least, and also more so than large portions of
the standard library.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html
Nov 15 '05 #31

P: n/a
Jack Klein <ja*******@spamcop.net> writes:
On Tue, 27 Sep 2005 09:35:10 -0700, Ben Pfaff <bl*@cs.stanford.edu>
wrote in comp.lang.c:
"John Bode" <jo*******@my-deja.com> writes:
> wilson...@hotmail.com wrote:
>> I have studied C language for just 2~3 months.
>> I'd like to know the critical parts of C, focusing on these.
>
> All parts of the language are equally important; [...]
That statement is absurd. Consider the basic types, such as int
and char. They are used in every C program, so they are
important. Now consider bit-fields. They are not used in many C
programs. Thus, bit-fields are less important than the basic
types.


Frankly, I disagree with your viewpoint. It is impossible to define
the most important parts of the C language/library without specifying
a problem domain. [...]


I don't think that's true at all. See below.
Some of the code you've done and made public, on the web and in C
Unleashed, makes extensive use of dynamic memory. To you, malloc(),
calloc(), realloc(), and free() are probably far more important than
bit-fields.
This is true. I don't use bit-fields much in my programming, but
I use dynamic memory extensively.
On the other hand, almost all of my C programming is in
safety-critical real time embedded systems, where dynamic allocation
is never used. Most of these systems use integer math only, no
floating point at all. And the smaller ones often have severe memory
constraints.


It's certainly true that different programmers use different
features. We can divide the C language into two categories of
features. There is a group of features that cannot be avoided
and that every programmer must understand. This includes basic
data types, the basics of declarators, block structure, statement
syntax, and so on. Everything else is in a second group, which
is features that not all programs or programmers use. I contend
that the features in the latter group are less important than
those in the former group.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}
Nov 15 '05 #32

P: n/a

In article <dh**********@nwrdmz01.dmz.ncs.ea.ibs-infra.bt.com>, "Malcolm" <re*******@btinternet.com> writes:

I'd say a "critical part" is a part of the language without which it is
impossible to write a real C program.
For many professional programmers, *reading* programs - often written
by others - is at least as important as writing them. Maintaining
(including enhancing) existing code and deriving implicit contracts
for inter-module calls, for example, both require reading code.
For instance I could get by without the tenary operator ( ? : ).


Until you need to understand a program that uses it.

Ben pointed out that, for example, basic types are used much more
commonly than bitfields, and so are more important to understanding
C, which is similar to what you're arguing here. And I'll agree that
few people need to know intimately every detail of the language.
I've yet to see a program that used strxfrm, so I don't bother
remembering what it's for. However, we should remember that for the
typical programmer, writing code is not the only task that calls for
a thorough understanding of the language.

--
Michael Wojcik mi************@microfocus.com

That's gotta be one of the principles behind reality. Accepting things
that are hard to comprehend, and leaving them that way. And bleeding.
Shooting and bleeding. -- Haruki Murakami (trans Philip Gabriel)
Nov 15 '05 #33

P: n/a
In article <433a062a.60493968@news-server>, ozbear <oz****@bigpond.com> wrote:
On Tue, 27 Sep 2005 09:35:10 -0700, Ben Pfaff <bl*@cs.stanford.edu>
wrote:
"John Bode" <jo*******@my-deja.com> writes:
wilson...@hotmail.com wrote:
I have studied C language for just 2~3 months.
I'd like to know the critical parts of C, focusing on these.

All parts of the language are equally important; [...]


That statement is absurd. Consider the basic types, such as int
and char. They are used in every C program, so they are
important. Now consider bit-fields. They are not used in many C
programs. Thus, bit-fields are less important than the basic
types.


Agreed. And setjmp/longjmp go to the bottom of my "must know" list.


I would put trigraphs are down there too.
Nov 15 '05 #34

P: n/a

"William Hughes" <wp*******@hotmail.com> wrote
It is quite possible to master C
declarations without knowing all possible quirks of the syntax,
and knowing all the quirks of the syntax does not mean that you
have mastered C declarations.

It is possible to know C declarations well enough to use them for practical
purposes, but you can't claim to have "mastered" it unless you know the full
grammar.

If you know the quirks of the syntax it doesn't mean you know how to use the
language effectively. Plenty of people can write grammatical English but
wouldn't win a place to read English literature at university.

Nov 15 '05 #35

P: n/a

Malcolm wrote:
"William Hughes" <wp*******@hotmail.com> wrote
It is quite possible to master C
declarations without knowing all possible quirks of the syntax,
and knowing all the quirks of the syntax does not mean that you
have mastered C declarations.

It is possible to know C declarations well enough to use them for practical
purposes, but you can't claim to have "mastered" it unless you know the full
grammar.

If you know the quirks of the syntax it doesn't mean you know how to use the
language effectively. Plenty of people can write grammatical English but
wouldn't win a place to read English literature at university.


And plenty of people are able to win a place to read English
literature at university without knowing all the quirks
of English syntax. The analogy holds.

-William Hughes

Nov 15 '05 #36

This discussion thread is closed

Replies have been disabled for this discussion.