why still use C?

[Mike Wahler]

Re: why still use C?


"Jirka Klaue" <jklaue@ee.tu-berlin.de> wrote in message
news:bmbgi7$4e9 $1@mamenchi.zrz .TU-Berlin.DE...[color=blue]
> Mike Wahler wrote:
> ...[color=green]
> > Most people I know tell me I have
> > an extraordinary sense of humor.[/color]
>
> This proves nothing.[/color]

It was not an attempt to prove anything.
[color=blue]
>BTW, it could stand for "none at all" as well.[/color]

Or anything else you like. I treat it as what it was,
an exchange of opinions between Cody and myself about
"sense of humor."

-Mike

[thp@cs.ucr.edu]

Re: why still use C?

In comp.std.c Douglas A. Gwyn <DAGwyn@null.ne t> wrote:
+ thp@cs.ucr.edu wrote:
+> Compiling C programs with a C++ compiler has the benefit that C++
+> compilers are required to perform intermodule type checking. But I'm
+> told that this intermodule type checking is a curse when one tries to
+> use precompiled libraries that have been compiled on different C++
+> compilers, since that checking is usually based on name-mangling and
+> there is no name-mangling standard. (Perhaps others have more
+> experience with that issue.)
+
+ On essentially any platform there is a unique standard API
+ for C linkage. And it is easy to get that linkage from C++
+ by using "extern C". Therefore, libraries written in C are
+ readily used from both C and C++ applications. Libraries
+ that rely on C++-specific features (e.g. classes) are not
+ readily used from C applications.

Is it feasible to interpose a proxy library whose headers are
conforming C code that's compiled with a C++ compiler and that calls
functions from the C++ library?

Tom Payne
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[thp@cs.ucr.edu]

Re: why still use C?

In comp.std.c Chris Hills <chris@phaedsys .org> wrote:
+ In article <clcm-20031008-0017@plethora.n et>, thp@cs.ucr.edu writes
+>In comp.std.c cody <NO.SPAM.deutro nium@gmx.net> wrote:
+>
+>C is pretty much, but not quite, a sublanguage of C++.
+
+ C++ is based on C90 However C++ is no longer a super set of C. They are
+ different languages.
+
+>C programmers who don't use the non-C++ features of C are
^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^^^^^^^^ ^^^^^^^^
+> programming in C++ whether
+>they claim to or not. They are restricting themselves to an older,
+>more established, more easily learned, and more easily implemented
+>subset of C++. But they are writing in C++ --- non-idiomatic C++, but
+>C++ nevertheless.
+
+ This is not true.

We are speaking of "C programmers to don't use the non-C++ features of
C", i.e., they use only those features of C that are C++ compatible.

+ The are using C.

That's why I referred to them as "C programmers".

+ C++ Inherits from C NOT the other way round.

I'm told that C has actually imported a few C++ features, but that's
beside the point.

Tom Payne
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[cody]

Re: why still use C?

> > > > pieces of the application where speed really matters you can still
use[color=blue][color=green][color=darkred]
> > > > "normal" functions or even static methods which is basically the[/color][/color][/color]
same.[color=blue][color=green][color=darkred]
> > >
> > > Suck it and see.[/color]
> >
> > ?[/color]
>
> A colloquialism roughly equivalent to "why don't you try it and find
> out, instead of whining to me about it?"[/color]

I said that some people said that C would be faster and I don't believe
that.
So why should i test it? I don't blieve it, as i said. But for the case that
people
where right, i asked that if somebody would know a case where C is faster
than C++, should tell me.
[color=blue][color=green]
> > i though in standard C, there isn't such a thing like "const" you can[/color][/color]
only[color=blue][color=green]
> > use macros to fake them.[/color]
>
> Well, you're wrong. Your response here, and your response to ERT,
> demonstrate that you apparently have a large gap in your C knowledge
> spanning roughly the years 1988-1998. (While "ancient" K&R C didn't
> have 'const', it has been standard C since 1989, and C99 didn't
> change much in this respect.)[/color]

Well, i'read books about C++ but this is long ago, and as we all know, books
are not
very up-to-date anyway and the knowlegde of some authors is alarming. how
many C++ books keep you telling to include <iostream.h> instead of
<iostream> or void main() instead of int main()?
[color=blue][color=green]
> > void foo(struct MyStruct struct){}
> >
> > in C you cannot omit the keyword "struct". when it compiles without[/color][/color]
"struct"[color=blue][color=green]
> > you probably using a C++ compiler.[/color]
>
> False. The above is neither C *nor* C++; it's a syntax error in
> both languages.[/color]

sorry, my mistake. it should read

void foo(struct MyStruct myStruct){}

or something similar :)
[color=blue]
> (And you should read up on 'typedef'; it's the C
> Gods' answer to the keyword-impaired.)[/color]

you mean a typedef let you omit the keyword? thanks, i didn't know that.
[color=blue][color=green]
> > not faster than C++. why should it?[/color]
>
> "Suck it and see," remember? I could run some size and speed
> benchmarks on my C and C++ compilers, and let you know the
> quantitative differences, but why should I bother? You're the
> one who wants to know! You do it![/color]

as i said, why should it? i asked just in case somebody could tell me a case
where
this assumption could be true, but i think it is an illogigal assumption.
[color=blue]
> (Oh, and re your response to Jack Klein: While IMHO Jack was a
> bit harsh, and a bit defensive, his criticism of your style was
> dead on.[/color]

sorry i don't know the term "dead on". what does it mean?
[color=blue]
> You really *don't* seem to know very much about C,[/color]

you're right. before i asked my question here, i wasn't aware that there are
so many
differences between C and C++. i always though of C as simply a subset of
C++
which is, as i learned here, not true.
[color=blue]
> and haven't demonstrated a terrible amount of knowledge of C++[/color]

i don't consider myself as a expert in C++ but i think i have reasonable
knowlegde of
it. the last year i programmed only Java and C# so my C++ knowledge might be
a bit
rusty.
[color=blue]
> either (not that that would be on-topic here), yet you want us
> to prove to you somehow that C is "still relevant," or something.[/color]

this already was proven to me by other posters.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[thp@cs.ucr.edu]

Re: why still use C?

In comp.std.c Seebs <seebs@plethora .net> wrote:
[...]
+ In reality, to say you are "programmin g in C++" means not just that your
+ code happens to be syntactically C++, but that you have adopted the philosophy
+ and design of that language. Often, people whose code passes through a C++
+ compiler are really writing FORTRAN IV; I've seen such code.

Hence, the distinction between idiomatic and non-idiomatic C++.

Tom Payne
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[cody]

Re: why still use C?

"Andy Sinclair" <andy@r2g2.nosp amplease.co.uk> schrieb im Newsbeitrag
news:clcm-20031012-0005@plethora.n et...[color=blue]
> cody wrote:[color=green]
> >void foo(struct MyStruct struct){}
> >
> >in C you cannot omit the keyword "struct". when it compiles without[/color][/color]
"struct"[color=blue][color=green]
> >you probably using a C++ compiler.[/color]
>
>
> typedef struct
> {
> int a;
> int b;
> } foo;
>
> void bar(foo data)
> {
> }[/color]


Thank you! I always said it, a snippet of code can tell more than hundreds
words!

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[Chris Hills]

Re: why still use C?

In article <clcm-20031012-0014@plethora.n et>, Douglas A. Gwyn
<DAGwyn@null.ne t> writes[color=blue][color=green][color=darkred]
>>>C supports the const keyword now.[/color][/color]
>cody wrote:[color=green]
>> since when? C99?[/color]
>
>No, since the first C standard in 1989.[/color]

That was just a local standard :-)


/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ chris@phaedsys. org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[Chris Hills]

Re: why still use C?

In article <clcm-20031012-0018@plethora.n et>, Andreas
<d99alu@efd.lth .se> writes[color=blue]
>C is much more alike the final machine code, and that is a benefit
>that some programmers take advantage of. This is handy when coding
>microprocessor s, which are mostly done in C, since assembler quickly
>gets out of hand. Also when core are to be translated in to HDL
>language to be realized in hardware, most often C (and SystemC) is
>used.
>
>A wild guess is that every minute of the day, there is more micro
>processor code running than PC code running. (?)[/color]

According to figures I have seen from several silicon vendors (they vary
slightly but they average out at about 1 in 3 processors on (and above)
the planet is an 8051....

PC x86 processors make up less than 10% of the total the other 88% are
embedded systems... (the 2% are MACs and mainframes.)

I am sure the figures have changed in detail but it gives a fair
picture.




/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ chris@phaedsys. org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
--
comp.lang.c.mod erated - moderation address: clcm@plethora.n et

[Mike Wahler]

Re: why still use C?

"cody" <dont.spam.me.d eutronium@gmx.d e> wrote in message
news:bmbml2$kn7 pe$1@ID-176797.news.uni-berlin.de...[color=blue][color=green][color=darkred]
> > > > > i disagree on that.
> > > > >how can you make sure that all data is properly
> > > > > encapsulated if
> > > > > the language provides no support?[/color]
> >
> > It does provide it. What do you mean by "properly"?
> >
> > struct data
> > {
> > int details;
> > };
> >
> > The value 'details' is properly encapsulated inside
> > the struct type 'data'. This encapsulation could
> > indeed be corrupted via making coding errors, but
> > this does *not* mean the encapsulation is 'improper'.[/color]
>
> This is no encapsulation. encapsulation means that nobody (except the[/color]
class[color=blue]
> itself)
> can access the variable directly,
> or the direct acess is limited to certain
> classes for example derived classes or friend classes.[/color]

Go ahead and believe that if you like. I'm done trying
to correct your misconceptions.

You also still seem to be insisting that OO concepts must
be expressed with C++ constructs, which is certainly
untrue. However my example is still valid in that language
anyway. It's not the way I'd actually do it with C++, but
that doesn't mean it's not encapsulation.
[color=blue]
> You are talking about things you don't understand.[/color]

If it pleases you to believe that, I don't mind.
However your opinion of my level of knowlege matters
to me not at all, given the statements you've made
in this forum.
[color=blue]
> But the same is true for
> me when i talk about plain C :)[/color]

So you admit that when talking about C, you are talking
about something you don't understand. So why do you
make the claims about it that you have?
[color=blue][color=green]
> > The existence of the possibility of coding errors does
> > not preclude a program from being expressed with OOP.
> > A language's enforcements of OOP concepts is a very
> > useful tool, but need not be present for a program
> > to be expressed using OOP.[/color]
>
> This is the point of encapsulation. it simply cannot happen that you[/color]
access[color=blue]
> a variable that you have no access to,[/color]

Feel free to believe that if you like. A couple of suggestions:

1. Research the terms 'data hiding' and 'interface'.

2. Call upon your knowledge of English in considering
why certain OO concepts have the names they do.
[color=blue]
> due to coding mistakes (Except you unintentional manipulate the variable
> using a memory address if you know its offset in the struct/class)[/color]
[color=blue][color=green]
> > No. 'for_each()' is simply a function which iterates
> > through a sequence, and applies a function to each
> > member of that sequence. It's a generalization of
> > a simple 'for loop', designed to be useful with
> > the standard library 'container' abstraction.
> > Nothing at all to do with 'functional programming'.[/color]
>
> Functional programming means you don't say how you want it done like in
> [C/C++/Pascal or similar] but you just say what you want have done.
>
> for (int i=0; i<10; i++) a[i]+=2; /* you excatly say how to do it */
>
> for_each (myContainer, MultiplicateWit h(2)) /* you just say what is to do
> you don't care about how it should be done */[/color]

1. That does *not* express an invocation of the C++
library function 'for_each()'

2. A correct invocation of 'for_each' expresses exactly
the same concept as your 'for' example above, only
using different words.

3. 'for_each' behavior is not an example of functional programming.
[color=blue]
> That's the way functional languages like haskell or lisp or whatever[/color]
solves[color=blue]
> problems.[/color]

I don't think so.


I'm going to stop trying to correct your misconceptions now.
If you'd like personal tutoring in C and/or C++, I'll need
some compensation.

-Mike

[Mike Wahler]

Re: why still use C?

"cody" <dont.spam.me.d eutronium@gmx.d e> wrote in message
news:bmckcd$kp0 k3$1@ID-176797.news.uni-berlin.de...[color=blue]
> Mike said that:
>[color=green]
> > struct data
> > {
> > int details;
> > };[/color]
>
> is properly encapsulated data. It isn't.
>
> Maybe he meant that if one would use this struct as opaque datatype, yes
> that would indeed be good encapsulation.
> If he actually meant that, he was right. I wasn't aware that OOP is so[/color]
well[color=blue]
> understood by C-programmers.[/color]

Apparently you're also unaware that the fact that many if not
most people who know and use C also use other development
tools and techniques as well.
[color=blue]
> This always was a contradiction for me.[/color]

"C programmer" is always a meaningless term for me. I am a
programmer. I use three or four different languages on a
regular basis. Sometimes I use others as well for specialized
tasks. I use whichever programming 'paradigm'(s), tools etc.
that I find most suitable for a given task. I don't know *any*
practicing professionals who only use a single language and/or
programming 'style' or toolset.
[color=blue]
>[color=green][color=darkred]
> > >> No. 'for_each()' is simply a function which iterates
> > >> through a sequence, and applies a function to each
> > >> member of that sequence. It's a generalization of
> > >> a simple 'for loop', designed to be useful with
> > >> the standard library 'container' abstraction.
> > >> Nothing at all to do with 'functional programming'.[/color]
> >[color=darkred]
> > >Functional programming means you don't say how you want it done like in
> > >[C/C++/Pascal or similar] but you just say what you want have done.[/color]
> >
> > Indeed. What has this to do with your point?[/color]
>
> for_each() says: Iterate throw all items in this container and you don't
> have to say how it should do that.
> Isn't that what functional programming is?[/color]

Feel free to believe that if you like.

-Mike

[cody]

Re: why still use C?

> "C programmer" is always a meaningless term for me. I am a[color=blue]
> programmer.[/color]

The languages somebody use tells a lot about him. Usually C-programmers are
people
who want to know what exactly is going on behind. they love small things
they love
details. C-progammers are like assembler programmers, but assembler
programmers are the worst (is this the correct term to express more
extremely marked
characteristics of somebody?).
[color=blue]
> I use three or four different languages on a regular basis.[/color]

Me to (c++/c#/java/php)
[color=blue]
> Sometimes I use others as well for specialized
> tasks. I use whichever programming 'paradigm'(s), tools etc.
> that I find most suitable for a given task.[/color]

Never written a webshop in C or a graphics driver with Java? :-[=]
Seriously i actually programmed once a fully functioning XXO game in a Excel
table using VBS.
[color=blue]
> I don't know *any*
> practicing professionals who only use a single language and/or
> programming 'style' or toolset.[/color]

It depends. Surely lots of people are only using *one* language regularly,
depending on their work.
[color=blue][color=green]
> > for_each() says: Iterate throw all items in this container and you don't
> > have to say how it should do that.
> > Isn't that what functional programming is?[/color]
>
> Feel free to believe that if you like.[/color]

OK, maybe i was wrong about that.

--
cody

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

[Alexander Terekhov]

Re: why still use C?


thp@cs.ucr.edu wrote:
[...][color=blue]
> C is pretty much, but not quite, a sublanguage of C++. C programmers
> who don't use the non-C++ features of C are programming in C++ whether
> they claim to or not. They are restricting themselves to an older,
> more established, more easily learned, and more easily implemented
> subset of C++. But they are writing in C++ --- non-idiomatic C++, but
> C++ nevertheless. AFAIK, a C++ compile is free to generate the same
> code for those programs as would a C compiler, so there is no
> intrinsic difference in performance.[/color]

In C without exceptions (stuff like MS or DEC/HP SEH extensions), all
functions are kinda "throw()". In the current C++ (without mandatory
2-phase EH and with brain-damaged exception specifications instead),
throw() is kinda expensive. So, there is some "intrinsic difference
in performance", I'm afraid.

http://lists.boost.org/MailArchives/boost/msg53807.php

http://lists.boost.org/MailArchives/boost/msg53808.php

http://lists.boost.org/MailArchives/boost/msg53826.php

regards,
alexander.

P.S. WRT to the last link: "Stack overflow is no problem on *entry*
to a throw() region..." is about explicit throw()-regions apart from
scope cleanup -- I mean {throw()-nothing} dtors... they shall have
implicit throw() ES by default, of course. We just can't retry thier
destruction because objects are gone. Optional stack checking (for
objects that live in throw-something routines) can be done prior to
construction (and, of course, the entire "landing pad" shall to be
protected by MS SEH like "__try/__except(goto_u nexpected()) {}" or
"something like that").

<quote>

LANDING PADS

The runtime transfers control to a landing pad whenever an exception
is thrown from a given call site. The landing pad contains code in
the following order:

- compensation code, restoring program state to what it would be if
optimizations had not been done in the main control flow;

- destructor invocation to destroy any local object that needs to be
destroyed;

- exception switches to select which catch handler, if any, to jump
to (an appropriate switch value is computed by the runtime from
the C++ exceptions table and placed in a temporary register); and

- a landing pad exit, which either returns to a catch block and
moves from there to the main control flow or resumes unwinding if
no appropriate exception handler is found in this subroutine.

<snip>

- If the variable is allocated to a different register in different
sections of code, the landing pad can simply copy that register to
the target register that represents the variable in the exception
handler.

- A value known to be constant that is replaced with the constant
value can be loaded into the appropriate register by the landing
pad, for use by the user code in the exception handler.

- Pending memory operations that have been delayed in the main
control flow can simply be executed in the landing pad should an
exception be thrown. Compensation code therefore lets the compiler
use any of the optimizations that were prevented by simpler table-
driven techniques.

</quote>

regards,
alexander.

[cody]

Re: why still use C?

"Mike Wahler" <mkwahler@mkwah ler.net> schrieb im Newsbeitrag
news:TBCib.9526 $dn6.8405@newsr ead4.news.pas.e arthlink.net...[color=blue][color=green][color=darkred]
> > > struct data
> > > {
> > > int details;
> > > };
> > >
> > > The value 'details' is properly encapsulated inside
> > > the struct type 'data'. This encapsulation could
> > > indeed be corrupted via making coding errors, but
> > > this does *not* mean the encapsulation is 'improper'.[/color]
> >
> > This is no encapsulation. encapsulation means that nobody (except the[/color]
> class[color=green]
> > itself)
> > can access the variable directly,
> > or the direct acess is limited to certain
> > classes for example derived classes or friend classes.[/color]
>
> Go ahead and believe that if you like. I'm done trying
> to correct your misconceptions.[/color]

OK, OK i already learned that in C proper encapsulation is possible.
But i could not know what you mean if you just say:

"struct data{ int details; };
The value 'details' is properly encapsulated inside the struct type 'data' "

That is no encapsulation. Combined with the concept of opaque types, it is.
I already learned that.
[color=blue]
> You also still seem to be insisting that OO concepts must
> be expressed with C++ constructs, which is certainly
> untrue. However my example is still valid in that language
> anyway. It's not the way I'd actually do it with C++, but
> that doesn't mean it's not encapsulation.[/color]

You are right. I used to see the concept of OOP only in OOP-languages, which
made
me blind for other approaches implementing OOP.
[color=blue]
> So you admit that when talking about C, you are talking
> about something you don't understand. So why do you
> make the claims about it that you have?[/color]

I hope to learn.
[color=blue][color=green][color=darkred]
> > > The existence of the possibility of coding errors does
> > > not preclude a program from being expressed with OOP.
> > > A language's enforcements of OOP concepts is a very
> > > useful tool, but need not be present for a program
> > > to be expressed using OOP.[/color][/color][/color]

Agreed.
[color=blue]
> 1. Research the terms 'data hiding' and 'interface'.[/color]

I know how to hide data with C. but I wonder how a C programmer would
implement
an Interface.
[color=blue][color=green]
> > for_each (myContainer, MultiplicateWit h(2)) /* you just say what is to[/color][/color]
do[color=blue][color=green]
> > you don't care about how it should be done */[/color]
>
> 1. That does *not* express an invocation of the C++
> library function 'for_each()'[/color]

for_each(myCont ainer.begin(), myContainer.end (), MultiplicateWit h<2>());

better? (consider MultiplicateWit h as a functor with <int> as template
parameter)
[color=blue]
> 2. A correct invocation of 'for_each' expresses exactly
> the same concept as your 'for' example above, only
> using different words.[/color]

for_each is using iterators, that means the container knows how it can be
traversed.
you only say: iterate through this thing!
[color=blue]
> 3. 'for_each' behavior is not an example of functional programming.[/color]

Is it. I googled a bit and found some good results:
Multi Paradigm programming in C++:

http://www.fz-juelich.de/zam/FACT/glossary/glossary.html

http://www.oreillynet.com/pub/a/network/2003/05/06/cplusplusian.html?page=la

st


--
cody

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

[E. Robert Tisdale]

Re: why still use C?

Alexander Terekhov wrote:
[color=blue]
> So, there is some "intrinsic difference in performance", I'm afraid.[/color]

No.

There is no difference in performance
unless an exception is actually thrown.
But C++ programs that handle exceptions
can be much "fatter" than C (or C++) programs
that don't handle exception.
This doesn't usually make much difference
on modern microprocessors with large code memories.

[Alexander Terekhov]

Re: why still use C?


"E. Robert Tisdale" wrote:[color=blue]
>
> Alexander Terekhov wrote:
>[color=green]
> > So, there is some "intrinsic difference in performance", I'm afraid.[/color]
>
> No.
>
> There is no difference in performance
> unless an exception is actually thrown.[/color]

To begin with, read this:

http://www.computer.org/concurrency/pd2000/p4072abs.htm

("C++ Exception Handling", Christophe de Dinechin,
IEEE Concurrency October-December 2000 (Vol. 8, No. 4))

regards,
alexander.