You can "early" dispose them using the dispose() methods we talked about before, but the GC is also smart. It takes into account relative costs of external resources (for GUI only, not for files etc) and will call GC pre-emptively when that cost gets too high.
I'm enjoying! GC is not (yet) smart enough to handle any resources but memory. You should get to know how brushes/pens/other of such stuff management is implemented in.NET. There are separate small resource managers for that.
An even if it is just a non-resource based class, I do new() on a class a few hundred times per program. Trying to find a delete() for each of those (especially if it is not located near the new() or if you have multiple execution paths etc.)
You're obviously not familiar with smart_ptr Boost library or even RAII idiom. Manual new/delete is not a issue in C++.
It amuses me that people not familiar with basic C++ ideology (like Web developers for example) tend to speculate about C++ deficiencies.
Please explain to me exactly how you can implement a resource management system (or regime as you call it) in C++ for, lets say, managing socket connections, that has no equivlent in Java. You are aware of this method, right? (close() method)
And your GC with automatic resource management goes out of the window right there! The point is GC is suitable for memory management only. But there's a lot more resources other than memory that requires managing. Well designed systems have to have some support for that too, otherwise you end up doing it with your bare hands (as in Java).
There is no such thing as built-in string implementation. If you don't like one vendor's standard library you take another one's, simple as that. There's a lot of choice when it comes to C++ standard library. Dinkunware, STLPort, SGI to name a few.
the *average* computer has enough RAM to run three horribly-inefficient
extreme memory-hog applications at the *same time* without needing any swap
You know my computer runs at least 50 apps at the moment, not 3 or 4. RAM is still not a resource conscious developers prefer to waste.
You talk about GC screwing
up virtual RAM algorithms, but it's really not an issue on most systems; if
a process grows to three or four *times* the size it needs to be, it doesn't
actually have any user-noticeable impact on performance.
Depends. It's not noticible only if that memory is not actually accessed, i.e. no frequent cache misses and, God forbid, swaps.
Memory leaks are
actually much worse, because in that case the wasted memory doesn't ever get
collected and eventually it becomes a problem, after a couple of hours of
use.
I'm sick of a "memory leak" argument. Do we compare well written apps here or sloppy written apps? If GC allows you to afford sloppiness in software development and still have a "decently" performing app then so much it's worth.
Slashdot Mirror
You can "early" dispose them using the dispose() methods we talked about before, but the GC is also smart. It takes into account relative costs of external resources (for GUI only, not for files etc) and will call GC pre-emptively when that cost gets too high.
I'm enjoying! GC is not (yet) smart enough to handle any resources but memory. You should get to know how brushes/pens/other of such stuff management is implemented in .NET. There are separate small resource managers for that.
An even if it is just a non-resource based class, I do new() on a class a few hundred times per program. Trying to find a delete() for each of those (especially if it is not located near the new() or if you have multiple execution paths etc.)
You're obviously not familiar with smart_ptr Boost library or even RAII idiom. Manual new/delete is not a issue in C++.
It amuses me that people not familiar with basic C++ ideology (like Web developers for example) tend to speculate about C++ deficiencies.
Please explain to me exactly how you can implement a resource management system (or regime as you call it) in C++ for, lets say, managing socket connections, that has no equivlent in Java. You are aware of this method, right? (close() method)
And your GC with automatic resource management goes out of the window right there! The point is GC is suitable for memory management only. But there's a lot more resources other than memory that requires managing. Well designed systems have to have some support for that too, otherwise you end up doing it with your bare hands (as in Java).
There is no such thing as built-in string implementation. If you don't like one vendor's standard library you take another one's, simple as that. There's a lot of choice when it comes to C++ standard library. Dinkunware, STLPort, SGI to name a few.
the *average* computer has enough RAM to run three horribly-inefficient extreme memory-hog applications at the *same time* without needing any swap
You know my computer runs at least 50 apps at the moment, not 3 or 4. RAM is still not a resource conscious developers prefer to waste.
You talk about GC screwing up virtual RAM algorithms, but it's really not an issue on most systems; if a process grows to three or four *times* the size it needs to be, it doesn't actually have any user-noticeable impact on performance.
Depends. It's not noticible only if that memory is not actually accessed, i.e. no frequent cache misses and, God forbid, swaps.
Memory leaks are actually much worse, because in that case the wasted memory doesn't ever get collected and eventually it becomes a problem, after a couple of hours of use.
I'm sick of a "memory leak" argument. Do we compare well written apps here or sloppy written apps? If GC allows you to afford sloppiness in software development and still have a "decently" performing app then so much it's worth.