Are c++ features a subset of java features?

[Ian Collins]

The STL does a lot of magic inside its black box in order to improve
performance, using custom allocators. The time they take to execute is
unpredictable. So I'm saying that GC is no worse than that. IME, GC can be
significantly better for worst case (OCaml vs STL).

Standard library containers either use a default allocator, or one
provided by the user. Either of these can be characterised. There's
nothing to stop the user providing a garbage collected allocator...

In the C++, the destructor is called as the exception handler unwinds past
the scope. In the ML, the finally clause is called as the exception handler
unwinds past the cope. So both approaches release the lock when an
exception is thrown. There isn't really much difference between the two.

But you still have to surround the function statements with a
try-finally block, or am I missing something?

 

[Jon Harrop]

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.

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


No, I want to know what it is about C++ that you claim has been "widely
accepted since about 1959."

I've quoted the whole context this time. As you can see, we were talking
about safety in the context of C++. You said "Again with the undefined
terms" as if you didn't know what safety was.

Historically, safety was one of the motivations behind the evolution of the
Lisp language, stemming from 1959. They introduced features like garbage
collection in order to reduce the number of errors in programs.

However, it takes more than garbage collection to make a language safe by
any reasonable definition of safety (like the one by Cardelli, that I
quoted verbatim elsewhere). C++ does not satisfy these requirements. C++ is
not safe. So I cited Stroustrup saying that C++ is not safe in an attempt
to convince you that C++ is, in fact, not safe. Given that programming C++
using a retrofitted GC like Boehm's is still programming C++, it follows
that such programs remain unsafe.

And note that that page talks about violating type safety. That wasn't
on your list of unsafe features. So are you now changing your definition
of safety?

This is a commonly used term with a widely accepted meaning. About seven
posts ago I referred you to six other languages, all of which are safe, so
that you could learn about safety by learning about them.

 

[Jon Harrop]

Standard library containers either use a default allocator, or one
provided by the user. Either of these can be characterised. There's
nothing to stop the user providing a garbage collected allocator...

Yes. I tried using custom allocators a few times. Never worked out very
well. Spreading the cost of cascade destructions is very hard to do
efficiently. OCaml's GC does it very well.

But you still have to surround the function statements with a
try-finally block, or am I missing something?

When you write the definition that is responsible for locking and unlocking,
you use try..finally instead of a destructor, yes.

I suppose you could say that I'm using a higher-order function to implement
scope.

 

[Ian Collins]

Ian Collins wrote:


When you write the definition that is responsible for locking and unlocking,
you use try..finally instead of a destructor, yes.

I suppose you could say that I'm using a higher-order function to implement
scope.

So going back to the complexity question, from the user's perspective,
the code is more complex and potentially error prone (if they omit the
unlock or return early)?

 

[Jon Harrop]

So going back to the complexity question, from the user's perspective,
the code is more complex and potentially error prone (if they omit the
unlock or return early)?

The users code is just:

f (fun x -> ..) x

so they can't return early from the closure (other than via an exception
which will be properly handled).

 

[Bo Persson]

Jon Harrop wrote:

and it [C++] isn't cross platform.

Java isn't cross platform at all, it only runs on the JVM.

Which has been ported to many platforms.

To move Sun's Open Source Java to a new target, you first have to
port a C++ compiler.

The most common platforms are existing targets.

And those targets then obviously have a C++ compiler than can build the JVM.
Exactly how does that make Java more portable than C++?


Bo Persson

 

[Pete Becker]

You spoke of "language extensions" elsewhere. Now you want to alter the
compiler (and the language's semantics) so that it can support GC. These
are all good ideas. Indeed, they are necessary to achieve competitive
performance. But the result will no longer be "C++".

Sigh.


If it did you would have a 31- or 63-bit int type, as OCaml does. I believe
that is no longer C++.

Sigh.


Are you now happy that the current Boehm GC is slower than other GCs?

Sigh.


These are some of the many optimisations that other languages have done and
this is the reason they are faster. As we have discussed, these
optimisations cannot be applied to C++.


Apart from Boehm's results and my results? Your results?

Plonk.

--

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

 

[Phlip]

Want to do OOP. Does c++ have all the abilities of java, or is it some
subset?

C++ came first.

Ordinarily, the language that came next has more features than the one that
came first.

Java is special. It was invented to be marketed via "management by
magazine".

The authors of Java wanted to tell your boss "your programmers will write
much fewer bugs if they use Java!"

So, compared to C++, in Java you cannot so easily run off the end of an
array, or point with a dangling pointer, or jump into a random spot in
memory, or delete a derived class object thru a pointer to a base class
without a virtual destructor, or corrupt your heap.

But this requires Java to have _less_ features than C++. And that, in turn,
makes it _harder_ to write Java code. You must write more lines to get less
done. And Java comes with its own wondrous bugs.

So Java productivity is not competitive with C++.

To really learn OO, learn one of the languages that actually tried to exceed
C++ _and_ Java. Maybe a language that I have been promoting on this
newsgroup for the last 6 years, and which recently developed a killer app
which has been selling-out entire press runs of books this Fall and
Spring...

 

[BillJosephson]

C++ came first.

Ordinarily, the language that came next has more features than the one that
came first.

Java is special. It was invented to be marketed via "management by
magazine".

The authors of Java wanted to tell your boss "your programmers will write
much fewer bugs if they use Java!"

So, compared to C++, in Java you cannot so easily run off the end of an
array, or point with a dangling pointer, or jump into a random spot in
memory, or delete a derived class object thru a pointer to a base class
without a virtual destructor, or corrupt your heap.

But this requires Java to have _less_ features than C++. And that, in turn,
makes it _harder_ to write Java code. You must write more lines to get less
done. And Java comes with its own wondrous bugs.

So Java productivity is not competitive with C++.

To really learn OO, learn one of the languages that actually tried to exceed
C++ _and_ Java. Maybe a language that I have been promoting on this
newsgroup for the last 6 years, and which recently developed a killer app
which has been selling-out entire press runs of books this Fall and
Spring...

What language?

 

[Phlip]

What language?

I was sparing the other readers here reading me dropping the name "Ruby"
again. That an Ruby on Rails is currently showing the rest of the OO world
how it's done...

People who migrate from a Java website system to RoR typically lament the
time and code they have wasted before discovering this incredibly lean and
elegant system...

 

[BillJosephson]

I was sparing the other readers here reading me dropping the name "Ruby"
again. That an Ruby on Rails is currently showing the rest of the OO world
how it's done...

People who migrate from a Java website system to RoR typically lament the
time and code they have wasted before discovering this incredibly lean and
elegant system...

Is it just for web stuff? Is it good for writing scientific
applications that need speed?

 

[sean]

C++ doesn't even have garbage collection and it isn't cross platform.

C++ and Java are implemented completely differently - what the argument
seems to be here is how both languages solve the problems thrown at
them - which is only important within the scale of a system that's
being developed - both languages have their strengths and weaknesses.

At this juncture, I'd like to respond to Jon's post above...

C++ is an object oriented high level language - it is not a rapid
application development framework, and it compiles into machine code
(that is: Processor specific), Whereas Java is a framework developed in
C++ in order to allow products and technologies to run accross
platforms, media and even format - you can find Java applications from
your PC to your phone to your PDA to your car! However - Java
applications are not compiled to machine code, they are compiled to a
mid-level between pseudocode and machine code that Java has termed
'bytecode' - while being quicker than a pure interpreted language (such
as Ruby) - the compiled application is neither as small, nor as fast as
a similar app written in C++.

Just so no one gets confused on the 'not cross platform' thing: Linux
was written in C/C++ - so was windows, and so was Mac OS - to me, it
seems that this language itself is the reason we are able to moan about
it not being cross platform.

Regards

 

[andrewmcdonagh]

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

Cheers,

for me its not enough... can you explain what you mean?

Andrew

 

[Phlip]

for me its not enough... can you explain what you mean?

They both suck. When you have the pattern Create Use Destroy, something else
might want to Use that which you Created. If you assume that thing must also
Destroy, then you break encapsulation. The best pattern for this is the
Execute Around Pattern, where the Creator itself calls a block closer for
the user to Use, and then when the user finishes the Creator itself ensures
a Destroy happens. This is better than both finalizers and destructors.

(But destructors are still better than finalizers - they break encapsulation
less...

 

[Jon Harrop]

Is it just for web stuff? Is it good for writing scientific
applications that need speed?

OCaml has an interesting and rather different approach to OOP and is a fast
language. Smalltalk is the pedagogical OOP language. I don't know how fast
it is.

However, OOP is of questionable benefit, so demanding both good OOP and fast
performance seems odd to me. Depending upon the problems you're trying to
solve, completely different approaches (like variant types and pattern
matching) may well be vastly faster than any OOP.

 

[Jon Harrop]

Just so no one gets confused on the 'not cross platform' thing: Linux
was written in C/C++

C. Not C++. I'm not saying that C isn't cross platform - it ports well. I'm
saying that C++ (using all the bells and whistles) is very
platform/compiler specific in my experience - it doesn't port well.

 

[Jon Harrop]

for me its not enough... can you explain what you mean?

I think "IR" is claiming that C++'s scope-based destructors render GC
unnecessary. If he is, I disagree.

 

[Ian Collins]

I think "IR" is claiming that C++'s scope-based destructors render GC
unnecessary. If he is, I disagree.

They can. You won't find 'delete' anywhere in my recent code except in
the smart pointer libraries. The lifetime of all objects can be managed
and documented by the correct smart pointer type.

 

[IR]

At least, we both agree to disagree ;-)

They can. You won't find 'delete' anywhere in my recent code
except in the smart pointer libraries. The lifetime of all
objects can be managed and documented by the correct smart pointer
type.

I fully second that. When using smart pointers (or whatever form of
RAII), a resource's lifetime is as little a concern as with a GC.

The biggest advantage of C++ destructors over GC finalizers being
that destructors are d-e-t-e-r-m-i-n-i-s-t-i-c.

If you don't need to know precisely when a resource will be
released, fine, don't think about it: RAII handles that for you.

But if you need to guarantee that a (possibly shared) resource will
be released *as soon as* there is no more references to it, well,
don't think about it either: RAII also handles that for you.


Cheers,

 

[andrewmcdonagh]

RAII), a resource's lifetime is as little a concern as with a GC.

The biggest advantage of C++ destructors over GC finalizers being
that destructors are d-e-t-e-r-m-i-n-i-s-t-i-c.

If you don't need to know precisely when a resource will be
released, fine, don't think about it: RAII handles that for you.

But if you need to guarantee that a (possibly shared) resource will
be released *as soon as* there is no more references to it, well,
don't think about it either: RAII also handles that for you.

Cheers,

Hmmm... this is what I thought....

Java Finalizers are not destructors. They are not even remotely
equivalent and so we are comparing apples and pears.

That being said, I've yet to find a real world use for Java's finalizer
methods.

Its almost universally better to do something simliar to phlip's
Execute Around Pattern.

Andrew