yes, from C# object gets anownced that it would like to be freed (By OS manager GC). You then perform alll logic to free resources the object posesss. Like sicrane said, study cli/c++
in c++ destrocturos are not necesary, nor any good logic, from C#, managememet of memory yes
You can still design your logic to not need destructors, but your logic must be freed and managed well
[quote name='JohnnyCode' timestamp='1350101946' post='4989668']
yes, from C# object gets anownced that it would like to be freed (By OS manager GC). You then perform alll logic to free resources the object posesss. Like sicrane said, study cli/c++
in c++ destrocturos are not necesary, nor any good logic, from C#, managememet of memory yes
You can still design your logic to not need destructors, but your logic must be freed and managed well
[quote name='InvalidPointer' timestamp='1350362505' post='4990618']
[quote name='JohnnyCode' timestamp='1350101946' post='4989668']
yes, from C# object gets anownced that it would like to be freed (By OS manager GC). You then perform alll logic to free resources the object posesss. Like sicrane said, study cli/c++
in c++ destrocturos are not necesary, nor any good logic, from C#, managememet of memory yes
You can still design your logic to not need destructors, but your logic must be freed and managed well
Why shouldn't one use exceptions in C++?
They can carry some very subtle, complicated costs and require some extra thinking when designing algorithms and classes. For games I don't really think they're worth said cost; in most cases using error codes can work equally well and can 're-enable' more dangerous (but speedier) class architectures. The latter is why I bring things up-- the C++ spec says the compiler will walk up the call stack, invoking destructors on everything until it finds an appropriate catch block. If you don't release any resources in the destructor, congratulations! You've just created a pretty massive, totally unfixable memory leak.
[/quote]
The cost of designing using object-oriented techniques, including exceptions, is no greater than procedural techniques and propagating error codes, unless and except if you are more familiar with one or the other. This is not a technical issue, but a personal or social issue.
It is easier to leak resources using procedural programming in which you need to handle releases nonlocally as you manually unwind the stack than it is using OO techniques in which the purpose of the destructor is to release resources. Sure, you can write bad code using any paradigm. You are less likely to write that particular kind of bad code using OO than procedural.
The third argument for using manual stack unwinding and error code propagation vs. exceptions is that you can write faster, simpler code with the manual method, because you just skip the error checks and cleanup code. You see a lot of that kind of code thrown up as examples of why exceptions are undesirable. I find it unconvincing.
The only really legitimate argument I've heard against using clean OO design with exceptions is that they're not supported by some runtimes. Now that seems fair to me, although the fact that they've been supported by C++ longer than most of the posters on these forums have been alive makes it seem to me that the vendor's decision on that front has been politically motivated.
The only really legitimate argument I've heard against using clean OO design with exceptions is that they're not supported by some runtimes. Now that seems fair to me, although the fact that they've been supported by C++ longer than most of the posters on these forums have been alive makes it seem to me that the vendor's decision on that front has been politically motivated.
Now that seems fair to me, although the fact that they've been supported by C++ longer than most of the posters on these forums have been alive makes it seem to me that the vendor's decision on that front has been politically motivated.
Nonetheless, lack of interest from their customer base is real.
