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

[Mark McIntyre]

On 14 Oct 2003 11:57:10 -0700, in comp.lang.c , ku****@wizard.net
(James Kuyper) wrote:

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.

I've no intention of arguing contrariwise. I'm merely pointing out
that "class", "friend class" "derived class" etc are C++ isms which do
not /define/ encapsulation, but /implement/ it. There are other ways
to do the same thing.
--
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 Tue, 14 Oct 2003 23:18:53 +0200, in comp.lang.c , "cody"
<do*********************@gmx.de> wrote:

Hint: what is the type of 'a'?

char???????

No its an int. For goodness sake, stop now, you're showing woeful
ignorance.
--
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 =---

[cody]

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

Was is the same in other versions of C besides C99?
(In C++, a character constant has type char, and sizeof('a') == 1.
We don't discuss C++ here.)

template <class T>
void FillBuf(T * buf, int nelements)
{
memset(buf, 0, sizeof(T)*nelements);
}

Would be very dangerous called with a char argument if C++ would behave like
C
in this context.

--
cody

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

[Christian Bau]

In article <3F************@jpl.nasa.gov>,
"E. Robert Tisdale" <E.**************@jpl.nasa.gov> wrote:

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.

If you post in comp.std.c and don't understand the C language then you
deserve everything that is coming. And if you don't know why that is so
then you don't understand usenet, so you have it coming twice.

[Christian Bau]

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

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

Was is the same in other versions of C besides C99?

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

template <class T>
void FillBuf(T * buf, int nelements)
{
memset(buf, 0, sizeof(T)*nelements);
}

Would be very dangerous called with a char argument if C++ would behave like
C
in this context.

I don't think you did understand a thing. You should _really_ stop
posting to comp.std.c for a year or so; by that time people might have
forgotten what a fool you are making of yourself right now.

[Sidney Cadot]

E. Robert Tisdale wrote:

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

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

Au contraire, I think everybody has been showing remarkable constraint
so far. I would like to point out that again and again he was given the
advice to read up on stuff before blurting out, and *wham* there comes
another one.

I was tempted for just a second to go across cody's posts of the last
couple of days and collect some of the highlights, but that would be
uncalled for. I would hope though that some gentle and, perhaps,
not-so-gentle reminders of silly behavior would help to bring about a
change.

It is important to consider that he didn't ask a question, he was trying
to answer it. Obviously, he has been unable to get his MSVC compiler to
compile in C mode. This would be amusing in a rather sad way, were it
not for the fact that he stated:

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

There's matters of intellectual hygiene to consider. Extrapolating one
(1) observation to a statement of such generality (obviously unburdened
by knowledge) warrants a slight slap on the wrist.

The reason I take some issue with this is that it took me the better
part of two hours to reply to his original "Why still use C?" post,
under the assumption that he wanted an answer. Now it appears he's not a
troll in the traditional sense, but his attitude definitely needs some
work. He's acting like a kid sitting for the first time at the grown-ups
table, trying to take part in the conversation while he's supposed to
just sit in and listen.

Just my 5 eurocents,

Best regards,

Sidney Cadot

[Keith Thompson]

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

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

Was is the same in other versions of C besides C99?

Yes. If you had carefully read question 8.9 of the C FAQ, you
wouldn't have had to ask that; "ANSI Sec. 3.1.3.4" is a reference to
the previous version of the C standard.

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

[C++ code snippet deleted]

We don't discuss C++ here. Really. If you'd like to discuss C++,
there are several C++ newsgroups. (There's also a C++ FAQ you should
read before you post there; google "C++ FAQ" to find it.)

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

[E. Robert Tisdale]

Christian Bau wrote:

If you post in comp.std.c and don't understand the C language
then you deserve everything that is coming.
The only thing that cody deserved was to be ignored.
And, if you don't know why that is so,
then you don't understand usenet
so you have it coming twice.

If you think that it is clever or smart to bully new subscribers,
you are nothing more than an indigenous troll.
And *you* should expect to be ignored.

[Sidney Cadot]

cody wrote:

But I tried it using the microsoft C Compiler [...]

That's a far cry from your previous statement:

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

Ok, you made the honest mistake to not properly instruct your compiler
to behave as a C compiler (there's a flag for that). The not-very-clever
thing to do is to extrapolate this to the grandiose statement you made
earlier. You do realize this no doubt.

The funny thing is, you're probably a nice guy and all. Judging from
your posts you show some genuine interest in C/C++ issues, combined,
unfortunately, with a lack of in-depth of knowledge of these topics.

Now from your viewpoint, I will probably come across as an old pedantic
arrogant fart, but in reality it's not that bad, I can assure you - I'm
not _that_ old ;-). So putting aside all heated posts of the last days
for a moment, I would just urge you to take in the advice given on
several occasions (to think & learn a bit more before you type).

Nobody's perfect and mistakes are ok, but when you are pointed to
similar mistakes on several occasions, this is often a good clue that
you need to adjust a bit.

As to the flags, I think you'll need '/TC'. For good measure I'd suggest
you put in '/W4' as well, this will give a lot of warnings;
understanding them can really shape up your understanding of C.

Best regards,

Sidney Cadot

[Mark McIntyre]

On Wed, 15 Oct 2003 00:21:21 +0200, in comp.lang.c , "cody"
<do*********************@gmx.de> wrote:

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

Was is the same in other versions of C besides C99?

Always been this way.
--
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 =---

[Sven Semmler]

cody wrote:

sorry i don't know the term "dead on". what does it mean?

http://dict.leo.org/?search=dead+on

/Sven ;)

--
Remove the "-usenet" part of the mail address to mail me. The Gibe/Swen
worm forced me to shutdown my usenet email address for a limited time.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Jerry Feldman]

On 14 Oct 2003 10:01:56 GMT
Keith Thompson <ks*@cts.com> wrote:

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.

I agree that "C++ has never been a strict superset of any version of C",
but I disagree with your logic. A superset can define new keywords (and
comment operators). However there are many constructs in standard C that
are illegal in C++. One example that comes to mine is:
In C:
void foo(void);
In C++ this will cause a syntax error because C++ requires fully
prototyped functions. So, the C++ equivalent is:
void foo();
Since in C++, an empty parameter list means just that, where in C, it
may indicate a legacy function declaration.

Additionally, C++ disallows most of the older legacy (K&R) code that the
C standard had to allow.

So, to be a superset, C++ must be able to compile any legal C program,
and clearly C++ was not intended to do so.
--
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

[Chris Hills]

In article <cl****************@plethora.net>, Francis Glassborow
<fr*****@robinton.demon.co.uk> writes

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.
Francis, AFAIK you have absolutely no knowledge of the 8051 other than
what I have told you in various ACCU and BSI meetings.... and that has
been very superficial. It would be best if you did not use it as an
example.

Being power hungry is not the reason why an 8051 does not (normally) run
at 2Ghz.... Many 8051's work in areas where power is not a factor. They
run code from 2Kbytes to 16Mega bytes.

There are also many 32 and 64 bit embedded systems running that have
megabytes of code.... virtually any car radio or engine management
system. I did have the figures for the line of code in a car radio. It
was in the 100's of thousand lines! It surprised me. Engine management
systems have the odd megabyte of code.

Then there is the telephone & internet system... based on MIPs and PPC.
One SDH switch I worked on had a PPS and 12 486 parts as slaves running
gigabytes of code....

Every aircraft is running a million or two lines of code as soon as the
inverters go on.....

Actually most things run far more code than you would imagine. From a
washing machine upwards.
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
Some of it faster than the average PC.
(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.)
Actually some of the more powerful embedded processors like the Power PC
don't have a power )or the associated heat) problem. Just listen to an
iMac running for hours with no fan....
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.
No so from my experience. though it is true that the average PC
programmer will be pulling in a large overhead of library code for the
GUi and other libraries.

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.

Good point..... very debatable. You get to choose do you want to be
Bill Gates or Plato for this one? :-)

/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ ch***@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[James Kuyper]

"cody" <do*********************@gmx.de> wrote in message news:<cl****************@plethora.net>...
,,,

you mean a typedef let you omit the keyword? thanks, i didn't know that.

Of course. Without typedefs, normal type specifiers have to contain at
least one keyword (such as 'int'), and usually contain many of them
(such as 'const' and 'volatile'). Typedefs allow you to replace the
entire type specifier with a single typedef name.

....

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

It means "exactly correct". The relevant image for this phrase is
someone shooting at a target; when they hit the target, their shooting
is said to be "dead on".
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[Douglas A. Gwyn]

cody wrote:

But I tried it using the microsoft C Compiler and
printf("%i",sizeof('a'));

If you mean Visual C++, that is not a C compiler but
rather some sort of C++ compiler. Perhaps it has some
option you can specify to make it operate as a C
compiler, in which case you should see a different
result. As was already explained, C and C++ differ
with regard to the type of a character constant.

By the way, you don't need the extra parentheses,
which obscure the distinction between the two forms
of sizeof.

[Douglas A. Gwyn]

cody wrote:

printf("%i",sizeof((char)'a'));
outputs 1. char is not the same as char. funny.

char *is* the same as char. Your error is in thinking
that in C a character constant has type char. As has
ben explained several times, it has type int. I could
explain the historical reasons for this but they are
beside the point.

[Douglas A. Gwyn]

E. Robert Tisdale wrote:

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.

Cody doesn't need anybody's help to look foolish.
If he would stop asserting misinformation and instead
ask questions, he would get a different response.

[Douglas A. Gwyn]

Keith Thompson wrote:

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.

There are a large number of things about C that deserve
to be changed, if we were to go about cleaning up the
language. Unfortunately, nearly all of these would
cause existing carefully written programs to behave
differently. Legacy is a severe constraint.

I'm thinking seriously about using my copious free time
(when I finally get some!) to go back to ~7th Edition
Unix and explore an alternate evolution using a clean
C-inspired language that takes into account lessons
learned over decades of C programming. I don't think
it would look much like Limbo, but it might borrow some
ideas such as tuples: (a;b) := (b;a); // swap a & b

[Douglas A. Gwyn]

cody wrote:

The type of 'a' is int. ... Was is the same in other versions of C besides C99?

It has "always" been that way.
template <class T>
void FillBuf(T * buf, int nelements)
{
memset(buf, 0, sizeof(T)*nelements);
}
Would be very dangerous called with a char argument if C++ would behave like
C
in this context.

No, you stll don't understand what has been explained
several times now. Char has nothing to do with this.

[Arthur J. O'Dwyer]

[cross-post to comp.lang.c.moderated removed, for chronological reasons
- I like to see my posts appear within a week, thankyouverymuch :) ]

On Wed, 15 Oct 2003, Jerry Feldman wrote:

Keith Thompson <ks*@cts.com> wrote:

th*@cs.ucr.edu writes
>
>C is pretty much, but not quite, a sublanguage of C++.
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.

I agree that "C++ has never been a strict superset of any version of C",
but I disagree with your logic.

"That's impossible! Logic cannot be refuted!"
A superset can define new keywords (and comment operators).
....however, if any of those additions mean that there exist C programs
that are not C++ programs, then (the set of) C++ (programs) is no
longer a superset of (the set of) C (programs). For example:

int test(int size)
{
int *new = malloc(size); /* two non-C++isms in this line */
return 1 //*
-1 + 1; /* 0 in C99, 1 in C++ */
}

However there are many constructs in standard C that
are illegal in C++. One example that comes to mine is:
In C:
void foo(void);
In C++ this will cause a syntax error because C++ requires fully
prototyped functions.
How long have you been programming in C++?
So, the C++ equivalent is:
void foo();
<snip>
So, to be a superset, C++ must be able to compile any legal C program,
and clearly C++ was not intended to do so.

Right. There's no shame in not being a superset of C; many
languages aren't. And they get along just fine. :-)

-Arthur

[Christian Bau]

In article <0Y********************@comcast.com>,
"Douglas A. Gwyn" <DA****@null.net> wrote:

Keith Thompson wrote:

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.

There are a large number of things about C that deserve
to be changed, if we were to go about cleaning up the
language. Unfortunately, nearly all of these would
cause existing carefully written programs to behave
differently. Legacy is a severe constraint.

I'm thinking seriously about using my copious free time
(when I finally get some!) to go back to ~7th Edition
Unix and explore an alternate evolution using a clean
C-inspired language that takes into account lessons
learned over decades of C programming. I don't think
it would look much like Limbo, but it might borrow some
ideas such as tuples: (a;b) := (b;a); // swap a & b

With a slightly different syntax

(a;b) = (b;a);

this could be added to C. The semantics would be interesting. I assume
that you would want this to have defined behaviour. Tuple r-values would
be obvious, and something like (a;a;a) is no problem as an r-value. I
guess modifying a tuple l-value that contains the same object twice is
undefined behavior, for example (a;a) = (1;2); would be undefined
behavior. Apart from that, if a tuple l-value is used in an assignment
statement, then all the components of the tuple form one object which is
the only object that is modified.

(a;b) += (b;a);

would be no problem because it is by definition the same as

(a;b) = (a;b) + (b;a);

[Richard Bos]

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

Christian Bau wrote:

If you post in comp.std.c and don't understand the C language
then you deserve everything that is coming.

The only thing that cody deserved was to be ignored.

What, and allow other newbies to believe that his erroneous statements
are correct? _That_ would be far less than courteous, perhaps not to
cody (though a good programmer is aware of his own failings and grateful
for correct information), but certainly to all other beginners trying to
find good C information here.

Richard

[cody]

> int test(int size)

{
int *new = malloc(size); /* two non-C++isms in this line */
return 1 //*
-1 + 1; /* 0 in C99, 1 in C++ */
}

is the missing semicolon at the end of a block allowed in C?

However there are many constructs in standard C that
are illegal in C++. One example that comes to mine is:
In C:
void foo(void);
In C++ this will cause a syntax error because C++ requires fully
prototyped functions.

How long have you been programming in C++?

Was there something incorrect?

--
cody

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

[cody]

"Douglas A. Gwyn" <DA****@null.net> schrieb im Newsbeitrag
news:FZ********************@comcast.com...

cody wrote:

But I tried it using the microsoft C Compiler and
printf("%i",sizeof('a'));

... By the way, you don't need the extra parentheses,
which obscure the distinction between the two forms
of sizeof.

You mean sizeof for types and sizeof for variables?
In C++ sizeof for variables needs parantheses, sizeof for types don't.

--
cody

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

[cody]

> Cody doesn't need anybody's help to look foolish.

If he would stop asserting misinformation and instead
ask questions, he would get a different response.

The problem is that i believe that my assertions are correct. But iam very
very
thankful for the many many valuable responses i got here.

--
cody

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

[Douglas A. Gwyn]

cody wrote:

In C++ sizeof for variables needs parantheses, sizeof for types don't.

First, you're posting in C newsgroups, not C++.
Second, I doubt very much that that is true for C++;
it is certainly wrong for C.
Third, they're not variables, they're expressions.

[Douglas A. Gwyn]

cody wrote:

The problem is that i believe that my assertions are correct.

Yes, that is a problem. You should work on a better
understanding of what it is that you definitely know
versus what it is that you're just guessing about.

[cody]

OK i tried it and:

int i = sizeof (int);
// int j = sizeof int; // invalid in both C and C++
int k = sizeof i;
int l = sizeof (i);

The form of sizeof that gets a type as parameter has to use parantheses,
while the sizeof that gets non-expressions as parameter do not need them.
This seems to be true for both C and C++ compilers (I tried both).

--
cody

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

[James Kuyper]

"Douglas A. Gwyn" wrote:

cody wrote:

In C++ sizeof for variables needs parantheses, sizeof for types don't.

First, you're posting in C newsgroups, not C++.
Second, I doubt very much that that is true for C++;
Third, they're not variables, they're expressions.

Section 5.3p1 of the C++ standard says pretty much the same thing that
6.5.3 says in the C standard:

_unary-expression_:
...
sizeof _unary-expression_
sizeof ( _type-id_ )

Paragraph 3 says the same thing in words: "... The operand is either an
expression, ..., or a parenthesized _type-id_. ..."

So cody has it almost exactly backwards. It's only "almost", not because
there's some truth in his claim, but because he used the wrong words.
This seems to fit his track record. I wonder when he'll decide to start
checking the validity of his claims before posting them?

[Richard Heathfield]

cody wrote:

int test(int size)
{
int *new = malloc(size); /* two non-C++isms in this line */
return 1 //*
-1 + 1; /* 0 in C99, 1 in C++ */
}
is the missing semicolon at the end of a block allowed in C?

No, and that wasn't his only mistake.

int test(int size)
{
int *new = malloc(size);
return 1 //*
-1 + 1 /* 0 in C90, 1 in C++ and C99 */
;
}

> However there are many constructs in standard C that
> are illegal in C++. One example that comes to mine is:
> In C:
> void foo(void);
> In C++ this will cause a syntax error because C++ requires fully
> prototyped functions.

How long have you been programming in C++?

Was there something incorrect?

Yes. void foo(void); /is/ a full prototype, in both C and C++.

It is as well for your real-world reputation that you post under a
pseudonym.

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

[Richard Heathfield]

cody wrote:

OK i tried it and:

int i = sizeof (int);
// int j = sizeof int; // invalid in both C and C++
int k = sizeof i;
int l = sizeof (i);
Wrong type. Use size_t for capturing the value yielded by sizeof.
The form of sizeof that gets a type as parameter has to use parantheses,
while the sizeof that gets non-expressions as parameter do not need them.
Wrong. In your example, i is an unary-expression, not a non-expression.

Specifically, the grammar says:

unary-expression:
postfix-expression
++ unary-expression
-- unary-expression
unary-operator cast-expression
sizeof unary-expression
sizeof ( type-name )

(taken from K&R2, p238, since it happened to be on my desk, opened to that
page!)

Note also that sizeof takes an operand, not a parameter.
This seems to be true for both C and C++ compilers (I tried both).

It really is time to stop guessing at this stuff. The C language is defined
by an international standard, not by your apparently random guesses.

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

[Richard Heathfield]

Douglas A. Gwyn wrote:

cody wrote:

The problem is that i believe that my assertions are correct.

Yes, that is a problem.

I hope the sig-monsters are awake.

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

[Keith Thompson]

Richard Heathfield <do******@address.co.uk.invalid> writes:

cody wrote:

OK i tried it and:

int i = sizeof (int);
// int j = sizeof int; // invalid in both C and C++
int k = sizeof i;
int l = sizeof (i);

Wrong type. Use size_t for capturing the value yielded by sizeof.

It's not entirely unreasonable to use int rather than size_t in this
particular case. The result of the sizeof operator, which is of
course of type size_t, is implicitly converted to type int, which is
virtually certain to be able to hold the result. (I say "virtually
certain" rather than "certain" because I can just barely imagine that
some insanely evil implementer might shove enough padding bits into
type int to make its size overflow an int without breaking
conformance.)

Richard's other criticisms are, of course, dead on.

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

[Arthur J. O'Dwyer]

On Wed, 15 Oct 2003, Richard Heathfield wrote:

cody wrote:
[Arthur wrote:]

int test(int size)
{
int *new = malloc(size); /* two non-C++isms in this line */
return 1 //*
-1 + 1; /* 0 in C99, 1 in C++ */
}

is the missing semicolon at the end of a block allowed in C?

No, and that wasn't his only mistake.

Whew, I'm lucky I was lazy in responding. :) I completely forgot
about // comments' being legal C99. But your code still has a
bug; under C90, the /**/ comments disappear to create

int foo = 1/;

don't they? So I guess after fixing that, we could throw in a
sizeof('x') for good measure. [ACTUAL TESTED CODE FOLLOWS(!)]
#include <stdio.h>

int test_version(void)
{
/* Returns 0 under C90, 1 under C99, and 2 under C++ */

int isnt_c90 = 1 //*
-1 /* 0 in C90, 1 in C99/C++ */
+2 / 2;
int is_cxx = (sizeof('x') == 1); /* not completely guaranteed
* to work, but the best I know
* off the top of my head */
return isnt_c90 + is_cxx;
}

int main(void)
{
printf("%d\n", test_version());
/* gcc -std=c89: 0 */
/* gcc -std=c99: 1 */
/* g++: 2 */
return 0;
}

Now, what silly mistakes have I made *this* time? :-)

-Arthur

[Chris Torek]

In article <Pi***********************************@unix47.andr ew.cmu.edu>
Arthur J. O'Dwyer <aj*@nospam.andrew.cmu.edu> writes, in part:

int is_cxx = (sizeof('x') == 1); /* not completely guaranteed
* to work, but the best I know
* off the top of my head */

As you note, this can falsely claim "is C++" if sizeof(int)==1.

A test that does not have this failing -- that *is* guaranteed
to distinguish between C and C++ -- is one that relies on the
differing scope rules. Here is a complete test program.

#include <stdio.h>

struct A { char c; };

int is_cplusplus(void) {
struct B { struct A { char c[2]; } b; };
struct A x;

return sizeof x.c == 1;
}

int main(void) {
printf("this was compiled with a %s compiler\n",
is_cplusplus() ? "C++" : "C");
return 0;
}

The trick is that the name "struct A" refers to the *inner* "struct
A" in C, but to the global (outer) "struct A" in C++. (In C++-ese,
x is defined as ::A instead of ::B::A. Thus in C++ x.c is a single
"char", while in C++ x.c is an array of two "char"s.)

This particular difference between the two languages can turn a
correct C program -- one that writes into both bytes of x.c[] --
into an incorrect C++ program when compiled with a C++ compiler.
Thus, even putting aside the obvious syntactic incompatibilities
between the two languages, I claim it is dangerous to compile C
code with a C++ compiler. You might overrun arrays, as this
program could do if it assumed it was compiled with a C compiler
(if is_cplusplus() were to write on x.c[1]).
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://67.40.109.61/torek/index.html (for the moment)
Reading email is like searching for food in the garbage, thanks to spammers.

[Mark Gordon]

On Wed, 15 Oct 2003 22:17:35 +0200
"cody" <do*********************@gmx.de> wrote:

Please don't trim the attributions since it prevents people from seeing
who said what.

int test(int size)
{
int *new = malloc(size); /* two non-C++isms in this line */
return 1 //*
-1 + 1; /* 0 in C99, 1 in C++ */
}

is the missing semicolon at the end of a block allowed in C?

A semicolon is required to terminate every C statement, however in C99
there is no missing semicolon in the above.

HINT: C99 added a form of // commenting.

<snip>
--
Mark Gordon
Paid to be a Geek & a Senior Software Developer
Although my email address says spamtrap, it is real and I read it.

[Richard Heathfield]

Arthur J. O'Dwyer wrote:

<snip>

I completely forgot
about // comments' being legal C99. But your code still has a
bug; under C90, the /**/ comments disappear to create

int foo = 1/;

don't they? So I guess after fixing that, we could throw in a
sizeof('x') for good measure. [ACTUAL TESTED CODE FOLLOWS(!)]

"ACTUAL TESTED CODE"? Isn't that cheating?

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

[Fergus Henderson]

Jerry Feldman <ga********@blu.org> writes:

Keith Thompson <ks*@cts.com> wrote:

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.
I agree that "C++ has never been a strict superset of any version of C",
but I disagree with your logic. A superset can define new keywords (and
comment operators).

A strict superset can't, if those keywords have names which are not
already reserved for use by the implementation, because adding new
keywords will invalidate existing C programs that happen to use those
keywords as identifiers.

Adding new comment operators can also change the meaning of existing code.
Consider the following program:

int main() {
printf(1//**/2
? "fail\n" : "pass\n");
return 0;
}

On a conforming C89 implementation, this will print "pass",
but on a C++ or C99 implementation, it will print "fail".
However there are many constructs in standard C that
are illegal in C++. One example that comes to mine is:
In C:
void foo(void);
In C++ this will cause a syntax error because C++ requires fully
prototyped functions.

That's not correct either. C++ allows "void foo(void);".

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

[Francis Glassborow]

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

Francis, AFAIK you have absolutely no knowledge of the 8051 other than
what I have told you in various ACCU and BSI meetings.... and that has
been very superficial. It would be best if you did not use it as an
example.

It would also be nice if you avoided assuming that you are my only
source of information.

However one factor often missed is that these days we often use
micro-processors to do things that are note remotely related to a
traditional view of their uses. The growth of digital sound and vision
systems is largely driven by the ability to bring computing power to
tasks that thirty years ago would have been considered as completely
outside the domain of computing.

One interesting point is that in times gone by much effort was put into
developing analogue computing technology in order to improve data
throughput where some loss of quality was acceptable. These days we
develop digital systems with the same motive:-)

I suspect that LSI has changed the world in ways that neither of us
could have imagined in our youth and that most people do not have the
slightest grasp of the extent to which modern technology relies on
computing technology.
--
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

[cody]

"Sven Semmler" <sv*********@semmlerconsulting.com> schrieb im Newsbeitrag
news:cl****************@plethora.net...

cody wrote:

sorry i don't know the term "dead on". what does it mean?

http://dict.leo.org/?search=dead+on

/Sven ;)

thankx

--
cody

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

[Keith Derriick]

Chris Hills <ch***@phaedsys.org> wrote in message news:<cl****************@plethora.net>...

Being power hungry is not the reason why an 8051 does not (normally) run
at 2Ghz.... Many 8051's work in areas where power is not a factor. They
run code from 2Kbytes to 16Mega bytes.

Yes, the usual reasons for slower clock speeds are (in my business):
- Slower rated chips are cheaper
- You don't usually need that speed
- Heat dissipation becomes a problem at high speeds
There are also many 32 and 64 bit embedded systems running that have
megabytes of code.... virtually any car radio or engine management
system. I did have the figures for the line of code in a car radio. It
was in the 100's of thousand lines! It surprised me. Engine management
systems have the odd megabyte of code.

and when things are programmed in assembler, an 8K processor can still
hold 6-8 KLOC!.

Keith Derrick (ACCU member)
PS Don't bother sending mail to my posting address, it's a spam trap.
--
comp.lang.c.moderated - moderation address: cl**@plethora.net

[j]

"Fergus Henderson" <fj*@cs.mu.oz.au> wrote in message
news:cl****************@plethora.net...

Jerry Feldman <ga********@blu.org> writes:

Keith Thompson <ks*@cts.com> wrote:

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.
I agree that "C++ has never been a strict superset of any version of C",
but I disagree with your logic. A superset can define new keywords (and
comment operators).

A strict superset can't, if those keywords have names which are not
already reserved for use by the implementation, because adding new
keywords will invalidate existing C programs that happen to use those
keywords as identifiers.

I don't know why people mold terms to fit things how they would like to see
them.
C++ is not a superset, period. ``strict superset'' throw it out of the
window.
When something is a ``superset'' of something else, that something else is
considered to be a ``subset''.
Now inorder for C to be a subset of C++, you would be able to compile _any_
C program with a C++ compiler. This can't be done, because C is not a subset
of C++, and that is because C++ is not a superset of C. It is a
``derivative'' of C. Nothing more and nothing less.
Adding new comment operators can also change the meaning of existing code.
Consider the following program:

int main() {
printf(1//**/2
? "fail\n" : "pass\n");
return 0;
}

On a conforming C89 implementation, this will print "pass",
but on a C++ or C99 implementation, it will print "fail".

However there are many constructs in standard C that
are illegal in C++. One example that comes to mine is:
In C:
void foo(void);
In C++ this will cause a syntax error because C++ requires fully
prototyped functions.
That's not correct either. C++ allows "void foo(void);".

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

[Brian Inglis]

On Mon, 13 Oct 2003 22:18:56 +0200 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()".

I take exception to the object of that last block! ;^>
In idiomatic C, each function is like a try block, each return is
like a throw, and each call is like a catch.

Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Br**********@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply

[Brian Inglis]

On Wed, 15 Oct 2003 00:21:21 +0200 in comp.std.c, "cody"
<do*********************@gmx.de> wrote:

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

Was is the same in other versions of C besides C99?

As far back as K&R1 -- common C idiom was 'ab' (16 bit) or 'abcd'
(32 bit) to handle packed chars -- undefined behaviour as of C89
-- but still allowed and works?

Thanks. Take care, Brian Inglis Calgary, Alberta, Canada
--
Br**********@CSi.com (Brian dot Inglis at SystematicSw dot ab dot ca)
fake address use address above to reply

[Jirka Klaue]

Arthur J. O'Dwyer wrote:

[C89/C99/C++ tests]

Now, what silly mistakes have I made *this* time? :-)

Failure to use the standard macros? ;-)

#include "stdio.h"
int main(void)
{
int
#ifdef __cplusplus
i = 2;
#elif defined __STDC_VERSION__ && __STDC_VERSION__ == 199901L
i = 1;
#else
i = 0;
#endif
puts(i == 2 ? "C++" : i == 1 ? "C99" : "C89");
return 0;
}

Jirka

[Jeremy Yallop]

Jirka Klaue wrote:

#include "stdio.h"
int main(void)
{
int
#ifdef __cplusplus
i = 2;
#elif defined __STDC_VERSION__ && __STDC_VERSION__ == 199901L
i = 1;
#else
i = 0;
#endif
puts(i == 2 ? "C++" : i == 1 ? "C99" : "C89");
return 0;
}

A C89 implementation is allowed to define a __cplusplus macro, AFAICT.
(You also classify C0X as C89).

Jeremy.

[Dave Hansen]

On Wed, 15 Oct 2003 23:42:23 +0000 (UTC), Richard Heathfield
<do******@address.co.uk.invalid> wrote:

cody wrote: [...]

This seems to be true for both C and C++ compilers (I tried both).

It really is time to stop guessing at this stuff. The C language is defined
by an international standard, not by your apparently random guesses.

"It works on my compiler" is never a good argument in c.s.c.

Regards,

-=Dave
--
Change is inevitable, progress is not.

[cody]

"Mark Gordon" <sp******@flash-gordon.me.uk> schrieb im Newsbeitrag
news:20031015232209.128f9a60.sp******@flash-gordon.me.uk...

On Wed, 15 Oct 2003 22:17:35 +0200
"cody" <do*********************@gmx.de> wrote:

Please don't trim the attributions since it prevents people from seeing
who said what.

int test(int size)
{
int *new = malloc(size); /* two non-C++isms in this line */
return 1 //*
-1 + 1; /* 0 in C99, 1 in C++ */
}

is the missing semicolon at the end of a block allowed in C?

A semicolon is required to terminate every C statement, however in C99
there is no missing semicolon in the above.

HINT: C99 added a form of // commenting.

int test(int size)
{
int *new = malloc(size); /* two non-C++isms in this line */

return 1 //* <-- the c version misses a semicolon here,
additionally //* will imho produce no valid comment in c.

-1 + 1; /* 0 in C99, 1 in C++ */
}

--
cody

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

[cody]

> > int i = sizeof (int);

// int j = sizeof int; // invalid in both C and C++
int k = sizeof i;
int l = sizeof (i);

The form of sizeof that gets a type as parameter has to use parantheses,
while the sizeof that gets non-expressions as parameter do not need

them.
Wrong. In your example, i is an unary-expression, not a non-expression.

I don't know why i wrote non-expression. My example clearly showed how to
use sizeof:

The form of sizeof that gets a type (NON-EXPRESSION) as parameter has to use
parantheses,
while the sizeof that gets expressions (NON-TYPES) as parameter do not need
them.

Is it now correctly stated?

--
cody

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

[cody]

"Richard Heathfield" <do******@address.co.uk.invalid> schrieb im Newsbeitrag
news:bm**********@titan.btinternet.com...

Douglas A. Gwyn wrote:

cody wrote:

The problem is that i believe that my assertions are correct.

Yes, that is a problem.

I hope the sig-monsters are awake.

What is a sig-monster?

--
cody

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