"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/06/c-vs-java-in-number-crunching.html

 

[Szabolcs Borsanyi]

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

 

[Chris McDonald]

(e-mail address removed) 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 McDonald]

Chris McDonald said:

(e-mail address removed) 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.

Surely even undergraduate students deserve *accurate* information?

Agreed.

 

[Richard Tobin]

[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

 

[Richard Tobin]

Obviously when comparing
languages you have to use words in a more general sense.

[/QUOTE]

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

 

[Bart]

(e-mail address removed) 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

 

[Bart]

(e-mail address removed) said:

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

 

[Chris Torek]

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.

Well, of course C does not actually have anything called a "reference",
but the chief difference between the two, in a general sense, is
that a pointer is an "ordinary variable": just like any other
variable, you can assign a new value to *the pointer*. A reference
is *not* an ordinary variable: if you attempt to assign a new
value to the reference, the value shoots straight on through to
"whatever the reference refers-to", as it were.

In other words, a "reference" (in languages that have them) is
generally bound to a variable (or object or whatever the language
calls it) at the time it is created, and from then on, always refers
to the same thing, no matter what else happens.

In C, since a pointer is not special at all, you must apply a
"dereference" operation to it in order to manipulate whatever it
points to:

*p = foo; /* updates the target to which p points */
p = &bar; /* re-points p; now *p names bar */
*p = foo; /* updates (alters) "bar" */

but in Language X (Which Has References), if "r" is a reference:

r <- foo; /* updates the target to which "r" refers */
r <- &bar; /* almost certainly fails to compile */
r <- foo; /* almost certainly does not alter "bar" */

so references are "special" in a way that C pointers are not.

 

[Ian Collins]

I guess if the question had been "create a constant", the answers could
be comparable.


Is it? why?

Because there's absolutely no practical reason why an integer constant
can't be a compile time constant.

 

[Chris McDonald]

(e-mail address removed) 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.

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

Chris McDonald wrote:

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.

 

[Ian Collins]

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.

 

[Chris McDonald]

You can have that.

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.

 

[Anand Hariharan]

(e-mail address removed) said: (...)
(...)

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>

 

[Ian Collins]

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?

 

[Bart]

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.

 

[Ian Collins]

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.

 

[stremler]

(e-mail address removed) said:

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

 

[Chris H]

(e-mail address removed) 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?