Re: Why C?
From: Mikael Aronsson (mikael-aronsson_at_telia.com)
Date: 09/02/03
- Next message: Vincent: "Re: Daemon vs app"
- Previous message: Mikael Aronsson: "Re: what is gtk ,glade,qt,dev c++"
- In reply to: VBDis: "CFO: Why C?"
- Next in thread: gswork: "Re: CFO: Why C?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 02 Sep 2003 07:27:36 GMT
So, why are you here then ?
Just a few small points, C does compile very fast (faster then Java and C#),
C++ on the other hand is another thing.
the truth is that you need different languages depending on what you want to
do, trust me, you do not want to implement a new device driver for Linux in
Object Pascal or Java*, just as you don't want to create a Java* applet in C
(and no one "wants" to make an Active/X control....)
I know J**a is a trademark of SUN, I hope I am not breaking any laws by
typing it here... ;o)
Mikael
"VBDis" <vbdis@aol.com> wrote in message
news:20030831211145.11891.00000382@mb-m11.aol.com...
> No doubt, C is fast, portable, and available everywhere.
>
> Really???
>
> My answer is NO, with regards to most of the pretended advantages of the C
> language.
>
> How can a language ever be slow or fast, or more or less portable?
>
> C programs can be as fast as a compiler can make them, not more or less
than
> programs in other languages. What makes some other languages slower than C
is
> the runtime system, at best, which may include some more overhead like the
> garbage collection built into Java. But the translation of application
source
> code into executable code is not affected by the choice of a specific
language.
> In contrast it takes much more time to compile C code, as opposed to other
> languages, because the C syntax is hard to parse, ambiguous, and typically
many
> related (header) files must be processed for every single C source file.
That's
> why C is not a good choice, with regards to development turn around time.
>
> C also is not more portable than any other language, in contrast it
requires
> much more efforts to make C code really portable, as is required for other
> languages. And C itself is not sufficient for writing portable code, much
more
> tools are required to build any C program or library, like configure. But
I'll
> discuss the configure topic in another thread, this procedure is not only
> related to the C language.
>
> The availability of C compilers also is no valid argument, since a
compiler for
> C is much harder to implement than a compiler for other languages. In fact
> processors for 2 languages must be implemented, since no C code can be
> translated without preparing the sources with the preprocessor. For other
> languages usually a single scanner and parser is sufficient instead.
Everything
> apart from scanner and parser is common to every compiler, for every
language,
> and that's why e.g. gcc can be used to translate more than only C code.
>
>
> There exist more reasonable disadvantages of C, resulting in many attempts
to
> cure some deficiencies, like Java, C++ or C#. But why then is C still used
for
> most free software, if there exist languages which claim to be better than
C?
> IMO the only valid argument is the simplicity of the C language, which
suggest
> to use C for teaching programming at all. But every C coder must admit
that C
> is unusable for any application without the huge C standard library, and
when
> one recognizes this disadavantage of C, then it's too late to move to a
> different language. Even if other C-ish languages try to simplify such a
move,
> by preserving much of the C syntax, the many bad habits from hacking C
code,
> and the already collected experience with the C library, will prevent most
> coders from moving to other languages. And since none of the C-ish
substitution
> languages could break with the bad and almost inappropriate C syntax, none
of
> these languages was accepted as a "better" standard language.
>
> So I'll take it as given that C will stay the most popular programming
language
> in the non-commercial area. But in business, where time is money, many
> companies use different languages or at least development tools, which
make the
> software development effectively safer, faster and cheaper. But in the
hobbyist
> area time is not a factor, neither the time to write the first version of
some
> program, nor the time to document or update that first version, nor the
time
> required to debug that code, nor the time to make the code portable. I'll
only
> try to give you an idea of the improvements, which other languages can
provide
> to an software developer.
>
> The most important issue IMO is type safety, which is very weak until
> inexistent in C. When I translated C code into a different language, or
only
> used the type checking features of an C++ compiler, I could find a lot of
> lurking bugs and inappropriate data types in any existing C code. Who ever
> claims that C is fast, would be surprised by seeing how easy it is to
write
> inefficient code in C, which results in many implicit type conversions
with
> every assignment to a variable of an integral data type. Warnings about
mixing
> signed and unsigned data types usually are ignored, and the compiler
either is
> instructed to ignore possible overflows, or will silently extend all
operands
> to the next larger data type. Of course the choice of a different language
will
> not cure this problem, but it may encourage the coder to think more about
the
> use of immediately compatible data types. Since C requires type casts all
the
> time, it's so easy to add some unnecessary type casts in many places. Such
type
> casts can not only slow down the code, they also effectively prevent any
type
> checking, which otherwise could reveal many coding errors just at compile
time.
> Using enums instead of #defined constants also would prevent the
inadvertent
> use of inappropriate values. C++ can offer more type safety, at no extra
cost,
> when macros are converted into inline functions. But nobody is forced to
use
> such cheap means for writing safe and checkable code in C, and if you
insist in
> making all your errors yourself...
>
> Another issue are the C-style type declarations, which are hard to read
and
> also hard to parse for the compiler. Ever tried to decode the type of a
> callback procedure, as passed as an argument to a subroutine? Or a list of
> variables, with various type modifiers? Which parts then are common to all
> members, and which specifiers belong to a specific member? What are
typenames
> at all, and where reside the names of procedures or variables in a lengthy
> declaration? With only a different declaration syntax it would be much
easier,
> for you or any tool, to extract the declarations of data types, procedures
and
> variables from some source code or header file. If you ever tried to port
some
> code, and came across undefined symbols, you'll know how comfortable it
will be
> if all declarations can be extracted easily, even if they are ignored by
the
> compiler due to some inappropriate #if's?
>
> Argh, those header files! Who has not already been swearing, on the
difference
> between the declaration and definition of global variables? Adding
"extern"
> variables to an header file is easy, but in which file are those variables
> defined? And are the data types in the declaration and definition really
the
> same? A real nightmare in many larger projects :-(
>
>
> In Delphi, or Object Pascal Language (OPL), I like the "set" type, which
cures
> a common deficiency of C. Most coders have already been struggling with
flag or
> option words, where every bit has a specific meaning. In many cases two
sets of
> constants are defined, one for the ordinal values of the options (1, 2, 3,
> 4...), and one for the bitmasks in the composite values (1, 2, 4, 8...),
with
> explicit conversions between both representations of the same option in
many
> cases, or inefficient switches or cascaded if's to check the value of
specific
> bits. Consider the isascii() and similar tests, which require a careful
layout
> and population of the chartype array, and the related constants and macros
in
> C. In OPL such collections of bits can be constructed from any enum, from
which
> the compiler not only makes the layout of the set variables, but also
provides
> all set operations like complement, union and intersection. Insert or
reorder
> the option values? No problem, only update the enum as desired, the
compiler
> will do the rest. No inadvertent wrong constant names or duplicate use of
the
> same bit, no gaps in the set variables, and (optional) automatic
adjustment of
> the size of the set variables, depending on the number of elements in the
enum.
> The implementation of such sets and set operations is not slower than what
one
> would write in C, and sometimes even faster when appropriate machine
> instructions can be used, which will hardly ever be created by a C
compiler.
>
>
> Okay, okay, all that "can be done in C as well". But in other languages it
can
> be done in a safer or more convenient way, with a reduced risk of
inadvertent
> coding errors, because the compiler or the IDE can immediately check and
verify
> the use of every single operator or identifier. Have a look at the many
style
> guides, which describe recommended coding practices that shall prevent you
from
> stumbling into the many known C traps. In other languages it's easier to
> circumvent such traps, because there the compiler won't let you make many
> obvious errors. Using C++ instead of C will already be a big step towards
> writing safer code, if you only are willing to use the extended features
of
> that language.
>
> And if I couldn't convince you, can you give me life examples of cases and
> constructs, where C is better or faster or more portable than other
languages?
> No, I don't want to know what's bad in other languages, I only want to
know
> what's so unique in C, inavailable in any other language.
>
> DoDi
- Next message: Vincent: "Re: Daemon vs app"
- Previous message: Mikael Aronsson: "Re: what is gtk ,glade,qt,dev c++"
- In reply to: VBDis: "CFO: Why C?"
- Next in thread: gswork: "Re: CFO: Why C?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
