"C vs java"

[aarklon]

Hi all,

See:- http://www.cs.princeton.edu/introcs/faq/c2java.html

for C vs Java in number crunching

http://husnusensoy.blogspot.com/2006...crunching.html

[Richard Heathfield]

Richard Tobin said:

In article <hO************ *************** ***@bt.com>,
Richard Heathfield <rj*@see.sig.in validwrote:

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

[Bart]

On May 14, 9:54*am, Richard Heathfield <[e-mail].i nvalidwrote:

aark...@gmail.c om 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 "compilatio n" 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\0x y"; 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 "polymorphi sm" 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 "inheritanc e" as "inheritenc e", 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 "overloadin g" 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

[Bart]

On May 14, 9:54*am, Richard Heathfield <[e-mail].i nvalidwrote:

aark...@gmail.c om 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

[Mark McIntyre]

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 >

[Mark McIntyre]

Chris McDonald wrote:

Richard Heathfield <rj*@see.sig.in validwrites:

>aa*****@gmail.c om 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 >

[Ian Collins]

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.

[Chris McDonald]

Mark McIntyre <ma**********@s pamcop.netwrite s:

>Chris McDonald wrote:

>Richard Heathfield <rj*@see.sig.in validwrites:

>>aa*****@gmail.c om 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
undergraduat e 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]

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.

[Mark McIntyre]

Chris McDonald wrote:

Mark McIntyre <ma**********@s pamcop.netwrite s:

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

[Chris McDonald]

Mark McIntyre <ma**********@s pamcop.netwrite s:

>Chris McDonald wrote:

>Mark McIntyre <ma**********@s pamcop.netwrite s:

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