Why is C good??? any experts?
Suresh
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.
Chris Dutton
I think all of your questions boil down to "why choose C over something
else?"
There are two answers.
1. 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. It's possible to understand exactly what a C
program is doing because there isn't (necessarily) a lot of overhead
going on. You don't have to guess what other information the compiler
is including in order for things like polymorphism to work, and how that
additional information will impact things like memory layout of an
aggregate data structure.
2. C is everywhere. C is about as ubiquitous a language as anyone
could ever hope for. If you want to write a clean, portable, minimal
(few dependencies) program, there are very few systems where it won't
compile and run.
E. Robert Tisdale
> 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?
New C programmers are required to maintain old C programs.
> And also its not an OO language either...
> is there any advantages in being not an OO language?
No.
Jack Klein
in comp.lang.c:
Your last statement is complete nonsense. IT started with FORTRAN and
COBOL as the high level languages, and other things like JCL.
--
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/~ajo/docs/FAQ-acllc.html
E. Robert Tisdale
> 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?
> It's possible to understand exactly what a C program is doing
> because there isn't (necessarily) a lot of overhead going on.
People who claim to know "exactly what a C program is doing"
are almost never correct.
> You don't have to guess what other information the compiler
> is including in order for things like polymorphism to work,
If you need to "guess" at these things,
you don't understand the programming language.
Kieran Simkin
operating system and the programs that run inside it are written in C not to
mention countless applications that are still in very much active
development.
I don't speak on behalf of the newsgroup here, but I simply don't like
object orientation. I find it obfuscates things in my mind and doesn't
provide many advantages in most non-gui situations. So to answer your
question about object orientation, OO is not necessarily the Way
Forward(tm), it just has some advantages in some situations.
I just started teaching myself C recently and if my reason for using it
would interest you; I'm replacing a lot of old Perl and PHP scripts I wrote
which were performing things that PHP in particular wasn't designed to do,
namely running as daemons and doing a lot of statistical calculations.
Compiled C beats Perl and PHP in speed and reliability hands down on both
these applications (assuming well written PHP/Perl vs. well written C).
Another thing that draws me to C over interpreted languages like Perl and
PHP is that if a program performs oddly, I can usually make the assumption
that it's my code that's broken rather than the language I'm writing it in.
Yes, there have been several occasions on which this hasn't been the case
with PHP.
Maybe this answers your question, I've explained why I like C in preference
to object orientated languages like C++ or Java *spit* and I've explained
why I like C over other procedural languages (if you count PHP and Perl as
programming languages rather than scripting languages).
--
~Kieran Simkin
Digital Crocus
http://digital-crocus.com/
"Suresh" <gsu...@rogers.com> wrote in message
news:lEhkc.319114$2oI1....@twister01.bloor.is.net.cable.rogers.com...
Neil Kurzman
"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?
CPUs execute Op-Codes. The CPU does not know about languages.
C gives you more control over what the CPU will get.
.NET and Java... are not under the Programmers control.
>
>
> > It's possible to understand exactly what a C program is doing
> > because there isn't (necessarily) a lot of overhead going on.
>
> People who claim to know "exactly what a C program is doing"
> are almost never correct.
Then do not guess. Look at the .LST file and be sure.
>
>
> > You don't have to guess what other information the compiler
> > is including in order for things like polymorphism to work,
>
> If you need to "guess" at these things,
> you don't understand the programming language.
Then explain Java and VB
>
>
> > 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.
gswork
> I am new to C and curious to know some basic questions about C.
> Why C is good?
Because you can create useful programs using it and...
> In what way its better than any other languages?
No overwhelming way, but it is very flexible in allowing a multitude
of approaches and 'styles' of programming, has good facility for
'lower level' systems programming and is widely implemented with an
ISO standard to help programmers who port apps from one platform to
another.
> If it is no longer a choice of programming language...why people still study
> it?
Because it is, still, a choice for many.
> And also its not an OO language either...is there any advantages in being
> not an OO language?
Perhaps in the implmentation of compilers, for many it makes C easier
to learn (initially) too.
> I know one reason is that, IT started with C and so they are still using
> them rather than changing it into new language.
IT started way before C, but indeed the huge amount of legacy code,
especially in systems code, ensures C's future as much if not more
than any other language characteristic.
Rob Thorpe
> 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?
I'm not sure that it is better than any other languages, but it has
certain advantages:
* There are C bindings available for many libraries, probably more
than any other language.
* It is relatively simple. This means that it's not unreasonable to
understand nearly all of the language. Its much harder to reach a
good understanding of a more complex language like C++.
* If you understand the machine you are using its possible to write
quite fast C.
> 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?
No, except you don't have to understand the OO parts. Which in most
languages I've used are really complicated.
> I know one reason is that, IT started with C and so they are still using
> them rather than changing it into new language.
No it didn't, but it is used heavily today.
CBFalconer
> "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?
>
> CPUs execute Op-Codes. The CPU does not know about languages.
> C gives you more control over what the CPU will get.
> .NET and Java... are not under the Programmers control.
_____________________
/| /| | |
||__|| | Please do not |
/ O O\__ | feed the |
/ \ | Trolls |
/ \ \|_____________________|
/ _ \ \ ||
/ |\____\ \ ||
/ | | | |\____/ ||
/ \|_|_|/ | _||
/ / \ |____| ||
/ | | | --|
| | | |____ --|
* _ | |_|_|_| | \-/
*-- _--\ _ \ | ||
/ _ \\ | / `
* / \_ /- | | |
* ___ c_c_c_C/ \C_c_c_c____________
--
Chuck F (cbfal...@yahoo.com) (cbfal...@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Joona I Palaste
> "Suresh" <gsu...@rogers.com> wrote in message news:<lEhkc.319114$2oI1....@twister01.bloor.is.net.cable.rogers.com>...
>> 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?
> I'm not sure that it is better than any other languages, but it has
> certain advantages:
> * There are C bindings available for many libraries, probably more
> than any other language.
People have been mistaking those bindings for the C language itself for
decades. I don't know if that counts as an advantage.
--
/-- Joona Palaste (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"We're women. We've got double standards to live up to."
- Ally McBeal
Rob Thorpe
> Rob Thorpe <robert...@antenova.com> scribbled the following:
> > "Suresh" <gsu...@rogers.com> wrote in message news:<lEhkc.319114$2oI1....@twister01.bloor.is.net.cable.rogers.com>...
> >> 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?
>
> > I'm not sure that it is better than any other languages, but it has
> > certain advantages:
>
> > * There are C bindings available for many libraries, probably more
> > than any other language.
>
> People have been mistaking those bindings for the C language itself for
> decades. I don't know if that counts as an advantage.
It certainly doesn't for reading a newsgroup about it. It means
people ask all kinds of things that few on the group know and most
would be better looking elsewhere.
It also means that a lot of people think of nasty win32 SDK things
when they're thinking of C.
John Bode
"Suresh" <gsu...@rogers.com> wrote in message
news:lEhkc.319114$2oI1....@twister01.bloor.is.net.cable.rogers.com...
> I am new to C and curious to know some basic questions about C.
> Why C is good?
"Good" depends on context. There are some tasks for which C is most
definitely *not* the right choice.
> In what way its better than any other languages?
Compared to many other languages, C is "small" (few keywords, relatively
simple syntax, etc.), meaning C compilers are relatively easy to write,
meaning C compilers are available for everything from mainframes to
microcontrollers. C is also very flexible, giving the programmer a wide
variety of tools to accomplish various tasks.
> If it is no longer a choice of programming language...why people still
study
> it?
Same reason people still study Fortran and COBOL -- there's a lot of legacy
code out there that needs to be maintained for whatever reason. It's almost
always cheaper to maintain an old program than to reimplement it in a new
language.
> And also its not an OO language either...is there any advantages in being
> not an OO language?
>
Mainly that the language is a little easier to learn (compared to something
like C++ anyway), and that the compilers are simpler to write. And not every
problem needs an object-oriented solution, anyway. There are cases for
which an object-oriented approach is overkill.
> I know one reason is that, IT started with C and so they are still using
> them rather than changing it into new language.
IT started long before C was around (whether it was called IT in those days
or not). What we consider IT probably started with COBOL.
gooch
> 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?
With few exceptions no programming language is either good or bad on
its own. Programmers can write good and bad code in any language out
there. The trick is to choose the appropriate language for the
application being developed. In a lot of cases where you want to have
good control over hardware and not have o deal directly with an
assembly language C is a good choice.
> If it is no longer a choice of programming language...why people still study
> it?
C is still widely used in many applications especially embedded
systems programming. As far as why is it often used to teach
programming, it is a fairly simple language to use for demonstrating
good programming practices and concepts so a lot of schools use it.
> And also its not an OO language either...is there any advantages in being
> not an OO language?
This is not exactly true. While C was not designed as an OO language
it is possible to implement virtually all of the functionalities of an
OO language such as Java or C++ in C. It is not as easy to do in some
cases and it would not make sense in all cases because it could make
the code somewhat convoluted. Where I work we do implement objects,
inheritence, polymorphism etc. in C when appropriate. This can help to
allow your code to be more reusable and fit more logically with an
OOAD approach (which we also use) than it might otherwise.
>
> I know one reason is that, IT started with C and so they are still using
> them rather than changing it into new language.
C was by no means the beginning of the programming languages. In fact
you can trace programming back as far as the 1800's (depending on who
you talk to maybe even farther).
Darrell Grainger
> Hi,
> I am new to C and curious to know some basic questions about C.
> Why C is good?
I feel it is a good language because it tends to have portable source
code, it is very mature, the library of standard functions is well defined
and understood, there is a wealth of code snippets and libraries
available and there are many programmers who know the language.
Additionally, as someone who comes from an assembly background, there is
something about C language that is intuitive for me. I have a certain
mindset and C language seems to mesh with it.
> In what way its better than any other languages?
I would not say that it is better than any other language. Because it is a
mature language, the compilers for it have been around for a while. They
tend to generate code that is comparable to something most programmers
could do with hand assembly. Additionally, mixing assembly and C is
usually not very difficult. I can therefore write something in C, profile
it, find the hot spots, optimize them by hand in assembly.
I would not say that only C language has these features.
> If it is no longer a choice of programming language...why people still study
> it?
Moot. C language is still a language of choice.
> And also its not an OO language either...is there any advantages in being
> not an OO language?
Less overhead for small projects. How you design the program is different.
For someone who is used to procedural languages like C they might not take
to OO languages. Again, one strong reason to prefer one language over
another is because it just seems more intuitive.
> I know one reason is that, IT started with C and so they are still using
> them rather than changing it into new language.
Legacy code is a big reason why COBOL is still around. I would imagine
that there will be a need for C programmers to maintain old projects.
Currently, there are still new C projects being created. So C language
hasn't become a maintenance language yet.
--
Send e-mail to: darrell at cs dot toronto dot edu
Don't send e-mail to vice.pr...@whitehouse.gov
Darrell Grainger
> 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,
meaning that the structure of the Latin language shares many similarity
with the Italian language.
With assembly language there is a one to one correspondence to machine
language (unless we are talking about algebric assemblers). If something
is similar to assembly language then it is "close to" assembly language.
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.
For example, I will notice that certain statements in C language will
always produce the same machine language on a given machine. 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.
> > It's possible to understand exactly what a C program is doing
> > because there isn't (necessarily) a lot of overhead going on.
>
> People who claim to know "exactly what a C program is doing"
> are almost never correct.
Depend who you are talking to. If you talk to Electrical Engineers,
people with 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.
> > You don't have to guess what other information the compiler
> > is including in order for things like polymorphism to work,
>
> If you need to "guess" at these things,
> you don't understand the programming language.
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?
E. Robert Tisdale
> CPUs execute Op-Codes. The CPU does not know about languages.
> C gives you more control over what the CPU will get.
> .NET and Java... are not under the Programmers control.
How is C more "under the programmers control" than .NET and Java?
> C effectively the next step above Assembly.
What does that mean?
Java doesn't emit C code.
> It gives more control over memory usage and hardware access.
Really?
Please show us an example of how C 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.
What does that have to do with the hardware?
E. Robert Tisdale
> 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*.
> 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.
> If something is similar to assembly language
> then it is "close to" assembly language.
How is C "similar" to assembler?
> 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.
> 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.
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?
> 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/
> 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.
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.
Xenos
"E. Robert Tisdale" <E.Robert...@jpl.nasa.gov> wrote in message
news:40929552...@jpl.nasa.gov...
> > 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"?
E. Robert Tisdale
> 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/foldoc.cgi?Assembly+Language
Assembly Language
<language, robotics> (AL) A language for industrial robots developed at
Stanford University in the 1970s.
["The AL Language for an Intelligent Robot", T. Binford in Langages et
Methods de Programation des Robots Industriels, pp. 73-88, IRIA Press 1979].
["AL User's Manual", M.S. Mujtaba et al, Stanford AI Lab, Memo AIM-323
(Jan 1979)].
Neil Kurzman
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
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)
and if
there were library functions that doesn't allow buffer overrun?
Kevin Bagust
> > 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/foldoc.cgi?Assembly+Language
> Assembly Language
<Snip>
Where as from the same place:
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?query=Assembler
<programming> A program which converts assembly language into machine
code.
(1996-03-25)
and
http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?assembly+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
>
> 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 nos...@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
> http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?assembly+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
to search for
+"assembler language"
and I found lots of stuff including
http://search390.techtarget.com/sDefinition/0,,sid10_gci211604,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 <Pine.GSO.4.58.04...@drj.pf>, dar...@NOMORESPAMcs.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 "maintenance" 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 michael...@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
> 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.
Darrell Grainger
> Kevin Bagust wrote:
>
> > http://wombat.doc.ic.ac.uk/foldoc/foldoc.cgi?assembly+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/sDefinition/0,,sid10_gci211604,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>
Joona I Palaste
> 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 (pal...@cc.helsinki.fi) ------------- Finland --------\
\-- http://www.helsinki.fi/~palaste --------------------- rules! --------/
"It's time, it's time, it's time to dump the slime!"
- Dr. Dante
Ben Pfaff
> On Fri, 30 Apr 2004, E. Robert Tisdale wrote:
>
>> The correct term is *assembler*.
[...]
> 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. [...]
ERT had credibility? That's news to me. You're best off just
ignoring his articles; he rarely has useful information to
impart.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz.\
\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;}
Richard Bos
> On Fri, 30 Apr 2004, E. Robert Tisdale wrote:
>
> You have lost a great deal of credibility
Amazing.
> > 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.
Then again, that _is_ a vast overstatement.
> > 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.
Oh, bull. C is the same on each architecture; the machine languages
differ, sometimes greatly. C can be interpreted; what does an
interpreter have to do with machine code?
> 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++)
Yes, but this says absolutely _nothing_ about C. Lots and lots of
programming languages have very similar constructs. Basic has FOR ...
NEXT; Pascal has for ... do; Icon has foreach.
If anything, the for statement seems to prove that C is _less_ close to
machine language than Basic and Pascal, and about as close as Icon,
because while all Basic and Pascal have is the normal, assembly-alike,
count up or down, C allows for loops like
for (ptr=list_head, total=0; ptr; total+=amount(ptr), ptr=ptr->next)
modify_list_element(ptr);
which does not have a similarly close equivalent in assembler language
(and Icon allows similar things with hand-written generators).
Richard
-wombat-
> 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?
Oh, come on, Robert. You embarrass the rest of us UCLA Ph.D's and soon-to-be
Ph.Ds. Walter is probably spinning in his grave.
It's a fundamental tenet in languages that there is a hypothetical, perfect
virtual machine that models the implementation and runtime semantics of a
language. C is no exception.
And yes, C is a portable assembler for lack of a better phrase. It seems to
grow like a weed on many different platforms because the processor model of
most platforms maps well to the hypothetical VM that maps to the language.
Paul Hsieh
> I am new to C and curious to know some basic questions about C.
Of course, some would argue that its not.
But in any event, C is usually implemented very close to the latest
ANSI and ISO standards prior to C99, and its implemented for just
about every platform in existence. For example, there are basically
no (or very few) C++ compilers that are totally standards compliant,
while very few C compilers are not. C has a long history, is fairly
stable, and has good functionality. There are more generally
applicable books and tools written for C than any other language.
> If it is no longer a choice of programming language...why people still study
> it?
Knowing C is kind of a prerequisite for learning C++.
> And also its not an OO language either...is there any advantages in being
> not an OO language?
OO introduces more complications to programming languages that have
nothing to do with general computation. Like Perl, OO makes programs
easier to write, but harder to maintain. More people know and
understand basic C, than the OO features of C++ -- this means that
moving to OO will necessarily reduce the set of programmers that will
be equipped to deal with it.
OO also has no feature which can improve the performance of programs
that cannot be duplicated with non-OO mechanisms. At the same time OO
hides lots of implementation details which *CAN* drastically impact
performance in a negative way. One typically needs a lot of expertise
to know when these cases occurr and to know how to avoid them.
--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
August Derleth
> "Suresh" <gsu...@rogers.com> wrote:
>> 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?
>
> Of course, some would argue that its not.
>
> But in any event, C is usually implemented very close to the latest
> ANSI and ISO standards prior to C99, and its implemented for just
> about every platform in existence. For example, there are basically
> no (or very few) C++ compilers that are totally standards compliant,
> while very few C compilers are not. C has a long history, is fairly
> stable, and has good functionality. There are more generally
> applicable books and tools written for C than any other language.
All of this true to a surprisingly large extent, but it can be difficult
to make some compilers conform to /only/ C89. For example, gcc requires a
small clutch of command-line options (-ansi -pedantic -Wall) to /not/
compile its set of extensions /and/ to generate all of the warnings it
needs to.
>
>> If it is no longer a choice of programming language...why people still study
>> it?
>
> Knowing C is kind of a prerequisite for learning C++.
False. C++ can be learned as a standalone language, and even as a /first/
language. (Although beginning with Python might be better, that's a matter
of pedagogical taste.)
In fact, learning about C and C++ as two very different languages (as
different as, say, Algol-68 and Pascal) is the best, in terms of code
hygiene (should malloc() be cast?) and conceptual modeling (the C++ STL,
for example, allows much different approaches to problems than the C
standard library).
>
>> And also its not an OO language either...is there any advantages in being
>> not an OO language?
>
> OO introduces more complications to programming languages that have
> nothing to do with general computation. Like Perl, OO makes programs
> easier to write, but harder to maintain. More people know and
> understand basic C, than the OO features of C++ -- this means that
> moving to OO will necessarily reduce the set of programmers that will
> be equipped to deal with it.
Now, this is simply ignorant. OO can improve the organization and
maintainability of the code by orders of magnitude when used by skilled
professionals, as opposed to inept fools. OO allows a programmer to
enforce a single unified interface to his solutions, as opposed to a
hodge-podge of exported subroutines and messy global variables.
>
> OO also has no feature which can improve the performance of programs
> that cannot be duplicated with non-OO mechanisms. At the same time OO
> hides lots of implementation details which *CAN* drastically impact
> performance in a negative way. One typically needs a lot of expertise
> to know when these cases occurr and to know how to avoid them.
OO does nothing of the sort. Compilers and, to a lesser extent, languages
do. The take-home lesson here is that languages aren't inefficient,
programs are: Either the OO code you write is absolutely hideous cruft
(likely) or your tools are badly-written.
--
yvoregnevna gjragl-guerr gjb-gubhfnaq guerr ng lnubb qbg pbz
To email me, rot13 and convert spelled-out numbers to numeric form.
"Makes hackers smile" makes hackers smile.
Paul Hsieh
> On Tue, 04 May 2004 15:13:09 -0700, Paul Hsieh wrote:
> >> If it is no longer a choice of programming language...why people still
> >> study it?
> >
> > Knowing C is kind of a prerequisite for learning C++.
>
> False. C++ can be learned as a standalone language, and even as a /first/
> language. (Although beginning with Python might be better, that's a matter
> of pedagogical taste.)
But if you try to learn C++ by itself, you end up learning basic C as
a result. You may learn something different about NULL, the way
structures can be declared, and how sizeof works, but these are
details that even C programmers are often not very clear on.
My point is that if you can't learn C for whatever reason, you aren't
really going to be able to learn C++.
> In fact, learning about C and C++ as two very different languages (as
> different as, say, Algol-68 and Pascal) is the best, in terms of code
> hygiene (should malloc() be cast?)
Should malloc be cast in C is a paranoia that I believe exists
strictly in CLC. I believe people outside CLC will cast it or not as
it suits them or, in C++'s case, as its required. Knowing this or
not, is not what I would seriously consider "knowledge" about C. Of
course malloc isn't used much in C++ at all.
> >> And also its not an OO language either...is there any advantages in being
> >> not an OO language?
> >
> > OO introduces more complications to programming languages that have
> > nothing to do with general computation. Like Perl, OO makes programs
> > easier to write, but harder to maintain. More people know and
> > understand basic C, than the OO features of C++ -- this means that
> > moving to OO will necessarily reduce the set of programmers that will
> > be equipped to deal with it.
>
> Now, this is simply ignorant. OO can improve the organization and
> maintainability of the code by orders of magnitude when used by skilled
> professionals, as opposed to inept fools.
You don't see the inherent contradiction in the statement you just
wrote? The bar for dealing with C++ is simply higher. You only point
out the extremes, but one cannot maintain what one does not
understand. The C++ standard is apparently > 1000 pages -- meaning
that even if you understand C++ for your own purposes, understanding
it to maintain someone else's code is a completely different matter.
> [...] OO allows a programmer to
> enforce a single unified interface to his solutions, as opposed to a
> hodge-podge of exported subroutines and messy global variables.
C doesn't require or encourage a hodgepodge of exported subroutines or
messy global variables. Minimizing or completely eliminating the use
of global variables is a good habit that has nothing to do with
anything about C or C++. The "static" keyword and function pointers
were also introduced in C, not C++.
> > OO also has no feature which can improve the performance of programs
> > that cannot be duplicated with non-OO mechanisms. At the same time OO
> > hides lots of implementation details which *CAN* drastically impact
> > performance in a negative way. One typically needs a lot of expertise
> > to know when these cases occurr and to know how to avoid them.
>
> OO does nothing of the sort. Compilers and, to a lesser extent, languages
> do.
This is just an assertion, and you don't understand that its wrong.
For example, to compute any algebraic expression, a compiler will
model the computation with temporary variables. However, whether or
not the compiler can eliminate some of the temporaries may be beyond
even the theoretical capabilities of any compiler -- and its usually
not clear unless the programmer goes through the same work as the
compiler by hand.
C++ introduces the concept of contructors/destructors which
necessitates built-in memory management for objects. This is fine
except that if you create an array of objects, raw performance of this
memory management and the fragmentation of the heap itself could be
improved if a group of objects (related by their use, not their type)
were allocated in a single allocation call. A C programmer has no
problem seeing and doing this -- I know of no C++ compiler capable of
this.
STL's vectors, for another example, have a surprising implementation
that requires that the default constructor be present for your object.
The reason is that in order to append an entry, its going to create
the default one, then copy the one you are passing via "=". That's
all very interesting, except that depending on your object design, the
"class A1(A0)" initialization idea (if implemented as basically a
copy) can skip this extra construction step (which can be arbitrarily
expensive -- your object could launch a thread on construction, for
example.) STL can't see this because of its implementation, and what
the language C++ specifies (the compiler can't know that class A1(A0)
is going to implement copying, even if the programmer does.)
> [...] The take-home lesson here is that languages aren't inefficient,
> programs are:
Ok now who's talking about ignorance. Look at Fortran, the "volatile"
keyword addition to C in C99, and any benchmarks of Java, C and Lisp.
There are serious differences in languages with respect to
performance, that go beyond the different capabilities of compilers.
People who follow these things on Windows like to hail the Intel C
compiler as being somewhat miraculous for being able to maintain a 20%
edge over MSVC or gcc, however I would be surprised if there is any
program in either Java of Fortran that stays pretty much within 20% of
C. You could at best make this argument between C and Pascal perhaps
-- but one could argue that these languages are very close in what
they implement beyond their syntactical differences.
Guillaume
> maintainability of the code by orders of magnitude when used by skilled
> professionals, as opposed to inept fools. OO allows a programmer to
> enforce a single unified interface to his solutions, as opposed to a
> hodge-podge of exported subroutines and messy global variables.
True (when properly used), but you can write C in an OO manner.
I've been using C in this way for years. And have still good
reasons to do so instead of using C++.
> OO does nothing of the sort. Compilers and, to a lesser extent, languages
> do. The take-home lesson here is that languages aren't inefficient,
> programs are: Either the OO code you write is absolutely hideous cruft
> (likely) or your tools are badly-written.
True in an abstract environment, but not true in the real world.
If you take the example of C vs. C++: there is no way you can make the
same piece of software use less resources and memory space with C++
compared to a C solution. Some people have been claiming the opposite
for ages, but I have yet to see a single proof of it.
CBFalconer
> August Derleth <s...@sig.now> wrote:
>
... snip ...
>
>> [...] OO allows a programmer to enforce a single unified
>> interface to his solutions, as opposed to a hodge-podge of
>> exported subroutines and messy global variables.
>
> C doesn't require or encourage a hodgepodge of exported
> subroutines or messy global variables. Minimizing or
> completely eliminating the use of global variables is a good
> habit that has nothing to do with anything about C or C++.
> The "static" keyword and function pointers were also introduced
> in C, not C++.
For an example of OO design in pure C, see my hashlib (URL
below). It is designed so that the user can only get his hands on
objects he designs himself (barring futzing with the hashlib
source code). All this is done through the normal C abilities,
with the exception that the user is told not to alter the portion
of the data object on which the hash depends. The use of static,
void *, and incomplete structures is essential. The user, in
turn, can define his objects as he likes, but must define a
specified set of operations on them. This is really no more than
an exercise in information hiding.
See <http://cbfalconer.home.att.net/download/hashlib.zip>
--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison
Vivek Mohan
> Hi,
> Why C is good?
Well, Yes and No. Its very good for the kind of programming task where
you need to be closer to the hardware, directly access the memory, and
need speed/effeciency. But when you are out to solve generic problems
where hardware is not a matter of concern, C would probably be a
not-so-good choice.
A 10 line program in C can be converted to a single line program in
Python. But that takes away speed. So its your choice.
> In what way its better than any other languages?
Well, most(!) other languages are written in C (eg. Python, Perl, PHP,
Ruby etc.) And IMHO its foolish to compare languages like this to C as
much as its foolish to compare a high level language with assembler or
uP opcodes, so to speak. I know a lot of "programmers" who complain
about the way strings are handled in C and the poor support for them;
and then they brag about how easy it is to do so in perl/php.
> If it is no longer a choice of programming language...why people still study
> it?
Frankly speaking, its because no other language has been able to
replace it and it still is the choice of programming language. Check
out the source code for any of the BSDs/Linux'es, they all use C. I
know people who develop operating systems in C++ but I don't think its
worth the effort. Even GNU prefers that all its official software be
written in C. I know there will be 1000s of anti-C advocates to refute
me, but they've been around since C was born.
> And also its not an OO language either...is there any advantages in being
> not an OO language?
OO is not everything. Oh yeah, if you really understood OO, to some
level it can be acheived in C also, although it could get ugly, thats
all.
http://ldeniau.home.cern.ch/ldeniau/html/oopc/oopc.html
> I know one reason is that, IT started with C and so they are still using
> them rather than changing it into new language.
Oh no, C is not as ubiquitous as everybody thinks. Check this out and
drive your myths away -
http://www.cobolwebler.com/cobolfacts.htm
Peace.
Vivek