Want to do OOP. Does c++ have all the abilities of java, or is it some
subset?
Thanks...
Jan 19 '07
148  5018 
IR wrote:
Cesar Rabak wrote:
>>>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.
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!
--
Ian Collins.
Ian Collins wrote:
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.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
Jon Harrop wrote:
Ian Collins wrote:
>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.
You know, you really shouldn't post while under LSD...
Cheers,
--
IR
Pete Becker wrote:
>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.
1. If memory management is handled by the compiler and runtime environment,
it can perform hybrid optimisations: http://lists.tunes.org/archives/gcli...er/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/tal...ation-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_...l/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.
>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"?
I've led you to water...
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
IR wrote:
Cesar Rabak wrote:
>>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.
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
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
IR wrote:
Jon Harrop wrote:
>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...
Look at Boehm's own benchmarks, for example.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
Jon Harrop wrote:
Ian Collins wrote:
>>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.
Maybe so, but languages that don't require garbage collection don't have
to make that choice.
--
Ian Collins.
Pete Becker wrote:
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.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
Ian Collins wrote:
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.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
Jon Harrop wrote:
Ian Collins wrote:
>>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.
Coupled with non-deterministic behaviour?
--
Ian Collins.
Ian Collins wrote:
Coupled with non-deterministic behaviour?
GC is no less deterministic than the STL. Indeed, GC typically gives much
better worst case time and memory performance than the STL.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
Jon Harrop wrote:
Ian Collins wrote:
>Coupled with non-deterministic behaviour?
GC is no less deterministic than the STL. Indeed, GC typically
gives much better worst case time and memory performance than the
STL.
Now comparing oranges and towels...
You're getting more entertaining with each and every post you make!
(ok, ok guys... I'll stop feeding the troll now. I know it's been
annoying for some of you, but I just couldn't stand it :-p)
Cheers,
--
IR
Jon Harrop wrote:
Ian Collins wrote:
>>Coupled with non-deterministic behaviour?
GC is no less deterministic than the STL. Indeed, GC typically gives much
better worst case time and memory performance than the STL.
Who's talking about the STL? The STL is the old name for part of the
C++ standard library.
How can GC be "no less deterministic" than the automatic calling of an
object's destructor when it goes out of scope?
Consider a lock object that claims a resource in its constructor and
releases it in the destructor. The point of release is known. How to
you duplicate that behaviour without additional complexity using GC?
--
Ian Collins.
IR wrote:
Jon Harrop wrote:
>>Ian Collins wrote:
>>>Coupled with non-deterministic behaviour?
GC is no less deterministic than the STL. Indeed, GC typically
gives much better worst case time and memory performance than the
STL.
Now comparing oranges and towels...
You're getting more entertaining with each and every post you make!
(ok, ok guys... I'll stop feeding the troll now. I know it's been
annoying for some of you, but I just couldn't stand it :-p)
But it is interesting watching the way they change the subject to avoid
answering direct questions :)
--
Ian Collins.
Ian Collins wrote:
Who's talking about the STL?
I am.
The STL is the old name for part of the C++ standard library.
Ok, whatever you kids are calling it these days.
How can GC be "no less deterministic" than the automatic calling of an
object's destructor when it goes out of scope?
The answer depends upon the semantics you are referring to. If you are
referring to allocating and deallocating externals resources then that is
not the purpose of a GC (although they can often be used for that). If you
are referring to the stacking of converse operations then I address that
below. If you are referring to the deallocation performed by a destructor
(e.g. an STL container) then it is a black box, no more deterministic than
a GC.
Consider a lock object that claims a resource in its constructor and
releases it in the destructor. The point of release is known. How to
you duplicate that behaviour without additional complexity using GC?
Wrap the lock and release in a higher-order function and write in
continuation passing style:
let f k x =
lock x;
try k x finally
release x
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
Jon Harrop wrote:
Pete Becker wrote:
>>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.
1. If memory management is handled by the compiler and runtime environment,
it can perform hybrid optimisations:
http://lists.tunes.org/archives/gcli...er/001291.html
What are the performance gains, if any, from doing this, and why is it
impossible for a C++ compiler to do something similar?
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
You're quoting an e-mail that says that if the GC isn't implemented
correctly you can get bad performance. Big deal. The e-mail also
suggests how to fix the problem, and it's pretty much a no-brainer.
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/tal...ation-agay.pdf
I'm not going to dig through a 90 page paper to find the parts that you
think are relevant.
4. Language implementors can choose to use stack or heap if the language is
designed for GC.
http://citeseer.ist.psu.edu/11526.html
Not as long as the previous, but still, more than I'm going to hunt
through for the parts that you think are relevant.
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_...l/slide_4.html
Er, he actually says just the opposite, but you've snipped context.
Here's the entire quotation:
Why non-moving? ... Because fundamental
performance considerations don't change
much. Many Java/ML/Scheme implementations
have "faster" garbage collectors that move
objects, but they're not consistently faster.
Besides, he's talking about a particular implementation. Even if he had
actually said what you claim he says, it doesn't support your assertion
that GC "will never work as well" as on a system designed for it. And
you quoted out of context. The actual comment is:
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"
I'm not going to hunt through those source files to see if that comment
is actually there. But even assuming it's accurate, it doesn't support
your assertion that GC "will never work as well" as on a system designed
for it.
Running Boehm's own benchmark here, Java is as fast as C++ without GC and
twice as fast as C++ with Boehm's GC:
You've already demonstrated that you edit what other people say to suit
your purposes. Show me an objective source with this information.
--
-- Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." ( www.petebecker.com/tr1book)
Jon Harrop wrote:
Ian Collins wrote:
>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.
Really? Please point to an objective study that supports this claim. Not
one that simply looks at existing implementations, but considers every
possible way of implementing GC in C++, including possible language
extensions. Unless, of course, you're abandoning your claim that it
"will never work as well."
--
-- Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." ( www.petebecker.com/tr1book)
Jon Harrop wrote:
Pete Becker wrote:
>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.
You've again snipped the actual context in order to make a rather
different claim. If you go back in this thread, you'll see that you made
the vague claim that after adding GC to C++ with the Boehm collector
"they're still lacking safety." That most certainly hasn't been "widely
accepted since about 1959".
--
-- Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." ( www.petebecker.com/tr1book)
Jon Harrop wrote:
Ian Collins wrote:
The answer depends upon the semantics you are referring to. If you are
referring to allocating and deallocating externals resources then that is
not the purpose of a GC (although they can often be used for that). If you
are referring to the stacking of converse operations then I address that
below. If you are referring to the deallocation performed by a destructor
(e.g. an STL container) then it is a black box, no more deterministic than
a GC.
No, it occurs when the object goes out of scope or is explicitly
destroyed. Quite deterministic.
>
>>Consider a lock object that claims a resource in its constructor and
releases it in the destructor. The point of release is known. How to
you duplicate that behaviour without additional complexity using GC?
Wrap the lock and release in a higher-order function and write in
continuation passing style:
let f k x =
lock x;
try k x finally
release x
So you have to add the complexity of a try-finally block and the
complexity and potential error of a release.
The C++ way would be
{
lock x;
doStuff
}
--
Ian Collins.
Pete Becker wrote:
Jon Harrop wrote:
>1. If memory management is handled by the compiler and runtime
environment, it can perform hybrid optimisations:
http://lists.tunes.org/archives/gcli...er/001291.html
What are the performance gains, if any, from doing this, and why is it
impossible for a C++ compiler to do something similar?
Such optimisations require the optimiser in the compiler to know the details
of the memory allocator and collector, i.e. the GC. This is not possible if
the GC has been retrofitted onto the language as a library. The compiler's
optimiser does not have the necessary information to make the
optimisations.
>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/tal...ation-agay.pdf
I'm not going to dig through a 90 page paper to find the parts that you
think are relevant.
It seems I really can't make you drink.
"Tagging is a well-known tech-
nique for implementing dynamically-typed languages
(Lisp, Smalltalk). It can be used as a special case of
run-time type inspection, where type information is at-
tached to data structures instead of being passed sepa-
rately, and type expressions are mapped to a small set
of base types, efficiently encoded at the bit level." http://216.239.59.104/search?q=cache...&cd=1&ie=UTF-8
>4. Language implementors can choose to use stack or heap if the language
is designed for GC.
http://citeseer.ist.psu.edu/11526.html
Not as long as the previous, but still, more than I'm going to hunt
through for the parts that you think are relevant.
From the abstract: "No stack is used".
>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_...l/slide_4.html
Er, he actually says just the opposite, but you've snipped context.
"Because it is hard to move objects for C programs", i.e. retrofitting
limits choices which limits performance.
Here's the entire quotation:
Why non-moving? ... Because fundamental
performance considerations don't change
much. Many Java/ML/Scheme implementations
have "faster" garbage collectors that move
objects, but they're not consistently faster.
Besides, he's talking about a particular implementation.
You cannot benchmark non-specific implementations.
Even if he had
actually said what you claim he says, it doesn't support your assertion
that GC "will never work as well" as on a system designed for it. And
you quoted out of context. The actual comment is:
Is what?
>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"
I'm not going to hunt through those source files to see if that comment
is actually there.
Second paragraph of this page: http://www.hpl.hp.com/personal/Hans_.../gc_bench.html
But even assuming it's accurate, it doesn't support
your assertion that GC "will never work as well" as on a system designed
for it.
I've now given you plenty of direct citations.
>Running Boehm's own benchmark here, Java is as fast as C++ without GC and
twice as fast as C++ with Boehm's GC:
You've already demonstrated that you edit what other people say to suit
your purposes.
If you don't believe my timings then run the code for yourself. I posted the
URL and even the compile commands.
Show me an objective source with this information.
Apparently any objective sources are too long for you to read.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
Pete Becker wrote:
You've again snipped the actual context in order to make a rather
different claim. If you go back in this thread, you'll see that you made
the vague claim that after adding GC to C++ with the Boehm collector
"they're still lacking safety." That most certainly hasn't been "widely
accepted since about 1959".
Sorry, you want to know why C++ is unsafe? Try Stroustrup: http://www.research.att.com/~bs/bs_faq.html#unsafe
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
Ian Collins wrote:
Jon Harrop wrote:
>Ian Collins wrote:
The answer depends upon the semantics you are referring to. If you are
referring to allocating and deallocating externals resources then that is
not the purpose of a GC (although they can often be used for that). If
you are referring to the stacking of converse operations then I address
that below. If you are referring to the deallocation performed by a
destructor (e.g. an STL container) then it is a black box, no more
deterministic than a GC.
No, it occurs when the object goes out of scope or is explicitly
destroyed. Quite deterministic.
We need to clarify. You're saying that the point the destructor call is made
is deterministic. Very true. I was saying that the time taken for the
destructor of an STL container to run is non-deterministic.
You can get the determinism of scope-based deconstruction in other languages
(see below).
Incidentally, can C++ compilers do block reordering optimisations, moving
the scopes around to generate better assembler? Presumably if it alters the
positions of destructor calls this is forbidden.
>Wrap the lock and release in a higher-order function and write in
continuation passing style:
let f k x =
lock x;
try k x finally
release x
So you have to add the complexity of a try-finally block and the
complexity and potential error of a release.
The C++ way would be
{
lock x;
doStuff
}
I wasn't clear enough. The code I posted is factored out commonality that
would appear in a library whereas the code you just posted is equivalent to
a use of that.
My code was equivalent to the code you omitted that contains the release in
C++ (it might as well contain the lock as well):
class F {
T x;
F(T x2) : x(x2) { lock x; }
~F() { release x; }
}
You'd use that like this in C++:
{
F f = new F(x);
...
}
The allocation takes the lock and the end of scope guarantees its removal.
The code you posted demonstrates how you might use this. The equivalent for
my code is:
f (fun x -...) x
So there is no significant difference in complexity, both are equally
deterministic, both are exception-safe. GC doesn't lose you anything here.
This is actually a common idiom used in many programming languages. I've
been using it recently in F# to constrain the lifetimes of DirectX objects
because the .NET GC is much less deterministic than OCaml's GC.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
Jon Harrop wrote:
Pete Becker wrote:
>Jon Harrop wrote:
>>1. If memory management is handled by the compiler and runtime
environment, it can perform hybrid optimisations:
http://lists.tunes.org/archives/gcli...er/001291.html
What are the performance gains, if any, from doing this, and why is it
impossible for a C++ compiler to do something similar?
Such optimisations require the optimiser in the compiler to know the details
of the memory allocator and collector, i.e. the GC. This is not possible if
the GC has been retrofitted onto the language as a library.
Oh, now you've changed your assertion from GC in general to GC
implemented as a library.
The compiler's
optimiser does not have the necessary information to make the
optimisations.
>>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/tal...ation-agay.pdf
I'm not going to dig through a 90 page paper to find the parts that you
think are relevant.
It seems I really can't make you drink.
You have to make your case. Citing 90 page papers that talk about a wide
variety of subjects doesn't do that.
"Tagging is a well-known tech-
nique for implementing dynamically-typed languages
(Lisp, Smalltalk). It can be used as a special case of
run-time type inspection, where type information is at-
tached to data structures instead of being passed sepa-
rately, and type expressions are mapped to a small set
of base types, efficiently encoded at the bit level."
http://216.239.59.104/search?q=cache...&cd=1&ie=UTF-8
And what makes you think a C++ compiler can't do this?
>>4. Language implementors can choose to use stack or heap if the language
is designed for GC.
http://citeseer.ist.psu.edu/11526.html
Not as long as the previous, but still, more than I'm going to hunt
through for the parts that you think are relevant.
From the abstract: "No stack is used".
So what?
>>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_...l/slide_4.html
Er, he actually says just the opposite, but you've snipped context.
"Because it is hard to move objects for C programs", i.e. retrofitting
limits choices which limits performance.
>Here's the entire quotation:
Why non-moving? ... Because fundamental
performance considerations don't change
much. Many Java/ML/Scheme implementations
have "faster" garbage collectors that move
objects, but they're not consistently faster.
Besides, he's talking about a particular implementation.
You cannot benchmark non-specific implementations.
Nope. But benchmarking particular implementations doesn't establish your
claim that GC in C++ "will never work as well" as in a language designed
for it.
>Even if he had
actually said what you claim he says, it doesn't support your assertion
that GC "will never work as well" as on a system designed for it. And
you quoted out of context. The actual comment is:
Is what?
Is a leftover part that didn't get properly edited.
>>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"
I'm not going to hunt through those source files to see if that comment
is actually there.
Second paragraph of this page:
http://www.hpl.hp.com/personal/Hans_.../gc_bench.html
>But even assuming it's accurate, it doesn't support
your assertion that GC "will never work as well" as on a system designed
for it.
I've now given you plenty of direct citations.
Most of which don't say what you claim they say, and don't support the
claim that you made.
>>Running Boehm's own benchmark here, Java is as fast as C++ without GC and
twice as fast as C++ with Boehm's GC:
You've already demonstrated that you edit what other people say to suit
your purposes.
If you don't believe my timings then run the code for yourself. I posted the
URL and even the compile commands.
>Show me an objective source with this information.
Apparently any objective sources are too long for you to read.
So, you don't have an objective source that supports your claimed timings.
--
-- Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." ( www.petebecker.com/tr1book)
Jon Harrop wrote:
Ian Collins wrote:
>Who's talking about the STL?
I am.
>The STL is the old name for part of the C++ standard library.
Ok, whatever you kids are calling it these days.
Too bad you don't have the grace to admit that you're wrong.
--
-- Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." ( www.petebecker.com/tr1book)
Jon Harrop wrote:
Pete Becker wrote:
>You've again snipped the actual context in order to make a rather
different claim. If you go back in this thread, you'll see that you made
the vague claim that after adding GC to C++ with the Boehm collector
"they're still lacking safety." That most certainly hasn't been "widely
accepted since about 1959".
Sorry, you want to know why C++ is unsafe? Try Stroustrup:
No, I want to know what it is about C++ that you claim has been "widely
accepted since about 1959."
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?
--
-- Pete
Roundhouse Consulting, Ltd. ( www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." ( www.petebecker.com/tr1book)
Jon Harrop wrote:
Ian Collins wrote:
>>Jon Harrop wrote:
>>>Ian Collins wrote:
The answer depends upon the semantics you are referring to. If you are
referring to allocating and deallocating externals resources then that is
not the purpose of a GC (although they can often be used for that). If
you are referring to the stacking of converse operations then I address
that below. If you are referring to the deallocation performed by a
destructor (e.g. an STL container) then it is a black box, no more
deterministic than a GC.
No, it occurs when the object goes out of scope or is explicitly
destroyed. Quite deterministic.
We need to clarify. You're saying that the point the destructor call is made
is deterministic. Very true. I was saying that the time taken for the
destructor of an STL container to run is non-deterministic.
How so and how would GC change that?
>
I wasn't clear enough. The code I posted is factored out commonality that
would appear in a library whereas the code you just posted is equivalent to
a use of that.
My code was equivalent to the code you omitted that contains the release in
C++ (it might as well contain the lock as well):
class F {
T x;
F(T x2) : x(x2) { lock x; }
~F() { release x; }
}
You'd use that like this in C++:
{
F f = new F(x);
F f(x);
...
}
The allocation takes the lock and the end of scope guarantees its removal.
The code you posted demonstrates how you might use this. The equivalent for
my code is:
f (fun x -...) x
So there is no significant difference in complexity, both are equally
deterministic, both are exception-safe. GC doesn't lose you anything here.
I'm not sure what yo are saying here, if an exception is thrown, how is
the lock released?
--
Ian Collins.
Ian Collins wrote:
Jon Harrop wrote:
>We need to clarify. You're saying that the point the destructor call is
made is deterministic. Very true. I was saying that the time taken for
the destructor of an STL container to run is non-deterministic.
How so and how would GC change that?
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).
...
F f(x);
Oops. :-)
> ...
I'm not sure what yo are saying here, if an exception is thrown, how is
the lock released?
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.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
Pete Becker wrote:
Jon Harrop wrote:
>Such optimisations require the optimiser in the compiler to know the
details of the memory allocator and collector, i.e. the GC. This is not
possible if the GC has been retrofitted onto the language as a library.
Oh, now you've changed your assertion from GC in general to GC
implemented as a library.
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++".
>"Tagging is a well-known tech-
nique for implementing dynamically-typed languages
(Lisp, Smalltalk). It can be used as a special case of
run-time type inspection, where type information is at-
tached to data structures instead of being passed sepa-
rately, and type expressions are mapped to a small set
of base types, efficiently encoded at the bit level."
http://216.239.59.104/search?q=cache...&cd=1&ie=UTF-8
>>
And what makes you think a C++ compiler can't do this?
If it did you would have a 31- or 63-bit int type, as OCaml does. I believe
that is no longer C++.
>>Besides, he's talking about a particular implementation.
You cannot benchmark non-specific implementations.
Nope. But benchmarking particular implementations doesn't establish your
claim that GC in C++ "will never work as well" as in a language designed
for it.
Are you now happy that the current Boehm GC is slower than other GCs?
>I've now given you plenty of direct citations.
Most of which don't say what you claim they say, and don't support the
claim that you made.
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++.
>If you don't believe my timings then run the code for yourself. I posted
the URL and even the compile commands.
So, you don't have an objective source that supports your claimed timings.
Apart from Boehm's results and my results? Your results?
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
Jon Harrop wrote:
Ian Collins wrote:
>>Jon Harrop wrote:
>>>We need to clarify. You're saying that the point the destructor call is
made is deterministic. Very true. I was saying that the time taken for
the destructor of an STL container to run is non-deterministic.
How so and how would GC change that?
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...
>>
I'm not sure what yo are saying here, if an exception is thrown, how is
the lock released?
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?
--
Ian Collins.
Pete Becker wrote:
>>If anyone wants to have garbage collection with C++, they install a
garbage collector such as the Boehm one.
Then they're still lacking safety.
>>Then they're still lacking safety.
Again with the undefined terms. 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.
>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.
>>You've again snipped the actual context in order to make a rather
different claim. If you go back in this thread, you'll see that you made
the vague claim that after adding GC to C++ with the Boehm collector
"they're still lacking safety." That most certainly hasn't been "widely
accepted since about 1959".
Sorry, you want to know why C++ is unsafe? Try Stroustrup:
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.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
Ian Collins wrote:
Jon Harrop wrote:
>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...
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.
>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?
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.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
Jon Harrop wrote:
Ian Collins wrote:
>>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.
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)?
--
Ian Collins.
Ian Collins wrote:
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).
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
Jon Harrop wrote:
Bo Persson wrote:
>>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
Jon Harrop wrote:
Pete Becker wrote:
>Jon Harrop wrote:
>>Such optimisations require the optimiser in the compiler to know the
details of the memory allocator and collector, i.e. the GC. This is not
possible if the GC has been retrofitted onto the language as a library.
Oh, now you've changed your assertion from GC in general to GC
implemented as a library.
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.
>>"Tagging is a well-known tech-
nique for implementing dynamically-typed languages
(Lisp, Smalltalk). It can be used as a special case of
run-time type inspection, where type information is at-
tached to data structures instead of being passed sepa-
rately, and type expressions are mapped to a small set
of base types, efficiently encoded at the bit level."
http://216.239.59.104/search?q=cache...&cd=1&ie=UTF-8
>And what makes you think a C++ compiler can't do this?
If it did you would have a 31- or 63-bit int type, as OCaml does. I believe
that is no longer C++.
Sigh.
>>>Besides, he's talking about a particular implementation.
You cannot benchmark non-specific implementations.
Nope. But benchmarking particular implementations doesn't establish your
claim that GC in C++ "will never work as well" as in a language designed
for it.
Are you now happy that the current Boehm GC is slower than other GCs?
Sigh.
>>I've now given you plenty of direct citations.
Most of which don't say what you claim they say, and don't support the
claim that you made.
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++.
>>If you don't believe my timings then run the code for yourself. I posted
the URL and even the compile commands.
So, you don't have an objective source that supports your claimed timings.
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)
BillJosephson wrote:
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...
--
Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Phlip wrote:
BillJosephson wrote:
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...
--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
What language?
BillJosephson wrote:
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...
--
Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Phlip wrote:
BillJosephson wrote:
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...
--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
Is it just for web stuff? Is it good for writing scientific
applications that need speed?
Jon Harrop wrote:
Erik Wikström wrote:
Well, I don't know of any comparison but personally I'd say that C++ is
a superset of Java, way more powerful.
C++ doesn't even have garbage collection and it isn't cross platform.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists
http://www.ffconsultancy.com/product...ex.html?usenet
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
On Jan 20, 8:14 pm, IR <no_em...@use.net.invalidwrote:
Cesar Rabak wrote:
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.I'd answer: finalizers vs. destructors.
Nuf' said, as far as I'm concerned.
Cheers,
--
IR
for me its not enough... can you explain what you mean?
Andrew
andrewmcdonagh wrote:
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.
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...;)
--
Phlip http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
BillJosephson wrote:
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.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
sean wrote:
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.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
andrewmcdonagh wrote:
On Jan 20, 8:14 pm, IR <no_em...@use.net.invalidwrote:
>Nuf' said, as far as I'm concerned.
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.
--
Dr Jon D Harrop, Flying Frog Consultancy
Objective CAML for Scientists http://www.ffconsultancy.com/product...ex.html?usenet
Jon Harrop wrote:
andrewmcdonagh wrote:
>>On Jan 20, 8:14 pm, IR <no_em...@use.net.invalidwrote:
>>>Nuf' said, as far as I'm concerned.
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.
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.
--
Ian Collins.
Ian Collins wrote:
Jon Harrop wrote:
>andrewmcdonagh wrote:
>>>On Jan 20, 8:14 pm, IR <no_em...@use.net.invalidwrote:
Nuf' said, as far as I'm concerned.
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.
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,
--
IR
On Jan 22, 6:11 pm, IR <no_em...@use.net.invalidwrote:
Ian Collins wrote:
Jon Harrop wrote:
andrewmcdonagh wrote:
>>On Jan 20, 8:14 pm, IR <no_em...@use.net.invalidwrote:
>>>Nuf' said, as far as I'm concerned.
>>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.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,
--
IR
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 This thread has been closed and replies have been disabled. Please start a new discussion. |
