BTW, I'm laughing at the managed code "programmer" who is modding down my posts as flamebait and overrated as a way to try to hurt my karma. Seriously, is that the best you got?
But seriously. Who writes a loop that does nothing but allocate objects on the free store and then does nothing with them? If this is actual code you are writing in a production environment you need to be fired.
This just in: If I create a program specifically to leak memory it will... LEAK MEMORY!!! Seriously, who is actually writing code like that? And why the fuck would you be creating the string with "new" anyway? Your code makes absolutely no fucking sense and appears to have been written intentionally to be crappy.
One could argue that the less deletes you have, more are the chances you have that there is a memory leak...
Yes, one could. This person is most likely an idiot, though. When you take full advantage of C++'s built-in memory management features or tools like boost, you will almost NEVER need to use new/delete.
If you care about when the file gets closed then you explicitly close it yourself.
What do you mean "if you care"? You should ALWAYS care. Leaving files opened for no good reason is the sign of being lazy.
But if you don't want to care about it then you don't have to - you can leave it to the garbage collector and it'll take care of it.
Translation: If you want to be a lazy and shitty programmer you can just leave it to the GC to close the file whenever it feels like it. It's not as if the user might want to open that file in another application or maybe reload it again, right? No, that never happens. One can only hope that you aren't responsible for writing critical software with such shitty standards for writing software.
You seem to be saying that after I save a file I have to wait for the garbage collector to run before I can open the file in another application or move it somewhere else on the disk. How will I know when the garbage collector has run (assuming it runs at all...)? Am I supposed to quit your application to force it to close the file before I can safely email it to somebody?
Exactly. A program that isn't closing files or disposing of native handles is just plain lazy and thus is probably the reason this person has C++ code that leaks so much memory or resources. Even IF the GC would take care of it for you you shouldn't be relying on it to do so (which in.NET the GC won't).
You don't have that right, and you're probably writing code with memory leaks.
Actually, I'm not.
From the Boost documentation: "Because the implementation uses reference counting, cycles of shared_ptr instances will not be reclaimed." You need to specially craft your cycle with a weak_ptr.
Okay, so my knowledge of boost is rusty, but again it has an object to handle what the person was complaining about. C++0x also has something to address that as well.
That thinks memory management is something a real programmer is concerned about.
A real programmer would know how to use built-in language features in C++ to handle most of the load of memory management. The ones still having issues are most likely idiots who you should fire.
Really? I didn't realize this tool was written in the 90s. Coincidentally it isn't and yet still has the same shittiness of a Java GUI since the beginning.
The primary use of this interface is to release unmanaged resources. The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used. However, it is not possible to predict when garbage collection will occur. Furthermore, the garbage collector has no knowledge of unmanaged resources such as window handles, or open files and streams.
So basically you are still having to manage your resources manually anyway or you are going to cause leaks. So what exactly am I gaining?
Because it doesn't provide full automatic memory management (smart pointers don't handle cycles), and because you have to write reams and reams of angle brackets to use them.
Then maybe you need to look at shared_ptr from boost and the equivalent introduced in C++0x? The very classes designed for the situation you are talking about? Oh right, it's more fun to make ignorant comments!
I can't speak for.net, but in Java you have very little need for it. It's better to close your files and connections, but they'll be garbage-collected for you if you don't.
I can speak for.NET since all one has to do is do a simple Google search for IDisposable or read MSDN about it. If you do not manage your nonmanaged resources with IDisposable the GC will not clean it up and you will leak handles and with anything GUI related you will with enough time causes GDI exhaustion to happen.
Yes, but you actually expect these people to understand C++? Most people like this probably don't realize that the C++ standard has had smart pointers to do automatic memory management for you for nearly a decade (and yes some of these still have issues with them which C++0x has addressed in many ways). Or ignore the boost libraries that provide smart pointers. The only time you really are doing manual memory management in C++ is when working with legacy code or if you are just pig ignorant of the features provided by the language or libraries like boost.
Isn't this much better than expecting every programmer to perfectly manage his memory every time?
Yes, how dare we expect a programmer to realize the implications of the code they write! And if it's so hard, there are plenty of built-in features or features in libraries like Boost that will help you in making memory management less of a chore. Again as a counterpoint, just look how much code written in.NET has to implement IDisposable which if not done means that programmers will leak all sorts of non-memory resources such as file handles, etc. The fact of the matter is is that you still need to learn about memory management and if you don't you are still going to have memory leaks even in a managed language. Pretending the problem doesn't exist doesn't make it go away.
Modern programmers have increasingly turned away from native compilation in favor of managed-code environments such as Java and.Net, which shield them from some of the drudgery of memory management and input validation.
So if you wanted to be shielded from the drudgery of memory management in C++ why weren't you using the features of the language that provide you automatic memory management to make this less of a pain? It's not as if you don't still have to do memory management in say.NET especially since the IDisposable pattern is needed all over the place in user-written code to clean up non-memory resources like file handles, GDI handles, etc held within your objects.
Yes, because I claimed at all that cutting just this one thing will solve all budget problems. Oh wait, I didn't. But if you start cutting MANY of these things they *gasp* add up to a much larger chunk of money. Funny how addition works, right?
If you're even paying attention to a single $500k budget item during the current crisis, you might as well be bailing out the Titanic with a soup ladle.
Except for the fact that cutting many $500k items adds up to a significant amount of money? No, clearly these cuts are not additive at all. And the reason why you cut lots of things that are small first is because they are usually the most easy things to cut.
Slashdot Mirror
BTW, I'm laughing at the managed code "programmer" who is modding down my posts as flamebait and overrated as a way to try to hurt my karma. Seriously, is that the best you got?
But seriously. Who writes a loop that does nothing but allocate objects on the free store and then does nothing with them? If this is actual code you are writing in a production environment you need to be fired.
Now the program when written the correct way as:
void testMemory() {
std::string s();
s.append("sample");
}
void testLoop() {
for (int x = 0; x 100000; x++) {
testMemory();
}
}
int main(int argc, char *argv[])
{
testLoop();
getchar();
}
Will not leak memory. Imagine that. If I don't write the program in a stupid way it won't actually behave stupidly! AMAZING!
This just in: If I create a program specifically to leak memory it will... LEAK MEMORY!!! Seriously, who is actually writing code like that? And why the fuck would you be creating the string with "new" anyway? Your code makes absolutely no fucking sense and appears to have been written intentionally to be crappy.
One could argue that the less deletes you have, more are the chances you have that there is a memory leak...
Yes, one could. This person is most likely an idiot, though. When you take full advantage of C++'s built-in memory management features or tools like boost, you will almost NEVER need to use new/delete.
If you care about when the file gets closed then you explicitly close it yourself.
What do you mean "if you care"? You should ALWAYS care. Leaving files opened for no good reason is the sign of being lazy.
But if you don't want to care about it then you don't have to - you can leave it to the garbage collector and it'll take care of it.
Translation: If you want to be a lazy and shitty programmer you can just leave it to the GC to close the file whenever it feels like it. It's not as if the user might want to open that file in another application or maybe reload it again, right? No, that never happens. One can only hope that you aren't responsible for writing critical software with such shitty standards for writing software.
You seem to be saying that after I save a file I have to wait for the garbage collector to run before I can open the file in another application or move it somewhere else on the disk. How will I know when the garbage collector has run (assuming it runs at all...)? Am I supposed to quit your application to force it to close the file before I can safely email it to somebody?
Exactly. A program that isn't closing files or disposing of native handles is just plain lazy and thus is probably the reason this person has C++ code that leaks so much memory or resources. Even IF the GC would take care of it for you you shouldn't be relying on it to do so (which in .NET the GC won't).
You don't have that right, and you're probably writing code with memory leaks.
Actually, I'm not.
From the Boost documentation: "Because the implementation uses reference counting, cycles of shared_ptr instances will not be reclaimed." You need to specially craft your cycle with a weak_ptr.
Okay, so my knowledge of boost is rusty, but again it has an object to handle what the person was complaining about. C++0x also has something to address that as well.
What does the IDE have to do with the language?
I don't know, honestly. The person I replied to was the one who brought up the IDE which I can only assume was Visual Studio.
Or, you know, he is actually competent at using the language features that make manual memory management mostly unneeded? Naaah, can't be that.
Well, it's garbage collection
Except for the cases when garbage collection will fail because you didn't implement IDisposable to manage the resources that the GC won't cleanup.
a metric fuckton of libraries at your disposal to make everything dead-simple
As opposed to the fuckton of libraries written for C and C++ programming?
and (honestly, if embarrassingly) the worlds greatest IDE.
Which can *gasp* be used to write C or C++ code as well.
That thinks memory management is something a real programmer is concerned about.
A real programmer would know how to use built-in language features in C++ to handle most of the load of memory management. The ones still having issues are most likely idiots who you should fire.
Really? I didn't realize this tool was written in the 90s. Coincidentally it isn't and yet still has the same shittiness of a Java GUI since the beginning.
Um, that you can only leak unmanaged resources, so you have an order of magnitude fewer possible leaks to worry about?
If you are having an order more possible leaks in your C++ code, then you are doing it wrong and are most likely a shitty programmer.
Yes, of course it does.
To quote from here:
The primary use of this interface is to release unmanaged resources. The garbage collector automatically releases the memory allocated to a managed object when that object is no longer used. However, it is not possible to predict when garbage collection will occur. Furthermore, the garbage collector has no knowledge of unmanaged resources such as window handles, or open files and streams.
So basically you are still having to manage your resources manually anyway or you are going to cause leaks. So what exactly am I gaining?
Because it doesn't provide full automatic memory management (smart pointers don't handle cycles), and because you have to write reams and reams of angle brackets to use them.
Then maybe you need to look at shared_ptr from boost and the equivalent introduced in C++0x? The very classes designed for the situation you are talking about? Oh right, it's more fun to make ignorant comments!
I can't speak for .net, but in Java you have very little need for it. It's better to close your files and connections, but they'll be garbage-collected for you if you don't.
I can speak for .NET since all one has to do is do a simple Google search for IDisposable or read MSDN about it. If you do not manage your nonmanaged resources with IDisposable the GC will not clean it up and you will leak handles and with anything GUI related you will with enough time causes GDI exhaustion to happen.
Yes, because managed code has no memory leaks.
Yes, and managed code never has need for manual memory management. Oh wait...
Yes, but you actually expect these people to understand C++? Most people like this probably don't realize that the C++ standard has had smart pointers to do automatic memory management for you for nearly a decade (and yes some of these still have issues with them which C++0x has addressed in many ways). Or ignore the boost libraries that provide smart pointers. The only time you really are doing manual memory management in C++ is when working with legacy code or if you are just pig ignorant of the features provided by the language or libraries like boost.
write guis in (preferably java or tcl).
Why would you write a GUI in Java? GUIs in Java look like shit.
Isn't this much better than expecting every programmer to perfectly manage his memory every time?
Yes, how dare we expect a programmer to realize the implications of the code they write! And if it's so hard, there are plenty of built-in features or features in libraries like Boost that will help you in making memory management less of a chore. Again as a counterpoint, just look how much code written in .NET has to implement IDisposable which if not done means that programmers will leak all sorts of non-memory resources such as file handles, etc. The fact of the matter is is that you still need to learn about memory management and if you don't you are still going to have memory leaks even in a managed language. Pretending the problem doesn't exist doesn't make it go away.
Modern programmers have increasingly turned away from native compilation in favor of managed-code environments such as Java and .Net, which shield them from some of the drudgery of memory management and input validation.
So if you wanted to be shielded from the drudgery of memory management in C++ why weren't you using the features of the language that provide you automatic memory management to make this less of a pain? It's not as if you don't still have to do memory management in say .NET especially since the IDisposable pattern is needed all over the place in user-written code to clean up non-memory resources like file handles, GDI handles, etc held within your objects.
He's talking about CPUs, moron.
Yes, because I claimed at all that cutting just this one thing will solve all budget problems. Oh wait, I didn't. But if you start cutting MANY of these things they *gasp* add up to a much larger chunk of money. Funny how addition works, right?
If you're even paying attention to a single $500k budget item during the current crisis, you might as well be bailing out the Titanic with a soup ladle.
Except for the fact that cutting many $500k items adds up to a significant amount of money? No, clearly these cuts are not additive at all. And the reason why you cut lots of things that are small first is because they are usually the most easy things to cut.