On Java and C++

[Noah Roberts]

Team coding and coding on your own are quite different experiences. I
presume you work mostly on your own. The conventions are very useful
to prevent bloodshed between team members. They are just accepted and
you get on with something more important to fight about.

I don't see how your assertion applies to my quoted statement above.
If you want to be understood I suggest you make your point more
clearly.

I also don't see how my quoted statement above would lead one to
believe I have never worked in a team...but whatever. It is clear you
don't have any good, and valid, arguments for you assertion that Java
is better than C++. This is frankly not surprising to me as such
assertions are always riddled with illogic and falacy.

 

[Alf P. Steinbach]

* Roedy Green:

see http://mindprod.com/jgloss/packratting.html

I think you are quibbling over terminology. A leak would be an object
nothing pointed to continuing to tie up ram. Packratting is holding
on to objects you will never need again.

When a program uintentionally gobbles up memory, never releasing it, and
never using it again, there is a memory leak. So, you're not quibbling
over terminology: you're using terminology to try to define that reality
away. Which would be utterly silly were it not that someone might
believe it, and that someone evidently has believed it.

Your reference states:

"In fact it is almost impossible to write a program that nullifies
references to every object the instant it will never be needed again.
So every program is guilty of minor packratting."

Apart from the lack of connection from premise to conclusion, that's not
a fact, it's an excuse for sloppiness. Trying to define the problem
away by inventing new terminology and redefining old is more of the
same, an extra, fallback excuse position for incompetence. "Hey, it's
not a memory leak, it's /packratting/ [or whatever], and besides
[fallback excuse position], it's impossible to avoid, so there!"

Let's not discuss at that level, trying to pull the wool over things
that are technically clear and trivial but perhaps not viewed as
compatible with one's position.

It is possible to avoid memory leaks, it is possible to have them with
or without automatic garbage collection, and it is possible to use
garbage collection in C++, so the assumptions are all incorrect.

 

[peter koch]

Roedy Green skrev:

I would be happy with that if people making the comments had working
knowledge of both before pontificating. It seem the people with the
strongest opinions have experience in primarily one language. We are
hearing the breast beatings similar to those about the best hockey or
basketball team, rather than a dispassionate comparison of features.

It further seems these fights could be turned into contests where
teams use their favoured language. The idea is to do the work in the
fewest man hours and have the fastest least resource hungry result.
You would also have a maintainability challenge, X hours to change the
program to do something different. You could get some hard data to
compare.

The one I know with expertise in both systems - James Kanze - believes
C++ to be the best and fastest language for software development. But
then he has very high standards for his software.

/Peter

 

[Roedy Green]

Hey, my CPU will run C++ byte code natively but there are no CPU's that
run Java source code...guess Java sucks then.

There are machines that run Java bytes codes directly. But even such
machines have some microcode or other assembler assists to handle the
lowest levels. see http://mindprod.com/jgloss/picojava.html

There is no equivalent to byte code in C++ that you as programmer see,
though there may be an intermediate triple form internal to the
compiler using during optimisation. In C++ you compile straight to
platform machine code. In Java you compile to a virtual machine, as
sort of idealized Java CPU similar to a FORTH stack machine. From
then it can be interpreted, JITed, HotSpotted, statically compiled
etc. Code is usually distributed in byte code format, often called
class file format or jars. The byte code format is
platform-independent. The platform independencies are handled by a
platform-specific JVM (a program written usually in C++) and set of
standard class libraries.

See http://mindprod.com/jgloss/compiler.html
http://mindprod.com/jgloss/jvm.html

 

[Bent C Dalager]

Large parts of the C++ libraries are implemented in C++.

This is also the case with Java. Even the Java compiler is implemented
in Java.

I do not understand that one - are you trying to put a joke on me - or
do you propose that Java should run only on processors supporting
byte-code? ;-)

It's just an observation. Since Java always compiles to one specific
instruction set that can be implemented in hardware with relative
ease, it doesn't need to rely on non-Java components at all.

You could still make it perform differently on different platforms but
I am not sure why that is important at all.

Cheers
Bent D

 

[Roedy Green]

This is ridiculous - like claiming you only know to drive a car with
automatic shifts because manual shifts are all to difficult. I do not
know what gear to use!

come on. There are alternate notations that generate the same
assembler code. That is a legacy wart, not a feature.

 

[Bent C Dalager]

This is playing wordgames. I don't care if it is what is in Java-speak
called a memory leak or pack-ratting. The fact is that you have to do
some "resource management" stuff to avoid memory usage increasing ad
infinitum. And this is not theoretical. If I remember correctly this
behaviour was found in a released official Java-library.

Swing is rather notorious for this. If you don't remember to call
"dispose()" on your GUI windows when you are done with them, they may
decide to stick around indefinately. This then also prevents the GC
from collecting everything that is referenced within the window, which
can be a lot.

So Java is not
just "allocate and forget" even when it comes down to "pure" memory.
Again the advantage is with C++.

Depends a bit on what you mean by "pure" memory, but that is probably
too academic a debate to get into.

Cheers
Bent D

 

[Noah Roberts]

Hey, my CPU will run C++ byte code natively but there are no CPU's that
run Java source code...guess Java sucks then.

There are machines that run Java bytes codes directly. But even such
machines have some microcode or other assembler assists to handle the
lowest levels. see http://mindprod.com/jgloss/picojava.html

[blah blah blah JVM blah blah]

I know all about that. Point is that it was asserted that C++ is not
as good as Java because Java binary code will run on some processors
but C++ source code won't. This is just stupid...almost as stupid as
me having to point this out to you.

I definately hear a vacuum...

 

[Alex Buell]

Language design is complicated, with lots of tradeoffs. I don't know
any language that doesn't contain at least one stupid feature its
designer should have known better about.

OK, are there any stupid features in D? ;o)

 

[Roedy Green]

go Ruby ..Go Ruby...Go Ruby

“I always knew one day Smalltalk would replace Java. I just didn’t know
it would be called Ruby." -- Kent Beck

My ex boss, (one of the cleverest guys I have ever run into) has gone
gung ho on Ruby. I did some work documenting it. It has much of the
appeal of Python, not making you ramble on for pages telling the
compiler things it can figure out on its own, but on the other hand,
it seems a lot harder to figure out what a program is doing without
all the embedded type clues.

I wonder if someday we will have a language that lets you write like
Ruby, but that does all kinds of inferencing to tell you additional
info like types, potential bounds etc. but only when you want to see
it.

 

[Roedy Green]

Java-based CPUs for desktops have been tried I think, but it didn't
take off.

they ran too hot.

But there are all kinds of tiny CPUs that run JVM byte code directly
(or more precisely in microcode).

This approach saves a lot of RAM. You don't need room for a JIT,
machine code, JITED machine code etc. All you have is nice compact
byte code.

 

[Roedy Green]

That is simply false - and most probably a bloody lie. About on par
with the other posts I've seen from you. Others might want to have a
look at

Have you read the book? Were in there on BIX when Stroustrup dropped
by for a month or two?

 

[Chris Smith]

I agree here. Readability matters a lot. And here C++ is a clear
winner, due to its more advanced features such as templates, operator
overloading and RAII,

You seem to have missed the point... whether intentionally or otherwise,
I don't know. I am referring to how quickly the language can be
understood; not how quickly software written in the language can be
understood.

Nevertheless, since we're now talking about it:

// C++
func()
{
class_with_possible_ressource cwpr;
dosomethingwith(cwpr);
}

// Java

void func()
{
ClassWithPossibleResource cwpr = new ClassWithPossibleResource();

try
{
doSomethingWith(cwpr);
}
finally
{
cwpr.dispose();
}
}

I don't know where you got the so-called Java code you posted. Whoever
gave it to you, don't accept their Java code any longer. Corrections
aside from syntax and naming conventions include:

1. A constructor would throw an exception if initialization failed, so
there is no need to check for that situation.

2. There is no need to catch exceptions within the finally block. If
the call to the clean-up method (e.g., dispose) fails, then an exception
will be thrown, which is what you wanted anyway. Although some people
may choose to be picky about which of the two exceptions they wish to
see in case doSomethingWith also failed, the C++ code doesn't handle
that any better, so it's rather irrelevant here.

3. Removed the cast to an interface before calling dispose. Upcasting
of references is always dispensible in situations like this. It appears
to have been added for no other reason than to make the Java code look
longer and uglier. Actually, come to think of it, most of the code that
was posted appears to have been added for that reason.

Four simple lines of C++ becomes 21 lines of complex and convoluted
Java-code.

Not sure how you're counting. Nevertheless, the C++ code is clearly a
little bit shorter, since the Java code needs to make cleanup explicit.

So the Java func above is as easy to understand as the C++-one?? Come
on - you do not really mean that.

No I don't mean that. See above.

Also you have a huge problem writing
generic code in Java .... those ugly and presumably costly runtime
checks have to be made all the time.

How is that relevant? Or is this just becoming a gripe list about
languages, which you obviously don't understand to begin with?

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Ian Collins]

Seems to me so much low level stuff in C++ (e.g. addressing trivia)
clutters readability. Operator overloading can make code more
readable, but if misused is one of the most powerful obfuscators ever
devised. I have not used the latest IDE's but I find it so much
harder in C++ to find the definition of somthing, especially when
smothered in macros.

That's why we avoid macros....

etags in (x)emacs solave the finding definition problem.

 

[Noah Roberts]

OK, are there any stupid features in D? ;o)

Its name?

 

[Mishagam]

Three things I _really_ hate about Java.

You should just relax and look for pleasure Having to obey these
rules don't bother me at all. I doubt they bother much other Java
programmers .

f) You don't have to choose between char *, string, CString ... - String
is better (or same) than either of them and it is only choice.

Actually, you are in err. Java also has char[] and there is nothing
stopping someone from using it or designing a new String. Therefor
Java suffers from the same "problem" as C++ here except there are no
Java functions and tools to work with char[]...you have to write them
from scratch.

Yes, you can use char[] (or byte[]), but as you said it has no support,
so nobody uses it (as opposed to String, which is more heavily supported
than any C/C++ strings version). It is VERY rare Java programmer who
would spend time deciding which string representation to use. Everybody
just uses String. And the beauty it - it is really very close to optimal
choice. (as opposed too, for example, original Pascal strings)

Yes, but all the benefits you are listing are things you *can't* do and
the things forced upon you. Where are the list of things you *can* do?
You make Java sound like a jail sentance.

Yes, it COULD easily become jail. The beauty of Java is that all choices
are made so clever, that they are very close to optimal, and (I am sure
for me) that advantage of not having to think about alternatives
overweights possible gains from other choices.
It also makes different pieces of software much more compatible.

 

[Walter Bright]

OK, are there any stupid features in D? ;o)

There was the bit basic type. It sure seemed like a good idea at the
time <g>.

 

[Roedy Green]

For some reason, you've put the most important statement in parentheses.
RAII is one of the two reasons I stick with C++. I don't know of any
other language that would support such concept. (C# and D both support
RAII, but require the programmer to explicitly mark objects that should

The equivalent in Java is called finalizers. This is one of the most
unsatisfactory parts of Java. One problem is guaranteeing ALL the
finalizers will be run on shutdown. The whole business is a bit flaky
and most people avoid using them.

You find ad hoc solutions, basically making a note to run some code on
exist.

In practice you find everyone using explicit procedural closes rather
than relying on any sort of finalizer. Part of the reason is when you
do it manually, you free the resource sooner.

 

[Noah Roberts]

Mishagam wrote:

f) You don't have to choose between char *, string, CString ... - String
is better (or same) than either of them and it is only choice.

Actually, you are in err. Java also has char[] and there is nothing
stopping someone from using it or designing a new String. Therefor
Java suffers from the same "problem" as C++ here except there are no
Java functions and tools to work with char[]...you have to write them
from scratch.

Yes, you can use char[] (or byte[]), but as you said it has no support,
so nobody uses it (as opposed to String, which is more heavily supported
than any C/C++ strings version). It is VERY rare Java programmer who
would spend time deciding which string representation to use. Everybody
just uses String. And the beauty it - it is really very close to optimal
choice. (as opposed too, for example, original Pascal strings)

Interesting statement. Just how close, in quantifiable values, to
optimal is it then? Also, optimal in what way?

Yes, it COULD easily become jail. The beauty of Java is that all choices
are made so clever, that they are very close to optimal, and (I am sure
for me) that advantage of not having to think about alternatives
overweights possible gains from other choices.
It also makes different pieces of software much more compatible.

Cleverness is subjective. IMHO a lot of choices in Java where rather
dumb.

"Very close to optimal"...that seems like a fluff statement to me but
if you can quantify it I'll place more value in it.

Not having any choices doesn't seem to me to be that great.

I'm still looking for the can. You listed all the thing Java *can't*
do but haven't come with anything it can. I don't see much advantage
in *can't*.

 

[Walter Bright]

(C# and D both support
RAII, but require the programmer to explicitly mark objects that should
be destroyed when leaving scope. Why?)

There must be a way to distinguish between an object to be have a longer
lifetime than the current scope, and one to be destroyed when the
current scope ends.

C++ has such a distinction by declaring using a '*'. D uses 'auto' to
make a distinction.

-Walter Bright
www.digitalmars.com C, C++, D programming language compilers