What are the important parts of C languages?

[Malcolm]

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.

 

[Malcolm]

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.

 

[Malcolm]

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.

 

[Alexei A. Frounze]

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

 

[John Bode]

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

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];

 

[William Hughes]

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

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

 

[wilsonidv]

I really appreciate your reply.
It seems unfamiliar to me with Pointer. I must work more on it.
^^^^^^^

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.

 

[wilsonidv]

I really appreciate your reply.
It seems unfamiliar to me with Pointer. I must work more on it.
^^^^^^^

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.

 

[ozbear]

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

 

[Old Wolf]

(e-mail address removed) 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.

 

[Jack Klein]

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.

 

[Ben Pfaff]

(e-mail address removed) 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.

 

[Michael Wojcik]

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 (e-mail address removed)

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)

 

[Anonymous 7843]

(e-mail address removed) 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.

 

[Malcolm]

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.

 

[William Hughes]

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