Holier than thou
-
Bulldozer00[^]:
Since C++ (by deliberate design) does not include a native garbage collector or memory compactor, programs that perform dynamic memory allocation and de-allocation (via explicit or implicit use of the “new” and “delete” operators) cause small “holes” to accumulate in the free store over time.
"Memory management is too important to be left to the computer."
-
Bulldozer00[^]:
Since C++ (by deliberate design) does not include a native garbage collector or memory compactor, programs that perform dynamic memory allocation and de-allocation (via explicit or implicit use of the “new” and “delete” operators) cause small “holes” to accumulate in the free store over time.
"Memory management is too important to be left to the computer."
::yawn::
-
::yawn::
What can I say? Slow news day. /shrug
TTFN - Kent
-
Bulldozer00[^]:
Since C++ (by deliberate design) does not include a native garbage collector or memory compactor, programs that perform dynamic memory allocation and de-allocation (via explicit or implicit use of the “new” and “delete” operators) cause small “holes” to accumulate in the free store over time.
"Memory management is too important to be left to the computer."
What a useless article :- presents the problem but offers no solution at all.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
-
What a useless article :- presents the problem but offers no solution at all.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
Rob Grainger wrote:
presents the problem but offers no solution at all.
Sure he does: For those types of niche systems, the best, and perhaps only, practical options available for preventing any holes from accumulating in your briefs are to eliminate all deletes from the code :laugh: Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
-
Rob Grainger wrote:
presents the problem but offers no solution at all.
Sure he does: For those types of niche systems, the best, and perhaps only, practical options available for preventing any holes from accumulating in your briefs are to eliminate all deletes from the code :laugh: Marc
Imperative to Functional Programming Succinctly Contributors Wanted for Higher Order Programming Project!
Marc Clifton wrote:
preventing any holes from accumulating in your briefs
This sounds like an altogether different problem... :laugh:
The United States invariably does the right thing, after having exhausted every other alternative. -Winston Churchill America is the only country that went from barbarism to decadence without civilization in between. -Oscar Wilde Wow, even the French showed a little more spine than that before they got their sh*t pushed in.[^] -Colin Mullikin
-
What a useless article :- presents the problem but offers no solution at all.
"If you don't fail at least 90 percent of the time, you're not aiming high enough." Alan Kay.
He listed several, but didn't explain them:
Quote:
If your application inherently requires post-initialization dynamic memory usage, then use pre-allocated, fixed size, unfragmentable, pools and stacks to acquire/release data buffers during runtime.
I've used those approaches before and they can be extremely fast, especially when you manage thread synchronization yourself.
Curvature of the Mind now with 3D