aa*****@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
