On Java and C++

[Roedy Green]

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.

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

The point we Java folk make is that what we call memory leaks are
basically handled. They can't happen unless the JVM designer has blown
it.

There are a few packratting gotchas you have to specifically watch out
for. We have tools called profilers for detecting the others. Memory
allocation is generally not a problem except in very complex programs.
Nearly all of us Java folk came originally from a C++ background, so
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.

 

[Roedy Green]

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

I am sure there are many application for which that is true, e.g.
device drivers, JVMs, Microsoft utilities, matrix math packages.

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.

It all depends on what you are trying to do which tool is best.

And would you kindly can the snide ad hominems. We are discussing
languages, not people. see http://mindprod.com/jgloss/adhominem.html

 

[Roedy Green]

What is it in Java that makes it
less low-level in a similar problem than Java?

In C++ you have quite a variety of addressing operators
.., ->, prefix &, postfix &, prefix *, postfix *, :: (in a way),
overloaded operators and probably some I overlooked.

In Java there is only one, the dot.

 

[Ian Collins]

In C++ you have quite a variety of addressing operators
., ->, prefix &, postfix &, prefix *, postfix *, :: (in a way),
overloaded operators and probably some I overlooked.

In Java there is only one, the dot.

Which is kind of what us C++ types strive for with our smart pointers

Except ours is the ->

 

[Roedy Green]

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.

 

[Roedy Green]

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

To assert you independendence in Java, you don't rebel against the
trivial conventions. Metaphorically speaking, you don't just wear a
nose ring to spite your parents. You express your creativity at a
higher level.

The advantage is, it is pretty easy for any Java programmer to come
along and make sense of any of your low level code with almost no
effort. All the low level stuff is done in the most boring idiomatic
standard way. The problem is always trying to figure out how it all
fits together..

This stereotypical coding style also means you can dig into anybody
else's code with relatively little effort to learn from it or change
it or override it. Java coding is anything but tricky.

 

[Roedy Green]

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.

Being team LEADER is quite different from team MEMBER. Autocrats can
succeed, but only as leader.

Being team leader is incredibly fun if you have some supportive
members. Tons of work get done, all as if you had done it yourself,
but without the effort. Your team keeps you from doing stupid things
and keep up the enthusiasm with a constant stream of ideas. Even if
you are dog tired the team keeps on plugging.

When the team gets into the groove everyone feels it. Everyone is
energised. It is just magical. I would literally fall in love with my
team, so pleased at the way they gave me this power to create so
effortlessly. After dealing with computers, folk who do what I mean
rather than do what I say are such a relief.

 

[Roedy Green]

I know all about that.

You seem to have forgotten the difference between email and
newsgroups. These are public posts not done exclusively for your
highness's entertainment.
..

 

[Roedy Green]

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

My original peeve in Java was making byte signed. It should have been
unsigned by default or there should have been an separate unsigned
primitive.

The original I/O library is a dog's breakfast. There is no
orthogonality. It as though every class were written by a different
programmer confined in solitary.

Conversion methods lack a consistent naming convention.

Casting should have been a postfix operation.

I think we will come to regret type erasure in generics. It has added
too much craziness and means you lose track of type info on
serialization. You can't even implement ArrayList with its features
without cheating.

For C++ I think I would nail down the names and sizes in bits of each
primitive the way Java does. I would see what could be done to reduce
the number of addressing modes and operators. I would either define
some additional operators to use in overloading or allow users to
specify the new operators so that you don't have ambiguity. C++
reuses the same operators for unrelated functions. I have always found
reusing the shift operator for I/O offensive.

 

[Chris Smith]

In C++ you have quite a variety of addressing operators
., ->, prefix &, postfix &, prefix *, postfix *, :: (in a way),
overloaded operators and probably some I overlooked.

As an aside to the conversation, there is no postfix * or postfix &. I
presume you are thinking of type declarations, but these symbols are
applied as prefix syntax to the identifier in a type declaration, not as
a postfix to the type. True, though, the syntax is certainly more
complex. This isn't fundamentally a syntactic problem, though... it's
fundamentally a matter of memory model complexity. Case in point: the
C++ language would be no simpler for having the "." operator
automatically dereference pointers when applied to them; quite the
contrary, as a matter of fact.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

Yes, you can use char[] (or byte[]), but as you said it has no support,
so nobody uses it (as opposed to String, which is more heavily supported
than any C/C++ strings version). It is VERY rare Java programmer who
would spend time deciding which string representation to use.

True, true, except not quite. There are certainly a number of choices
in Java for representing a character sequence, depending on the
requirements of the situation. Sometimes, for example, it's more
efficient to do string operations directly on a java.nio.CharBuffer for
performance reasons. The Swing JPasswordField class has a getPassword
method that returns a char[] so that the information can be cleared from
memory immediately after use. String wouldn't work for that, because
it's immutable... the information would survive in RAM or swap space
until the GC reclaims the memory and allocates it to a new object.
There are also java.lang.StringBuilder and the older
java.lang.StringBuffer, for working with rapidly mutating strings in a
way that minimizes copying of information.

Certainly not as bad as the situation in C++, since all of these
alternatives are rare and (with the exception of the now-outdated
StringBuffer class) necessitated by the varying requirements of
different situations. Nevertheless, it's not quite so clear-cut as it
sounded from your post.

Of course, String is used 99.5% of the time, and there are easy ways to
convert back and forth to/from the other options most of the time, and a
common interface java.lang.CharSequence for all but the char[]
possibility.

It also makes different pieces of software much more compatible.

Bingo. There are a lot of things that would make sense about freedom of
choice if you only had to deal with your own code.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Walter Bright]

For C++ I think I would nail down the names and sizes in bits of each
primitive the way Java does.

D does that.

I would see what could be done to reduce
the number of addressing modes and operators. I would either define
some additional operators to use in overloading or allow users to
specify the new operators so that you don't have ambiguity. C++
reuses the same operators for unrelated functions. I have always found
reusing the shift operator for I/O offensive.

I agree that using operators for unrelated functions is a bad design
idea. Enshrining iostreams' use of << and >> for non-arithmetic purposes
in the Standard was a worse idea, as it legitimizes such uses.

Operator overloading should be used only for the purpose of making user
defined types work like built-in types.

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

 

[Chris Smith]

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

Sorry to jump in, but it's terribly misleading to call finalizers the
Java equivalent of RAII, even with all the qualification above. Without
a doubt, try/finally is the Java equivalent of RAII, with all that is
implied by the asymmetry of the two. I'd hate to see someone misled
into using a finalizer for this.

So what are finalizers good for? Causing programs to run out of memory
by interfering with the garbage collector. That, and pretty much
nothing else, except for MAYBE the possibility of displaying diagnostic
messages telling programmers that they forgot to close a resource, but
it would be best to disable that in a production build to avoid the
program correctness problems that finalizers imply; some kind of ant
magic, perhaps.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Chris Smith]

I think we will come to regret type erasure in generics.

"Will come to"? I'd say it more like this: We have been regretting type
erasure in generics for the last year and a half.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Alf P. Steinbach]

* Roedy Green:

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

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. Perversely, I hope you're trolling.

 

[Roedy Green]

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.

See http://mindprod.com/jgloss/sscce.html

 

[Roedy Green]

Bingo. There are a lot of things that would make sense about freedom of
choice if you only had to deal with your own code.

One of the more remarkable things about Java is how easily code from
different sources can be cobbled together.

Everything follows the same commenting conventions for example so you
can create Javadoc (automatically generated documentation) as a
unified whole.

This blending works because, for example a HashMap from Source A will
be the exact same beast as a HashMap from Source B. The collection
can be passed freely back and forth without special glue.

Even when you use vendor specific implementations like SQL, JCE
(cryptography), JMF (media), JavaMail (email), vendor packages all
hook up using the same API. Sun has a defined a standard pluggable
API for darn near everything.

You can plug in a free implementation, or a high performance one, or a
special features one. You can have different customers with different
service providers all running the exact same object code.

 

[Luc The Perverse]

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

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

[blah blah blah JVM blah blah]

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

I definately hear a vacuum...

If you think you are being witty, vacuum boy, you are falling short.

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.
You can't ignore counter arguments and expect people not to remember that
one post ago you posted something grossly inaccurate.

You hide behind a thin veil of intelligence - but it only works among the
ignorant. Don't argue with experts about things you don't know. You only
succeed in making yourself look stupid. Almost as stupid as me having to
point this out to you.

 

[Luc The Perverse]

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.

And then pass it on to their children

 

[Roedy Green]

Operator overloading should be used only for the purpose of making user
defined types work like built-in types.

If operator overloading comes to Java, I would hope that matrix
overloaded plus would not use + (already confusingly meaning both
addition and concatenation See
http://mindprod.com/jgloss/gotchas.html#CONCATENATION
)

I would hope they would use a high Unicode character that looks like +
but would not easily be confused with it such as \u2a01

see http://mindprod.com/jgloss/unicode.html to view the glyphs.