Are c++ features a subset of java features?

[Jon Harrop]

Again with the undefined terms.

Safety = no dangling pointers, no buffer overruns, no segmentation faults...

More Java marketing.

You should read up on some other languages: OCaml, SML, Scheme, Lisp,
Haskell, even C#. They all offer these features and more. This is not
specific to Java.

 

[Jon Harrop]

I see. If it's not part of the language specification, it doesn't exist.

The original question was specifically regarding the C++ and Java languages.

Do you have any actual evidence to support that sweeping claim?

Ask in the forums of any languages that support these features. Or just use
Google. Try porting some simple programs from other languages to C++...

 

[Jon Harrop]

In that case I'd say Java loses much of it's winning points, the
extensive library for example. Without it Java would probably not be
near as big as it is today.

IMHO, Java only has a "big" library because it is ridiculously verbose. If
you look at the functionality provided by Java's standard library it is not
actually very extensive.

 

[Jon Harrop]

Indeed. EDG has one, and it works with Dinkumware's Jcore library, most
of which I wrote. And, oddly enough, code that compiles just fine with
Sun's compiler sometimes doesn't compile with EDG's, except in
bug-compatible mode. So Java's claimed portability comes from using one
compiler only, and that one doesn't actually follow the published
specification.

Sure. Java is still more portable than C++ in practice.

 

[Pete Becker]

The original question was specifically regarding the C++ and Java languages.


Ask in the forums of any languages that support these features.

You're the one making the claim, not me. The fact that you decline to
cite evidence supporting your claim makes it highly suspect.

Or just use
Google. Try porting some simple programs from other languages to C++...

Huh? How in the world does porting some simple program from some other
language to C++ show that some things "will never work as well as a
system designed for them"? At best, it might show that some things are
harder in C++ now. But "never" is an awfully long time.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

 

[Pete Becker]

Safety = no dangling pointers, no buffer overruns, no segmentation faults...

Then Java isn't safe. After all, it has an exception named
NullPointerException. And it does, indeed, run into segmentation faults.
Yes, that's usually caused by JNI code, but that doesn't change the fact
that these things do occur, despite marketing hype to the contrary.

You should read up on some other languages: OCaml, SML, Scheme, Lisp,
Haskell, even C#. They all offer these features and more. This is not
specific to Java.

Thank you for your condescension. Nevertheless, using undefined terms is
a classic technique for people who don't have facts to support there
positions. And vague suggestions to look at other languages does not
magically produce definitions.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

 

[Pete Becker]

Sure. Java is still more portable than C++ in practice.

Sigh. You've snipped the context here, which was about having to install
a runtime environment to get portability.

--

-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)

 

[Ian Collins]

This is about language features. All of those features come with Java. None
come with C++. Some can be retrofitted but will never work as well as a
system designed for them (e.g. GC).

C++ doesn't require GC, Java does. So how can it be described as a
beneficial feature?

 

[Cesar Rabak]

Ian Collins escreveu:

C++ doesn't require GC, Java does. So how can it be described as a
beneficial feature?

To answer that you need to question yourself if this features allow
easier programming, safely, less error prone.

 

[IR]

To answer that you need to question yourself if this features
allow easier programming, safely, less error prone.

I'd answer: finalizers vs. destructors.

Nuf' said, as far as I'm concerned.


Cheers,

 

[Ian Collins]

I'd answer: finalizers vs. destructors.

Nuf' said, as far as I'm concerned.

I was going to say RAII vs. GC, but your post sums it up just as well!

 

[Jon Harrop]

C++ doesn't require GC, Java does. So how can it be described as a
beneficial feature?

Languages designed to be garbage collected have more freedom over their
choice of garbage collector, so they will be faster than languages with
retrofitted GCs.

 

[Jon Harrop]

You're the one making the claim, not me. The fact that you decline to cite
evidence supporting your claim makes it highly suspect.

1. If memory management is handled by the compiler and runtime environment,
it can perform hybrid optimisations:

http://lists.tunes.org/archives/gclist/1997-November/001291.html

2. Retrofitting a GC alters the semantics of the language and makes
languages like C++ even less safe and even more error-prone unless you
manage the whole language, in which case performance suffers terribly:

http://gcc.gnu.org/ml/java/1999-q4/msg00467.html

3. Run-time representation can be tuned for GC if the language was designed
for GC, e.g. tagging vs boxing.

http://pauillac.inria.fr/~xleroy/talks/compilation-agay.pdf

4. Language implementors can choose to use stack or heap if the language is
designed for GC.

http://citeseer.ist.psu.edu/11526.html

5. A retrofitted GC cannot move objects to compact the heap, i.e. it will
never be as space-efficient as a real GC.

"Many Java/ML/Scheme implementations have faster garbage collectors that may
move objects..." - Hans Boehm
http://www.hpl.hp.com/personal/Hans_Boehm/gc/nonmoving/html/slide_4.html

6. Conservative garbage collectors try to make the best of a bad job by
guessing which heap values are pointers.

Look at Boehm's own GC benchmark:

http://www.hpl.hp.com/personal/Hans_Boehm/gc/gc_bench/

"Some Java implementations have similar or better performance"

Running Boehm's own benchmark here, Java is as fast as C++ without GC and
twice as fast as C++ with Boehm's GC:

$ g++ -DGC -lgc -O2 GCBench.cpp -o GCBench
$ time ./GCBench
....
real 0m1.975s
user 0m1.604s
sys 0m0.356s

$ javac GCBench.java
$ java GCBench
....
real 0m0.982s
user 0m1.008s
sys 0m0.120s

This is primarily due to the fundamental limitations of retrofitting a GC
onto C++, as Boehm himself described.

Huh? How in the world does porting some simple program from some other
language to C++ show that some things "will never work as well as a
system designed for them"?

I've led you to water...

 

[Jon Harrop]

I'd answer: finalizers vs. destructors.

Marshalling vs nothing
Closures vs nothing
Tagging/Boxing vs nothing
Reflection vs nothing
EVAL vs nothing
Sandboxing vs nothing

 

[Jon Harrop]

You know, you really shouldn't post while under LSD...

Look at Boehm's own benchmarks, for example.

 

[IR]

Languages designed to be garbage collected have more freedom over
their choice of garbage collector, so they will be faster than
languages with retrofitted GCs.

You know, you really shouldn't post while under LSD...


Cheers,

 

[Jon Harrop]

but you have to admit Java's anonymous inner classes are way cool...

Like closures but worse...

 

[Jon Harrop]

Thank you for your condescension. Nevertheless, using undefined terms is
a classic technique for people who don't have facts to support there
positions. And vague suggestions to look at other languages does not
magically produce definitions.

I'm sorry but you are asking me to cite evidence to support a claims that
have been widely accepted since about 1959.

 

[Jon Harrop]

Maybe so, but languages that don't require garbage collection don't have
to make that choice.

Yes. So the advantage compared to retrofitted GC is performance and the
advantage compared to no GC is simplicity.

 

[Ian Collins]

Languages designed to be garbage collected have more freedom over their
choice of garbage collector, so they will be faster than languages with
retrofitted GCs.

Maybe so, but languages that don't require garbage collection don't have
to make that choice.