Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > why still use C?

Reply
Thread Tools

why still use C?

 
 
cody
Guest
Posts: n/a
 
      10-05-2003
no this is no trollposting and please don't get it wrong but iam very
curious why people still use C instead of other languages especially C++.

i heard people say C++ is slower than C but i can't believe that. in pieces
of the application where speed really matters you can still use "normal"
functions or even static methods which is basically the same.

in C there arent the simplest things present like constants, each struct and
enum have to be prefixed with "struct" and "enum". iam sure there is much
more.

i don't get it why people program in C and faking OOP features(function
pointers in structs..) instead of using C++. are they simply masochists or
is there a logical reason?

i feel C has to benefit against C++.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
--
comp.lang.c.moderated - moderation address: http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
 
 
 
Juergen Heinzl
Guest
Posts: n/a
 
      10-05-2003
In article <(E-Mail Removed)>, cody wrote:
> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.
>
> i heard people say C++ is slower than C but i can't believe that.

[-]
It isn't.

[-]
> i don't get it why people program in C and faking OOP features(function
> pointers in structs..) instead of using C++. are they simply masochists or
> is there a logical reason?

[-]
C++ compilers used to pose problems like being more or less standards
compliant and in all honesty they often still do plus to generate optimal
machine code the compiler / linker combo needs to work together much more
closely than it is the case with C.

Well, and developers used to and use to pose problems, too as just take
some seasoned C developers and be assured over their dead body they'll
admit not to be able to output high quality C++ code almost straight
away and so it must be the language.

In short C++ isn't slower for sure as both, a C as well as a C++ compiler
is going to generate machine code. It's just no compiler can do the
thinking for you (yet) and I haven't met all too many C++ developers
yet who really do know the language.

Mind I'm far from saying I'd really do. Far from it, though I'm not
having problems admiting that while, after being more then 10 years in
the job, I dare say there's a fair share of developers, often the local
"star developers", who prefer arguing to listening.

In general language wars are pointless anyway, though as the end user
couldn't care less about "your" problems but he or she wants to see
a working result, so the real question is are you able to deliver or
are you not ?

Cheers,
Juergen

--
\ Real name : Juergen Heinzl \ no flames /
\ EMail Private : (E-Mail Removed) \ send money instead /
 
Reply With Quote
 
 
 
 
Sidney Cadot
Guest
Posts: n/a
 
      10-06-2003
Hi cody,

> no this is no trollposting and please don't get it wrong but iam very
> curious why people still use C instead of other languages especially C++.


I can't answer for people in general of course, but as a moderately able
C programmer with a thorough dislike of C++ I can try to explain what my
motives are.

> i heard people say C++ is slower than C but i can't believe that. in pieces
> of the application where speed really matters you can still use "normal"
> functions or even static methods which is basically the same.


A few years ago I did some timing and (counter to my intuition) I found
that, indeed, it didn't make a difference, as you point out. One
remarkable thing was that the C++ executables for my (small) benchmarks
were quite a bit larger, which may be relevant for embedded applications.

> in C there arent the simplest things present like constants, each struct and
> enum have to be prefixed with "struct" and "enum". iam sure there is much
> more.


These are some areas where I would agree that yes, C++ is (a bit)
cleaner than C. Another example is declaring variables inside for()
statements and such, this can truly help readability, and limiting the
scope of a local variable if possible is a good thing. Note that many of
these (almost cosmetic) changes have made their way back into C99.

> i don't get it why people program in C and faking OOP features(function
> pointers in structs..) instead of using C++. are they simply masochists or
> is there a logical reason?


In all honesty I think that many people who prefer C over C++ don't
quite get what all the fuzz is about in OOP (I know I don't). In
principle there are sound advantages to grouping together structs and
their associated method functions from a design perspective. Inheritance
and polymorphism have an important part to play as well, especially in
some areas of application (such as GUIs).

However, this is the first place where you get a tradeoff of execution
speed, executable size, and runtime memory usage (for virtual method
tables) versus design-time advantages. In reality of course, especially
with nowadays' big machines, these disadvantages are not too important
for most applications. However, (to me at least) it is a bit unnerving
to be at the mercy of the compiler and its designer, and hope that he
implemented all this machinery properly and without causing too much
overhead. This is more a psychological barrier than a real one of
course, since modern compilers are able to optimize away many
unneccessary machinery, and some rather clever tricks have been found to
make virtual method calls very cheap. However, as a programmer I am no
longer completely in the driver's seat as I am with C. Looking at a C
porgram, I can have a straightforward and relatively accurate mental
picture of what the actual machine code produced by the compiler will
look like. With OOP and C++, that's no longer true, especially with code
that uses all the available C++ features including exceptions and templates.

One generic complaint I have with OOP (not limited to C++) is that I can
no longer look at a code fragment and reconstruct the execution flow in
my head, because of polymorphism and operator overloading; in C (unless
you're doing funky stuff with threads or longjumps), the execution flow
is pretty much known at compile-time, and can be reproduced from the
code. I happen to like that.

Of course OOP proponents will counter that this is in fact the entire
point of OOP: one should no longer be thinking in terms of structural
execution flow, but rather in terms of objects with a well-defined
behaviorial 'contract', that can be triggered by invoking methods.

Now this is where a lot of subjectivity comes in, but I for one simply
don't think that way. This is probably due to the way I earned my
computer experience (going up from BASIC to 8-bit machine language to
Pascal to C). "Thinking in classes", something that is essential for
good OOP programming, is just not for me (except for some obvious cases
with a small number of classes - I have done some C++ programming in my
time of course).

When the programs get bigger, and the number of classes grows, you come
to another point: there is a transition in the level of design: instead
of putting statements in the right order, you have to start managing a
class model. The Design Patterns school-of-thought comes in here: how do
I design a set of classes with interaction to get a certain type of
bahavior? For me, this has two problems. First, there is often more than
one sensible way of designing a set of classes to address a certain
problem. I have an instinctive dislike of that kind of situation: I have
the (admittedly rather naive) feeling that software related problems
should have a canonical 'best' solution. The second (real) problem is
that C++ doesn't really support the Design Pattern level of abstraction.
Instead, it hands the programmer a number of nuts and bolts that enable
him to approximate the abstract idea encapsulated in a DP. I think there
are no programming languages available today that properly support the
Design Pattern methodology, and it's certainly not C++.

Now of course all this is more a rant against OOP than C++, but IMHO C++
offers no advantages to C99 other than OOP-support, so it is relevant to
your question.

You could argue of course that C++ > (C + OOP). The two most prominent
features apart from OOP that set aside C and C++ are, I think,
exceptions and templates.

As for exceptions, you may know Dijkstra's paper "Goto's considered
harmful". In this paper he has a number of points that I would subscribe
to, concerning the ability of the human programmer to read the meaning
of a piece of code from the source. In essence, he argues that GOTO
statements destroy this possibility.

I would argue that exceptions are "goto's on steroids". Since exceptions
are allowed to cross function-call boundaries, execution flow becomes
very non-transparant - at least to me! This is a similar objection I
have with polymorphism as described above.

A serious problem with exception handling in C++ is it's interaction
with memory management, which is made even worse by having implicit
object creation (with implicit constructor calls). Now I know a lot of
talented programmers, many of which are far more accomplished in C++
programming than I am, but not a single one of them can quote me the
do's-and-don'ts of a 'good' C++ program in this respect. It's a minefield.

Incidentally, having just written a rather big real-life C library with
error handling, I do appreciate the need for exception handling.
However, I think it is a mistake to have a language that does include
exception handling but doesn't do garbage collection for the reason
stated above. Sure, it's possible to do it properly. But one has to
remember that programmers are human beings; most programmers I know have
simply not the level of intimacy with the C++ runtime model to do this
without making mistakes.

Templates.... Suffice it to say that one cannot write a portable C++
program using templates and expect it to work identically on different
compilers. Portability is nil, and this makes this feature not useful in
many practical sutuations. One can complain about (or to) compiler
builders in this regard, but this is just a symptom of overly
complicated semantics. Even if compiler builders get their act together,
the semantics would still be too difficult for most programmers.
Including me.

To summarize I would say C++ with its feature set is just too
complicated, as a language design I feel it has failed. One has to keep
in mind that a programming language is a tool to make programs. If a
tool has a significant chance of being unintentially misused (with
possibly disastrous results), it's not a good tool. I will stick with
something I actually (more or less) understand, which is C.

By the way, did you ever read the Stroustrup book ('Programming in
C++')? As the book progresses, his examples evolve from things that look
sort-of-like-C to STL-based programs that are (to my untrained eye at
least) simply ugly. My feeling is that he tries to bring the expressive
power of dynamic interpreted languages to the realm of compiled
languages. A valliant attempt, and I would applaud him for it. However,
his writing conveys a breathtaking arrogance or perhaps lack of
understanding for the fact that most programmers are mere mortals... I'm
sure as the language's designer he is able to mentally internalize the
runtime model of C++, but to think that your average programmer could
readily do the same is just preposterous.

And a last thing: try writing a library in C++ and linking it with a
program written in C (like Matlab, IDL, Mathematica...). Now there's a
practical reason to prefer C over C++ if I ever saw one.

Thank you for giving me an opportunity to rant a bit about this. Perhaps
this therapeutical excercise of mine will give you some insight in the
reasons why some of us still prefer C over C++!

Best regards,

Sidney Cadot
The Netherlands

 
Reply With Quote
 
Richard Heathfield
Guest
Posts: n/a
 
      10-06-2003
Sidney Cadot wrote:

> Hi cody,
>
>> no this is no trollposting and please don't get it wrong but iam very
>> curious why people still use C instead of other languages especially C++.

>
> I can't answer for people in general of course, but as a moderately able
> C programmer with a thorough dislike of C++ I can try to explain what my
> motives are.


<superb answer snipped>

Very well said. A very thoughtful article indeed.

--
Richard Heathfield : (E-Mail Removed)
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton
 
Reply With Quote
 
Glen Herrmannsfeldt
Guest
Posts: n/a
 
      10-06-2003

"Sidney Cadot" <(E-Mail Removed)> wrote in message
news:blqeq9$1lc$(E-Mail Removed)...
> Hi cody,
>
> > no this is no trollposting and please don't get it wrong but iam very
> > curious why people still use C instead of other languages especially

C++.
>
> I can't answer for people in general of course, but as a moderately able
> C programmer with a thorough dislike of C++ I can try to explain what my
> motives are.
>
> > i heard people say C++ is slower than C but i can't believe that. in

pieces
> > of the application where speed really matters you can still use "normal"
> > functions or even static methods which is basically the same.

>
> A few years ago I did some timing and (counter to my intuition) I found
> that, indeed, it didn't make a difference, as you point out. One
> remarkable thing was that the C++ executables for my (small) benchmarks
> were quite a bit larger, which may be relevant for embedded applications.


OOP in general tends to be slower. The process of allocating and
deallocating memory, including finding a good sized region to allocate,
takes time. As you say, though, one can do non-OOP in C++, and, with some
work, OOP in C.

> > in C there arent the simplest things present like constants, each struct

and
> > enum have to be prefixed with "struct" and "enum". iam sure there is

much
> > more.


As if the compiler didn't know... In PL/I structures can be referenced in
any unambiguous way. I don't know if that leads to more bugs, or makes
programs more or less readable, though. It does seem strange that you have
to keep reminding the compiler that something is a struct.

> These are some areas where I would agree that yes, C++ is (a bit)
> cleaner than C. Another example is declaring variables inside for()
> statements and such, this can truly help readability, and limiting the
> scope of a local variable if possible is a good thing. Note that many of
> these (almost cosmetic) changes have made their way back into C99.
>
> > i don't get it why people program in C and faking OOP features(function
> > pointers in structs..) instead of using C++. are they simply masochists

or
> > is there a logical reason?


Note, though, that Java is much closer to C than C++ is, despite the
similarity of names. If you like C, but want an OO language, Java should be
your choice.

> In all honesty I think that many people who prefer C over C++ don't
> quite get what all the fuzz is about in OOP (I know I don't). In
> principle there are sound advantages to grouping together structs and
> their associated method functions from a design perspective. Inheritance
> and polymorphism have an important part to play as well, especially in
> some areas of application (such as GUIs).


For some kinds of programming projects, yes.

(snip)

>. However, as a programmer I am no
> longer completely in the driver's seat as I am with C. Looking at a C
> porgram, I can have a straightforward and relatively accurate mental
> picture of what the actual machine code produced by the compiler will
> look like. With OOP and C++, that's no longer true, especially with code
> that uses all the available C++ features including exceptions and

templates.

Well, some people consider C as a glorified assembler. It isn't quite that,
especially as it has changed over the years, but not so far off.

> One generic complaint I have with OOP (not limited to C++) is that I can
> no longer look at a code fragment and reconstruct the execution flow in
> my head, because of polymorphism and operator overloading; in C (unless
> you're doing funky stuff with threads or longjumps), the execution flow
> is pretty much known at compile-time, and can be reproduced from the
> code. I happen to like that.


Well, with library functions in general you don't know what is inside the
function. If you are writing the whole program yourself then the
abstraction is less useful. If different people are working on different
parts then abstraction means you need to know less about the specific
features of those parts. The interface is narrower, which sometimes
decreases efficiency. (It may take more calls to get something done, or
more things done than are really needed.)

> Of course OOP proponents will counter that this is in fact the entire
> point of OOP: one should no longer be thinking in terms of structural
> execution flow, but rather in terms of objects with a well-defined
> behaviorial 'contract', that can be triggered by invoking methods.


(snip)

> As for exceptions, you may know Dijkstra's paper "Goto's considered
> harmful". In this paper he has a number of points that I would subscribe
> to, concerning the ability of the human programmer to read the meaning
> of a piece of code from the source. In essence, he argues that GOTO
> statements destroy this possibility.
>
> I would argue that exceptions are "goto's on steroids". Since exceptions
> are allowed to cross function-call boundaries, execution flow becomes
> very non-transparant - at least to me! This is a similar objection I
> have with polymorphism as described above.


Well, there is that. But the name, exception, gives you some idea of their
use. They should be used for exceptional things. In compilers sometimes
there is nothing that can be done. Especially in recursive descent
compilers it may be that the only thing to do is declare an error and go
onto the next statement. That requires crossing function call boundaries,
but it is easy to understand what is happening. The C setjmp/longjmp has a
similar use, and is similarly non-transparent.

(snip)

> To summarize I would say C++ with its feature set is just too
> complicated, as a language design I feel it has failed. One has to keep
> in mind that a programming language is a tool to make programs. If a
> tool has a significant chance of being unintentially misused (with
> possibly disastrous results), it's not a good tool. I will stick with
> something I actually (more or less) understand, which is C.


Well, much of the idea of C is to be simple. I learned PL/I as my first
structures language, and I still prefer it, in some ways, to C. PL/I is
complicated, almost by design. (It was designed to include features from
Algol, Fortran, and COBOL, all in one language.) C string handling is
simple in design, somewhat efficient, but so easy to do wrong. Again,
PL/I was designed to be complicated, but such that you didn't need to learn
parts you didn't need to use. That required no reserved words. (If you
didn't know about a feature how could you know not to use the words?)
Writing simple programs is pretty simple. The dynamic memory features of C
are fine once you are used to them, but pretty strange until then.

-- glen


 
Reply With Quote
 
nospam@nospam.invalid
Guest
Posts: n/a
 
      10-06-2003

On 6-Oct-2003, "cody" <(E-Mail Removed)> wrote:

> [snip]


Because C is more portable?

 
Reply With Quote
 
Mike Wahler
Guest
Posts: n/a
 
      10-06-2003

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> On 6-Oct-2003, "cody" <(E-Mail Removed)> wrote:
>
> > [snip]

>
> Because C is more portable?


No more portable than C++.

-Mike


 
Reply With Quote
 
cody
Guest
Posts: n/a
 
      10-06-2003
> Inheritance and polymorphism have an important part to play as well,
> especially in some areas of application (such as GUIs).
>
> However, this is the first place where you get a tradeoff of execution
> speed, executable size, and runtime memory usage (for virtual method
> tables) versus design-time advantages. In reality of course, especially
> with nowadays' big machines, these disadvantages are not too important
> for most applications. However, (to me at least) it is a bit unnerving
> to be at the mercy of the compiler and its designer, and hope that he
> implemented all this machinery properly and without causing too much
> overhead. This is more a psychological barrier than a real one of


that is really true!

> course, since modern compilers are able to optimize away many
> unneccessary machinery, and some rather clever tricks have been found to
> make virtual method calls very cheap. However, as a programmer I am no
> longer completely in the driver's seat as I am with C. Looking at a C
> porgram, I can have a straightforward and relatively accurate mental
> picture of what the actual machine code produced by the compiler will
> look like. With OOP and C++, that's no longer true, especially with code
> that uses all the available C++ features including exceptions and

templates.
>
> One generic complaint I have with OOP (not limited to C++) is that I can
> no longer look at a code fragment and reconstruct the execution flow in
> my head, because of polymorphism and operator overloading;


yes, operator overloading is one of the most the most sucking thing in c++!

> As for exceptions, you may know Dijkstra's paper "Goto's considered
> harmful". In this paper he has a number of points that I would subscribe
> to, concerning the ability of the human programmer to read the meaning
> of a piece of code from the source. In essence, he argues that GOTO
> statements destroy this possibility.
>
> I would argue that exceptions are "goto's on steroids". Since exceptions
> are allowed to cross function-call boundaries, execution flow becomes
> very non-transparant - at least to me!


where the exception goes is well defined, it cannot go somewhere, it goes
simply
down the callstack which is more readable than gotos, imo.

but doesn't c support structured exception handling too? i heard something
like that.

> It's a minefield.


absolutely.

> Templates.... Suffice it to say that one cannot write a portable C++
> program using templates and expect it to work identically on different
> compilers. Portability is nil, and this makes this feature not useful in
> many practical sutuations. One can complain about (or to) compiler
> builders in this regard, but this is just a symptom of overly
> complicated semantics.


that is not true. name me one example where semantics are different on
different compilers!
templates are a very very useful and mighty feature in c++. however it is a
bit difficult to use.

> To summarize I would say C++ with its feature set is just too
> complicated, as a language design I feel it has failed. One has to keep
> in mind that a programming language is a tool to make programs. If a
> tool has a significant chance of being unintentially misused (with
> possibly disastrous results), it's not a good tool. I will stick with
> something I actually (more or less) understand, which is C.


yes and no. c++ should not be used for everything. gui's should not be made
with c++.
for libraries, c++ is good because it is very fast and flexible thanks to
templates.
you say the language design has failed, but do you have a better idea how it
can be solved?
imo for high performance applications there is no better way than c++. since
c lacks of templates,
c++ would be the choice for me.

> By the way, did you ever read the Stroustrup book ('Programming in
> C++')? As the book progresses, his examples evolve from things that look
> sort-of-like-C to STL-based programs that are (to my untrained eye at
> least) simply ugly. My feeling is that he tries to bring the expressive
> power of dynamic interpreted languages to the realm of compiled
> languages. A valliant attempt, and I would applaud him for it. However,
> his writing conveys a breathtaking arrogance or perhaps lack of
> understanding for the fact that most programmers are mere mortals... I'm
> sure as the language's designer he is able to mentally internalize the
> runtime model of C++, but to think that your average programmer could
> readily do the same is just preposterous.


right i cannot imagegine that somebody really and completely understands the
STL.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk


 
Reply With Quote
 
Tim Prince
Guest
Posts: n/a
 
      10-06-2003
Mike Wahler wrote:

>
> <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>>
>> On 6-Oct-2003, "cody" <(E-Mail Removed)> wrote:
>>
>> > [snip]

>>
>> Because C is more portable?

>
> No more portable than C++.
>
> -Mike

Are you excluding "C++" programs written for Microsoft compilers, or g++
prior to 3.x? That would nearly make the point, that C++ portability has
been possible (but not commonly adhered to) for about a year, compared to
over 20 for C.
--
Tim Prince
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      10-06-2003
Sidney Cadot <(E-Mail Removed)> wrote in message news:<blqeq9$1lc$(E-Mail Removed)>...
....
> And a last thing: try writing a library in C++ and linking it with a
> program written in C (like Matlab, IDL, Mathematica...). Now there's a
> practical reason to prefer C over C++ if I ever saw one.


It seems to me that only this last issue truly addresses the question.
In all of your other issues, you're complaining about features of C++
that you don't have to use if you don't want to.

I personally use C or C++ for the simple reason that our company's
contract with NASA requires us to deliver code for either Fortran 77,
Fortran 90, C90 (more precisely, C94), or Ada.

I like C because it's a simpler language than C++, and because I've
got a lot more experience with it. However, I love complicated things,
and I see all kinds of interesting features in C++ that I'd love to
have time to play with. However, as long as all of my C++ programming
is done at home, rather than at work, I'm never going to build up much
experience with it. I'm hpping that the next project I work on allows
both C++ and C99 (which also has some neat new features that aren't in
C++).
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Why do DSLR's still use mirrors? Eric Stevens Digital Photography 2 11-07-2008 07:07 PM
why why why why why Mr. SweatyFinger ASP .Net 4 12-21-2006 01:15 PM
findcontrol("PlaceHolderPrice") why why why why why why why why why why why Mr. SweatyFinger ASP .Net 2 12-02-2006 03:46 PM
Why do so many new style ansi streams and files etc, still use old style strings? Kza C++ 4 03-03-2006 07:00 PM
I need to kow why analog is still in update. My computer browser(XP) Can't use it.... Charles Computer Support 1 05-01-2004 09:18 PM



Advertisments