why still use C?

[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 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: cl**@plethora.net

[Mike Wahler]

"Jirka Klaue" <jk****@ee.tu-berlin.de> wrote in message
news:bm**********@mamenchi.zrz.TU-Berlin.DE...

Mike Wahler wrote:
...

Most people I know tell me I have
an extraordinary sense of humor.
This proves nothing.

It was not an attempt to prove anything.
BTW, it could stand for "none at all" as well.

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]

In comp.std.c Douglas A. Gwyn <DA****@null.net> wrote:
+ th*@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.moderated - moderation address: cl**@plethora.net

[thp]

In comp.std.c Chris Hills <ch***@phaedsys.org> wrote:
+ In article <cl****************@plethora.net>, th*@cs.ucr.edu writes
+>In comp.std.c cody <NO****************@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.moderated - moderation address: cl**@plethora.net

[cody]

> > > > pieces of the application where speed really matters you can still
use

> "normal" functions or even static methods which is basically the same.
Suck it and see.
?

A colloquialism roughly equivalent to "why don't you try it and find
out, instead of whining to me about it?"

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.

i though in standard C, there isn't such a thing like "const" you can only use macros to fake them.

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.)

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()?

void foo(struct MyStruct struct){}

in C you cannot omit the keyword "struct". when it compiles without "struct" you probably using a C++ compiler.

False. The above is neither C *nor* C++; it's a syntax error in
both languages.

sorry, my mistake. it should read

void foo(struct MyStruct myStruct){}

or something similar :)
(And you should read up on 'typedef'; it's the C
Gods' answer to the keyword-impaired.)
you mean a typedef let you omit the keyword? thanks, i didn't know that.

not faster than C++. why should it?

"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!

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.
(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.
sorry i don't know the term "dead on". what does it mean?
You really *don't* seem to know very much about C,
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.
and haven't demonstrated a terrible amount of knowledge of C++
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.
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.

this already was proven to me by other posters.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[thp]

In comp.std.c Seebs <se***@plethora.net> wrote:
[...]
+ In reality, to say you are "programming 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.moderated - moderation address: cl**@plethora.net

[cody]

"Andy Sinclair" <an**@r2g2.nospamplease.co.uk> schrieb im Newsbeitrag
news:cl****************@plethora.net...

cody wrote:

void foo(struct MyStruct struct){}

in C you cannot omit the keyword "struct". when it compiles without "struct"you probably using a C++ compiler.

typedef struct
{
int a;
int b;
} foo;

void bar(foo data)
{
}

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.moderated - moderation address: cl**@plethora.net

[Chris Hills]

In article <cl****************@plethora.net>, Douglas A. Gwyn
<DA****@null.net> writes

C supports the const keyword now.

cody wrote:

since when? C99?

No, since the first C standard in 1989.

That was just a local standard :-)
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Chris Hills]

In article <cl****************@plethora.net>, Andreas
<d9****@efd.lth.se> writes

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
microprocessors, 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. (?)

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 /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Mike Wahler]

"cody" <do*********************@gmx.de> wrote in message
news:bm************@ID-176797.news.uni-berlin.de...

> > i disagree on that.
> >how can you make sure that all data is properly
> > encapsulated if
> > the language provides no support?
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'.

This is no encapsulation. encapsulation means that nobody (except the

class itself)
can access the variable directly,
or the direct acess is limited to certain
classes for example derived classes or friend classes.
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.
You are talking about things you don't understand.
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.
But the same is true for
me when i talk about plain C :)
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?

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.

This is the point of encapsulation. it simply cannot happen that you

access a variable that you have no access to,
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.
due to coding mistakes (Except you unintentional manipulate the variable
using a memory address if you know its offset in the struct/class)

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'.

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, MultiplicateWith(2)) /* you just say what is to do
you don't care about how it should be done */

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.
That's the way functional languages like haskell or lisp or whatever solves problems.

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]

"cody" <do*********************@gmx.de> wrote in message
news:bm************@ID-176797.news.uni-berlin.de...

Mike said that:

struct data
{
int details;
};
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

well understood by C-programmers.
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.
This always was a contradiction for me.
"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.

> 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'.

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.

Indeed. What has this to do with your point?

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?

Feel free to believe that if you like.

-Mike

[cody]

> "C programmer" is always a meaningless term for me. I am a

programmer.
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?).
I use three or four different languages on a regular basis.
Me to (c++/c#/java/php)
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.
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.
I don't know *any*
practicing professionals who only use a single language and/or
programming 'style' or toolset.

It depends. Surely lots of people are only using *one* language regularly,
depending on their work.

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?

Feel free to believe that if you like.

OK, maybe i was wrong about that.

--
cody

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

[Alexander Terekhov]

th*@cs.ucr.edu wrote:
[...]

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.

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_unexpected()) {}" 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]

"Mike Wahler" <mk******@mkwahler.net> schrieb im Newsbeitrag
news:TB*****************@newsread4.news.pas.earthl ink.net...

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'.
This is no encapsulation. encapsulation means that nobody (except the

class

itself)
can access the variable directly,
or the direct acess is limited to certain
classes for example derived classes or friend classes.

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

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.
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.
You are right. I used to see the concept of OOP only in OOP-languages, which
made
me blind for other approaches implementing OOP.
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?
I hope to learn.

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.

Agreed.
1. Research the terms 'data hiding' and 'interface'.
I know how to hide data with C. but I wonder how a C programmer would
implement
an Interface.
for_each (myContainer, MultiplicateWith(2)) /* you just say what is to do you don't care about how it should be done */

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

for_each(myContainer.begin(), myContainer.end(), MultiplicateWith<2>());

better? (consider MultiplicateWith as a functor with <int> as template
parameter)
2. A correct invocation of 'for_each' expresses exactly
the same concept as your 'for' example above, only
using different words.
for_each is using iterators, that means the container knows how it can be
traversed.
you only say: iterate through this thing!
3. 'for_each' behavior is not an example of functional programming.

Is it. I googled a bit and found some good results:
Multi Paradigm programming in C++:
http://www.fz-juelich.de/zam/FACT/gl.../glossary.html
http://www.oreillynet.com/pub/a/netw...n.html?page=la
st
--
cody

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

[E. Robert Tisdale]

Alexander Terekhov wrote:

So, there is some "intrinsic difference in performance", I'm afraid.

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]

"E. Robert Tisdale" wrote:

Alexander Terekhov wrote:

So, there is some "intrinsic difference in performance", I'm afraid.

No.

There is no difference in performance
unless an exception is actually thrown.

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.

[Mark McIntyre]

On Mon, 13 Oct 2003 00:25:37 +0200, in comp.lang.c , "cody"
<do*********************@gmx.de> wrote:

I wasn't aware that OOP is so well understood by C-programmers.
This always was a contradiction for me.

Perhaps you should do a websearch for some of the names of the
regulars, or hang out in comp.programming for a few weeks. Then
perhaps you'd understand why you are looking like a bit of an idiot
right now. :-) Just because they're posting in CLC doesn't mean that C
is the only language they programme in.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Mark McIntyre]

On Mon, 13 Oct 2003 22:00:44 +0200, in comp.lang.c , "cody"
<do*********************@gmx.de> wrote:

"C programmer" is always a meaningless term for me. I am a
programmer.
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?).

IME people who can programme good C tend to be people who are good
programmers because C, unlike some languages, requires to you to
*think*.

I use three or four different languages on a regular basis.

Me to (c++/c#/java/php)

well, three of those are the same language, with a different name :-0
Seriously i actually programmed once a fully functioning XXO game in a Excel
table using VBS.

This is probably a good example of the wrong choice of language. :-)

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[E. Robert Tisdale]

Alexander Terekhov wrote:

E. Robert Tisdale wrote:

Alexander Terekhov wrote:

So, there is some "intrinsic difference in performance", I'm afraid.

No.

There is no difference in performance
unless an exception is actually thrown.

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))

According to Bjarne Stoustrup, "The C++ Programming Language:
Third Edition", Chapter 14 Exception Handling,
Section 8 Exceptions and Efficiency, page 381:

"In principle, exception handling can be implemented so that
there is no run-time overhead when no exception is thrown."

This principle has been realized in practice.

[thp]

In comp.std.c Alexander Terekhov <te******@web.de> wrote:
+
+ th*@cs.ucr.edu wrote:
+ [...]
+> 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.
+
+ 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.

Huh? We're talking about code that is conforming under both C
(perhaps I should specify C89/90) and C++. Are you saying that there
are some such programs for which a C++ compiler must generate code
that is somehow different from what a C compiler would/could generate?

Tom Payne

[Allin Cottrell]

E. Robert Tisdale wrote:

But C++ programs that handle exceptions
can be much "fatter" than C (or C++) programs
that don't handle exception.

"Fatter" is some sort of technical term here?
Anything to do with "bloat"?

--
Allin Cottrell
Department of Economics
Wake Forest University, NC

[Fergus Henderson]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> writes:

Alexander Terekhov wrote:

E. Robert Tisdale wrote:

Alexander Terekhov wrote:

So, there is some "intrinsic difference in performance", I'm afraid.

No.

There is no difference in performance
unless an exception is actually thrown.

There is certainly a difference in performance between languages which
support exception handling (or equivalent feature) and those that don't.
The difference is generally small, but it does exist. Compilers have
less freedom to reorder code that might throw exceptions.

Consider, for example, the following function:

int foo() {
static int x = 0;
bar();
x = x + 1;
return x;
}

Since the address of "x" is not taken, the compiler can be sure that
it won't be used in bar(). If it is sure that bar() won't throw an
exception, then it can evaluate "x + 1" and store the result back into
"x" _in parallel_ with evaluating the function call.

However, in C, any function might call longjmp().
This feature is quite similar in power to exception handling --
it can for instance easily be used to implement exception handling
(see e.g. my C exception handling library CXCPT
<http://www.cs.mu.oz.au/~fjh/CXCPT/index.html>).
So I'm not sure if there is any intrinsic difference between
C and C++ in this regard.
http://www.computer.org/concurrency/pd2000/p4072abs.htm
("C++ Exception Handling", Christophe de Dinechin,
IEEE Concurrency October-December 2000 (Vol. 8, No. 4))
According to Bjarne Stoustrup, "The C++ Programming Language:
Third Edition", Chapter 14 Exception Handling,
Section 8 Exceptions and Efficiency, page 381:

"In principle, exception handling can be implemented so that
there is no run-time overhead when no exception is thrown."

That's true to a first approximation, but I'm not yet convinced
that it is true to a second approximation.
This principle has been realized in practice.

Are you sure? Which implementation realizes it?

The following is from a KAI C++ exception exception handling tutorial
<http://www.hlrs.de/organization/tsc/services/tools/docu/kcc/tutorials/exceptions.html>:

| General point: Some implementations of C++ claim to have "zero overhead"
| exceptions. This is impossible as exceptions inherently add new paths of
| control flow to a program. What they really mean by "zero overhead" is
| "prepaid overhead". (I like the vendor who advertises "zero overhead",
| but has a switch to turn off exceptions to enable a "faster smaller
| executable".)
|
| The way to find out what the overhead is for exception handling is
| to benchmark your own application with it turned on and off. In our
| experience, the overhead is usually in the 1-10% range.

--
Fergus Henderson <fj*@cs.mu.oz.au> | "I have always known that the pursuit
The University of Melbourne | of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.

[Christian Bau]

In article <bm**********@glue.ucr.edu>, th*@cs.ucr.edu wrote:

In comp.std.c Alexander Terekhov <te******@web.de> wrote:
+
+ th*@cs.ucr.edu wrote:
+ [...]
+> 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.
+
+ 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.

Huh? We're talking about code that is conforming under both C
(perhaps I should specify C89/90) and C++. Are you saying that there
are some such programs for which a C++ compiler must generate code
that is somehow different from what a C compiler would/could generate?

size_t s = sizeof ('a');

will set s to sizeof (char) = 1 on all C++ compilers, and set s to
sizeof (int) on C compilers, which is in practice greater than 1.

[Richard Bos]

"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

Alexander Terekhov wrote:

So, there is some "intrinsic difference in performance", I'm afraid.

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.

You are Bill Gates, and I claim my five pounds.

Richard

[Alexander Terekhov]

Fergus Henderson wrote:
[...]

However, in C, any function might call longjmp().
Oh yeah. Apart from straight deprecation, that thing just ought to
throw "std::jump_exception" (caught by a handler kinda "injected" by
setjmp()) or something like that.
This feature is quite similar in power to exception handling --
it can for instance easily be used to implement exception handling
(see e.g. my C exception handling library CXCPT
<http://www.cs.mu.oz.au/~fjh/CXCPT/index.html>).
So I'm not sure if there is any intrinsic difference between
C and C++ in this regard.
"All accessible objects have values, and all other components of the
abstract machine 209) have state, as of the time the longjmp function
was called, except that the values of objects of automatic storage
duration that are local to the function containing the invocation of
the corresponding setjmp macro that do not have volatile-qualified
type and have been changed between the setjmp invocation and longjmp
call are indeterminate."

http://h30097.www3.hp.com/docs/base_...rules_volatile

"1. Values of updated_volatile and updated_before_try are reliable.
Values of updated and updated_static are unreliable.

2. Regardless of the path to this code, the values of
updated_volatile and updated_before_try are reliable. If this
code is reached after the ENDTRY macro is invoked and no
exception has been raised, the values of updated and
updated_static are reliable. If this code is reached after the
exception fully_handled_exception has been caught,
the values of updated and updated_static are unreliable.

The code in Example 5-15 demonstrates:

- For variables referenced within exception handler code blocks,
it is necessary to distinguish between those whose value is set
before versus after the TRY macro is invoked in order to declare
those variables properly.

- The requirement to use the volatile type qualifier pertains to
a variable regardless of its C storage class -- that is, for both
automatic and static variables). "

;-)

Now, don't you think that "landing pads" is kinda better approach?

http://www.computer.org/concurrency/pd2000/p4072abs.htm
("C++ Exception Handling", Christophe de Dinechin,
IEEE Concurrency October-December 2000 (Vol. 8, No. 4))

According to Bjarne Stoustrup, "The C++ Programming Language:
Third Edition", Chapter 14 Exception Handling,
Section 8 Exceptions and Efficiency, page 381:

"In principle, exception handling can be implemented so that
there is no run-time overhead when no exception is thrown."

That's true to a first approximation, but I'm not yet convinced
that it is true to a second approximation.

This principle has been realized in practice.

Are you sure? Which implementation realizes it?

The following is from a KAI C++ exception exception handling tutorial
<http://www.hlrs.de/organization/tsc/services/tools/docu/kcc/tutorials/exceptions.html>:

| General point: Some implementations of C++ claim to have "zero overhead"
| exceptions. This is impossible as exceptions inherently add new paths of
| control flow to a program. What they really mean by "zero overhead" is
| "prepaid overhead". (I like the vendor who advertises "zero overhead",
| but has a switch to turn off exceptions to enable a "faster smaller
| executable".)
|
| The way to find out what the overhead is for exception handling is
| to benchmark your own application with it turned on and off. In our
| experience, the overhead is usually in the 1-10% range.

I believe that "the right thing" is that if you have declared ALL your
functions throw()-nothing (and don't use any try-catch/throw... I
mean things like setjmp/longjmp ;-) ) than the only "overhead" shall be
one single "phase one" handler:

__try {
// ... ctors for non-local objects of static duration in C++
exit(main());
// ... dtors for local objects of static duration in C++
}
__except(goto_unexpected()) {}

(threads and "better main" aside for a moment)

This does require two-phase EH and a bit different semantics for ES --
violations shall NOT unwind, they shall simply trigger std::unexpected()
processing at throw points.

regards,
alexander.

[Mark McIntyre]

On Tue, 14 Oct 2003 03:04:16 +0000 (UTC), in comp.lang.c ,
th*@cs.ucr.edu wrote:

In comp.std.c Alexander Terekhov <te******@web.de> wrote:

Stuff which seemed to mostly be about C vs C++, and offtopic in both
CLC and CSC. This thread is dead I think ?

Also Tom can you use "normal" quotation style, your + signs doesn't
work with my newsreader.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Alexander Terekhov]

Mark McIntyre wrote:

On Tue, 14 Oct 2003 03:04:16 +0000 (UTC), in comp.lang.c ,
th*@cs.ucr.edu wrote:

In comp.std.c Alexander Terekhov <te******@web.de> wrote:

Stuff which seemed to mostly be about C vs C++, and offtopic in both
CLC and CSC. This thread is dead I think ?

Next silly question?

regards,
alexander.

[cody]

> 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?

when you have a C++ Library you can only call C-Style-Functions from that
Library. You cannot export Classes/Methods from that Library.

--
cody

[Freeware, Games and Humor]
www.deutronium.de.vu || www.deutronium.tk
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Keith Thompson]

Chris Hills <ch***@phaedsys.org> writes:

In article <cl****************@plethora.net>, th*@cs.ucr.edu writes

In comp.std.c cody <NO****************@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++ has never been a strict superset of any version of C. C++ has
several keywords that are not reserved in C; that alone makes prevents
it from being a superset.

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Jerry Feldman]

On 12 Oct 2003 22:49:25 GMT
Chris Hills <ch***@phaedsys.org> wrote:

C++ is based on C90 However C++ is no longer a super set of C. They
are different languages. <snip> This is not true. The are using C. C++ Inherits from C NOT the other
way round.

I think that members of both the standards committee tried to keep the
standards as coordinated as possible. C++ dropped a lot of the C legacy
(K&R) stuff.
But also C99 added the // comment which is illegal in C90.
--
Jerry Feldman <gaf-nospam-at-blu.org>
Boston Linux and Unix user group
http://www.blu.org PGP key id:C5061EA9
PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Francis Glassborow]

In article <cl****************@plethora.net>, Chris Hills
<ch***@phaedsys.org> writes

A wild guess is that every minute of the day, there is more micro
processor code running than PC code running. (?)

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.

No one who understands the degree to which embedded systems pervade our
technological societies would argue that the processors in general
purpose computers represent anything but a a very small part of the
population of processors in use. However the step from that to the
volume of code running at any given time is far more debatable. 8051
based equipment tends to be running very small amounts of code
relatively slowly, quite apart from anything else high clock speeds are
very power hungry so running an 8051 at 2GHz would be inappropriate.

General purpose computer tend to run very large volumes of, often flaky,
code very fast. Of course there is embedded code running on very fast
processors (e.g. the latest high end graphics cards that are so power
hungry that they need to take power directly from the power unit and not
from the motherboard.) OTOH embedded processor code tends to be compact
and carefully honed code which is relatively error free. I would hazard
a guess that the hours of development time per code instruction is an
order of magnitude (or possibly 2 or even 3 orders) higher than that for
even for operating systems for PCs.

There is also the issue as to whether the code running on the graphics
card, sound card etc. counts as PC code or embedded processor code.

--
Francis Glassborow ACCU
If you are not using up-to-date virus protection you should not be reading
this. Viruses do not just hurt the infected but the whole community.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[James Kuyper]

Fergus Henderson <fj*@cs.mu.oz.au> wrote in message news:<3f********@news.unimelb.edu.au>...
....

The difference is generally small, but it does exist. Compilers have
less freedom to reorder code that might throw exceptions.

An issue that does not apply to code which uses only the common subset
of C and C++, where care is taken to ensure that the code has the same
meaning in both languages.

[James Kuyper]

Mark McIntyre <ma**********@spamcop.net> wrote in message news:<1o********************************@4ax.com>. ..

On Sun, 12 Oct 2003 15:58:13 +0200, in comp.lang.c , "cody"
<do*********************@gmx.de> wrote:

This is no encapsulation. encapsulation means that nobody (except the class itself)
can access the variable directly, or the direct acess is limited to certain
classes for example derived classes or friend classes.

This is what C++ defines encapsulation as, sure. But encapsulation was
around before C++ you know.Try to define it without using C++isms,
before you spout caeculum tauri.

Without language support for encapsulation, attempts to reference
something from inappropriate locations in the code is something that
can only be prevented by very careful checking by fallible human
beings during code reviews. With such language support, some such
errors can be automatically checked for by the compiler.

The option of using opaque types in C code provides some support for
encapsulation, but nowhere near as much support as C++ provides.

[Paul Hsieh]

In article <8b**************************@posting.google.com >, ku****@wizard.net
says...

Fergus Henderson <fj*@cs.mu.oz.au> wrote in message news:<3f********@news.unimelb.edu.au>...
...

The difference is generally small, but it does exist. Compilers have
less freedom to reorder code that might throw exceptions.

An issue that does not apply to code which uses only the common subset
of C and C++, where care is taken to ensure that the code has the same
meaning in both languages.

Not so. A function written in C++ that calls another function cannot assume
that the called function will not throw an exception. Therefore it *must*
retain enough information to reconstruct the call stack so that the exception
handling mechanisms still work (and it can't do code reording as suggested by
Fergus Henderson.) In C, on the other hand, the mechanism for reconstructing
the stack need only preserve the ability to properly return to the calling
function. This difference can result in substantially different object code.

--
Paul Hsieh
http://www.pobox.com/~qed/

[Alexander Terekhov]

James Kuyper wrote:

Fergus Henderson <fj*@cs.mu.oz.au> wrote in message news:<3f********@news.unimelb.edu.au>...
...

The difference is generally small, but it does exist. Compilers have
less freedom to reorder code that might throw exceptions.

An issue that does not apply to code which uses only the common subset
of C and C++, where care is taken to ensure that the code has the same
meaning in both languages.

The Hewlett-Packard PA-RISC aC++ compiler (table-driven EH, maximum
optimization level):

SPEC SPEED SIZE
BENCHMARK PENALTY(%) PENALTY(%)

099.go 15.60 0.21
129.compress 2.00 <0.01
130.li 11.15 1.24
132.ijpeg –0.49 0.06
134.perl 0.81 1.02
147.vortex 0.66 –0.04

(source: computer.org/concurrency/pd2000/p4072abs.htm)

regards,
alexander.

[Sidney Cadot]

cody wrote:

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?

when you have a C++ Library you can only call C-Style-Functions from that
Library. You cannot export Classes/Methods from that Library.

Unfortunately, "doh" doesn't map well to ascii (the question already
suggests 'interposing a proxy library').

This means writing a number of C++ functions to get rid of the classes,
declaring the functions extern "C", and linking to a C program using a
C++ aware linker.

And yes, this should work (does so with gcc, at least). Things like
global C++ object constructors/destructors are properly executed, and
exceptions are properly handled (but cannot, of course, be propagated
into the C domain - the proxy library should take care of them).

Sidney

[cody]

> size_t s = sizeof ('a');

will set s to sizeof (char) = 1 on all C++ compilers, and set s to
sizeof (int) on C compilers, which is in practice greater than 1.

sizeof (int)==sizeof ('a') is never true on no C nor C++ compiler on this
world.

--
cody

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

[Douglas A. Gwyn]

Alexander Terekhov wrote:

SPEC SPEED SIZE
BENCHMARK PENALTY(%) PENALTY(%)

Don't bring reality into this discussion!

[j]

"cody" <do*********************@gmx.de> wrote in message
news:bm************@ID-176797.news.uni-berlin.de...

size_t s = sizeof ('a');

will set s to sizeof (char) = 1 on all C++ compilers, and set s to
sizeof (int) on C compilers, which is in practice greater than 1.

sizeof (int)==sizeof ('a') is never true on no C nor C++ compiler on this
world.

--
cody

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

# cat qed.c
#include <stdio.h>
int main(void)
{
if(sizeof(int) == sizeof 'a')
puts("Read c99 6.4.4.4#10 -- Q.E.D");
return 0;
}
# ./qed
Read c99 6.4.4.4#10 -- Q.E.D
#

As Dan Pop would say: ``Engage your brain before posting''

[Douglas A. Gwyn]

cody wrote:

sizeof (int)==sizeof ('a') is never true on no C nor C++ compiler on this
world.

To the contrary, it is required of every C compiler that
conforms to the standard. (C++ is a different story.)

I suggest that you consider that perhaps the posters to
whom you're responding know more than you do about the
subjects they're discussing. In order to contribute in
a positive way, you need to learn more.

[Irrwahn Grausewitz]

"cody" <do*********************@gmx.de> wrote:

size_t s = sizeof ('a');

will set s to sizeof (char) = 1 on all C++ compilers, and set s to
sizeof (int) on C compilers, which is in practice greater than 1.

sizeof (int)==sizeof ('a') is never true on no C nor C++ compiler on this
world.

That would mean that there is no conforming implementation available
at all; once more you show your lack of C knowledge. Lookup ISO/IEC
9899:1999 6.4.4.4#10 for an explanation why you are wrong.

Hint: what is the type of 'a'?

Regards
--
Irrwahn
(ir*******@freenet.de)

[cody]

> Hint: what is the type of 'a'?

char???????

that would mean sizeof((char)1), sizeof((short)1) would output sizeof(int),
too.

But I tried it using the microsoft C Compiler and

printf("%i",sizeof('a'));

prints 1 (as expected from me), whereas

printf("%i",sizeof('a'+'b'));

outputs 4 (as expected)

--
cody

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

[Default User]

cody wrote:

sizeof (int)==sizeof ('a') is never true on no C nor C++ compiler on this
world.

Don't you ever get tired of looking like a fool?


Brian Rodenborn

[Richard Heathfield]

cody wrote:

Hint: what is the type of 'a'?
char???????

Wrong.

that would mean sizeof((char)1), sizeof((short)1) would output
sizeof(int), too.

But I tried it using the microsoft C Compiler and

printf("%i",sizeof('a'));

prints 1 (as expected from me),

That's not the C compiler. That's the C++ compiler. Change your file
extension to .c if you wish to invoke the C compiler.

--
Richard Heathfield : bi****@eton.powernet.co.uk
"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

[Irrwahn Grausewitz]

"cody" <do*********************@gmx.de> wrote:

[crosspost to c.s.c removed]

Hint: what is the type of 'a'?
char???????

<sigh> Nooo!!!!!!!

Now that you are unwilling, unable or just too lazy, here you go:

ISO/IEC 9899:1999
6.4.4.4 Character constants
[...]
10 An integer character constant has type int. The value of an integer
character constant containing a single character that maps to a
single-byte execution character is the numerical value of the
representation of the mapped character interpreted as an integer.
The value of an integer character constant containing more than one
character (e.g., 'ab'), or containing a character or escape sequence
that does not map to a single-byte execution character, is
implementation-defined. If an integer character constant contains a
single character or escape sequence, its value is the one that
results when an object with type char whose value is that of the
single character or escape sequence is converted to type int.
[...]

that would mean sizeof((char)1), sizeof((short)1) would output sizeof(int),
too.

But I tried it using the microsoft C Compiler and

No. If at all, you tried it using a C++ compiler. And, as we all know:

<chorus> Cee plus plus is off topic in comp lang cee </chorus>

[drivel snipped]
--
No man is an island -- but some of us are long peninsulas.

[Christian Bau]

In article <bm************@ID-176797.news.uni-berlin.de>,
"cody" <do*********************@gmx.de> wrote:

Hint: what is the type of 'a'?

char???????

that would mean sizeof((char)1), sizeof((short)1) would output sizeof(int),
too.

But I tried it using the microsoft C Compiler and

printf("%i",sizeof('a'));

prints 1 (as expected from me), whereas

printf("%i",sizeof('a'+'b'));

outputs 4 (as expected)

Try again. This time make sure that you use the compiler as a C
compiler, not a C++ compiler.

[E. Robert Tisdale]

Brian Rodenborn wrote:

Don't you ever get tired of looking like a fool?

I don't think there was any call for that.

[E. Robert Tisdale]

cody wrote:

sizeof (int)==sizeof ('a') is never true
on [any] C nor C++ compiler on this world. cat main.c #include<stdio.h>

int main(int argc, char* argv[]) {
fprintf(stdout, "%u = sizeof 'a'\n", sizeof 'a');
return 0;
}
gcc -Wall -std=c99 -pedantic -O2 -o main main.c
./main

4 = sizeof 'a'

Our indigenous trolls are more interested
in making new subscribers look foolish
than they are in helping them to understand
the C computer programming language.

[Keith Thompson]

"cody" <do*********************@gmx.de> writes:

Hint: what is the type of 'a'?

char???????

Let me explain why you're wrong.

The type of 'a' is int. The C99 standard, section 6.4.4.4 paragraph 2,
says:

An integer character constant is a sequence of one or more
multibyte characters enclosed in single-quotes, as in 'x'.

Paragraph 10 says:

An integer character constant has type int.

Any decent C textbook should explain this. Any C compiler (i.e., not
a C++ compiler) should allow you to demonstrate that sizeof('a') ==
sizeof(int). If you find that sizeof('a') != sizeof(int), you're not
using a C compiler.

(In C++, a character constant has type char, and sizeof('a') == 1.
We don't discuss C++ here.)

In most contexts, it doesn't matter whether a character constant has
type int or char; it's usually going to be implicitly converted
anyway. Personally, I would actually prefer it if character constants
had type char rather than int, but my preference isn't strong enough
to suggest changing the language.

If you're going to make definitive statements about these things,
please keep in mind that you're hanging out with experts. Some of us
(not including myself) helped write the standard; a lot of us have a
copy of it just an arm's reach or a few keystrokes away.

If you want to learn, we'll be delighted to help. At your current
level of knowledge, I think you're generally better off asking
questions than answering them. And in many cases you can find the
answers in the C FAQ or in a good textbook.

And speaking of the FAQ, I strongly suggest you read the whole thing.
It's at <http://www.eskimo.com/~scs/C-faq/top.html>. In particular, I
call your attention to question 8.9, "Why is sizeof('a') not 1?".

--
Keith Thompson (The_Other_Keith) ks*@cts.com <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://www.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[cody]

> >> Hint: what is the type of 'a'?

char???????

Wrong.

that would mean sizeof((char)1), sizeof((short)1) would output
sizeof(int), too.

But I tried it using the microsoft C Compiler and

printf("%i",sizeof('a'));

prints 1 (as expected from me),

That's not the C compiler. That's the C++ compiler. Change your file
extension to .c if you wish to invoke the C compiler.

Damn you are right :(

But the strange thing is, that

printf("%i",sizeof((char)'a'));

outputs 1. char is not the same as char. funny.

--
cody

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

[Irrwahn Grausewitz]

"cody" <do*********************@gmx.de> wrote:

But the strange thing is, that

printf("%i",sizeof((char)'a'));

outputs 1. char is not the same as char.

No. A /character constant/ is not of type char.
--
Irrwahn
(ir*******@freenet.de)