On Java and C++

[Noah Roberts]

The other huge benefit is platform independence. Java has everything
removed that would temp you to write platform dependent code.

Well, that is one area where Java *can't* be used then isn't it.

Another can't. Where is the can?

 

[Roedy Green]

You don't like Sun Style? I find it not worse than any other, and it has
advantage that most Java programmers use it. In C, for example, Linux
core uses one style, and Gnu uses other, incompatible style, and
Microsoft, of course, uses third.

1. A Java shop can adopt Sun style which every new programmer knows
since they have seen it ad nauseam in the Sun classes.

2. Or a shop can adopt its own more rigid super set of Sun rules.

3. Or a shop can adopt its own style.

4. Or a shop can adopt chaos and start blood feuds between programmers
to poison the coffee of the programmers who reformat "their" code and
deal with repository false deltas.

How is a C++ shop better off having only choices 3 and 4?

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

 

[Noah Roberts]

Mixing exception handling and memory management boggles the human
mind.

Only one incapable of learning very simple techniques to make it a
non-issue.

http://www.hackcraft.net/raii/

Note that this won't work in Java. You can't use this technique to
clean up resources like handles and other resources that are not memory
related as you can't depend on the deallocation of any object in your
code; GC picks it up when it wants to.

There are also the three exception guarantees, which are applicable in
ANY language, that also make exception handling in C++ less risky.

If you aren't capable of avoiding a memory leak in an exceptional
situation then you can't handle any other kind of leak and believe
me...the problem exists in ANY language that has exceptions as there
are numerous resources that you gather and have to release that are not
memory related and so you can't use GC as a crutch for that.

So, if your mind is boggled by memory and exception handling then you
better stick to simple problems.

 

[=?ISO-8859-1?Q?Martin_Vejn=E1r?=]

[5] Java doesn't have explicit deletes. The garbage
collection is expected to take care of things. (There are
some exceptions; a FileOutputStream for example will be
left open indefinitely, even if the reference is lost.)

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

 

[Roedy Green]

Learning C++ is marginally more difficult than learning Java.

I used to be a die hard C++ advocate - but the added complexity doesn't
really add a great deal of usability; but it is great for obscuring the
meaning of the code.

Stroustrup wrote a book about his trials designing C++ called the
Design and Evolution of C++ with a sprouting oak tree on the cover. He
was heavily constrained by his committee of C users who insisted on
strict upward compatibility. The language was designed and implemented
a bit at a time. He was never permitted to have a reintegration/tidy
up phase.

I felt much better about C++ knowing at Stroustrup was on my side in
wanting a cleaner language. It was just he was not forceful enough to
persuade his committee of bosses focused on the current job (which was
not designing a new language) of the need.

I think of computer languages as like species of dinosaur. Each new
species can build on the last and do one new "trick". It would be
silly to expect one early dinosaur to be the ultimate. Because others
built on the shoulders of its design does not detract from the
"pioneering" work of the earlier species.

People like to pretend their current favourite is the end point in
language evolution. Getting too attached just slows evolution. We
have a long way to go.

We will have to give up more and more fine control, and let more and
more programming be handled by the augmented equivalent of CSS style
sheets. We will have to get used to the idea of specifying the
desired results and letting computers figure out the best algorithms.

The big change will be the effect of the SCID on language design. A
program will become a set of structured data describing how you want a
computer to behave. It won't just be a text stream. It will consist of
binary data, dialogs, images, internationalisation, cross references,
declarations, rules of thumb, style sheets, spreadsheets, PET tables,
examples, online/offline documentation, algorithms that can be
displayed in dozens of different ways, even flow charts.

 

[Remon van Vliet]

Only one incapable of learning very simple techniques to make it a
non-issue.

http://www.hackcraft.net/raii/

Note that this won't work in Java. You can't use this technique to
clean up resources like handles and other resources that are not memory
related as you can't depend on the deallocation of any object in your
code; GC picks it up when it wants to.

There are also the three exception guarantees, which are applicable in
ANY language, that also make exception handling in C++ less risky.

If you aren't capable of avoiding a memory leak in an exceptional
situation then you can't handle any other kind of leak and believe
me...the problem exists in ANY language that has exceptions as there
are numerous resources that you gather and have to release that are not
memory related and so you can't use GC as a crutch for that.

So, if your mind is boggled by memory and exception handling then you
better stick to simple problems.

It's quite tricky to be really condecending and really wrong at the same
time but hey, somehow you managed. Rather than question the intelligence and
expertise of someone who offered perfectly valid points you may want to
consider either actually having a look at Java instead of browing Java
newsgroups ready to jump in on the first sigh of a troll. I'd be more than
interested in even a single practical example of these resource/exception
issues of Java you speak of that are so much easier in C++...just one..

 

[Remon van Vliet]

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.

Three things I _really_ hate about Java.

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

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

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.

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.

I don't think one is better than the other but common, these are just
bad arguments.

You do think one is better than the other, it's just a flawed way of
reasoning. Also, all arguments you mentioned in your posts range from
somewhat doubtful to factually inaccurate. You're just bashing, which is a
waste of time for people that bother reading this. Move along.

 

[Walter Bright]

Only one incapable of learning very simple techniques to make it a
non-issue.

http://www.hackcraft.net/raii/

There's another way to do it - scope guard. Here's an article on it:
http://www.digitalmars.com/d/exception-safe.html

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

 

[Remon van Vliet]

[5] Java doesn't have explicit deletes. The garbage
collection is expected to take care of things. (There are
some exceptions; a FileOutputStream for example will be
left open indefinitely, even if the reference is lost.)

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

Have you ever used Java and actually ran into an issue that requires RAII?

 

[Alf P. Steinbach]

* Remon van Vliet -> Noah Roberts

I'd be more than
interested in even a single practical example of these resource/exception
issues of Java you speak of that are so much easier in C++...just one..

All external resources.

They're not "so much easier" to handle in C++. In fact they're /very
difficult/ to handle correctly in C++. However, C++ offers facilities
that make it practically possible to prevent such problems from arising.

People who come from e.g. Java or C tend to not see those issues as
problems, because in those languages there's just no hope of dealing
preventively with fundamental resource leak issues, so the pragmatic
approach of "if it becomes a real problem, let's deal with that concrete
real problem" is applied instead of designing in any guarantee from the
start. Pick up any C or Java code dealing with external resources of
any kind, and more often than not, there's a potential resource leak
staring the C++ programmer in the eye. However, the C++ programmer
would be wrong to chastise the C or Java programmer for that, because
most probably the resource leaks will be consequences of the intentional
pragmatic approach to dealing with the languages' shortcomings: those
potential leaks won't, in general, be actual problematic leaks.

Add to that that C++ is so infernally huge and complex, like COBOL or
PL/1, that it's seldom used correctly by the average programmer.

And in sum that means that the C or Java code may actually have less
relevant resource leaks than the equivalent average programmer's C++
code. Only for the critical support code written by an expert or
experts does C++ shine. Because there the potential can be realized.

 

[Remon van Vliet]

There's another way to do it - scope guard. Here's an article on it:
http://www.digitalmars.com/d/exception-safe.html

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

What point am i missing if i mention the "finally" block in Java?

 

[Remon van Vliet]

* Remon van Vliet -> Noah Roberts

All external resources.

I think this is factually untrue. So, a practical example please?

They're not "so much easier" to handle in C++. In fact they're /very
difficult/ to handle correctly in C++. However, C++ offers facilities
that make it practically possible to prevent such problems from arising.

People who come from e.g. Java or C tend to not see those issues as
problems, because in those languages there's just no hope of dealing
preventively with fundamental resource leak issues, so the pragmatic
approach of "if it becomes a real problem, let's deal with that concrete
real problem" is applied instead of designing in any guarantee from the
start. Pick up any C or Java code dealing with external resources of any
kind, and more often than not, there's a potential resource leak staring
the C++ programmer in the eye.

Perhaps said C++ programmer just isnt overly familiar with Java. It seems to
be the red line through these kind of threads.

However, the C++ programmer would be wrong to chastise the C or Java
programmer for that, because most probably the resource leaks will be
consequences of the intentional pragmatic approach to dealing with the
languages' shortcomings: those potential leaks won't, in general, be actual
problematic leaks.

Add to that that C++ is so infernally huge and complex, like COBOL or
PL/1, that it's seldom used correctly by the average programmer.

Once again this sounds like a C++ developer with a superiority complex.
"Average programmers" here and there. Fact remains i still need to hear of a
external resource leak problem that's consistently easier to deal with in
C++ compared to Java.

And in sum that means that the C or Java code may actually have less
relevant resource leaks than the equivalent average programmer's C++ code.
Only for the critical support code written by an expert or experts does
C++ shine. Because there the potential can be realized.

"Critical support code"? like?

 

[Noah Roberts]

It's quite tricky to be really condecending and really wrong at the same
time but hey, somehow you managed. Rather than question the intelligence and
expertise of someone who offered perfectly valid points you may want to
consider either actually having a look at Java instead of browing Java
newsgroups ready to jump in on the first sigh of a troll. I'd be more than
interested in even a single practical example of these resource/exception
issues of Java you speak of that are so much easier in C++...just one..

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.

Why do I question your ability to comprehend the written word? Because
I _never_ said anything was easier in C++ than Java or the other way
around. The one thing I did say that could even REMOTELY be considered
such was to say that RAII won't work and I already gave the reason why
- you can't depend on the timing of deallocation in Java and you have 0
control over it.

I am more capable in C++ but that is because I rarely use Java. On the
other hand, I am fully capable of coding in Java and have done so many
times.

 

[Noah Roberts]

What point am i missing if i mention the "finally" block in Java?

That nobody said it was impossible to release resources correctly in
exceptional situations in Java.

What was said is that memory management and exceptions are "mind
boggling" issues and I made the point that you better be able to handle
such things because the problem comes up in any language that has
exceptions as there are other resources besides memory that need
correct handling in exceptional situations. I also gave two examples
of how C++ programmers deal with the problem from the ground up.

Also, you could read that article above which shows some shortcommings
of both RAII and finally. However, the "scope guard" appears to be a D
language particular construct so is rather moot in this discussion. It
is just another way to do the same thing...better or not, I pretend to
know.

 

[peter koch]

Remon van Vliet skrev:

I think this is factually untrue. So, a practical example please?

Just one simple example, then: files. The lack of cleaning up of
resources in Java is so common that the Java library calls the
garbagecollector whenever opening a file fails. Often this solves the
problem since the likely reason is that the program leaks this
resource.
You might argue that there's a solution to that problem, but the
"solution" is a hack and it works less than well on a system that is
truly multiuser.

[snip]

Perhaps said C++ programmer just isnt overly familiar with Java. It seems to
be the red line through these kind of threads.

Look at any reasonably sized Java program and look at the try ...
finally constructs. Likely each of these is a place where resources are
to be released. This is evidence that this handling of leaks is a
manual process which makes the program more fragile. Also it causes the
programs to be difficult to maintain. What happens - as an example - to
a

Once again this sounds like a C++ developer with a superiority complex.
"Average programmers" here and there. Fact remains i still need to hear of a
external resource leak problem that's consistently easier to deal with in
C++ compared to Java.

I do not understand you. So long as you encapsulate all resources in a
class, there is no chance of leaks anymore. This is not the case for
Java.

"Critical support code"? like?

I believe most large system out there in the real world relies on C or
C++. Examples are numerous, but I could mention banking,
telecommunication and database management systems. I doubt you will
find any large product of this type in Java. There will be lots of Java
in the "supporting" infrastructure of course - most likely my
homebanking solution is Java. But all the "real" and "heavy" stuff is
most likely C/C++.

/Peter

 

[Noah Roberts]

You do think one is better than the other,

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

Just some helpful hints.

 

[Alf P. Steinbach]

* Remon van Vliet:

I think this is factually untrue. So, a practical example please?

Perhaps the most infamous was the earliest versions of the Swing library
in Java.

isnt overly familiar with Java
superiority complex.
Fact remains i still need

Keep to the technical, not the emotional, please, even in a trolling thread.

"Critical support code"? like?

That's an ungood question, from the perspective of topicality. What's
critical generally depends on the context (e.g. project, organization),
and describing such a context fully, so that a troller can't take issue
with it, isn't possible in a Usenet posting. However, the C++ standard
library is one example of support code that's critical in any context.

 

[Noah Roberts]

I believe most large system out there in the real world relies on C or
C++. Examples are numerous, but I could mention banking,
telecommunication and database management systems. I doubt you will
find any large product of this type in Java. There will be lots of Java
in the "supporting" infrastructure of course - most likely my
homebanking solution is Java. But all the "real" and "heavy" stuff is
most likely C/C++.

Oh I think there are plenty of large projects using Java even if I
can't think of one off the top of my head. Besides, any fact that lots
of large stuff uses C or C++ can be written of as a legacy issue
anyway. Millions and millions of lines of code don't get turned over
to a different language just because it's better (assuming for the
moment that Java is 'better') even if there has been over 10 years to
do so. It just doesn't happen and anyone insisting that it should is
going to be out of work really fast.

 

[peter koch]

Roedy Green skrev:

This is a huge benefit. There are so many addressing modes in C++ that
really don't buy you much other than confusion.

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

The other huge benefit is platform independence. Java has everything
removed that would temp you to write platform dependent code.

The problem here is that Java is not as portable as C/C++. Also, there
are lots of platforms out there where Java simply can't run.

Granted I tend to use a very vanilla style of coding, but platform
specific problems just don't happen to me.

Even writing something as UI-free as a compiler takes a huge amount of
platform-adjusting application code. In Java, that his already
handled by standard libraries.

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.

/Peter

 

[peter koch]

Roedy Green skrev:

[snip]

Stroustrup wrote a book about his trials designing C++ called the
Design and Evolution of C++ with a sprouting oak tree on the cover. He
was heavily constrained by his committee of C users who insisted on
strict upward compatibility. The language was designed and implemented
a bit at a time. He was never permitted to have a reintegration/tidy
up phase.

I felt much better about C++ knowing at Stroustrup was on my side in
wanting a cleaner language. It was just he was not forceful enough to
persuade his committee of bosses focused on the current job (which was
not designing a new language) of the need.

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

http://public.research.att.com/~bs/bs_faq.html

I think of computer languages as like species of dinosaur. Each new
species can build on the last and do one new "trick". It would be
silly to expect one early dinosaur to be the ultimate. Because others
built on the shoulders of its design does not detract from the
"pioneering" work of the earlier species.

But Java was never meant to be a step forward in the evolutionary
chain. It was meant to be simpler and with less capability than C++,
and for that it sacrificed some safety features present in C++ (such as
e.g. const and ability to pass by value) while removing others (such as
pointer manipulators).

People like to pretend their current favourite is the end point in
language evolution. Getting too attached just slows evolution. We
have a long way to go.

We will have to give up more and more fine control, and let more and
more programming be handled by the augmented equivalent of CSS style
sheets. We will have to get used to the idea of specifying the
desired results and letting computers figure out the best algorithms.

We are a long way from that. But if you focus simply on
high-performance, easy-to-use products C++ has come a long way
delivering this.
[snip]

/Peter