I
Ian Collins
#include <new>Razii said:
I
Ian Collins
That's not the point. The example was merely an illustration of howRazii said:
object allocation can be optimised if required.
Custom allocators are a common optimisation in C++ where many small
objects are dynamically allocated.
M
Mike Schilling
Razii said:
Your premise was that each C++ "new" does a system call.. That's
nonsense, as what you quote below demonstrates.
A
asterisc
Probably because of some compiler's optimizations.
When do you free memory in Java? Before or after you stop the clock?
I
Ian Collins
You have just disproved your original hypothesis. Memory is returned toRazii said:
the allocator, so it doesn't have to keep fetching more from the system.
I
Ian Collins
As I pointed out earlier, you are leaking memory. Didn't you realiseRazii said:
that? Do you read peoples responses?
A
asterisc
Let me rephrase that:
When exactly is the memory deallocated? Before or after you stop the
clock?
Do you know exactly when the GC will free the memory ?
I think the memory for every new is not referenced outside the loop.
Does GC run in every loop step?
Can you print out a message like: "here is allocated at address: xxx"
and "here is deallocated from address: xxx"
What you said is pure theory. I'm worried about how is that in
practice...
I
Ian Collins
You claimed "In C++, each "new" allocation request will be sent to theRazii said:
operating system, which is slow."
You have just disproved this by comparing the performance with and
without returning memory to the allocator. If each new requested memory
from the system, the performance would not have changed so
significantly.
A
asterisc
Can you print out a message like: "here is allocated at address: xxx"
and "here is deallocated from address: xxx"
A
asterisc
Can you print out a message like: "here is allocated at address: xxx"
and "here is deallocated from address: xxx"
A
asterisc
Can you print out a message like: "here is allocated at address: xxx"
and "here is deallocated from address: xxx"
M
Matthias Buelow
Juha said:
And your point is? The simple fact is, that bad programmers write bad
code, and good programmers write good code, no matter what the language
is or whether memory is managed automatically or manually.
M
Matthias Buelow
Razii said:
Maybe you shouldn't believe everything you read on a web site.
A
asterisc
What's the point allocating 1.000.000 new objects and never use them?
Why doesn't Java optimize this and allocate nothing, since they are
not used?
Anyway, in C++ it's a good idea to create memory pools if you intend
to play with a lot of small objects. Something like Ian did.
Try creating a memory pool in Java and compare it with GC's
performance.
Can you overwrite the new operator in Java?
Or are you comparing std::new with Java's new?
You forget that Java's GC is implemented in a lower-level programming
language, as C or C++. It cannot be faster than an implementation in C/
C++.
J
James Kanze
And I wrote C and assembler for some 20 years before starting in
C++, and I never had a memory leak in them, either. From
experience, I'd say that you can either write correct programs
in any language, or you can't do it in any language. The
question is one of cost. How much effort does it take.
Garbage collection is a tool which reduces the amount of coding
necessary in some specific cases. As such, it would be foolish
not to avail oneself of it when appropriate. And it would be
just as foolish to expect it to suddenly solve all your
problems, just like that.
There are many styles of programming, both in C++ and in any
other language. Many of them don't lead to encapsulated, clean
and safe code. A few do. I use very similar styles of
programming in both Java and C++, but I've seen some pretty bad
code in both as well.
Of course, I don't quite see the relevance to garbage collection
in this. Quite obviously, you can write bad code with garbage
collection. And just as obviously, you can write bad code
without garbage collection.
There are applications, of course, where you don't have the
choice; where you're developing dynamic structures (graphs,
etc.). But even there, the real gain is not in runtime (which
will rarely differ more than 10%-15% one way or the other), but
in development time. If the design determines that object
lifetime can be non-determinate, then you don't have to worry
about it when coding.
Obviously, in languages in which every object is allocated
dynamically, such objects are an overwhelming majority---almost
by definition, a value type doesn't have a determinate lifetime.
In C++, typically, objects without a determinate lifetime tend
more to be special cases: value types with variable size, or
which are too expensive to copy, even when you'd like to, or
"agents": small polymorphic objects without much, if any, state,
which are passed around, typically so that an object A can do
something dependent on the actual type of another object B.
While such objects aren't the majority, at least not in most C++
programs, they do occur often enough to make it worth having
garbage collection in your toolkit. Every little bit helps, as
they say.
You seem to be misunderstanding the argument. There are
specific times when garbage collection might be chosen for
performance reasons, but they are fairly rare, and as you say,
you can also optimize the performance of manual schemes. The
main argument for garbage collection is greater programmer
efficiency.
(There is a second argument, involving security. The fact that
the underlying memory of an object cannot be used for any other
object as long as there remains a pointer to the original
object. In an ideal system, of course, there wouldn't be such
pointers. But in practice, it's nice that you can make behavior
defined even if they happen to occur.)
J
Juha Nieminen
Razii said:
Which "older OS"? Some 30yo?
J
Juha Nieminen
Matthias said:
My point is that the style of C++ programming which produces safe code
tends to also produce good code in other respects as well. Thus there's
a positive side-effect to not having GC in this case.
I often find that even quick&dirty small programs to perform minuscule
tasks look good because of this style of programming, and it doesn't
even necessarily require any extra work (mainly because usually the STL
can be used for data management).
J
Juha Nieminen
Razii said:Well, my friend, I have proven you wrong. Razi has been victorious
once again
Uh? I said that the claim that each "new" performs an OS call is
blatantly false. How does your program prove that wrong?
Your C++ program does *not* perform a system call for each executed
new, and I can prove that.
J
Juha Nieminen
Razii said:
Your quote confirms that your claim that each 'new' causes an OS call
is false.
J
James Kanze
We must have had to maintain C++ code written by different
people
. I don't think you can really claim that C++ forcesyou to write clean, abstract, encapsulated code. (Nor does
Java, of course. Or any other language.)
Woah. Garbage collection has absolutely nothing to do with how
often you use new. In fact, in many cases, it will result in a
lot less use of new than otherwise. It's much easier to share
representations if you don't have to worry about who's going to
delete it.
The whole argument is irrelevant. On both sides. Garbage
collection doesn't make a language "dynamic", at least not in
the usual sense. Weak typing does, and I would agree that most
of the time, this leads to less robust code. The fact that
everything derives from Object (or rather, that so many things
only know about Object) is a disaster when it comes to writing
robust code. But you can do this in C++ as well---some early
container libraries did. (I believe that the problems revealed
by such libraries were part of the motivation for adding
templates to the language. Although even before templates, many
of us found that using <generic.h>, as painful as that was, was
preferable to "everything is an Object".)
In practice (and I speak here from experience), using garbage
collection in C++ doesn't impact style that much. (And with the
exception of a few people like you and Jerry Collins, many of
those worried about its impact on style really do need to change
their style.) Even with garbage collection, the "default" mode
in C++ is values, not references or pointers (call them whatever
you want), with true local variables, on the stack, and not
dynamically allocated memory. As far as I know, there's never
been the slightest suggestion that this should be changed.
The result is that, unlike the case in Java, garbage collection
isn't necessary in C++. But it does save some effort in certain
cases. And it can be used to significantly enhance security in
others. (Dangling pointers can be a serious security problem,
see
http://searchsecurity.techtarget.com/news/article/0,289142,sid14_gci1265116,00.html.
And while garbage collection can't completely eliminate dangling
pointers in C++---you can still return a pointer to a local
variable---it can certainly help.)