Automatic memory management...?
"Just use Boost" is not a viable strategy when it adds so much complexity in and of itself.
I'm not defending Java, but it's helpful to know what the limits of each tool are.
"Just use Boost" is not a viable strategy when it adds so much complexity in and of itself.
I'm not defending Java, but it's helpful to know what the limits of each tool are.
I strongly disagree that Boost really adds "so much complexity"--and, by the way, shared_ptr and friends are in C++11, and by extension within the standard library. So you don't even need this, unless your goal is to target extremely old platforms. But honestly, if you seriously need shared_ptr, your code design is probably just Not Very Good.
The LMAX Disruptor pattern would like to have a word with you.
http://lmax-exchange.github.io/disruptor/
http://martinfowler.com/articles/lmax.html
http://stackoverflow.com/questions/6559308/how-does-lmaxs-di...
I'm not just namechecking the Disruptor pattern. I have extensive experience with it. It's about 10% slower than what could be achieved with C -- which is to say, the benefits of not having to program in C far outweigh the 10% loss of performance. And its performance is almost always far higher than what's needed, i.e. the bottlenecks are elsewhere.
I strongly disagree that Boost really adds "so much complexity"
We'll have to agree to disagree, I think. Importing Boost is often a sign that something is awry with the design goals of the project. Either the choice of language is wrong, or the project is too ambitious. Though there are some aspects of Boost that are pretty good, such as its unit testing framework.
if you seriously need shared_ptr, your code design is probably just Not Very Good.
This I fully agree with.
What does that even mean?
Are you saying that you have a proof of the theoretically fastest C program that would implement the same functionality and it's 10% slower than that? Does the C you're comparing it against use the Disruptor pattern too? Or is this just a comparison against a naive, single-threaded C program? How does that number vary with the overall heap size of the program?
Numbers like this get thrown around that strike me as incredibly dubious.
Hunting for memory leaks and pointers gone berserk will become someone's full time job.
I like C++, but don't miss using it in enterprise projects.
If you're comparing the JVM's GCed heap with some specific, user-managed allocation scheme, then know that the latter can be done (and is often done) in Java too.
Modern machines have, I don't know, say, 64GB RAM? How much of that can you use for thread stacks? 1GB tops? Modern applications work with really big heaps. Stack allocation is irrelevant for most of what the application is doing.
> Enforcing the placement of small objects on the heap, even a garbage collected heap, seems such a waste of time and efficiency.
Yeah, it seems that way, but it turns out that it isn't. Previous attempts to allocate Java objects on the stack showed little or no improvements.
A heap allocation in Java is a pointer bump, and deallocation of a short-lived object is free (Well, this is not quite true, because many allocations will trigger a young-generation collection which, in the JDK's GCs – though not in some commercial ones – takes linear time in the size of surviving objects)
> You have the option of implementing a garbage collector manually, or an object memory pool to remove the malloc/free new/delete overhead.
You have the same option in Java, too, and it's pretty much the same amount of work.
Well I disagree with that. In C++ it is quite common for most objects to be allocated on the stack. I have never heard stack allocation being described as irrelevant. Of course if the language puts everything on the heap then that statement might be true.
Most objects? You have 64GB of RAM! You want to tell me that you can take advantage of all that RAM with thread stacks? You're unlikely to even use 4GB of stack.
If you don't, then you're talking about a small application.