On Java and C++

[wellstone9912]

Java programmers seem to always be whining about how confusing and
overly complex C++ appears to them. I would like to introduce an
explanation for this. Is it possible that Java programmers simply
aren't smart enough to understand C++?

This is not merely a whimsical hypothesis. Given my experience with
Java programmers --- the code they write and the conversations they
have --- Occam's Razor points to this explanation. For example,

"Oooh I'm confused about the difference between pointers, references,
and objects! How confusing!"

"Oooh operator overloading confuses me! The expression x + y is so
confusing, who knows what's happening with that? If x and y are
complex numbers, what the hell could x + y mean?"

"Oooh multiple inheritance is so confusing! Though I am both a father
and a programmer, I still find it so confusing how the same object can
be two different things! How confusing!"

"Oooh and virtual bases are so bizarre! I am a student --- myself
'the father' is the same student as myself 'the programmer' --- but
nonetheless the idea of virtual bases is absolutely confounding and
confusing to me!"

Again, Occam's Razor is a valuable tool here. In deciding among
competing hypotheses, choose the simplest one. To impartial observers
of indoctrinated Java programmers, the explanation is simple indeed.

[Oliver Wong]

"Noah Roberts" <ro**********@gmail.com> wrote in message
news:11**********************@i39g2000cwa.googlegr oups.com...

Roedy Green wrote:

On 27 Apr 2006 10:54:17 -0700, "Noah Roberts" <ro**********@gmail.com>
wrote, quoted or indirectly quoted someone who said :

>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.
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 think Roedy is saying that when you work in a team, there are certain
things you can't do (e.g. ignore the conventions of the team). Java helps
you not do those things (by establishing a convention, as opposed to having
each team coming up with their own, so you have to relearn conventions when
switching teams). Or something along those lines.

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.

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

- Oliver

[Oliver Wong]

"Noah Roberts" <ro**********@gmail.com> wrote in message
news:11*********************@i40g2000cwc.googlegro ups.com...

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

That you can't shoot yourself in the foot (or at least not as easily as
in some other languages) seems like a big advantage to me.

- Oliver

[Noah Roberts]

Oliver Wong wrote:

See
http://en.wikipedia.org/wiki/Psychological_projection

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.

[Noah Roberts]

Roedy Green wrote:

However, I know C++ is not the best choice for many others. I know
from first hand, rather than second hand experience. For a start,
there is not even such an animal as a C++ Applet.
Holy crap, you people actually comming up with a can??!! Almost
anyway...I'll count it.

Took you long enough...damn!!!
There is nothing
comparable to rich set of GUARANTEED PRESENT class libraries.
Of course there is something comparable. The whole second half of the
C++ standard specifies the GUARANTEED PRESENT class (and other object
type) libraries.
C++ is
hopeless at platform-independent code.

Not even remotely true.

[The Ghost In The Machine]

In comp.lang.java.advocacy, peter koch
<pe***************@gmail.com>
wrote
on 27 Apr 2006 14:51:39 -0700
<11*********************@u72g2000cwu.googlegroups. com>:

The Ghost In The Machine skrev:

[snip]

"finally" is to RAII as manual transmission is to
automatic, from the looks of things.

Not at all. RAII is to finally what a printing machine is to a pen.
RAII simplifies a nontrivial and tedious task. Or do you always check
for your objects being of the IDisposable type before deciding if you
can leave their destruction to the garbage collector or if you will
have to destroy them manually?
If not - how will your program cope with classes that change?
Also - how do you write generic code if you do not know if you will
have to destroy your objects - except than by using run-time
information?

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.

[.sigsnip]

--
#191, ew****@earthlink.net
Windows Vista. Because it's time to refresh your hardware. Trust us.

[Noah Roberts]

Roedy Green wrote:

On 27 Apr 2006 16:16:20 -0700, "Noah Roberts" <ro**********@gmail.com>
wrote, quoted or indirectly quoted someone who said :

I also don't see how my quoted statement above would lead one to
believe I have never worked in a team...

I would think anyone who had ever worked on a team was familiar with
the ego battles that go on especially over how code should be
formatted. You would have seen the necessity of deciding on project
coding conventions to keep people from each others' throats.

You made several comments of form "conventions are like a
straightjacket", which indicated you had never experienced a situation
where you needed them or where pre-existing conventions eased the
tensions.

You appeared to believe they had no value at all.

You also sounded independent and argumentative, not the type of person
who can stand working in a corporate team environment for very long.
You have to bite your tongue till it bleeds.

This entire avenue of argument is not only riddled with ego and
argumentative remarks but it is also entirely beside the point even if
true.

[Chris Smith]

Martin Vejnár <av****@volny.cz> wrote:

Could you please give me equivalent Java code for this...

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

...and for this?

// C++
func()
{
class_with_possible_ressource cwprs[1000];
dosomethingwith(cwprs);
}

No. :) I think you already know the answer. The latter would generally
be done by modifying the structure a bit. If there's really a need to
hold all those resources open at the same time, then some kind of
aggregate class could be written whose close method attempts to close
all of the resources in a collection.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

[Mishagam]

Mishagam wrote:

OK. True, the D language has cleaned up old C inheritances C++ suffers
from. However, I doubt anyone would switch to D unless you provide a
large class library for almost everything. That's the only true
benefit of Java, the large std library.

Yes, large standard library helps. However Perl, Python, C# have
something close.
I would give additional benefits (for me).
a) You don't have to think should you include fields of have variables
as objects or references or pointers. It is decided for you usually
close to optimal way (closest to references).
b) You don't have to bother to use auto_pointer (not working with
collections) or new delete or automatic destructor. It is decided for
you to use something like auto_ptr but much better.
c) You don't have to decide about programming style. Sun provided
standard Java style.
d) You don't have to decide about naming of files and classes - they are
the same.
e) Logical package directory structure is forced on you.
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.
g) you don't have to choose between long int, unsigned int, WORD, DWORD,
size_t .... - close to optimal choice if forced on you.
h) You don't decide do you use internal or external functions
definitions, or do you use macro. - close to optimal choice if only one
possible.
i) You don't have to decide if you use methods or define new operators.
Java choice is sometimes more verbose, but usually more clear.
...
As you can guess, I can continue.
Dropping all these choices first - makes programming easier, you have
less things to bother about, second - makes language smaller and more
easy to understand. Of course such approach could lead to very bad
language - but Java luckily has good design. And I thing C++ standard
committee just made bad design - introducing complexities which doesn't
add enough benefits to justify them.

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 .

[Mishagam]

peter koch wrote:

Roedy Green wrote:

However, I know C++ is not the best choice for many others. I know
from first hand, rather than second hand experience. For a start,
there is not even such an animal as a C++ Applet. There is nothing
comparable to rich set of GUARANTEED PRESENT class libraries. C++ is
hopeless at platform-independent code.

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]

Noah Roberts schrieb:

Oliver Wong wrote:

See
http://en.wikipedia.org/wiki/Psychological_projection

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]

"Alf P. Steinbach" <al***@start.no> wrote in message
news:4b************@individual.net...

* Roedy Green:

On Fri, 28 Apr 2006 01:19:40 +0200, "Alf P. Steinbach"
<al***@start.no> wrote, quoted or indirectly quoted someone who said :

Apart from the lack of connection from premise to conclusion, that's not
a fact, it's an excuse for sloppiness.
In java, memory leaks and packratting are quite different problems and
require quite different tools to detect them and quite different
solutions.

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.

If you wished, you could make the same distinction in C++, but you
don't because the distinction does not matter so much for C++.
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).

there is no way on earth you will convince us that C++ memory
allocation is easier and more fool proof, especially when you don't
even claim to know Java.

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]

Roedy Green wrote:

On 27 Apr 2006 10:59:36 -0700, "Noah Roberts" <ro**********@gmail.com>
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]

Oliver Wong wrote:

"Alf P. Steinbach" <al***@start.no> wrote in message
news:4b************@individual.net...

* Roedy Green:

On Fri, 28 Apr 2006 01:19:40 +0200, "Alf P. Steinbach"
<al***@start.no> wrote, quoted or indirectly quoted someone who said :

Apart from the lack of connection from premise to conclusion, that's not
a fact, it's an excuse for sloppiness.

In java, memory leaks and packratting are quite different problems and
require quite different tools to detect them and quite different
solutions.

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.

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]

"peter koch" <pe***************@gmail.com> wrote in message
news:11**********************@e56g2000cwe.googlegr oups.com...

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]

Mishagam wrote:

peter koch wrote:

Roedy Green wrote:

However, I know C++ is not the best choice for many others. I know
from first hand, rather than second hand experience. For a start,
there is not even such an animal as a C++ Applet. There is nothing
comparable to rich set of GUARANTEED PRESENT class libraries. C++ is
hopeless at platform-independent code.

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.

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]

"Noah Roberts" <ro**********@gmail.com> wrote in message
news:11**********************@e56g2000cwe.googlegr oups.com...

Oliver Wong wrote:

See
http://en.wikipedia.org/wiki/Psychological_projection

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]

Luc The Perverse wrote:

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]

The Ghost In The Machine wrote:

In comp.lang.java.advocacy, peter koch

Not at all. RAII is to finally what a printing machine is to a pen.
RAII simplifies a nontrivial and tedious task. Or do you always check
for your objects being of the IDisposable type before deciding if you
can leave their destruction to the garbage collector or if you will
have to destroy them manually?
If not - how will your program cope with classes that change?
Also - how do you write generic code if you do not know if you will
have to destroy your objects - except than by using run-time
information?

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]

peter koch wrote:

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]

Bent C Dalager wrote:

In article <11*********************@e56g2000cwe.googlegroups. com>,
Noah Roberts <ro**********@gmail.com> wrote:

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.

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]

On 28 Apr 2006 08:37:45 -0700, "Noah Roberts" <ro**********@gmail.com>
wrote, quoted or indirectly quoted someone who said :

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.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

[Noah Roberts]

Mishagam wrote:

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]

On Fri, 28 Apr 2006 14:37:29 GMT, "Oliver Wong" <ow***@castortech.com>
wrote, quoted or indirectly quoted someone who said :

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.
--
Canadian Mind Products, Roedy Green.
http://mindprod.com Java custom programming, consulting and coaching.

[Oliver Wong]

"Noah Roberts" <ro**********@gmail.com> wrote in message
news:11*********************@j33g2000cwa.googlegro ups.com...

Bent C Dalager wrote:

In article <11*********************@e56g2000cwe.googlegroups. com>,
Noah Roberts <ro**********@gmail.com> wrote:

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

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 :-) "

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]

Roedy Green wrote:

On 28 Apr 2006 08:37:45 -0700, "Noah Roberts" <ro**********@gmail.com>
wrote, quoted or indirectly quoted someone who said :

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.

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

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

Noah Roberts <ro**********@gmail.com> wrote:

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]

"Noah Roberts" <ro**********@gmail.com> wrote in message
news:11**********************@j73g2000cwa.googlegr oups.com...

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/....html#exit(int)

- Oliver

[Noah Roberts]

Oliver Wong wrote:

"Noah Roberts" <ro**********@gmail.com> wrote in message
news:11*********************@j33g2000cwa.googlegro ups.com...

Bent C Dalager wrote:

In article <11*********************@e56g2000cwe.googlegroups. com>,
Noah Roberts <ro**********@gmail.com> wrote:
>
>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.

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 :-) "

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

[Timo Stamm]

Noah Roberts schrieb:

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.
It is mostly independent of the language. Java is usually compiled to
byte code, and it is much easier to safely run byte code in a sandbox
than machine code.

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.
I think applets are much worse than Flash. They take a long time to
load, their abilities to communicate with the browser (Javascript) is
even worse than Flashs.

It simply doesn't work well to have parts of the interface in
Java/Flash, the other parts in HTML. In my experience, you are better
off sticking either to plain HTML/CSS/JS or a Java Web Start application.

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.
Actually, the current version of the Eclipse based Flash IDE is
available for free. There is also an ActionScript2 open source compiler,
and an alternative to the upcoming ActionScript3 - HaXe - that will
target current and future Flash Players.

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

I must admit that I don't like most Java desktop apps. Swing just
doesn't feel like a native GUI. SWT is much better than Swing, but it
has disadvantages too.
Timo

[The Ghost In The Machine]

In comp.lang.java.advocacy, Mishagam
<no*****@provider.com>
wrote
on Fri, 28 Apr 2006 15:57:11 GMT
<rX******************@tornado.southeast.rr.com>:

The Ghost In The Machine wrote:

In comp.lang.java.advocacy, peter koch

Not at all. RAII is to finally what a printing machine is to a pen.
RAII simplifies a nontrivial and tedious task. Or do you always check
for your objects being of the IDisposable type before deciding if you
can leave their destruction to the garbage collector or if you will
have to destroy them manually?
If not - how will your program cope with classes that change?
Also - how do you write generic code if you do not know if you will
have to destroy your objects - except than by using run-time
information?

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.

The little I've studied the issue indicates it's more
than that. Apparently, the general idea is that a resource
can be destructed at any time, and in a human-predictable
fashion. (This includes during exceptions.)

C++ destructors here are merely a means to an end.
It works if you work with objects as values, it doesn't work if you work
with pointers or references.
Java has neither pointers nor references (although one could consider
any Object a pointer to some sort of data structure, really, and
any Object function parameter is passed by reference, allowing
modification methods and/or field assignments to that parameter).

Personally, I prefer smart pointers in C++, when I
use pointers at all, and tend to use reference counts.
(std::auto_ptr<> is IMO a horrid hack.) There are a number of
problems with reference counts, though; the main one is the
"floating loop" problem.
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.

Depends on the Object and the Collection. TreeMap, for instance,
cannot work with Objects that aren't Comparables without a
Comparator.

I don't see major problems in this area, though, except that
the List interface requiring implementation of a get by index
is a little weird.

--
#191, ew****@earthlink.net
Windows Vista. Because it's time to refresh your hardware. Trust us.

[Noah Roberts]

Timo Stamm wrote:

Noah Roberts schrieb:

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.

Actually, the current version of the Eclipse based Flash IDE is
available for free. There is also an ActionScript2 open source compiler,
and an alternative to the upcoming ActionScript3 - HaXe - that will
target current and future Flash Players.

I did not know any of that...obviously. Thanks for the info.

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

I must admit that I don't like most Java desktop apps. Swing just
doesn't feel like a native GUI. SWT is much better than Swing, but it
has disadvantages too.

My opinion is based more on the general clunkyness of the
implementations for my chosen OS. Java seems to work quite a bit
better on Windows than on Linux. C++ options for cross-platform
development (which are numerous) actually provide an end result that
is, in my opinion, a better all around solution that runs better on the
target platforms. Sure, there might be a little more work but not much
really...not when I use the tools available to me instead of
reinventing the wheel only to come up with a square one.

[Andrey Kuznetsov]

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

His word are clear... for every one who familiar with java.
Its just different levels.

True leaks are just another level - they can appear only if JVM has a heavy
bug.
Only JVM vendor should/can fix such bugs.
You can't fix JVM, you have to write SSCCE and send it to JVM vendor.

Andrey

--
http://uio.imagero.com Unified I/O for Java
http://reader.imagero.com Java image reader
http://jgui.imagero.com Java GUI components and utilities

[Noah Roberts]

Andrey Kuznetsov wrote:

His word are clear... for every one who familiar with java.
Its just different levels.
And that is my interpretation. I don't go along with the null set
interpretation of his statements. So apparently, if I am
misinterpreting what he said then you are also and that makes at least
three people now.
True leaks are just another level - they can appear only if JVM has a heavy
bug.
Only JVM vendor should/can fix such bugs.
You can't fix JVM, you have to write SSCCE and send it to JVM vendor.

That is a pretty major can't but isn't so different I suppose than a
buggy compiler. However, a buggy compiler could theoretically be fixed
yourself if it is OS. On the other hand even fixing java on a single
platform involves cooperation from Sun does it not? I know there are
licensing issues I just don't know how controlling they are.

You would also necessarily have to get all your users to switch to your
fixed VM. Your fixed compiler just generates a now good executable you
can pass on.

That all depends on OS versions of the compilers and VMs involved...as
is the case in any other proprietery system if you don't have the
source you are at the mercy of the vendor...in other words fucked.

Anotehr point though is that with a buggy compiler you have a broken
program, not a program that only breaks on one VM.

[TJW]

Hello,

On 28 Apr 2006 09:34:56 -0700 "Noah Roberts" <ro**********@gmail.com> writes:

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

As a purely outside observer to this thread, I found this
statement fairly amusing considering the following text that has
appeared in this thread.

On 28 Apr 2006 07:53:46 -0700 "Noah Roberts" <ro**********@gmail.com> writes:
Ahhh yes, the last ditch attack from the weak.
On 27 Apr 2006 11:08:42 -0700 "Noah Roberts" <ro**********@gmail.com> writes:
Only one incapable of learning very simple techniques to make it a
non-issue.
...
So, if your mind is boggled by memory and exception handling then you
better stick to simple problems.
On 27 Apr 2006 12:06:16 -0700 "Noah Roberts" <ro**********@gmail.com> writes:
Well since you can't read and/or comprehend what you are reading I
think it would be a waste of time and effort to offer any proof of
anything to you...besides being unwilling to prove something I didn't
bring up.
On 27 Apr 2006 12:19:47 -0700 "Noah Roberts" <ro**********@gmail.com> writes:
You need to have your mind reading ability rechecked. It isn't working
anymore. IMHO you shouldn't have grown to depend on it anyway.

Your logical reasoning circuitry could use some work too...
On 27 Apr 2006 16:27:49 -0700 "Noah Roberts" <ro**********@gmail.com> writes:
This is just stupid...almost as stupid as
me having to point this out to you.

I definately hear a vacuum...
On 28 Apr 2006 08:54:21 -0700 "Noah Roberts" <ro**********@gmail.com> writes:
Come back when you can understand.

And perhaps my personal favorite:

28 Apr 2006 08:29:24 -0700 "Noah Roberts" <ro**********@gmail.com> writes:
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.

Sometimes the threads started by the trolls end up the most
informative ...
Good Luck,
-TJW

[The Ghost In The Machine]

In comp.lang.java.advocacy, Mishagam
<no*****@provider.com>
wrote
on Fri, 28 Apr 2006 15:59:33 GMT
<FZ******************@tornado.southeast.rr.com>:

peter koch wrote:

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?

I think he's serious, but then RAII may or may not be a big issue. I
for one can't tell at this point.

The typical usage paradigm is opening a file:

[a] normal case.

File f = ...; // optional
FileInputStream fs = new FileInputStream(f);

....

fs.close();

[b] with exception handling.

File f = null;
FileInputStream fs = null;

try
{
f = ...;
fs = new FileInputStream(f);
doSomething(fs);
}
catch(Exception ex)
{
log.error("Oops", ex);
}
finally
{
if(fs != null) try { fs.close(); } catch(Exception ex2) {}
}

I've seen prettier but the general idea is clear enough.

In C++:

{
std::ifstream ifs("pathname");
doSomething(ifs);
}

is far simpler; if an exception is thrown std::ifstream::~ifstream
is also guaranteed to be called. However, I have no idea what

{

std::ifstream ifs1("pathname");
std::ifstream ifs2(ifs1);
doSomething(ifs1);
doSomething(ifs2);
}

or

{

std::ifstream ifs1("pathname");
std::ifstream ifs2("path2");

ifs1 = ifs2;

doSomething(ifs1);
doSomething(ifs2);
}

are intended to do; the most logical would be the C++ equivalent
of dup2(). In Java, one runs into object aliasing issues:

FileInputStream fs1 = ...;
FileInputStream fs2 = fs1;

in the foregoing fs1 and fs2 refer to *the same object*. This is either
a bug or a feature.

--
#191, ew****@earthlink.net
Windows Vista. Because it's time to refresh your hardware. Trust us.

[The Ghost In The Machine]

In comp.lang.java.advocacy, Noah Roberts
<ro**********@gmail.com>
wrote
on 28 Apr 2006 07:58:43 -0700
<11**********************@v46g2000cwv.googlegroups .com>:

Roedy Green wrote:

However, I know C++ is not the best choice for many others. I know
from first hand, rather than second hand experience. For a start,
there is not even such an animal as a C++ Applet.
Holy crap, you people actually comming up with a can??!! Almost
anyway...I'll count it.

Took you long enough...damn!!!

I should point out that there *is* a C++ applet -- sort of.
It's the same as with C++ threading, an outside API. In the
case of the "applet" it's ActiveX.

This is not all that standard of course but ActiveX is widely
used internally in Microsoft software (it's not used on the Web,
for reasons related to security).

There is nothing
comparable to rich set of GUARANTEED PRESENT class libraries.

Of course there is something comparable. The whole second half of the
C++ standard specifies the GUARANTEED PRESENT class (and other object
type) libraries.

C++ is
hopeless at platform-independent code.

Not even remotely true.

The main problem with C++ is that the binaries are platform-dependent.
Java does not have this issue.

However, the C++ problem can be worked around by doing
something along the lines of Gentoo: build the binaries
locally. Whether this works or not for the individual
user depends on licensing and CPU speed. Distributing
multiple binary types and standardizing on a single platform
(which we're periously close to doing anyway, at least on
the user's deskop) are also possible.

Java has obfuscation ability which suggests conflicting masters.
But then code has conflicting masters anyway; it's a tradeoff
between loading/execution expediency and debuggability, among
other things. Some code also hides trade secrets, such as
license checking algorithms and/or private keys.

--
#191, ew****@earthlink.net
Windows Vista. Because it's time to refresh your hardware. Trust us.

[Noah Roberts]

TJW wrote:

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.

Sometimes the threads started by the trolls end up the most
informative ...

You can come to any conclusion you want and provide whatever view you
wish people to see if you quote people out of context.

For example...the above (yes, I am taking liberty in my selection).
That was in reply to someone telling me I'm a fundamentalist religious
nut because my parents apparently are because my name is Noah. That is
an incredibly stupid statement to make (which was just one more in a
long line of incredibly stupid statements, generalizations, and ad
hominems) and had nothing to do with anything.

Everything in my reply fit, including the admision that the reply
itself was a personal attack that was not on topic...something you
neatly snipped from my post.

Your post is no more informed, balanced, or interesting than the
person's to whom that above quote replies to.

[Phlip]

Andrew McDonagh wrote:

go Ruby ..Go Ruby...Go Ruby

Ruby:

- a cheap imitation of Smalltalk that stretches
too far, all the way to Perl. (And don't get
me started about Perl!)
- syntax crippled by an early design decision
to make parens on method calls () optional.
this has since been adjusted, leaving the
language whitespace-sensitive
- the require('module') command dumps everything
into your module, even if you don't want it,
even if it causes a circular dependency
- if you name your class the same as some other
class, somewhere, then they become one class!
- a dynamic and interpreted model that makes
compiling and optimizing absolutely impossible
- permits a super-terse style that everyone
exploits to show off

Java:

- write once debug everywhere
- forgets everything on all its CLASSPATHs at
the drop of a hat
- projects must depend on fragile and
programmer-hostile tools, like ANT,
that make easy things hard and hard
things absurd
- impersonates the worst of C++ - typecasts
for simple containers, two different kinds
of type to store a stupid Integer, multiple
String classes, and last but least generics!
- arrays aren't really arrays. But they really
are. Kinda.
- static typing, to flatter Pascal with a vain
impersonation that, instead, forces you to
break typesafety just to get anything done
- everything must be inside a class. You can
still write object-disoriented crap, but at
least it's inside a class!
- pretends you broke something if your file
name differs from your class name. Figure
it out, stoopid!
- when a smart editor like Eclipse can finish
every line for you, it makes you wonder
what the language is _there_ for!
- 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
- comes with an advertising campaign capable
of making inexperienced programmers think
all this cruft is "lean and elegant".
- 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
- instead of providing a narrow and reasonable
implementation of multiple inheritance like
C++ (or an alternate "mixin" system like
Ruby) we instead get endless lectures,
endlessly repeated by newbies, about why
real programmers don't need multiple
inheritance of implementation
- at least C++ makes some of the benefits
of dynamic typing available. Java instead
enforces such a narrow view of static
typing that you can't even simulate
those benefits
- why the >F---< does Netbeans ask me where
the _same_ JAR files are, _each_ time I
launch it???
- a marketing campaign that teaches newbies
that a language is good if only smart
people can figure out how to use it
- GUIs require block closures and dynamic
typing. But what language does your boss
tell you to write the GUI in???

C++ (deep breath):
- where in memory do you want to
accidentally jump today?
- the only smart pointer that could pass
the 97 committee was one so primitive
and broken that its copy constructor
changes the copied-from object!
- mutable; because constancy is enforced
at compile time, not runtime, yet it
_could_ exploit hardware support
- strings, strings, and more strings. The
ISO Standard string came so late in the
language's history that every serious
library has its own (multiple) string
classes
- what the >F---< does imbue() do???
- void main is neither illegal nor legal!
Some, but not all, compiler-specific
extensions use a __ prefix
- of course RAII can be better than
redundant finally blocks. But _all_
these systems are cheap imitations
of the Execute Around Pattern, which
requires block closures, so objects
can clean themselves up, exception-
safely, deterministically, and
_without_ elaborate destructors
- the majority of the glitches and
common bugs when implementing code
in C++ happen because it's designed
to be efficiently compiled by a
simple compiler. A reinvented language
could make better use of modern
compiler technology
- teachers, bosses, and colleagues make
us use the language because it's
popular, even for inappropriate
situations. This newsgroup gets
a dozen questions per month asking
how to do something that a scripting
language can do
- you can do an "Applet" in C++ trivially,
using ActiveX. And because C++ has no
security model to speak of, anyone
using your applet exposes their browser
to gawd-knows-what-else is out there...
- how many here have _ever_ written a
program with _absolutely_ no undefined
behavior? How many _know_ they did??
- when folks say C++ is portable, they
mean the _compiler_ ports easily to
other platforms. By marrying your
statements to the metal, a C++
implementation forces you to
consider _endless_ portability issues
at port time
- the exception handling model is so
complex it makes me wonder if Bjarne
Stroustrup actually determined how to
write exception-safe programs when
he invented the language

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[Oliver Wong]

"Noah Roberts" <ro**********@gmail.com> wrote in message
news:11**********************@v46g2000cwv.googlegr oups.com...

Andrey Kuznetsov wrote:

True leaks are just another level - they can appear only if JVM has a
heavy
bug.
Only JVM vendor should/can fix such bugs.
You can't fix JVM, you have to write SSCCE and send it to JVM vendor.

That is a pretty major can't but isn't so different I suppose than a
buggy compiler. However, a buggy compiler could theoretically be fixed
yourself if it is OS. On the other hand even fixing java on a single
platform involves cooperation from Sun does it not? I know there are
licensing issues I just don't know how controlling they are.

No, there's an open source JVM called SableVM. If you find a bug in
SableVM, you can modify it to fix the bug, without dealing with Sun as an
intermediate step. Note though that Sun owns the trademark "Java", and they
allow you to use the term "Java" with your products as long as your products
pass certain well defined tests. For example, if your product is supposed to
be a Java virtual machine, then it must adhere to the appropriate
specifications. SableVM does, so it is legally allowed to call itself a
"JVM". If you modify SableVM so that it doesn't adhere to the specs, then
you can't call your modified product a "JVM" anymore.

You would also necessarily have to get all your users to switch to your
fixed VM. Your fixed compiler just generates a now good executable you
can pass on.

That all depends on OS versions of the compilers and VMs involved...as
is the case in any other proprietery system if you don't have the
source you are at the mercy of the vendor...in other words fucked.

If there's a bug in a JVM which causes a memory leak, that's a bug in
the JVM, and not a bug in the Java Compiler. I guess the equivalent in C++
(or other languages) would be a bug in the OS (Operating System, not Open
Source). You write a C++ program which request the OS to allocate you some
memory, and then you later request for the OS to deallocate that memory. If
the OS doesn't deallocate that memory, then you're fucked.

If it's an open source OS (e.g. Linux), you could fix it, and then ask
all your users to switch their OSes. If it's a closed source one (e.g.
Windows), you could submit a bug report and hope for the best.

- Oliver

[Timo Stamm]

Noah Roberts schrieb:

Timo Stamm wrote:

Noah Roberts schrieb:

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). I must admit that I don't like most Java desktop apps. Swing just
doesn't feel like a native GUI. SWT is much better than Swing, but it
has disadvantages too.

My opinion is based more on the general clunkyness of the
implementations for my chosen OS. Java seems to work quite a bit
better on Windows than on Linux.

I doubt that the raw JVM performance changes much on different
platforms, but the GUI is obiously less snappy in Java apps than in
native applications, startup time is quite long, and memory requirements
are enormous.

C++ options for cross-platform
development (which are numerous) actually provide an end result that
is, in my opinion, a better all around solution that runs better on the
target platforms.
How do you define "runs better"? I use Java mostly for server
applications, and I can simply copy the war (Web Application aRchive)
from my PPC/OSX box to an Intel/Debian server. There are /zero/ platform
dependencies and performance is not an issue.

Sure, there might be a little more work but not much
really...

I am afraid it takes a lot of effort to make an application fit well on
more than one platform, but I am actually sure that you *can* get better
results.

If you need a secure, easy to distribute programm on as many platforms
as possible without much effort, java web start really shines.

Different requirements, different tools.
Timo

[Andrey Kuznetsov]

> I think applets are much worse than Flash. They take a long time to load,

their abilities to communicate with the browser (Javascript) is even worse
than Flashs.

you should try Opera.
While Firefox needs up to 5 second for applet on my page
(http://reader.imagero.com),
with Opera it starts immediately!

Andrey

--
http://uio.imagero.com Unified I/O for Java
http://reader.imagero.com Java image reader
http://jgui.imagero.com Java GUI components and utilities

[Walter Bright]

Phlip wrote:

- the majority of the glitches and
common bugs when implementing code
in C++ happen because it's designed
to be efficiently compiled by a
simple compiler.

A C++ compiler is probably the most complex of all language compilers.

[Phlip]

Walter Bright wrote:

Phlip wrote:

- the majority of the glitches and
common bugs when implementing code
in C++ happen because it's designed
to be efficiently compiled by a
simple compiler.

A C++ compiler is probably the most complex of all language compilers.

There's a better way to state that item, because otherwise C++ wouldn't
suck, and we all know that's not the case.

Newbie: Why can't I put template bodies in .cpp files?

Guru: Because the linker doesn't have a compiler in it.

Newbie: Why doesn't the linker have a compiler in it?

And so on...

I grant you the point a C++ compiler is complex, but in a bad way...

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[Noah Roberts]

Phlip wrote:
[snip]

And the moral is....
We should all be using Objective-C.

[Phlip]

Noah Roberts wrote:

We should all be using Objective-C.

Maaster!! You have created ... a monster!!

Yes, Igor! By tr-r-ransplanting Smalltalk's virtual dispatch system into zee
skull of my cadaver of zee C language, zee virtual messages shall move zee
arms and zee legs of structs and ints! Und zey vill doo our biddings!! Vee
vill rool zee wooorld!! Mwha-ha-haha!

Vhat vill you call heem, Maaster??

I vill call him... Id.

--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!

[Oliver Wong]

"Walter Bright" <wa****@digitalmars-nospamm.com> wrote in message
news:-8********************@comcast.com...

Phlip wrote:

- the majority of the glitches and
common bugs when implementing code
in C++ happen because it's designed
to be efficiently compiled by a simple compiler.

A C++ compiler is probably the most complex of all language compilers.

COBOL is pretty difficult to parse. It isn't an LL(*) language, like C,
C++ and Java are.

- Oliver

[Monique Y. Mudama]

["Followup-To:" header set to comp.lang.java.programmer.] On
2006-04-27, peter koch penned:

Well... the company I work for also programs (partially) in Java and
it has had lots of portability problems. The Java library (e.g. for
locking of files or creating new processes) simply does not work the
same way when moving between Solaris, Windows and AIX.

Odd. At my first company we did java apps that ran in Solaris and
Windows with almost no trouble. The only real trouble we ran into was
when someone hard coded things like "C:".

That was several years ago, when java was much more immature, too.

--
monique

Help us help you:
http://www.catb.org/~esr/faqs/smart-questions.html

[Andrew McDonagh]

Noah Roberts wrote:

Roedy Green wrote:

However, I know C++ is not the best choice for many others. I know
from first hand, rather than second hand experience. For a start,
there is not even such an animal as a C++ Applet.

Holy crap, you people actually comming up with a can??!! Almost
anyway...I'll count it.

Took you long enough...damn!!!

Wellll..... to be honest (and I'm a long time Java dev who made the
transition from C++) whilst Java does have applets - they are used much
now a days as the concept sucks.

They are good for only simple jobs, anything else and it better use one
of the Java web application approaches.

Applets certainyl aren't somethign I would use to say 'Java is better
than your xyz' because it would be like being proud of acne.

[Andrew McDonagh]

TJW wrote:

Hello,

On 28 Apr 2006 09:34:56 -0700 "Noah Roberts" <ro**********@gmail.com> writes:

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

As a purely outside observer to this thread, I found this
statement fairly amusing considering the following text that has
appeared in this thread.

snipped brilliantly researched response.

v cool TJW.

[Walter Bright]

Phlip wrote:

Walter Bright wrote:

Phlip wrote:

- the majority of the glitches and
common bugs when implementing code
in C++ happen because it's designed
to be efficiently compiled by a
simple compiler.

A C++ compiler is probably the most complex of all language compilers.

There's a better way to state that item, because otherwise C++ wouldn't
suck, and we all know that's not the case.

Newbie: Why can't I put template bodies in .cpp files?

Guru: Because the linker doesn't have a compiler in it.

You can put template bodies in separate .d files in the D programming
language, and it works with a standard linker.

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