Why is C good??? any experts?

[Suresh]

Hi,
I am new to C and curious to know some basic questions about C.
Why C is good?
In what way its better than any other languages?
If it is no longer a choice of programming language...why people still study
it?
And also its not an OO language either...is there any advantages in being
not an OO language?

I know one reason is that, IT started with C and so they are still using
them rather than changing it into new language.

[Neil Kurzman]

First

Like any other tool make sure it is the right tool for the job.
My Job 8 and 16 bit battery chargers.
I can see the code as I step though it with the emulator.
I need to know what gets pushed on my tiny stack.
I need to know what is going to call a library and push all the
registers during an interrupt.
On a PC who cares, the memory and power are there.
I need to know that the clocks I pulse out to to get serial data are the
right size each time.
In VB you wound need a C DLL to direct access Hardware registers.
Bit banging works better in C. C can directly access register arrays
without special libraries. Is easier to link to ASM.
C still works on 8 and 16 bit stuff. I try to not to write it all in
ASM. It takes too long and is more tedious.

Managed code has real time limits. C is more predictable. It also
allows you to do play with types. Peek and Poke memory that is not yours
and other hideous stuff. More control, but more ability to screw stuff
up.

So it is far from dead. But it is not the right tool for every job.
There is not 1 perfect tool for all jobs.
You write Windows program in assembler. I would not recommend it.
There are a lot of thing that you can do in C, but is easier in other
languages.
I tend to talk to the chargers in VB 6. It is much quicker and easier
to debug. ( It is also obsolete)
When ask to write a program to reflash them. that " must fit on a
floppy, and does not have to be installed"
only C and C++ jumped out. C++ would have been over kill.

Learning C will not hurt a programmer. Nor would learning ASM. Someone
fresh out of school has a high chance of tripping over it.

The electric screw driver did not make the regular one obsolete. All
the new stuff has not made C obsolete yet.
BTW try this Is assume JPL has a few programmers. On a board write all
the languages all have programed in. Note the number of dead or almost
dead ones.

No I can not believe I wrote so much on this topic.

Neil

[Neil Kurzman]

First

Like any other tool make sure it is the right tool for the job.
My Job 8 and 16 bit battery chargers.
I can see the code as I step though it with the emulator.
I need to know what gets pushed on my tiny stack.
I need to know what is going to call a library and push all the
registers during an interrupt.
On a PC who cares, the memory and power are there.
I need to know that the clocks I pulse out to to get serial data are the
right size each time.
In VB you wound need a C DLL to direct access Hardware registers.
Bit banging works better in C. C can directly access register arrays
without special libraries. Is easier to link to ASM.
C still works on 8 and 16 bit stuff. I try to not to write it all in
ASM. It takes too long and is more tedious.

Managed code has real time limits. C is more predictable. It also
allows you to do play with types. Peek and Poke memory that is not yours
and other hideous stuff. More control, but more ability to screw stuff
up.

So it is far from dead. But it is not the right tool for every job.
There is not 1 perfect tool for all jobs.
You write Windows program in assembler. I would not recommend it.
There are a lot of thing that you can do in C, but is easier in other
languages.
I tend to talk to the chargers in VB 6. It is much quicker and easier
to debug. ( It is also obsolete)
When ask to write a program to reflash them. that " must fit on a
floppy, and does not have to be installed"
only C and C++ jumped out. C++ would have been over kill.

Learning C will not hurt a programmer. Nor would learning ASM. Someone
fresh out of school has a high chance of tripping over it.

The electric screw driver did not make the regular one obsolete. All
the new stuff has not made C obsolete yet.
BTW try this Is assume JPL has a few programmers. On a board write all
the languages all have programed in. Note the number of dead or almost
dead ones.

No I can not believe I wrote so much on this topic.

Neil

[RoSsIaCrIiLoIA]

On Fri, 30 Apr 2004 06:29:29 GMT, Neil Kurzman <ns*@mail.asb.c om>
wrote:

"E. Robert Tisdale" wrote:

Chris Dutton wrote:

> and how that additional information will impact things like
> memory layout of an aggregate data structure.

C effectively the next step above Assembly.
It gives more control over memory usage and hardware access.
You pay for the control with more responsibility. More code to do the
same task.
And you get to watch for buffer overruns and memory leaks.

and if
it is defined a function that in the end of prog free all dynamic
allocated memory with malloc or realloc? (there will no memory leak)

and if
there were library functions that doesn't allow buffer overrun?

[Kevin Bagust]

In article <40************ @jpl.nasa.gov>,
E. Robert Tisdale <E.************ **@jpl.nasa.gov > wrote:

Xenos wrote:

E. Robert Tisdale wrote:

With assembly language

The correct term is *assembler*.

God, I hate it when people said that. No, it is Assembly Language.
The assembler is the tool that converts it to machine code.
Do you say "compiler" instead of "C"?

According to the Free OnLine Dictionary Of Computing http://wombat.doc.ic.ac.uk/foldoc/fo...embly+Language Assembly Language

<Snip>

Where as from the same place:

http://wombat.doc.ic.ac.uk/foldoc/fo...uery=Assembler

<programming> A program which converts assembly language into machine
code.

(1996-03-25)

and

http://wombat.doc.ic.ac.uk/foldoc/fo...embly+language

<language> (Or "assembly code") A symbolic representation of the machine
language of a specific processor. Assembly language is converted to
machine code by an assembler. Usually, each line of assembly code
produces one machine instruction, though the use of macros is common.

Programming in assembly language is slow and error-prone but is the only
way to squeeze every last bit of performance out of the hardware.

Filename extension: .s (Unix), .asm (CP/M and others).

See also second generation language.

(1996-09-17)

[Erik de Castro Lopo]

RoSsIaCrIiLoIA wrote:

and if
it is defined a function that in the end of prog free all dynamic
allocated memory with malloc or realloc? (there will no memory leak)
That is not the problem. What if you have a program that needs to run continuously
for weeks or months, like a mail or web server, database? If this program has a
memory leak, it can run out of memory. Releasing memory when the progam
terminates is not a solution.
and if
there were library functions that doesn't allow buffer overrun?

Carefuly programming with functions already in the standard library can
prevent buffer overflows.

Erik
--
+-----------------------------------------------------------+
Erik de Castro Lopo no****@mega-nerd.com (Yes it's valid)
+-----------------------------------------------------------+
"The day Microsoft makes something that doesn't suck is probably the
day they start making vacuum cleaners." -- Ernst Jan Plugge

[E. Robert Tisdale]

Kevin Bagust wrote:

http://wombat.doc.ic.ac.uk/foldoc/fo...embly+language

<language> (Or "assembly code") A symbolic representation of the machine
language of a specific processor. Assembly language is converted to
machine code by an assembler. Usually, each line of assembly code
produces one machine instruction, though the use of macros is common.

Programming in assembly language is slow and error-prone but is the only
way to squeeze every last bit of performance out of the hardware.

Filename extension: .s (Unix), .asm (CP/M and others).

See also second generation language.

(1996-09-17)

I used Google

http://www.google.com/

to search for

+"assembler language"

and I found lots of stuff including

http://search390.techtarget.com/sDef...211604,00.html

The *correct* name for the language accepted by an assembler
is assembler.

The term "assembly language" is an anachronism used by the "unwashed".

[Michael Wojcik]

In article <Pi************ *************** ****@drj.pf>, da*****@NOMORES PAMcs.utoronto. ca.com (Darrell Grainger) writes:

Legacy code is a big reason why COBOL is still around.

New applications are also a big reason why COBOL is still around.

Once a programming language comes into widespread use, it tends to
stick around. In the case of COBOL, there's a very large workforce
of COBOL programmers, and development managers who are used to
running COBOL projects, and company officers who are comfortable with
the idea of COBOL-based applications - factors which prevent COBOL
from becoming a "maintenanc e" language. (I imagine the situation
with Fortran is similar.)

Which is fine with me, since COBOL pays my salary.

Getting back on topic: C has even more momentum than COBOL, in part
because it's also a popular hobbyist language; free implementations
are readily available, as is source code to examine and modify; the
runtime is generally preinstalled, which simplifies packaging and
distribution of programs.

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

[After the lynching of George "Big Nose" Parrot, Dr. John] Osborne
had the skin tanned and made into a pair of shoes and a medical bag.
Osborne, who became governor, frequently wore the shoes.
-- _Lincoln [Nebraska] Journal Star_

[Darrell Grainger]

On Fri, 30 Apr 2004, E. Robert Tisdale wrote:

Darrell Grainger wrote:

E. Robert Tisdale wrote:

Chris Dutton wrote:

C is sometimes known as "portable assembler".
The key concept represented by this statement is that
C is closer to the machine that most other languages.

I don't know what that means.
Which "machine" is C "close to"?
Is C "farther" from machines that are not "close to"
the machine that C is "close to".
What sort of topology allows this sort of reasoning?

Have you never heard someone use the expression "close to" as a way of
saying "similar in attributes"? For example, Latin is close to Italian,

With assembly language

The correct term is *assembler*.

Go to www.dictionary.com ans search for "assembly language". Or you could
try going to IEEE and get a copy of 610.12. From the IEEE:

assembly language. A programming language that corresponds
closely to the instruction set of a given computer, allows
symbolic naming of operations and addresses, and usually
results in a one-to-one translation of program instructions
into machine instruction. Syn: assembler language; low
level language; second generation language.

How could you not be aware of this? You have lost a great deal of
credibility and so far you have only made one statement. By the way, an
assembler is the computer program that translates programs expressed in
ASSEMBLY LANGUAGE into their machine language equivalents.

Compare C language to assembly language. It is nonsense to compare C
language to an assembler.

there is a one to one correspondence to machine language
(unless we are talking about algebraic assemblers).

Here are the first five lines of an assembler listing:

.file "main.c"
.text
.align 2
.globl loop
.type loop,@function

Please tell us
which machine language instructions correspond to these lines.

Proof by example. NOTE: 'close to' or 'similar'. To prove that assembly
language is not 'close to' machine language you must show how there is a
notable difference between *ALL* assembly listings and machine language.

If something is similar to assembly language
then it is "close to" assembly language.

How is C "similar" to assembler?

The C programming language is not similar to an assembler. I never claimed
that it was.

Because there is a one to one correspondence
between assembly language and machine language, it could be said that
it is also close to machine language or close to the machine.

I don't dispute that
assembler *instructions* correspond to machine instructions.

You seem to be stuck on semantics here. If you cannot understand that
assembler instructions and assembly language (or assembly code or
assembler code) are the same thing then you are too thick to talk to.

For example, I will notice that certain statements in C language
will always produce the same machine language on a given machine.

I have noticed that certain statements in C language
will *not* always produce the same machine language on a given machine.

Okay, so C language is not EXACTLY machine language. There is not a hard
one-to-one correspondence. Thus it has been said that C is 'close to' the
machine language.
Generally, the emitted code depends upon context.
Different compilers emit different machine code
for the same C language statements.
Different options can cause the compiler to emit different machine code
for the same C language statements.

This is not to say that, for all C language,
there is a one to one correspondence with machine/assembly language.
How similar C code will be to the machine language
will differ for each compiler on each architecture.
How, then, can C language code be "close" to machine language code
on each of these different architectures?

For any given architecture it is 'close to' that architecture. If I was to
write a loop that counted from zero to 100 in PDP-11 assembly language,
same thing for a MC68000 assembly language and again for ARM9 assembly
language there will be similarities between them. Even if I never
programmed ARM9 assembly language, I could look at the code and figure out
it is a loop that counts from 0 to 100. If I compiled:

for(i = 0; i <= 100; i++)
/* do something */

The machine code generated by this code snippet would be similar on
PDP-11, MC68000, ARM9 just like the assembly language on those three
processors would be similar. They will never be exact but the general idea
will be the same. This is what 'close to' means.

Depend who you are talking to. If you talk to Electrical Engineers,
people with a hardware design background

I have a hardware design background.

or embedded programmers you will find that
they really do know what a C program is doing.
Most of them will code in C but optimize and debug in assembler.

Most of us don't do this anymore.
We use good optimizing compilers instead/

You took a survey? Or asked all the embedded programmers in the world? I
can believe that there are embedded programmers who don't know assembly
language but I would never say that 'most of them' don't do this anymore.
My experience has been that they do. I have seen certain groups of
embedded programmers that don't know what is happening at the machine
level but my experience has been that the majority of them do.

Strange, first you say that 'People who claim to know
"exactly what a C program is doing" are almost never correct.'
and now you are implying that
people who understand a programming language
don't need to "guess" at what it is doing. So which is it?

You need read the assembler listing emitted by you C compiler
to know exactly what your C program is doing.

Or you load the program in to a debugger and do a disasssembly of it. This
is how most the people I work with know what the C compiler is doing.
Actually, the debugger I have will display the C code with the assembly
language interlaced.
The assembler will depend upon

1. the machine architecture,
2. the compiler and
3. the options that you chose to compile your program.

C programmers are notoriously bad at predicting
what assembler code will be emitted
when they port their programs from one platform to another.

How have you come to this conclusion?

I guess the bottom line is that my experiences are different from your.
You seem to be exposed to a different group of programmers than myself.
Additionally, the fact that you are so hung up on semantics makes me
wonder if there is any point discussing this any further.

This will most likely be the last posting from me on the topic. I see no
reason for beating a dead horse.

--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vi************@ whitehouse.gov

[Darrell Grainger]

On Sat, 1 May 2004, E. Robert Tisdale wrote:

Kevin Bagust wrote:

http://wombat.doc.ic.ac.uk/foldoc/fo...embly+language

<language> (Or "assembly code") A symbolic representation of the machine
language of a specific processor. Assembly language is converted to
machine code by an assembler. Usually, each line of assembly code
produces one machine instruction, though the use of macros is common.

Programming in assembly language is slow and error-prone but is the only
way to squeeze every last bit of performance out of the hardware.

Filename extension: .s (Unix), .asm (CP/M and others).

See also second generation language.

(1996-09-17)
I used Google

http://www.google.com/

to search for

+"assembler language"

and I found lots of stuff including

http://search390.techtarget.com/sDef...211604,00.html

Went there.
The *correct* name for the language accepted by an assembler
is assembler.
Searched the page for "correct". Found no reference.
The term "assembly language" is an anachronism used by the "unwashed".

Searched for "assembly language". Found 1 occurence:

Some people call these instructions assembler language
and others use the term assembly language.

Nothing about whether it is correct or not. No reference to "unwashed". It
seems to me that this is your opinion. I choose to disagree with your
opinion.

<Plonk>

--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vi************@ whitehouse.gov

[Joona I Palaste]

Darrell Grainger <da*****@nomore spamcs.utoronto .ca.com> scribbled the following:

On Fri, 30 Apr 2004, E. Robert Tisdale wrote:

The correct term is *assembler*.

Go to www.dictionary.com ans search for "assembly language". Or you could
try going to IEEE and get a copy of 610.12. From the IEEE: assembly language. A programming language that corresponds
closely to the instruction set of a given computer, allows
symbolic naming of operations and addresses, and usually
results in a one-to-one translation of program instructions
into machine instruction. Syn: assembler language; low
level language; second generation language. How could you not be aware of this? You have lost a great deal of
credibility and so far you have only made one statement. By the way, an
assembler is the computer program that translates programs expressed in
ASSEMBLY LANGUAGE into their machine language equivalents. Compare C language to assembly language. It is nonsense to compare C
language to an assembler.

Here are the first five lines of an assembler listing:

.file "main.c"
.text
.align 2
.globl loop
.type loop,@function

Please tell us
which machine language instructions correspond to these lines. Proof by example. NOTE: 'close to' or 'similar'. To prove that assembly
language is not 'close to' machine language you must show how there is a
notable difference between *ALL* assembly listings and machine language. How is C "similar" to assembler?

The C programming language is not similar to an assembler. I never claimed
that it was.

> Because there is a one to one correspondence
> between assembly language and machine language, it could be said that
> it is also close to machine language or close to the machine.

I don't dispute that
assembler *instructions* correspond to machine instructions.

You seem to be stuck on semantics here. If you cannot understand that
assembler instructions and assembly language (or assembly code or
assembler code) are the same thing then you are too thick to talk to.

Either E.Robert Tisdale is a patent idiot or he does a very good job at
pretending to be one. Trying to get your point across to him is a lost
cause. Arguing with him is futile. I suggest all comp.lang.c
participatns killfile him.

--
/-- Joona Palaste (pa*****@cc.hel sinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It's time, it's time, it's time to dump the slime!"
- Dr. Dante