On Java and C++

[Mishagam]

I do agree that Java probably should be used for client side web-based
programming.
That said there is ATL which COM which is used extensively in those
area - resulting in platform dependent code, of course.

/Peter

If you are talking about IE ActiveX controls they were also responsible
for a lot of security breaches (I am not expert here), because C++ and
specifically ActiveX controls don't have Java Applets inherent security.

 

[Timo Stamm]

Ahhh yes, the last ditch attack from the weak.

You are the only one who takes this discussion for a battle. Oliver
didn't attack you, he just tried to help you realizing what is going on.


Timo

 

[Oliver Wong]

* Roedy Green:

Exactly how can the memory leak that cannot exist, be detected and require
a different solution?

If Roedy had written "require quite different sets of tools and quite
different sets of solutions", would that have been better? Then you could
say that for problems which do not exist, the appropriate sets are the empty
sets.

Obviously, if one problem can occur, and another problem cannot occur,
then they must be different problems, which I believe was Roedy's main
point, even if he failed to express it properly.

On the contrary, in C++ it's meaningful to talk about different kinds of
memory leaks, such as when there's still a reference somewhere, what you
call a "packrat", and when there's no reference anywhere. If the case of
no reference couldn't exist, as in Java, then it would be meaningless to
distinguish it. That distinction is meaningless for Java.

(Ditto as above, I think what Roedy meant is clear, though he may have
not have expressed it in a way that you wanted).

I have not made the claims you assert. I don't believe that you talk on
behalf of "us", as you imply.

Maybe this is a psychological phenomena, but when I read "us", I had
assumed he was referring to "Java folks" (perhaps because I am one of those
Java folks). I think there's a lot of emotional energy here which may cause
us to say things we wish we hadn't (where we here is both Java folks and C++
folks). There's too much of an us-versus-them mentality going on, and it's
very easy for a Java person, posting from a Java newsgroup, to see an
unfamiliar name, and think "must be some C++ fanatic" and vice versa.

Perversely, I hope you're trolling.

If you go through the Google archives of comp.lang.java.programmer,
you'll see Roedy has a pretty good track record of being a helpful
contributor to the Java community. I don't suspect him of trolling. Rather,
I suspect these kind of threads bring out the worst in us.

- Oliver

 

[Noah Roberts]

On 27 Apr 2006 10:59:36 -0700, "Noah Roberts" <[email protected]>
wrote, quoted or indirectly quoted someone who said :

The big advantage of the Java approach is it FORCES you to write
cleaner code.

Your name Noah, suggests you might be the son of fundamentalist
parents. Fundamentalists are people who are utterly convinced their
faith is the one true faith, and guarantee they never change their
opinion by scrupulously avoiding studying any others.

Another totally unrelated ad hominem. You are obviously a very stupid
person. I base this on your method of argument, your inability to
argue effectively, your inability to comprehend simple statements, and
your overwhelming supply of idiotic assumptions that have nothing,
whatsoever, to do with the purported evidence.

....there is ample evidence in your own statements to support that you
are in fact an idiot.

Interesting set in this last post of yours though...bring up Java's
nature to force you into doing something the way a set of people
decided where best and then call ME a fundamentalist - you have no
evidence to support that statement except the fact that there was a
famous and important Hebrew that shared my namesake but your own
statements lend some support to the argument that in fact you are very
likely a fundamentalist as well as a facist.

Irony can be a facinating thing.

Yes, this is also a personal attack having nothing to do with the
topic, however, instead of grasping at staws in an attempt to discredit
you based on assumed ansestry and upbringing I am simply pointing out
the fact that you already discredited yourself through your own words
and methods.

You loose, no question about it. Of course this has no bearing on the
usefulness of the Java language...it only means you are a piss poor
advocate of it and not a particularly intelligent or nice person.

 

[Noah Roberts]

If Roedy had written "require quite different sets of tools and quite
different sets of solutions", would that have been better? Then you could
say that for problems which do not exist, the appropriate sets are the empty
sets.

Obviously, if one problem can occur, and another problem cannot occur,
then they must be different problems, which I believe was Roedy's main
point, even if he failed to express it properly.

That is really grasping at straws. Using set theory to weed out a
meaning you like from a the rewording of a statement. If we were in
the middle of an argument about abstract math then maybe it would have
its place...but we are not.

 

[Oliver Wong]

Very interesting post, Koch. I've snipped the parts I've agreed with, and am
only including some concerns I have about C++ and clarifications on Java.

I do not
understand why each class MUST have its own file (unless you make that
class a secondary citizen).

Actually, only the top level public classes should be in their own
files. Private classes, or nested classes, can be within any file. I suspect
the reason why is primarily a pragmatic one: So that the classloader can
easily locate the file that contains the bytecode for the classes and load
them.

It has some nice side effects. When I'm given someone else's code base,
and I have a qualified class name, I always immediately know the full path
to the source code file. I don't even have to browse a directory listing or
anything like that.

There are three kinds of lies. Lies, statistics and benchmarks.... or
so I've heard. The nice thing about C++ strings is that the number of
characters in a string is a O(1) operation. In Java, you would have to
check the number of surrogates making it a O(n) operation. Also C++
strings are more powerful than Java strings. All in all I believe I'd
prefer using C++ strings, switching to some specialised class in the
unlikely case string-handling did turn up to take a significand part of
my programs execution time.

I'm surprised unicode-stuff would appear as an advantage of C++ over
Java. I won't dispute this, since I don't know enough about the state of C++
libraries, but I was under the impression that the lowest common denominator
for C++ was ASCII, while the lowest common denominator for Java was the BMP
(Basic Multilingual Plane) portion of unicode.

I can't speak for others (e.g. archeologists, etc.), but I've never used
characters characters outside the BMP. For example, while I am interested in
writing text in English, French and Japanese, I am not interested in writing
in cuneiform, cypriot, or byzantinne musical notation. So I've never had a
problem with text in Java applications.

However, I have had problems with C++ applications which assumed ASCII.
WinAmp is one example. It has trouble handling the ID3 tags of my Japanese
songs. iTunes seems a bit better at this. *SOMETIMES* it properly renders
the kanji characters, but other times the track name will show up as a bunch
of question marks.

So I was under the impression that C++ support for unicode was behind
Java, not ahead of it. I guess times have changed.

Javas type system is not freedom but rather a jail. It has prevented
porting of Java to several platforms, it gives cumbersome Unicode
support and it forces Java to stick with inefficient 32-bit integers in
a world that is soon turning to 64 bits.

In its defense, I think the fact that the size of Java's primitive
datatypes remains constant is a "good thing". If an when you want to use a
64 bit datatype, you'd simply use "long" instead of "int". And I don't think
there's any technical reason why, in a few years from now, if 128 bit were
desired, a new datatype couldn't be added to Java to support that, without
breaking any previous code (except possibly via the addition of a new
keyword, which could no longer be used as a variable or method name).

The company I work at, Castor Technologies, makes some money by porting
C code from 32 bit platforms to 64 bit platforms. The fact that we're making
money must mean it's too painful for our clients to do the migration
themselves. I don't know if this C situation applies to C++ as well.

- Oliver

 

[Noah Roberts]

If you are talking about IE ActiveX controls they were also responsible
for a lot of security breaches (I am not expert here), because C++ and
specifically ActiveX controls don't have Java Applets inherent security.

Yes, Applets have to be given to Java as something it can do that
current incarnations of C++ cannot. I do not know that this is
inherent to the language or more because of the way Java is normally
processed.

Also it must be mentioned that flash is also used quite a bit in this
area and in fact, in my opinion at least, results in better output.
Flash "applets" seem to work better on more platforms than Java. Hell,
at home where I use Linux I will use Flash but won't even bother with
installing the Java plugins because much of the time the applets just
don't function well.

However, flash is much more expensive for the devolper, who doesn't
even have to pay for the JDK but has to pay a fortune for flash. When
I write applets it is with Java, not Flash and certainly not C++. But
when I write cross-platform code that won't be running in a browser
most of the time I use C++, not Flash, and not Java (though sometimes I
think about that as an alternative).

 

[Oliver Wong]

Ahhh yes, the last ditch attack from the weak. I grant you that it
appears to be a big gun as there is no way to argue against it...any
such attempt is of course also projecting. But only the unintelligent
cannot see it for what it is; I'll count you among them.

Taken in context, you wrote:

<quote>
It is clear you
don't have any good, and valid, arguments for you assertion that Java
is better than C++.
</quote>

and I wrote

<quote>
I don't think Roedy asserted that "Java is better than C++". See
http://en.wikipedia.org/wiki/Psychological_projection
</quote>

Assuming that I am correct in thinking that Roedy did not make the
assertion you claim he made, what would you call your behaviour, if not
psychological projection?

Alternatively, perhaps he DID make that assertion somewhere, and I had
forgotten about it, or perhaps that particular message never arrived at my
newsgroup server. If so, I apologize for any offense I may have caused you
by suggesting that you might have been projecting.

I don't mind if you think I'm "weak" or "unintelligent". My goal wasn't
to earn your praise, but rather to point out a possible source of the
apparent disagrement you're having with Roedy.

- Oliver

 

[Noah Roberts]

You can't use 6th grade rhetoric to try to convince a group of people who
have been using Java for years that suddenly it "sucks" because you say so.

Quote me saying that.

Simple request...

You won't...because you can't...because I never said it.

Come back when you can understand.

 

[Mishagam]

In comp.lang.java.advocacy, peter koch

How indeed? The best Java can do in that department is
a dispose() method (Swing) -- and that's not supported
in the language, unlike C++'s virtual destructor. finalize()
is overridable but it's never clear exactly when that will
be called.

I understand that RAII is basically use automatically called
destructor's to dispose resources? I agree it is useful where it can be
used.
It works if you work with objects as values, it doesn't work if you work
with pointers or references. In such cases destructor can easily leave
dangling pointer. If you work with references you are on your own, or
have to duplicate something like reference counting or Java GC. I don't
think you can work without using references in big program.
I think because of this STL mostly works (in examples) with value
elements, and this creates a lot of problems - you cannot place
descended class objects were you can place base objects, you have to
deal with constructors, destructor's, copy constructors called in
strange places, you waste memory and so on. Also, you have to have
different generated code for different objects and use templates. And in
Java one Collections library works OK with any object.

 

[Mishagam]

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 are joking, Right?

 

[Noah Roberts]

That is an assertion that may exist inside your head, but you will not
actually find it in this thread.

Really? I guess you never said the following then:

"Interestingly, of course, while there are no CPUs that support C++
instructions natively (that I know of anyway), there are those that
support Java bytecode natively. The conclusion being that while it is
possible to have a pure Java system, it is not possible to have a pure
C++ system "

Now, that statement can only be talking about C++ source code as all
other forms of C++ come in the form of binary codes meant for execution
by a CPU or in the intermediate object form, also composed primarily of
CPU instructions but without enough total information to be a true
executable...sort like pulling a Java .class file out of its package
and trying to run it.

At any rate, no matter how you slice it...the comparison is purposfully
scewed, being a compiled form on one hand and something other than a
complete compilation on the other...it's a red herring, and not a very
good one.

 

[Roedy Green]

That is really grasping at straws. Using set theory to weed out a
meaning you like from a the rewording of a statement. If we were in
the middle of an argument about abstract math then maybe it would have
its place...but we are not.

You are not a programmer at heart. You would make a better lawyer.
They get paid to deliberately misinterpret.

 

[Noah Roberts]

And of course one of main items:
j: In Java you generally don't have to think how to report error - you
throw Exception. In C++ you have different conventions for different
systems changing over time. Some programs return NULL or 0 or -1 or
SIGNALS ..., Microsoft COM programs returned HRESULT, lately C++ started
using exceptions, but I am sure it is still only one of choices. I don't
know, but doubt that C++ exceptions are as convenient as in Java. Of
course this result of Java being designed later when exceptions already
were well known .

Where to start...

First, are you really making the statement that Java supports no other
error reporting facility? That is blatantly false but let's assume for
the moment that is true and ask ourselves if that is actually a good
thing...

Second...I'm not sure of you use of the term "program". Are you really
claiming that a Java *program* can somehow report exceptions to the OS
or object running it in a way other than what the OS supports - signals
being one common facility? If this is in fact true it would be an
interesting CAN I am not aware of. C++ programs never "return NULL"
but do most commonly return an integer...0 meaning all is ok. AFAIK
Java must do this too as many operating systems depend on the behavior.

Third...COM is not C++, it is a MS specific standard of coding a set of
functionality in ANY language that can be used from ANY language
capable of interacting with COM. I do believe Java can be counted
among them but of course any such program instantly looses any platform
independance.

Finally, if you don't know then your doubts are meaningless.

 

[Roedy Green]

I don't think Roedy asserted that "Java is better than C++"

That is a meaningless assertion. Better for WHAT?.

Arguing with Noah is as silly as arguing with a five year old about
the merits of sex vs ice cream. If you have not used both languages,
how can you possibly compare them, much less make dogmatic assertions?

This argument reminds me of "which team is better". Everything is
determined by team loyalty. The debate becomes just a primate
territory ritual.

So I end my participation in this thread by flinging some metaphoric
feces in Noah's face, and thumping my chest like a good primate.

Many years ago on BIX, I was bitching about some of the features of
C++ and one of the participants got extremely emotional and defensive,
as if he were responsible for the failings. I was greatly embarrassed
to find out handle bstroustrup was THE Bjarne Stroustrup, creator of
C++. He had reason to take the criticism of C++ personally. You, Noah,
do not. C++ is just a language you learned, not your life partner.

 

[Oliver Wong]

Really? I guess you never said the following then:

"Interestingly, of course, while there are no CPUs that support C++
instructions natively (that I know of anyway), there are those that
support Java bytecode natively. The conclusion being that while it is
possible to have a pure Java system, it is not possible to have a pure
C++ system "

FWIW, on the very next line, Bent wrote "(No, it's not an important
point.)"

From the text you've quoted, even if you omit the parenthesis that
follows, I don't see where Bent implies "C++ is not as good as Java". This
is an example of what I was referring to when I mentioned psychological
projection. Bent simply stated the fact that chips exist which process Java
bytecode natively. From there, you inferred that Bent was making a statement
about the merits of Java versus C++. I don't think Bent intended for that
interpretation.

- Oliver

 

[Noah Roberts]

You are not a programmer at heart. You would make a better lawyer.
They get paid to deliberately misinterpret.

Won't respond to your personal attack but I will respond to your claim
I am purposfully misinterpreting your statements.

QUOTE

Exactly how can the memory leak that cannot exist, be detected and
require a different solution?

If you discovered a true leak, you have to create an SSCCE and submit
that to the JVM vendor, or the AOT run time vendor.
ENDQUOTE

Both your original statement and your reply indicate that the non set
theory interpretation of your words are in fact what you originally
meant. Are you claiming otherwise? If so then perhaps you wish to
reword YOURSELF instead of letting other attempt weed nuggets of
insight on their own? There is at least one other person who
interpreted what you said as I have so your meaning is obviously not as
clear as you indicate. If I misinterpret your words it is because they
are ambiguous at best...not because I do so on purpose.

 

[Chris Smith]

Really? I guess you never said the following then:

"Interestingly, of course, while there are no CPUs that support C++
instructions natively (that I know of anyway), there are those that
support Java bytecode natively. The conclusion being that while it is
possible to have a pure Java system, it is not possible to have a pure
C++ system "

I don't see any "C++ is not as good as Java because" in that paragraph.
I took it as an indictment of the silliness of bringing up this hardware
CPU/bytecode stuff in this conversation in the first place. Maybe I
misinterpreted something, but I really don't think so.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Oliver Wong]

Where to start...

First, are you really making the statement that Java supports no other
error reporting facility? That is blatantly false but let's assume for
the moment that is true and ask ourselves if that is actually a good
thing...

Of course, it's possible in Java to declare a method as returning an
int, and then using various codes for reporting status (e.g. 0 means
everything is OK, -1 means something bad happened, etc.), however if you
actually write Java code like this, you will probably be ridiculed. It's
like those conventions people brought up earlier and were complained as
being "can'ts" or "straightjackets" of Java. You *CAN* return error codes.
It's just that most Java programmers don't. It's considered bad form.

Second...I'm not sure of you use of the term "program". Are you really
claiming that a Java *program* can somehow report exceptions to the OS
or object running it in a way other than what the OS supports - signals
being one common facility? If this is in fact true it would be an
interesting CAN I am not aware of. C++ programs never "return NULL"
but do most commonly return an integer...0 meaning all is ok. AFAIK
Java must do this too as many operating systems depend on the behavior.

If the OS expects specific return values as the primary mechanism for
exception reporting, I fail to see how Java, C++, or any other language and
their conventions are relevant. If you had a Java-centric OS, the OS might
simply expect "nothing" (in the same way that you expect nothing from a void
method) when everything is working normally, and expect exceptions when
something bad happens. I believe BlueJ does something like this:
http://www.bluej.org/

And for what it's worth, the main method of a Java program is declared
to return void. I.e.:

public static void main(String args[])

If you wish to signal an error to the OS, you would usually use the
"Runtime.exit(int status)" method. See
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Runtime.html#exit(int)

- Oliver

 

[Noah Roberts]

FWIW, on the very next line, Bent wrote "(No, it's not an important
point.)"

If you are correct in what you point out below then it is not only not
important it is completely meaningless.

From the text you've quoted, even if you omit the parenthesis that
follows, I don't see where Bent implies "C++ is not as good as Java". This
is an example of what I was referring to when I mentioned psychological
projection. Bent simply stated the fact that chips exist which process Java
bytecode natively.

And that none exist to process C++ "instructions".

From there, you inferred that Bent was making a statement

about the merits of Java versus C++. I don't think Bent intended for that
interpretation.

Well perhaps he wasn't infering Java was thus better than C++ but he
was certainly stating that this was something Java does that C++
doesn't. Either way it is a meaningless comparison between compiled
Java vs. an apparently less than compiled form of C++.