49  2700  aa*****@gmail.com wrote:
Hi all,
See:- http://www.cs.princeton.edu/introcs/faq/c2java.html
Nice list, I would however mention a few things that go through my mind
while going through the list. Comments appreciated.
1) integer types / floating point types / character type
I would specify the minimum requested by the standard, instead of the
"usual" size, where "usual" probably means on x86 systems.
2) boolean type
I guess the page refers to C89, right?
3) array declarations
Malloc is just /*one*/ option to define arrays.
Another option is to defines them as fixed length, or as VLAs in C99.
4) memory allocation of data structures and arrays
why not just write "implementation defined"?
5) variable auto-initialization
"not guaranteed" is definitely wrong and misleading. E.g., global and
static variables /*are*/ initialized. Automatic variable aren't. This
difference in treating objects with different linkage and storage
duration doesn't make initialization "not guaranteed".
6) casting
"anything goes"? Some casting errors are detected at compile time.
7) variable declaration
see 2)
Pietro Cerutti
>
See:- http://www.cs.princeton.edu/introcs/faq/c2java.html
Hmm, I wonder what the intention of the editors of this could be.
c2java.html ... to convert c programs to java? or C programmers to
Java programmers?
The list indeed seem to refer to C89, and a comparison of Java to C99
would differ in many points. What struck me most was the comparison
of conventions. That's not a language feature. The list also suggests
as gcc was the standard compiler (although on many systems it is,
indeed),
still, comparing the gcc interface to the javac interface is hardly
due to
the differences of between two languages.
After reading the list, I still could not
get the main differences that I believed to be most important (mostly
following
from the different levels of support for object orientated
programming.)
To say something positive, the list nicely reflects that C and Java
have been
designed for mostly disjoint audiences, (But this makes me suspicious
about
a title like c2java), and based on the list one can make decisions
which
to learn or use for a specific purpose, even though the list is biased
towards
Java.
Could be that all criticism is undue, since the target audience for
which
this list has been compiled for is unknown to me.
Szabolcs aa*****@gmail.com said:
Hi all,
See:- http://www.cs.princeton.edu/introcs/faq/c2java.html
The first obvious error is the confusion of implementations with the
language proper, in the "compilation" row. This error occurs again in each
of the following three rows.
Minor nit: the "hello, world" row doesn't show a "hello, world" program in
either C or Java.
The "integer types" row omits char, short, and unsigned types.
The "floating point types" row omits long double.
The "for loops" row doesn't demonstrate the full power of the for loop.
The "array declarations" row doesn't show how to declare an array. Instead,
it shows how to allocate memory for N objects. (Curiously, the author not
only gets the allocation right, but almost gets it *canonically* right.)
The "array size" row says that arrays don't know their own length, but in
fact it is trivially calculable from sizeof arr / sizeof arr[0].
The "strings" row incorrectly says that a string is a '\0'-terminated
character array. Consider: char foo[8] = "u\0v\0w\0xy"; this contains not
one string but six, and none of them is an array. Furthermore, the array
itself is not '\0'-terminated. It is 'y'-terminated!
The "accessing a library" row does not demonstrate how to access a library.
It demonstrates how to include a header.
The "accessing a library function" row shows two code fragments that cannot
coincide as if they did coincide, and makes a claim about the "global"
nature of function and variable names without making it clear what they
mean by "global". Whether "variables" are "global" depends not only on
what you mean by "global" and what you mean by "variable" but also on
whether the "variables" are auto-qualified (and remember that, within a
function, auto qualification is the /default/). If the author is referring
solely to functions and variables that are (a) contained in a library and
(b) visible to the caller - and this seems like a reasonable deduction -
then he ought to make this explicit.
The "printing to standard output" row shows example code that writes to a
stream that is line-buffered by default, without either terminating the
line or flushing the stream.
The "formatted printing" row is interesting insofar as it basically says
"look what Java stole from C".
The "reading from stdin" row shows broken example code, which fails to
check the result of the read.
The "memory address" row doesn't make it clear how a reference differs from
a pointer. It seems to me that a reference /is/ a pointer. A rose by any
other name, and all that.
The "pass-by-value" row suggests that non-primitive non-struct non-pointer
data types (e.g. unions) might /not/ be passed by value, whereas of course
the truth is that, in C, *everything* is passed by value.
Minor nit: the "accessing a data structure" row uses the term "numerator",
which seems rather strange in the context, as nothing is being numerated.
The "allocating memory" row focuses on malloc, ignoring not only calloc and
realloc but also static declaration syntax.
The "memory allocation of data structures and arrays" row confuses the
language with an implementation.
The "buffer overflow" row seems to suggest that crashing with a run-time
error exception is somehow preferable to crashing with a segfault, but it
isn't made clear why this is preferable.
The "declaring constants" row suggests that #define constitutes a
declaration, which it doesn't.
The "variable auto-initialization" row suggests, as someone has pointed out
elsethread, that C doesn't make any initialisation guarantees at all,
whereas static, external, and partially-initialised aggregate objects all
have well-defined and guaranteed initialisation rules.
The "casting" row says "anything goes", which is simply wrong.
The "polymorphism" row contains a spelling error. Now, I know it's a bit
infra dignitatis to point out spelling errors, but this one is a
misspelling of "inheritance" as "inheritence", which suggests either that
the author hasn't read a great deal about OOP or that he doesn't have a
very retentive memory. Neither of these possibilities is very reassuring.
Minor nit: the "overloading" row overlooks C's admittedly minor examples of
overloading, on operators such as +, ++, *, and so on.
The "variable declaration" row overlooks the fact that names declared at
file scope are not even /in/ a block, let alone at the start of one.
The "variable naming conventions" row is simply wrong. There are as many
conventions as there are programmers. No single convention is mandated by
the C language spec, implementations, or anything of the kind. (Project
managers, now - that's a different story. If only they could all agree on
one convention...)
The "file naming conventions" row confuses the language with the
implementation and even the file system!
The "callbacks" row suggests that "non-global" functions can't be used as
callbacks. Of course, static functions are a counter-example.
The "variable number of arguments" row mentions "varargs" under the C
column, but I have no idea why. The C Standard doesn't even mention this
term, and it is effectively meaningless without definition.
The "exit and return value to OS" row provides a very poor-style exit call
(value has no portable semantics), and fails to mention returning from
main.
If one is to attack a language, one had better start by learning it.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard Heathfield <rj*@see.sig.invalidwrites:
>aa*****@gmail.com said:
>See:- http://www.cs.princeton.edu/introcs/faq/c2java.html
[snip]
>If one is to attack a language, one had better start by learning it.
I didn't see any attempt to attack either language;
I saw an attempt to summarize differences at a level suitable for
undergraduate students.
--
Chris.
Chris McDonald said:
Richard Heathfield <rj*@see.sig.invalidwrites:
>>aa*****@gmail.com said:
>>See:- http://www.cs.princeton.edu/introcs/faq/c2java.html
[snip]
>>If one is to attack a language, one had better start by learning it.
I didn't see any attempt to attack either language;
The biggest clue, for me, was in this row:
graphics | use external libraries | Java library support, use our
| standard drawing library
The "our" suggested partisanship.
I saw an attempt to summarize differences at a level suitable for
undergraduate students.
Surely even undergraduate students deserve *accurate* information?
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Richard Heathfield <rj*@see.sig.invalidwrites:
>Chris McDonald said:
>Richard Heathfield <rj*@see.sig.invalidwrites:
>>>aa*****@gmail.com said:
>>>See:- http://www.cs.princeton.edu/introcs/faq/c2java.html
[snip]
>>>If one is to attack a language, one had better start by learning it.
I didn't see any attempt to attack either language;
>The biggest clue, for me, was in this row:
>graphics | use external libraries | Java library support, use our
| standard drawing library
>The "our" suggested partisanship.
Wow! you must live in, or seek, a very confrontational world if you
read partisanship for one as an attack on the "other".
Surely it's clear that a standard drawing library is/was provided for
Java, but no equivalent *provided* for C.
That's far from an attack.
>I saw an attempt to summarize differences at a level suitable for
undergraduate students.
>Surely even undergraduate students deserve *accurate* information?
Agreed.
--
Chris.
In article <HO******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
[lots of complaints]
Many of your supposed errors are a result of interpreting words as if
they meant what the C standard means by them. Obviously when comparing
languages you have to use words in a more general sense.
For example, when it says that you declare constants using #define,
this is perfectly true if you interpret it as "how do you accomplish
in C the task that would typically be described as declaring a
constant". The fact that you can't do this with a real C declaration
is a deficiency of C, not of the comparison.
-- Richard
--
:wq
Richard Tobin said:
In article <HO******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
[lots of complaints]
Many of your supposed errors are a result of interpreting words as if
they meant what the C standard means by them.
Right. This is, after all, comp.lang.c, yes?
Obviously when comparing
languages you have to use words in a more general sense.
In which case you also have to move the discussion to a group where those
words won't be misinterpreted as having a more specific sense - i.e. not
comp.lang.c. My review was based on the theme of the newsgroup in which
the URL was posted.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
In article <hO******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>Obviously when comparing
languages you have to use words in a more general sense.
>In which case you also have to move the discussion to a group where those
words won't be misinterpreted as having a more specific sense - i.e. not
comp.lang.c. My review was based on the theme of the newsgroup in which
the URL was posted.
Frankly, that's just silly. If every newsgroup insists on pretending
things are in their own idiosyncratic terminology, even when they're
obviously not, how can we possibly have conversations? Do we have to
create a newsgroup for every possible combination of topics? Surely
it makes perfect sense to draw the attention of people in comp.lang.c
to a comparison of Java and C.
And it's disingenuous of you to suggest that the document will be
misinterpreted in comp.lang.c. It will only be misinterpreted by a
very few comp.lang.c readers, and they will be doing it deliberately.
-- Richard
--
:wq
Richard Tobin said:
In article <hO******************************@bt.com>,
Richard Heathfield <rj*@see.sig.invalidwrote:
>>Obviously when comparing
languages you have to use words in a more general sense.
>>In which case you also have to move the discussion to a group where those
words won't be misinterpreted as having a more specific sense - i.e. not
comp.lang.c. My review was based on the theme of the newsgroup in which
the URL was posted.
Frankly, that's just silly.
Frankly, then, we disagree, and it appears that we disagree in a way that
is unlikely to be resolved. Such is life.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
On May 14, 9:54*am, Richard Heathfield <r...@see.sig.invalidwrote:
aark...@gmail.com said:
Hi all,
See:- * * * * * *http://www.cs.princeton.edu/introcs/faq/c2java.html
The first obvious error is the confusion of implementations with the
language proper, in the "compilation" row. This error occurs again in each
of the following three rows.
Minor nit: the "hello, world" row doesn't show a "hello, world" program in
either C or Java.
The "integer types" row omits char, short, and unsigned types.
The "floating point types" row omits long double.
The "for loops" row doesn't demonstrate the full power of the for loop.
The "array declarations" row doesn't show how to declare an array. Instead,
it shows how to allocate memory for N objects. (Curiously, the author not
only gets the allocation right, but almost gets it *canonically* right.)
The "array size" row says that arrays don't know their own length, but in
fact it is trivially calculable from sizeof arr / sizeof arr[0].
The "strings" row incorrectly says that a string is a '\0'-terminated
character array. Consider: char foo[8] = "u\0v\0w\0xy"; this contains not
one string but six, and none of them is an array. Furthermore, the array
itself is not '\0'-terminated. It is 'y'-terminated!
The "accessing a library" row does not demonstrate how to access a library..
It demonstrates how to include a header.
The "accessing a library function" row shows two code fragments that cannot
coincide as if they did coincide, and makes a claim about the "global"
nature of function and variable names without making it clear what they
mean by "global". Whether "variables" are "global" depends not only on
what you mean by "global" and what you mean by "variable" but also on
whether the "variables" are auto-qualified (and remember that, within a
function, auto qualification is the /default/). If the author is referring
solely to functions and variables that are (a) contained in a library and
(b) visible to the caller - and this seems like a reasonable deduction -
then he ought to make this explicit.
The "printing to standard output" row shows example code that writes to a
stream that is line-buffered by default, without either terminating the
line or flushing the stream.
The "formatted printing" row is interesting insofar as it basically says
"look what Java stole from C".
The "reading from stdin" row shows broken example code, which fails to
check the result of the read.
The "memory address" row doesn't make it clear how a reference differs from
a pointer. It seems to me that a reference /is/ a pointer. A rose by any
other name, and all that.
The "pass-by-value" row suggests that non-primitive non-struct non-pointer
data types (e.g. unions) might /not/ be passed by value, whereas of course
the truth is that, in C, *everything* is passed by value.
Minor nit: the "accessing a data structure" row uses the term "numerator",
which seems rather strange in the context, as nothing is being numerated.
The "allocating memory" row focuses on malloc, ignoring not only calloc and
realloc but also static declaration syntax.
The "memory allocation of data structures and arrays" row confuses the
language with an implementation.
The "buffer overflow" row seems to suggest that crashing with a run-time
error exception is somehow preferable to crashing with a segfault, but it
isn't made clear why this is preferable.
The "declaring constants" row suggests that #define constitutes a
declaration, which it doesn't.
The "variable auto-initialization" row suggests, as someone has pointed out
elsethread, that C doesn't make any initialisation guarantees at all,
whereas static, external, and partially-initialised aggregate objects all
have well-defined and guaranteed initialisation rules.
The "casting" row says "anything goes", which is simply wrong.
The "polymorphism" row contains a spelling error. Now, I know it's a bit
infra dignitatis to point out spelling errors, but this one is a
misspelling of "inheritance" as "inheritence", which suggests either that
the author hasn't read a great deal about OOP or that he doesn't have a
very retentive memory. Neither of these possibilities is very reassuring.
Minor nit: the "overloading" row overlooks C's admittedly minor examples of
overloading, on operators such as +, ++, *, and so on.
The "variable declaration" row overlooks the fact that names declared at
file scope are not even /in/ a block, let alone at the start of one.
The "variable naming conventions" row is simply wrong. There are as many
conventions as there are programmers. No single convention is mandated by
the C language spec, implementations, or anything of the kind. (Project
managers, now - that's a different story. If only they could all agree on
one convention...)
The "file naming conventions" row confuses the language with the
implementation and even the file system!
The "callbacks" row suggests that "non-global" functions can't be used as
callbacks. Of course, static functions are a counter-example.
The "variable number of arguments" row mentions "varargs" under the C
column, but I have no idea why. The C Standard doesn't even mention this
term, and it is effectively meaningless without definition.
The "exit and return value to OS" row provides a very poor-style exit call
(value has no portable semantics), and fails to mention returning from
main.
If one is to attack a language, one had better start by learning it.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
On May 14, 9:54*am, Richard Heathfield <r...@see.sig.invalidwrote:
aark...@gmail.com said:
Hi all,
See:- * * * * * *http://www.cs.princeton.edu/introcs/faq/c2java.html
The "array size" row says that arrays don't know their own length, but in
fact it is trivially calculable from sizeof arr / sizeof arr[0].
I think it had dynamic arrays in mind. In that case the language
doesn't itself store the array size.
(In C it's not trivial to get the size of even an ordinary array,
despite your comment; imagine arr had a considerably longer name.
What /would/ have been trivial, but out of character for C, was
a .length property for such arrays.)
All in all this seems a good at-a-glance guide to the two languages,
even if had to simplify many things. Perhaps a reference to a more
detailed guide to C and Java could have been added.
[Apologies for the other post; google said "your post was successful",
even though I clicked no buttons; honest!]
--
Bartc
Richard Tobin wrote:
For example, when it says that you declare constants using #define,
this is perfectly true if you interpret it as "how do you accomplish
in C the task that would typically be described as declaring a
constant".
I guess if the question had been "create a constant", the answers could
be comparable.
The fact that you can't do this with a real C declaration
is a deficiency of C, not of the comparison.
Is it? why?
--
Mark McIntyre
CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Chris McDonald wrote:
Richard Heathfield <rj*@see.sig.invalidwrites:
>aa*****@gmail.com said:
>>See:- http://www.cs.princeton.edu/introcs/faq/c2java.html
[snip]
>If one is to attack a language, one had better start by learning it.
I didn't see any attempt to attack either language;
Come now; there were any number of statements which strongly implied the
writer preferred java and was listing what he felt were C's deficiencies.
I saw an attempt to summarize differences at a level suitable for
undergraduate students.
People attempting to do this without prejudice would
- not have stated unequivocally that Java code is portable without
discipline, instead they'd have noted that to make Java portable you
need to show the same discipline as for C - vis to stick to the standard
libraries you can guarantee to have present.
- have noted that C /code/ is portable, subject to the above.
- have noted that using a class library in Java requires it to be
installed on the host, breaking portability in its strictest sense.
- not have implied that java won't lose precision when demoting types
(of course it will - you can't take a 32-bit value and stuff it into 16
bits without losing /something/ ).
- have known both langages well enough not to have made a number of
glaring errors; or at least got a C expert to review it before publication.
--
Mark McIntyre
CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Mark McIntyre wrote:
Richard Tobin wrote:
>For example, when it says that you declare constants using #define,
this is perfectly true if you interpret it as "how do you accomplish
in C the task that would typically be described as declaring a
constant".
I guess if the question had been "create a constant", the answers could
be comparable.
>The fact that you can't do this with a real C declaration
is a deficiency of C, not of the comparison.
Is it? why?
Because there's absolutely no practical reason why an integer constant
can't be a compile time constant.
--
Ian Collins.
Mark McIntyre <ma**********@spamcop.netwrites:
>Chris McDonald wrote:
>Richard Heathfield <rj*@see.sig.invalidwrites:
>>aa*****@gmail.com said:
>>>See:- http://www.cs.princeton.edu/introcs/faq/c2java.html
[snip]
>>If one is to attack a language, one had better start by learning it.
I didn't see any attempt to attack either language;
>Come now; there were any number of statements which strongly implied the
writer preferred java and was listing what he felt were C's deficiencies.
>I saw an attempt to summarize differences at a level suitable for
undergraduate students.
>People attempting to do this without prejudice would
[list of 6 items snipped]
The statements (more likely) could have easily been made in ignorance
or a vacuum of knowledge; that's certainly an error, but it still does
not make the document an attack on either language.
Why do many posters in c.l.c take a confrontational stance?
The original document was intending to help undergraduates, and the
OP probably thought it a document in which readers of c.l.c would be
interested. The background facts may have been wrong, but the intentions
were genuine.
--
Chris.
Ian Collins wrote:
Mark McIntyre wrote:
>Richard Tobin wrote:
>>The fact that you can't do this with a real C declaration
is a deficiency of C, not of the comparison.
Is it? why?
Because there's absolutely no practical reason why an integer constant
can't be a compile time constant.
Absolutely no practical reason (you can think of) on today's hardware,
you mean.
And why is that a deficiency?
--
Mark McIntyre
CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Chris McDonald wrote:
>
The statements (more likely) could have easily been made in ignorance
or a vacuum of knowledge; that's certainly an error, but it still does
not make the document an attack on either language.
*shrug*.
It need not have, but the language is (in my opinion) just pejorative
enough and the ignorance just annoying enough to be read as such by
anyone familiar with either language as such.
Why do many posters in c.l.c take a confrontational stance?
Perhaps its because so many newbies post "help me now, dammit, I'm in a
hurry" type postings.
The original document was intending to help undergraduates,
And in my opinion, would not achieve that because of the lack of C
knowledge that was displayed.
If I wanted to help students understand the difference between German
and English grammar, I wouldn't do it from a position of relative
ignorance of German grammar.
and the
OP probably thought it a document in which readers of c.l.c would be
interested.
It is, as this thread has demonstrated. Personally I think this thread
has been *GOOD* - if the writer of the webpage has been reading they;ll
have learned something, and better yet, many of its target market will
be able to review the google archives to see this debate.
The background facts may have been wrong, but the intentions
were genuine.
As were Richards. Perhaps you missed that point in your haste to complain.
--
Mark McIntyre
CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Mark McIntyre <ma**********@spamcop.netwrites:
>Chris McDonald wrote:
>The background facts may have been wrong, but the intentions
were genuine.
>As were Richards. Perhaps you missed that point in your haste to complain.
Whoa! Nice try to get the last word, but you'll find that I haven't
complained, only asked questions and stated my opinion. Richard seems to
"read in" attacks, and now you're reading in complaints.
--
Chris.
Mark McIntyre wrote:
Ian Collins wrote:
>Mark McIntyre wrote:
>>Richard Tobin wrote:
The fact that you can't do this with a real C declaration
is a deficiency of C, not of the comparison.
Is it? why?
Because there's absolutely no practical reason why an integer constant
can't be a compile time constant.
Absolutely no practical reason (you can think of) on today's hardware,
you mean.
And why is that a deficiency?
Because we have to use hacks like enums and worse still (spit) macros
for compile time constants.
--
Ian Collins.
Chris McDonald wrote:
Mark McIntyre <ma**********@spamcop.netwrites:
>Chris McDonald wrote:
>>The background facts may have been wrong, but the intentions
were genuine.
>As were Richards. Perhaps you missed that point in your haste to complain.
Whoa! Nice try to get the last word,
You can have that.
but you'll find that I haven't complained,
Other than the point where you complained about Richard reading attacks
into stuff that you didn't think contained any.
--
Mark McIntyre
CLC FAQ <http://c-faq.com/>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Mark McIntyre <ma**********@spamcop.netwrites:
>Chris McDonald wrote:
>Mark McIntyre <ma**********@spamcop.netwrites:
>>Chris McDonald wrote:
>>>The background facts may have been wrong, but the intentions
were genuine.
>>As were Richards. Perhaps you missed that point in your haste to complain.
Whoa! Nice try to get the last word,
>You can have that.
>but you'll find that I haven't complained,
>Other than the point where you complained about Richard reading attacks
into stuff that you didn't think contained any.
OK; you win, you've made it tiresome by twisting words.
--
Chris.
Chris McDonald wrote:
>
.... snip ...
>
Why do many posters in c.l.c take a confrontational stance? The
original document was intending to help undergraduates, and the
OP probably thought it a document in which readers of c.l.c
would be interested. The background facts may have been wrong,
but the intentions were genuine.
Generally because we like to see all questions answered correctly,
or that a suitable correction appears in the thread. This is also
the reason for objecting viciously to off-topic queries, and, even
worse, answers to those off-topic queries that do not just redirect
the asker. The confrontation usually is later, when the
originators insist their OT words are not.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
Ian Collins wrote:
Mark McIntyre wrote:
>Ian Collins wrote:
>>Mark McIntyre wrote:
Richard Tobin wrote:
The fact that you can't do this with a real C declaration
is a deficiency of C, not of the comparison.
Is it? why?
Because there's absolutely no practical reason why an integer
constant can't be a compile time constant.
Absolutely no practical reason (you can think of) on today's
hardware, you mean. And why is that a deficiency?
Because we have to use hacks like enums and worse still (spit)
macros for compile time constants.
Well, I see no law insisting you use C. You are quite free to pick
a language that works the way you think it should. Maybe Modula
will fit you better? Also Ada has recently been updated.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
On Wed, 14 May 2008 08:54:29 +0000, Richard Heathfield wrote: aa*****@gmail.com said:
(...)
>>
See:- http://www.cs.princeton.edu/introcs/faq/c2java.html
(...)
>
The "array declarations" row doesn't show how to declare an array. Instead,
it shows how to allocate memory for N objects. (Curiously, the author not
only gets the allocation right, but almost gets it *canonically* right.)
Is the 'almost' because of sizeof(*a) as opposed to sizeof *a?
(...)
>
The "formatted printing" row is interesting insofar as it basically says
"look what Java stole from C".
And took its time to steal it as well. ;-) http://www.horstmann.com (scroll down past 'March of Progress').
>
The "pass-by-value" row suggests that non-primitive non-struct non-pointer
data types (e.g. unions) might /not/ be passed by value, whereas of course
the truth is that, in C, *everything* is passed by value.
I didn't see it that way. I think the author was trying to say
'everything but arrays' (especially considering the latter part of
that sentence, and what was said in the same row for Java).
<snip>
--
ROT-13 email address to reply
CBFalconer wrote:
Ian Collins wrote:
>Mark McIntyre wrote:
>>Ian Collins wrote:
Mark McIntyre wrote:
Richard Tobin wrote:
>
>The fact that you can't do this with a real C declaration
>is a deficiency of C, not of the comparison.
Is it? why?
Because there's absolutely no practical reason why an integer
constant can't be a compile time constant.
Absolutely no practical reason (you can think of) on today's
hardware, you mean. And why is that a deficiency?
Because we have to use hacks like enums and worse still (spit)
macros for compile time constants.
Well, I see no law insisting you use C. You are quite free to pick
a language that works the way you think it should. Maybe Modula
will fit you better? Also Ada has recently been updated.
What has that nonsense got to do with topic of this sub-thread? Does it
make the hacks less of a hack?
--
Ian Collins.
Anand Hariharan said:
On Wed, 14 May 2008 08:54:29 +0000, Richard Heathfield wrote:
<snip>
>
>(Curiously, the
author not only gets the allocation right, but almost gets it
*canonically* right.)
Is the 'almost' because of sizeof(*a) as opposed to sizeof *a?
Yep. (And yes, I can be a tough crowd.)
(...)
>>
The "formatted printing" row is interesting insofar as it basically says
"look what Java stole from C".
And took its time to steal it as well. ;-)
http://www.horstmann.com (scroll down past 'March of Progress').
<gQuite so.
>The "pass-by-value" row suggests that non-primitive non-struct
non-pointer data types (e.g. unions) might /not/ be passed by value,
whereas of course the truth is that, in C, *everything* is passed by
value.
I didn't see it that way. I think the author was trying to say
'everything but arrays' (especially considering the latter part of
that sentence, and what was said in the same row for Java).
If he was trying to say "arrays aren't passed by value", then he needs to
work on his wording, but he's trivially right, because arrays aren't
actually passed at all.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Ian Collins wrote:
CBFalconer wrote:
>Ian Collins wrote:
>>Mark McIntyre wrote:
Ian Collins wrote:
Mark McIntyre wrote:
>Richard Tobin wrote:
>>
>>The fact that you can't do this with a real C declaration
>>is a deficiency of C, not of the comparison.
>>
>Is it? why?
>
Because there's absolutely no practical reason why an integer
constant can't be a compile time constant.
Absolutely no practical reason (you can think of) on today's
hardware, you mean. And why is that a deficiency?
Because we have to use hacks like enums and worse still (spit)
macros for compile time constants.
Well, I see no law insisting you use C. You are quite free to
pick a language that works the way you think it should. Maybe
Modula will fit you better? Also Ada has recently been updated.
What has that nonsense got to do with topic of this sub-thread?
Does it make the hacks less of a hack?
You are the one moaning about the evil restrictions the C language
places on you. I just suggested a way for you to avoid them. You
don't have to take my suggestion, nor do you have to use C.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com **
On May 15, 1:42*pm, CBFalconer <cbfalco...@yahoo.comwrote:
Ian Collins wrote:
CBFalconer wrote:
Ian Collins wrote:
>Because we have to use hacks like enums and worse still (spit)
macros for compile time constants.
Well, I see no law insisting you use C. *You are quite free to
pick a language that works the way you think it should. *Maybe
Modula will fit you better? *Also Ada has recently been updated.
What has that nonsense got to do with topic of this sub-thread?
Does it make the hacks less of a hack?
You are the one moaning about the evil restrictions the C language
places on you. *I just suggested a way for you to avoid them. *You
don't have to take my suggestion, nor do you have to use C.
That's not a practical suggestion; any other choice will have it's own
set of problems.
And to give a (not very good) analogy, and imagining there is only one
make of car: if I complained that it didn't have electric windows,
your suggestion would be to take a bus?
C could have been tidied up in lots of little ways, but it's been
around so long it's dug itself into a hole in various areas.
But it is quite serviceable.
--
Bartc
CBFalconer wrote:
Ian Collins wrote:
>CBFalconer wrote:
>>Ian Collins wrote:
Mark McIntyre wrote:
Ian Collins wrote:
>Mark McIntyre wrote:
>>Richard Tobin wrote:
>>>
>>>The fact that you can't do this with a real C declaration
>>>is a deficiency of C, not of the comparison.
>>Is it? why?
>Because there's absolutely no practical reason why an integer
>constant can't be a compile time constant.
Absolutely no practical reason (you can think of) on today's
hardware, you mean. And why is that a deficiency?
Because we have to use hacks like enums and worse still (spit)
macros for compile time constants.
Well, I see no law insisting you use C. You are quite free to
pick a language that works the way you think it should. Maybe
Modula will fit you better? Also Ada has recently been updated.
What has that nonsense got to do with topic of this sub-thread?
Does it make the hacks less of a hack?
You are the one moaning about the evil restrictions the C language
places on you. I just suggested a way for you to avoid them. You
don't have to take my suggestion, nor do you have to use C.
I wasn't moaning, I was answering a question.
--
Ian Collins.
begin quoting Richard Heathfield <rj*@see.sig.invalid:
aa*****@gmail.com said:
Hi all,
See:- http://www.cs.princeton.edu/introcs/faq/c2java.html
[chop]
Nice list, BTW!
The "printing to standard output" row shows example code that writes to a
stream that is line-buffered by default, without either terminating the
line or flushing the stream.
Also not equivalent examples, as the Java side includes excess newlines.
The "formatted printing" row is interesting insofar as it basically says
"look what Java stole from C".
If you're going to steal ideas, why not steal the good ideas?
The "reading from stdin" row shows broken example code, which fails to
check the result of the read.
There is also no default StdIn class in Java; one uses System.in instead.
The "memory address" row doesn't make it clear how a reference differs from
a pointer. It seems to me that a reference /is/ a pointer. A rose by any
other name, and all that.
You can perform arithmetic on pointers, but not on (Java) references.
You can have a pointer to a pointer, but you can't have a reference
to a reference.
You can point a pointer at any (accessible) memory location, while
references refer only to objects on the heap.
The "pass-by-value" row suggests that non-primitive non-struct non-pointer
data types (e.g. unions) might /not/ be passed by value, whereas of course
the truth is that, in C, *everything* is passed by value.
Perhaps the authors thought that unions were a special case of structs?
Minor nit: the "accessing a data structure" row uses the term "numerator",
which seems rather strange in the context, as nothing is being numerated.
They seem to be using concrete examples needlessly. To run a java program,
one normally does not type "java Hello" at the command prompt, since only
a few Java programs are named "Hello".
[snip]
The "casting" row says "anything goes", which is simply wrong.
I wish to hear more on this; what can't you cast in C?
[snip]
If one is to attack a language, one had better start by learning it.
I am not terribly impressed with their grasp of either language, or their
habit of giving concrete examples without indicating which parts are the
general case and which the specific.
--
--Stewart St**********************************... ohan.sdsu.edu--
A person without a sense of humor is like a wagon without springs, jolted
by every pebble in the road. --Henry Ward Beecher st******@rohan.sdsu.edu said:
begin quoting Richard Heathfield <rj*@see.sig.invalid:
<snip>
>The "casting" row says "anything goes", which is simply wrong.
I wish to hear more on this; what can't you cast in C?
Well, for one thing, you can't cast structs or unions. (C99 muddies the
waters a little with compound literals, but the document was certainly
addressing C90, so I'll confine my answer to that.) But my rejection of
"anything goes" was really a rebuttal of the very popular idea that
casting is some kind of magic wand that can turn anything into anything
else. It isn't. A cast converts a value from one type to another type, but
makes no guarantees that the conversion makes sense. For example, you can
cast a long int into a pointer to struct tm if you want, but that doesn't
mean you'll get anything useful out of it. In fact, almost all casting in
C is wrong.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
In message <HO******************************@bt.com>, Richard Heathfield
<rj*@see.sig.invalidwrites
>aa*****@gmail.com said:
The "formatted printing" row is interesting insofar as it basically says
"look what Java stole from C".
And look at what C stole from B etc
If you look at a "tree" of computer language development new languages
are evolution of the previous ones. (And borrow from cousins twice
removed)
There is no "universal" best language. Much like spoken languages. C
has much in common with English in the fact it is the most widely used
(and misused). IT does not make either "the best" for any particular
situation. Both can be badly misused and still do what is needed. Even
if u wuld not usually writ it like that.
Now, life is just far short to waste on irrelevant things like C vs Java
when the Great questions of our day need answering:
Is Nikon Better than Cannon?
Is CD better than vinyl?
--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
begin quoting Richard Heathfield <rj*@see.sig.invalid:
st******@rohan.sdsu.edu said:
begin quoting Richard Heathfield <rj*@see.sig.invalid:
<snip>
The "casting" row says "anything goes", which is simply wrong.
I wish to hear more on this; what can't you cast in C?
Well, for one thing, you can't cast structs or unions. (C99 muddies the
waters a little with compound literals, but the document was certainly
addressing C90, so I'll confine my answer to that.)
/me tests
Hm... indeed. You have to abuse void * instead of casting to get that
sort of thing to happen.
But my rejection of
"anything goes" was really a rebuttal of the very popular idea that
casting is some kind of magic wand that can turn anything into anything
else. It isn't. A cast converts a value from one type to another type, but
makes no guarantees that the conversion makes sense. For example, you can
cast a long int into a pointer to struct tm if you want, but that doesn't
mean you'll get anything useful out of it. In fact, almost all casting in
C is wrong.
I've always thought of a cast as an instruction to the compiler to trust
the programmer about types in this instance; a sort of "No, really, I know
what I'm doing, I want to treat this object as THAT type, truly, trust me."
If actual conversion of data (as opposed to coercion of type) is involved,
yah, it's probably wrong.
--
--Stewart Stremler----------------------------...rohan.sdsu.edu--
If Alan Turing was alive today, the homosexuality would be OK
but he'd be in trouble for codebreaking. -- Martin Bacon st******@rohan.sdsu.edu writes:
begin quoting Richard Heathfield <rj*@see.sig.invalid:
>st******@rohan.sdsu.edu said:
begin quoting Richard Heathfield <rj*@see.sig.invalid:
<snip>
>The "casting" row says "anything goes", which is simply wrong.
I wish to hear more on this; what can't you cast in C?
Well, for one thing, you can't cast structs or unions. (C99 muddies the
waters a little with compound literals, but the document was certainly
addressing C90, so I'll confine my answer to that.)
/me tests
Hm... indeed. You have to abuse void * instead of casting to get that
sort of thing to happen.
But it's not quite the same thing. A cast applied to a struct, if it
were legal, might plausibly convert between two sufficiently similar
struct types by copying member values.
> But my rejection of
"anything goes" was really a rebuttal of the very popular idea that
casting is some kind of magic wand that can turn anything into anything
else. It isn't. A cast converts a value from one type to another type, but
makes no guarantees that the conversion makes sense. For example, you can
cast a long int into a pointer to struct tm if you want, but that doesn't
mean you'll get anything useful out of it. In fact, almost all casting in
C is wrong.
I've always thought of a cast as an instruction to the compiler to trust
the programmer about types in this instance; a sort of "No, really, I know
what I'm doing, I want to treat this object as THAT type, truly, trust me."
If actual conversion of data (as opposed to coercion of type) is involved,
yah, it's probably wrong.
A cast performs a value conversion; it doesn't (necessarily) treat an
object as being of a specified type. For example, ``(double)42''
yields the value 42.0 of type double.
Pointer conversions *typically* work by reinterpreting the
representation as the specified type, but that's not how the operation
is defined; on an implementation where different pointers have
different representations, an actual conversion will have to be
performed. And converting a pointer to an integer *of a different
size* will have to trim or pad bits, and might have to do more than
that.
Pointer conversion can be used to implement type-punning of the
pointed-to object, but the conversion itself doesn't do type-punning.
The point is that most of the cases where a conversion is portable can
be expressed as an implicit conversion rather than a cast. Taking
advantage of an implicit conversion lets the compiler figure out the
relevant types, rather than requiring the programmer to do so (and to
get it right with no help from the compiler).
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister" st******@rohan.sdsu.edu writes:
begin quoting Richard Heathfield <rj*@see.sig.invalid:
<snip>
>A cast converts a value from one type to another type, but
makes no guarantees that the conversion makes sense. For example, you can
cast a long int into a pointer to struct tm if you want, but that doesn't
mean you'll get anything useful out of it. In fact, almost all casting in
C is wrong.
I've always thought of a cast as an instruction to the compiler to trust
the programmer about types in this instance; a sort of "No, really, I know
what I'm doing, I want to treat this object as THAT type, truly,
trust me."
It is these uses that are usually wrong, either because the conversion
is not guaranteed (as in Richard's example) or because the cast is
redundant (as in the classic cast on a malloc call).
The real meaning of a (correct) cast is most often: "please convert
the value to one of this type because that is correct in this
situation and you (the compiler) will get it wrong otherwise". For
example:
printf("%d bytes at %p\n", (int)sizeof *ip, (void *)ip);
or
void process(const char *const *strings);
int main(int argc, char **argv)
{
process((const char **)(argv + 1)); /* add outer const */
return 0;
}
In the first case, the default conversions will be wrong, and in the
second the types are not compatible without a little help.
If actual conversion of data (as opposed to coercion of type) is involved,
yah, it's probably wrong.
I don't think that conversion of data makes it any more or less likely
to be right. Maybe I've missed your point. What were you think of?
--
Ben.
begin quoting Ben Bacarisse <be********@bsb.me.uk:
st******@rohan.sdsu.edu writes:
begin quoting Richard Heathfield <rj*@see.sig.invalid:
<snip>
A cast converts a value from one type to another type, but
makes no guarantees that the conversion makes sense. For example, you can
cast a long int into a pointer to struct tm if you want, but that doesn't
mean you'll get anything useful out of it. In fact, almost all casting in
C is wrong.
I've always thought of a cast as an instruction to the compiler to trust
the programmer about types in this instance; a sort of "No, really, I know
what I'm doing, I want to treat this object as THAT type, truly,
trust me."
It is these uses that are usually wrong, either because the conversion
is not guaranteed (as in Richard's example) or because the cast is
redundant (as in the classic cast on a malloc call).
I'm not comfortable considering redundant "wrong". Next you'll be
telling me that excessive parenthesis is "wrong" as well. "Wrong"
means that the resulting code does something other than what the
programmer (or reader of the code) expects.
The real meaning of a (correct) cast is most often: "please convert
the value to one of this type because that is correct in this
situation and you (the compiler) will get it wrong otherwise".
[snip]
>
If actual conversion of data (as opposed to coercion of type) is involved,
yah, it's probably wrong.
I don't think that conversion of data makes it any more or less likely
to be right. Maybe I've missed your point. What were you think of?
When I read "conversion of data", I think the bit-patterns have changed.
When I read "coercion of type", I think the bit-patterns remain exactly
the same, but that their interpretation changes.
Where am I going wrong?
--
--Stewart Stremler----------------------------...rohan.sdsu.edu--
Or did you simply have a sudden compulsion to add a pointless anecdote?
-- David P. Murphy (February 2003) st******@rohan.sdsu.edu said:
begin quoting Ben Bacarisse <be********@bsb.me.uk:
<snip>
>It is these uses that are usually wrong, either because the conversion
is not guaranteed (as in Richard's example) or because the cast is
redundant (as in the classic cast on a malloc call).
I'm not comfortable considering redundant "wrong". Next you'll be
telling me that excessive parenthesis is "wrong" as well.
Excessive parenthesis use is indeed wrong, yes. "Excessive" means "more
than is good".
"Wrong"
means that the resulting code does something other than what the
programmer (or reader of the code) expects.
No, "wrong" means "not right". There is no law against i = i++ doing
exactly what you expect (whatever that is), and it may well do just that -
but it's still wrong.
<snip>
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999 st******@rohan.sdsu.edu writes:
begin quoting Ben Bacarisse <be********@bsb.me.uk:
>st******@rohan.sdsu.edu writes:
<snip>
If actual conversion of data (as opposed to coercion of type) is involved,
yah, it's probably wrong.
I don't think that conversion of data makes it any more or less likely
to be right. Maybe I've missed your point. What were you think of?
When I read "conversion of data", I think the bit-patterns have changed.
When I read "coercion of type", I think the bit-patterns remain exactly
the same, but that their interpretation changes.
Where am I going wrong?
The two are linked and it can be misleading to equate value and "bit
pattern". I am not saying you are just warning that you can get lead
astray that way.
To take two examples, given 'double pi = 3.14;' (int)pi and pi are
different values, don't compare equal and, if the int is stored in an
int variable, the bit patters are different.
People often assume that pointer conversions are no-ops at the machine
level but on a word-addressed machine, the conversion of, say, an int
pointer to void * might generate code to shift the bits to the left.
The bit pattern is different and the two pointers can't be compared.
They will, of course, compare equal if one is again converted to the
type of the other but, the cast caused the data to change.
<aside>
I am not sure if the value has changed in this case. A week ago, I'd
have said no -- we have two different representations (with different
types) of the same value: a pointer to a particular int. That was
before I'd read the definition of "value" in the standard. For
reference it is:
"precise meaning of the contents of an object when interpreted as
having a specific type"
Given an int *ip, I don't think that is enough to say whether ip and
(void *)ip have the same value. Either the definition does not apply
(because (void *)ip is not an object) or, by allowing the natural
extension to expressions, we have to know what "specific type" is to
be used. The obvious one is the type of the object or expression and
by that interpretation no two expressions of different type can have
the same value. If that is what it means then a cast always changes
the value if it changes the type.
If someone has another interpretation that makes more sense I'll take
it!
</aside>
--
Ben. st******@rohan.sdsu.edu wrote:
When I read "conversion of data", I think the bit-patterns have changed.
The evaluation of these two expressions:
(0u == 0)
(UINT_MAX == -1)
requires conversions of the int type sub expressions to type unsigned.
But those signed int values may or may not have the same bit patterns
as the unsigned int values to which they compare equal.
--
pete
On Thu, 29 May 2008 18:25:25 +0000 (UTC), st******@rohan.sdsu.edu
wrote:
>begin quoting Ben Bacarisse <be********@bsb.me.uk:
>st******@rohan.sdsu.edu writes:
begin quoting Richard Heathfield <rj*@see.sig.invalid:
<snip>
>A cast converts a value from one type to another type, but
makes no guarantees that the conversion makes sense. For example, you can
cast a long int into a pointer to struct tm if you want, but that doesn't
mean you'll get anything useful out of it. In fact, almost all casting in
C is wrong.
I've always thought of a cast as an instruction to the compiler to trust
the programmer about types in this instance; a sort of "No, really, I know
what I'm doing, I want to treat this object as THAT type, truly,
trust me."
It is these uses that are usually wrong, either because the conversion
is not guaranteed (as in Richard's example) or because the cast is
redundant (as in the classic cast on a malloc call).
I'm not comfortable considering redundant "wrong". Next you'll be
telling me that excessive parenthesis is "wrong" as well. "Wrong"
means that the resulting code does something other than what the
programmer (or reader of the code) expects.
There is one difference. Unnecessary parentheses don't change the
action of the compiler. A superfluous cast can cause the compiler to
suppress a diagnostic. Consider the case of the "objected to" cast of
the return value of malloc. The cast itself is not "wrong" but if you
forget to include stdlib.h the compiler will not see the constraint
violation.
>The real meaning of a (correct) cast is most often: "please convert
the value to one of this type because that is correct in this
situation and you (the compiler) will get it wrong otherwise".
[snip]
>>
If actual conversion of data (as opposed to coercion of type) is involved,
yah, it's probably wrong.
I don't think that conversion of data makes it any more or less likely
to be right. Maybe I've missed your point. What were you think of?
When I read "conversion of data", I think the bit-patterns have changed.
When I read "coercion of type", I think the bit-patterns remain exactly
the same, but that their interpretation changes.
Where am I going wrong?
Remove del for email
pete wrote:
st******@rohan.sdsu.edu wrote:
>When I read "conversion of data", I think the bit-patterns have
changed.
The evaluation of these two expressions:
(0u == 0)
(UINT_MAX == -1)
requires conversions of the int type sub expressions to type
unsigned. But those signed int values may or may not have the
same bit patterns as the unsigned int values to which they
compare equal.
To the contrary, that is guaranteed by the standard. Section 6.2.5:
[#9] The range of nonnegative values of a signed integer
type is a subrange of the corresponding unsigned integer
type, and the representation of the same value in each type
is the same.28) A computation involving unsigned operands
can never overflow, because a result that cannot be
represented by the resulting unsigned integer type is
reduced modulo the number that is one greater than the
largest value that can be represented by the resulting type.
--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.
** Posted from http://www.teranews.com ** st******@rohan.sdsu.edu wrote:
begin quoting Ben Bacarisse <be********@bsb.me.uk:
It is these uses that are usually wrong, either because the conversion
is not guaranteed (as in Richard's example) or because the cast is
redundant (as in the classic cast on a malloc call).
I'm not comfortable considering redundant "wrong". Next you'll be
telling me that excessive parenthesis is "wrong" as well.
The difference between those two is that excessive parentheses are like
a wire that's better insulated than necessary, while an excessive cast
is like a high voltage sign on a battery. The first will do no harm; the
second will _probably_ do no harm _of itself_, but at the very least it
will tempt the user into ignoring other, more valid high voltage signs/
casts, and at worst, they can hide a real wiring/conversion error.
"Wrong" means that the resulting code does something other than what
the programmer (or reader of the code) expects.
Many excessive casts _can_ mean that. Won't always, but can.
Richard
CBFalconer wrote:
pete wrote:
>st******@rohan.sdsu.edu wrote:
>>When I read "conversion of data", I think the bit-patterns have
changed.
The evaluation of these two expressions:
(0u == 0)
(UINT_MAX == -1)
requires conversions of the int type sub expressions to type
unsigned. But those signed int values may or may not have the
same bit patterns as the unsigned int values to which they
compare equal.
To the contrary, that is guaranteed by the standard. Section 6.2.5:
[#9] The range of nonnegative values of a signed integer
type is a subrange of the corresponding unsigned integer
type, and the representation of the same value in each type
is the same.28)
Concerning (0u == 0):
I think I would have been more right, or maybe less wrong,
if I had used lvalues instead of constants.
stremler said "bit-patterns" which I took to include padding bits.
N869
6.2.6.2 Integer types
[#1]
The values of any padding bits are unspecified.
[#2]
39) All other combinations of
padding bits are alternative object representations of
the value specified by the value bits.
Padding bits in constants aren't accessible,
so I don't think there's any significance in their possible
existence in representations of constant expressions.
A computation involving unsigned operands
can never overflow, because a result that cannot be
represented by the resulting unsigned integer type is
reduced modulo the number that is one greater than the
largest value that can be represented by the resulting type.
But concerning (UINT_MAX == -1):
the case is that if (-1) is not represented in two's complement,
then it won't have the same bit pattern as UINT_MAX.
--
pete
CBFalconer <cb********@yahoo.comwrites:
pete wrote:
>st******@rohan.sdsu.edu wrote:
>>When I read "conversion of data", I think the bit-patterns have
changed.
The evaluation of these two expressions:
(0u == 0)
(UINT_MAX == -1)
requires conversions of the int type sub expressions to type
unsigned. But those signed int values may or may not have the
same bit patterns as the unsigned int values to which they
compare equal.
To the contrary, that is guaranteed by the standard. Section 6.2.5:
[#9] The range of nonnegative values of a signed integer
type is a subrange of the corresponding unsigned integer
type, and the representation of the same value in each type
is the same.28) A computation involving unsigned operands
can never overflow, because a result that cannot be
represented by the resulting unsigned integer type is
reduced modulo the number that is one greater than the
largest value that can be represented by the resulting type.
That guarantees that 0u and 0 have the same representation. It
doesn't guarantee that UINT_MAX and -1 have the same representation --
and in fact they don't on non-two's-complement systems.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Barry Schwarz <sc******@dqel.comwrote:
>
There is one difference. Unnecessary parentheses don't change the
action of the compiler.
#include <stdio.h>
int main()
{
int i;
if (i = 1) printf("Warning\n");
if ((i = 1)) printf("No warning\n");
return 0;
}
bash-2.02$ gcc -c -Wall test.c
test.c: In function `main':
test.c:7: warning: suggest parentheses around assignment used as truth value
-- Larry Jones
They can make me do it, but they can't make me do it with dignity. -- Calvin
\begin quoting Barry Schwarz <sc******@dqel.com:
On Thu, 29 May 2008 18:25:25 +0000 (UTC), st******@rohan.sdsu.edu wrote:
begin quoting Ben Bacarisse <be********@bsb.me.uk:
st******@rohan.sdsu.edu writes:
begin quoting Richard Heathfield <rj*@see.sig.invalid:
[snip]
It is these uses that are usually wrong, either because the conversion
is not guaranteed (as in Richard's example) or because the cast is
redundant (as in the classic cast on a malloc call).
I'm not comfortable considering redundant "wrong". Next you'll be
telling me that excessive parenthesis is "wrong" as well. "Wrong"
means that the resulting code does something other than what the
programmer (or reader of the code) expects.
There is one difference. Unnecessary parentheses don't change the
action of the compiler. A superfluous cast can cause the compiler to
suppress a diagnostic. Consider the case of the "objected to" cast of
the return value of malloc. The cast itself is not "wrong" but if you
forget to include stdlib.h the compiler will not see the constraint
violation.
Which may indeed be unwise.
Got that. :)
--
--Stewart Stremler----------------------------...rohan.sdsu.edu--
Humans are like goats. We'll eat any damned thing. Just ask the people
who make PowerBars. --Tim Cameron
/b/e/g/i/n/ quoting Richard Bos <rl*@hoekstra-uitgeverij.nl:
st******@rohan.sdsu.edu wrote:
begin quoting Ben Bacarisse <be********@bsb.me.uk:
It is these uses that are usually wrong, either because the conversion
is not guaranteed (as in Richard's example) or because the cast is
redundant (as in the classic cast on a malloc call).
I'm not comfortable considering redundant "wrong". Next you'll be
telling me that excessive parenthesis is "wrong" as well.
The difference between those two is that excessive parentheses are like
a wire that's better insulated than necessary, while an excessive cast
is like a high voltage sign on a battery. The first will do no harm; the
second will _probably_ do no harm _of itself_, but at the very least it
will tempt the user into ignoring other, more valid high voltage signs/
casts, and at worst, they can hide a real wiring/conversion error.
I'll buy that. Thanks.
"Wrong" means that the resulting code does something other than what
the programmer (or reader of the code) expects.
Many excessive casts _can_ mean that. Won't always, but can.
Which brings us back to casts changing things or not.
From my (limited) experiments with "gcc -S", there's no difference in the
resulting output whether or not I cast (some things). Is there a case where
the output *would* be different?
--
--Stewart Stremler----------------------------...rohan.sdsu.edu--
Cats seem to go on the principle that it never does any harm to ask for
what you want. --Joseph Wood Krutch st******@rohan.sdsu.edu writes:
<big snip>
Which brings us back to casts changing things or not.
From my (limited) experiments with "gcc -S", there's no difference in the
resulting output whether or not I cast (some things). Is there a case where
the output *would* be different?
I would have thought that was clear from previous answers. For
example:
#include <stdio.h>
int main(int argc, char **argv)
{
printf("%f\n", (double)argc);
return 0;
}
I also posted an example of pointer cast that must generate code. It
seems sufficiently clear that I suspect I've missed your point.
--
Ben. This discussion thread is closed Replies have been disabled for this discussion. |
