Re:I'm all for science/technology/astronomy but...
on
Back to Moon in 2015?
·
· Score: 2, Insightful
Because the moon doesn't have such a high gravity as let's say earth. This makes it easier to assemble and launch any vehicle that may be sent to Mars.
I think that Close is called in the destructor anyways, but the destruction is called when the garbage collector clears the object. And you don't known when this will happen. The only problem I have with the garbage collector is, that the amount of code increases IMHO. But I thought the reason behind using the garbage collector is, that it should make life a little easier. Sure having to call delete for objects on the heap can easily forgotten, but there are very good tools to find these mistakes. But think about a case were you forget to implement the _finaly block. You write to the file and later you want to delete it (eg. because it is a temporary file). This delete works if the GC has finlaized the Stream, but fail sometimes when the GC has not yet finalized the Stream. I think this mistake is harder to find than the forgotten delete. Just my 2 cents
I have to stand behind you. I recently had to try.NET at work. Can somebody explain me what this garbage collection sould be good for. It only standy in your way when working with files for example. You always have to call Close() to get ride of the file handle. In C++ I just create the file object on the stack and the compiler closes the handle when it gets out of scope. I don't have to worry about it.
C++ Native: {
ifstream ("FileName.txt");
Do something }
C++.NET: {
FileStream * pStream = 0;
try
{
pStream = new FileStream ("tt");
Do Something
}
catch (..)
{
}
_finally
{
pStream->Close();
} }
Thank you garbage collection for multiplying the number of code that is needed to do something with a file.
Slashdot Mirror
Because the moon doesn't have such a high gravity as let's say earth. This makes it easier to assemble and launch any vehicle that may be sent to Mars.
I think that Close is called in the destructor anyways, but the destruction is called when the garbage collector clears the object. And you don't known when this will happen.
The only problem I have with the garbage collector is, that the amount of code increases IMHO. But I thought the reason behind using the garbage collector is, that it should make life a little easier.
Sure having to call delete for objects on the heap can easily forgotten, but there are very good tools to find these mistakes.
But think about a case were you forget to implement the _finaly block. You write to the file and later you want to delete it (eg. because it is a temporary file). This delete works if the GC has finlaized the Stream, but fail sometimes when the GC has not yet finalized the Stream. I think this mistake is harder to find than the forgotten delete.
Just my 2 cents
I have to stand behind you. I recently had to try .NET at work. Can somebody explain me what this garbage collection sould be good for. It only standy in your way when working with files for example. You always have to call Close() to get ride of the file handle. In C++ I just create the file object on the stack and the compiler closes the handle when it gets out of scope. I don't have to worry about it.
C++ Native:
{
ifstream ("FileName.txt");
Do something
}
C++.NET:
{
FileStream * pStream = 0;
try
{
pStream = new FileStream ("tt");
Do Something
}
catch (..)
{
}
_finally
{
pStream->Close();
}
}
Thank you garbage collection for multiplying the number of code that is needed to do something with a file.