On Java and C++

[Noah Roberts]

If you discover you must optimize, you can convert from foo(string bar) to
foo(string const & bar) in only one logical place; typically 2 physical
places. The change won't cause force other designs to change.

When you have a design decision that's harder to reverse, _then_ you fret
about its performance as you commit it.

(My current boss, though otherwise good at coding, refuses to allow us to
rely on the return value optimization, so maybe I take it out on this
newsgroup

Return value optimization is not always available and that IS a hard to
reverse design decision.

Besides, that won't help you with inputs.

 

[Phlip]

Return value optimization is not always available and that IS a hard to
reverse design decision.

I didn't say it wasn't.

Besides, that won't help you with inputs.

I didn't say it did.

 

[Noah Roberts]

I didn't say it wasn't.


I didn't say it did.

Then you should know better.

 

[Chris Smith]

Just for fun,

Java:

- write once debug everywhere

I find this to be not at all true. In fact, most of what I do for a
living these days is write code (and manage a development team that
writes code) in Java on Windows, and deploy the code on Linux. In the
last five years of doing so, I have seen exactly ONE bug that was
operating system specific... and it failed on Windows but not Linux,
rather than the other way around. It had to do with another programmer
misinterpreting String.replaceAll and not realizing that the parameters
were regular expressions, and passing the platform-specific file
separator as a parameter. Of course, on Windows that was a backslash
and resulted in an error trying to parse the regular expression.

That's it. No other bugs in five years. Of course other bugs are
possible. There are even areas I'd describe as pitfalls: character
encodings, Runtime.exec, and the like. However, I haven't run into them
in practice. I have enough confidence that I feel pretty good releasing
code tested on Windows directly onto a production system running Linux.

(I imagine there are also issues with the Macintosh and GUI apps, since
I see questions about it. I wouldn't really know.)

- forgets everything on all its CLASSPATHs at
the drop of a hat

I don't understand what you mean by this. As far as I can tell, it's a
completely senseless statement. If you're talking about a CLASSPATH
environment variable, then this is an operating system issue, not at all
related to Java. If you're talking about the classpath (in more general
terms, not the environment variable) used by the system class loader,
then it doesn't change, ever. Perhaps you managed to confuse yourself
at some point with a custom class loader?

- projects must depend on fragile and
programmer-hostile tools, like ANT,
that make easy things hard and hard
things absurd

I also dislike ant. That's why I've never used it -- except for a brief
period of experimentation with XDoclet, which seems to depend on it. So
far as I can tell, I don't suffer any great disadvantages from not using
ant.

- impersonates the worst of C++
multiple String classes

Are you referring to my earlier post where I listed different ways of
representing character sequences? The point of that post was that
different functionality requirements require different types for the
same basic concept, regardless of language... The only dispensable
representation from my list in Java is StringBuffer, and it will go away
over time.

and last but least generics!

I have my complaints about generics in Java. Their existence, though,
is not one of those complaints.

- arrays aren't really arrays. But they really
are. Kinda.

Eh? Arrays are arrays. Perhaps you're too married to some language-
specific concept of what an array is.

- pretends you broke something if your file
name differs from your class name. Figure
it out, stoopid!

Exactly what important information did you expect to express by naming
your source file something different? A decent development environment
might have mitigated the headache you would have caused by doing so...
but it's no justification.

(Technically, this is not a requirement of the Java language. It is
only suggested by the Java Language Specification, and is enforced by
choice in all major Java compilers. The JLS doesn't mention source
files at all in any normative statement.)

- when a smart editor like Eclipse can finish
every line for you, it makes you wonder
what the language is _there_ for!

This is perhaps a useful thing for some to wonder, but only so that they
can get around to knowing the answer. The answer is that we're talking
about two different sets of things:

(1) What can be reasonably guessed, with the assurance that the
programmer will see the guess and correct it if it's wrong?

(2) What is so certain to be the programmers meaning that it can be done
without guessing?

Clearly, there are things that fit into set (1) without also fitting
into set (2). Those things should be implemented with IDE auto-complete
features, and not with the language itself. Whether the boundaries are
drawn correctly is another issue, and there are undoubtedly places where
the boundaries could be drawn better... but criticizing the need for
auto-complete entirely doesn't look reasonable.

- adds keywords, like interface, based on
someone else's preconceived notion of good
design. Not keywords like 'virtual', based
on what the hardware will actually do

So you don't like the lack of multiple inheritance. That's fine.
However, the existence of interfaces as a language feature is perfectly
sensible in a language without multiple inheritance. This is not a
separate gripe.

- provides whole new categories of bugs, based
on zombie objects, non-deterministic
destructors, redundant finally blocks, all
under the excuse we are saving you from all
the C++ memory errors that a good standard
library implementation will save you from
anyway

It's not true that, in practice, good libraries have saved C++
programmers from memory management bugs. Results indicate that long-
running applications in C++ tend to benefit when the new operator is
overloaded with a simple conservative garbage collected implementation,
and delete with a no-op. This is because the accidental memory leaks
from the dumb conservative collector and from these "zombie" objects are
substantially less than the memory leaks from typical memory allocation
bugs. Clearly something is wrong. If you wish to embark upon a massive
education campaign to teach C++ programmers how to avoid these bugs,
that would perhaps be a noble undertaking. In the interim, though, it
would be counterproductive to interfere with efforts to avoid memory
management bugs that do occur in real-life applications. Modern Java
implementations have non-conservative collectors that are even better.

- GUIs require block closures and dynamic
typing. But what language does your boss
tell you to write the GUI in???

Anonymous inner classes actually tend to solve this problem very easily.
Yes, they are more wordy. If you don't like wordy languages, then you
shouldn't use Java. (And shouldn't take jobs where Java is used, or
should just deal with it when the language is decided on; your choice!)
The only significant lost feature is the ability to modify the values of
local variables. That feature would be nice just for consistency, but
it is probably more dangerous than it's worth in practice.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Phlip]

I find this to be not at all true. In fact, most of what I do for a
living these days is write code (and manage a development team that
writes code) in Java on Windows, and deploy the code on Linux.

Me too. I could have kicked off the list with a less cheap shot. For
example:

"Java : the elegant simplicity of C++ and the blazing speed of Smalltalk."
--Jan Steinman

So you don't like the lack of multiple inheritance. That's fine.
However, the existence of interfaces as a language feature is perfectly
sensible in a language without multiple inheritance. This is not a
separate gripe.

Ooh, I was gonna snip it all, but you finally got thru to me.

I didn't mention MI!!!

When I was a tiny kid, my mom read me a children's book about a rabbit
scolding another rabbit (or something like that) for sneaking into a
garden. The one rabbit complains, "but I didn't sneak in!" "Because you
stopped in time!!" "But I wasn't _gonna_ sneak in!!" etc.

I apologise for just being about to mention MI and stopping in time.
(Noah!

 

[Noah Roberts]

I apologise for just being about to mention MI and stopping in time.
(Noah!

?

 

[Andrew McDonagh]

C++ pointers and references have completely different purposes. The
fact that Java lacks pointers is just another can't.

I can't say Java's, "everything is a reference except when it is not,"
is a move up from having explicit value, reference, and pointer
semantics that operate in a uniform manner.

Java has a thing called 'references'. Its more like a C Pointer than a
C++ reference, as in it can be nulled. The major difference is that no
pointer arithmetic can be done with it.

Java references are passed by value. The objects that they point to does
actually move.

Granted a better name than 'reference' or 'pointer' would have helped -
though I cant think of one.

 

[Mishagam]

....
C++ pointers and references have completely different purposes.

'purpose' is what language designers imagined references would be used
for. Functionaly, as I understand, difference between references and
pointers is little syntax sugar [ -> replaced with . ] + what values
they can hold - references cannot hold null or objects allocated by new.
But you CAN have reference to destructed object out of scope (or field
in deleted object allocated on heap). Also references syntax resembles
value objects enough that is is difficult to distinguish what you are
using now. It is one more way where C++ loses C clarity.
What I meant is difference with pointer is too small to justify
existence of references for well designed language. I think that
designers of C++ just hated C pointers too much to think rationally.

By the way, I have little problem. I Wiki about C++ reference types I read:
"Once a reference is created, it cannot be later made to reference
another object; we say it cannot be reseated. This is often done with
pointers."
But in my VS 2003 C++ compiler you can easily put new value to
reference, like code sample below. Do you know who is correct here?

int main() {
int aa = 25;
int & ra = aa;
int bb = 323;
ra = bb;
printf("ra= %d\n", ra);
int *ii = new int;
*ii = 999;
ra = *ii;
printf("ra= %d\n", ra);
ii = NULL;
ra = *ii;
......
THis code compiled and run OK on VS 2003

 

[Noah Roberts]

...
C++ pointers and references have completely different purposes.

'purpose' is what language designers imagined references would be used
for. Functionaly, as I understand, difference between references and
pointers is little syntax sugar [ -> replaced with . ] + what values
they can hold - references cannot hold null or objects allocated by new.
But you CAN have reference to destructed object out of scope (or field
in deleted object allocated on heap). Also references syntax resembles
value objects enough that is is difficult to distinguish what you are
using now. It is one more way where C++ loses C clarity.
What I meant is difference with pointer is too small to justify
existence of references for well designed language. I think that
designers of C++ just hated C pointers too much to think rationally.

You say that references are little more than syntatic sugar and then
directly quote at least one way in which they are drastically different
below. I guess logic isn't something you are good at.

By the way, I have little problem. I Wiki about C++ reference types I read:
"Once a reference is created, it cannot be later made to reference
another object; we say it cannot be reseated. This is often done with
pointers."
But in my VS 2003 C++ compiler you can easily put new value to
reference, like code sample below. Do you know who is correct here?

int main() {
int aa = 25;
int & ra = aa;
int bb = 323;
ra = bb;
printf("ra= %d\n", ra);
int *ii = new int;
*ii = 999;
ra = *ii;
printf("ra= %d\n", ra);
ii = NULL;
ra = *ii;
.....
THis code compiled and run OK on VS 2003

You obviously don't understand what a reference is. Print out aa and
you will have your answer. Print out bb after your second change and
it may become more clear.

 

[Phlip]

[followups set to non-Java groups]

C++ pointers and references have completely different purposes.

'purpose' is what language designers imagined references would be used
for. Functionaly, as I understand, difference between references and
pointers is little syntax sugar [ -> replaced with . ]

Nope. A reference is an alias for an object. Unlike a pointer, you cannot
take the address of the refering thing (the thing that's probably secretly
a pointer). It's secret because the compiler can optimize it away, and go
to the real object if possible.

+ what values
they can hold - references cannot hold null or objects allocated by new.

They can hold heap objects; they just shouldn't.

int & i = *new int;
delete &i;

That's valid but high risk.

But you CAN have reference to destructed object out of scope (or field
in deleted object allocated on heap).

Yep. Even thinking about i after my delete line is illegal.

Also references syntax resembles
value objects enough that is is difficult to distinguish what you are
using now. It is one more way where C++ loses C clarity.

There's a difference between clarity and exposed plumbing...

What I meant is difference with pointer is too small to justify
existence of references for well designed language. I think that
designers of C++ just hated C pointers too much to think rationally.

If they burdened C++ with your misunderstandings of references, then your
point might be valid. References are good because they are the _weakest_
kind of alias or handle we have. Use them in preference to pointers.

By the way, I have little problem. I Wiki about C++ reference types I
read: "Once a reference is created, it cannot be later made to reference
another object; we say it cannot be reseated. This is often done with
pointers."
But in my VS 2003 C++ compiler you can easily put new value to
reference, like code sample below. Do you know who is correct here?

int main() {
int aa = 25;
int & ra = aa;
int bb = 323;
ra = bb;

That copys the value of bb into aa, which ra still refers to.

printf("ra= %d\n", ra);
int *ii = new int;
*ii = 999;
ra = *ii;

Right. Now that copies the 999 to the aa, which ra still refers to.

printf("ra= %d\n", ra);
ii = NULL;

I hope you didn't think that 'delete's ii. It just leaks the memory.

ra = *ii;

And that's undefined behavior.

So the well-defined parts of your sample program do indeed demonstrate how
references are aliases for their target objects. You may want to debug your
program, or even look at its opcodes, to see what's going on. The compiler
might optimize ra away, and the statement ra = bb might produce the same
opcodes as aa = bb.

 

[Oliver Wong]

Java has a thing called 'references'. Its more like a C Pointer than a
C++ reference, as in it can be nulled. The major difference is that no
pointer arithmetic can be done with it.

Java references are passed by value. The objects that they point to does
actually move.

I'm assuming you mean "does NOT actually move".

- Oliver

 

[Oliver Wong]

This is perhaps a useful thing for some to wonder, but only so that they
can get around to knowing the answer. The answer is that we're talking
about two different sets of things:

(1) What can be reasonably guessed, with the assurance that the
programmer will see the guess and correct it if it's wrong?

(2) What is so certain to be the programmers meaning that it can be done
without guessing?

Clearly, there are things that fit into set (1) without also fitting
into set (2). Those things should be implemented with IDE auto-complete
features, and not with the language itself. Whether the boundaries are
drawn correctly is another issue, and there are undoubtedly places where
the boundaries could be drawn better... but criticizing the need for
auto-complete entirely doesn't look reasonable.

Also, when some types in:

public class Foo i

the Eclipse Editor, and just about anyone else who is familiar with
Java, could probably safely assume that the programmer is about to type in
"mplements" to yield:

public class Foo implements

does that mean that the designers of Java should have used the string
"i" instead of "implements" as the keyword? It depends on whether one values
clarity or terseness.

- Oliver

 

[Luc The Perverse]

int main() {
int aa = 25;
int & ra = aa;
int bb = 323;
ra = bb;
printf("ra= %d\n", ra);
int *ii = new int;
*ii = 999;
ra = *ii;
printf("ra= %d\n", ra);
ii = NULL;
ra = *ii;
.....
THis code compiled and run OK on VS 2003

Wow. Noah your point is well taken. I have just been convinced that Java
is a superior programming language for not allowing this kind of BS.

 

[Luc The Perverse]

From the TIOBE faq:

Q: What happened to Java in April 2004? Did you change your methodology?
A: No, we did not change our methodology at that time. Google changed its
methodology. They performed a general sweep action to get rid of all kinds
of
web sites that had been pushed up. As a consequence, there was a huge drop
for
languages such as Java and C++. In order to minimize such fluctuations in
the
future, we added two more search engines (MSN and Yahoo) a few months
after
this incident.

It's a flawed method of rating to begin with. I do not believe we can
directly infer that web page occurrences some how indicate usage. It may
provide some kind of vague correlation - I suppose.

 

[Phlip]

Wow. Noah your point is well taken. I have just been convinced that
Java is a superior programming language for not allowing this kind of BS.

Noah's point - between the cheap shots - was that C++ does _not_ allow that
kind of BS.

 

[Noah Roberts]

Wow. Noah your point is well taken.

Can't figure out who you're quoting??

I have just been convinced that Java

is a superior programming language for not allowing this kind of BS.

Java doesn't allow this huh? Hmm...guess that will be news for some.
Can't exactly function as a language I guess...

 

[Timo Stamm]

It's a flawed method of rating to begin with. I do not believe we can
directly infer that web page occurrences some how indicate usage. It may
provide some kind of vague correlation - I suppose.

I think a simple chart of sourceforge projects by programming languages
would be much more meaningful. It wouldn't be representational because
it's far from complete, but at least you know what you are measuring.


Timo

 

[The Ghost In The Machine]

In comp.lang.java.advocacy, Noah Roberts
<[email protected]>
wrote

C++ pointers and references have completely different purposes. The
fact that Java lacks pointers is just another can't.

Pointers are a means to an end (well, so is everything else in
a computer language, really). Exactly what is it that Java can't
do in this space?

(Especially since java.nio.channels.FileChannel.map() is Java's
answer to C/C++'s mmap() method.)

I can't say Java's, "everything is a reference except when it is not,"
is a move up from having explicit value, reference, and pointer
semantics that operate in a uniform manner.

It would help if "uniform" = "consistent with type declaration".

int a[5];
int * b = a;

just isn't quite kosher to those schooled in Pascal, convenient as it
might be otherwise; it should be:

int a[5];
int * b = &a[0];

(I don't remember the actual Pascal offhand. It's been too long,
and in any event standard Pascal didn't have an addr() method.)

I'm also not all that sure of the usefulness of such things as

const char * p = "A rainy day in Georgia";
const char * q = p + 15; // q="Georgia"

unless q is an index variable stepping through p's string,
usually in a for or while loop:

for(q = p; *q; q++) { ... }

And of course there are the problems with such things as punning:

char * p = "Another rainy day in Georgia";

void routine(const char * p, char * q)
{
for(;*p;p++, q++) *q = (*p) + 1;
}

routine(p,p);

which could confuse maintainers of routine() -- especially
if routine() for some reason frees its arguments without
checking them first.

For its part Java has its own problems with arrays:

int[] s = new int[]{1,2,3};
int[][] a = new int[][]{
s,
new int[]{1,2,3},
s,
new int[]{4,5},
new int[]{6},
null,
new int[]{7,8,9,10,11}
}

can quite easily trip up naive coding in programs; also,
the int/Integer dichtotomy is a bit of a wart, though not
nearly as bad a lesion as it could have been had Integer
been implemented with a setIntvalue() method.

I like the syntax, though.

 

[Mishagam]

I think a simple chart of sourceforge projects by programming languages
would be much more meaningful. It wouldn't be representational because
it's far from complete, but at least you know what you are measuring.

SourceForge is very non random selection, not very representative of all
language usages.

 

[Timo Stamm]

- when a smart editor like Eclipse can finish
every line for you, it makes you wonder
what the language is _there_ for!

[...]

Also, when some types in:

public class Foo i

the Eclipse Editor, and just about anyone else who is familiar with
Java, could probably safely assume that the programmer is about to type
in "mplements" to yield:

public class Foo implements

does that mean that the designers of Java should have used the string
"i" instead of "implements" as the keyword? It depends on whether one
values clarity or terseness.

No. But maybe it could have looked like this:

class Foo : List

"public" is made default, ":" replaces "implements" (extends could be
replaced by "<").


A better example for superfluous verbosity:

ArrayList<Entry<String, Integer, Object>> l = new
ArrayList<Entry<String, Integer, Object>>();

Wouldn't it be nice to have local type inference here?

def l = new ArrayList<Entry<String, Integer, Object>>();


Getters and Setters are another good example. Sure, the IDE can generate
them. But C#s properties are a lot more elegant. You can start with
simple public members and introduce getters and setters later without
any need to change the clients of the class.


Anonymous classes are also quickly generated by the IDE, but true
closures with a short syntax would certainly make the code more
expressive and readable.


I don't say that these changes should be made. Java sacrifices
flexibility and expressiveness for readability, and that's fine in many
situations. But I think Phlip raised a valid point, even if it was
comically exaggerated.


Timo