Jump to content

  • Log In with Google      Sign In   
  • Create Account


Destructor vs Cleanup()


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
29 replies to this topic

#21 InvalidPointer   Members   -  Reputation: 1369

Like
1Likes
Like

Posted 15 October 2012 - 10:41 PM

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


I really, really hope you don't use C++ exceptions.
clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.

Sponsor:

#22 simpler   Members   -  Reputation: 912

Like
0Likes
Like

Posted 16 October 2012 - 04:32 AM


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


I really, really hope you don't use C++ exceptions.


Why shouldn't one use exceptions in C++?

Edited by simpler, 16 October 2012 - 04:34 AM.


#23 BitMaster   Crossbones+   -  Reputation: 3653

Like
2Likes
Like

Posted 16 October 2012 - 05:22 AM

If you use exceptions and not destructors (as JohnnyCode 'suggested') you will have one hell of a time doing resource management. InvalidPointer makes no point beyond that. He neither said you should nor should not use exceptions.

#24 InvalidPointer   Members   -  Reputation: 1369

Like
0Likes
Like

Posted 16 October 2012 - 08:04 AM



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


I really, really hope you don't use C++ exceptions.


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.

EDIT: That also means that using raw allocations on the stack, anywhere, is unsafe. Consider the implications. Overloading operator new can help you in limited cases, come to think of it. If you don't, though, you're in trouble.

Edited by InvalidPointer, 16 October 2012 - 08:13 AM.

clb: At the end of 2012, the positions of jupiter, saturn, mercury, and deimos are aligned so as to cause a denormalized flush-to-zero bug when computing earth's gravitational force, slinging it to the sun.

#25 Bregma   Crossbones+   -  Reputation: 4768

Like
2Likes
Like

Posted 17 October 2012 - 08:30 AM


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.

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.
Stephen M. Webb
Professional Free Software Developer

#26 swiftcoder   Senior Moderators   -  Reputation: 9635

Like
1Likes
Like

Posted 17 October 2012 - 08:56 AM

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.

QFT.

Working in C++ on a platform without exception support is a continual nightmare.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#27 SiCrane   Moderators   -  Reputation: 9395

Like
0Likes
Like

Posted 17 October 2012 - 11:28 AM

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.

I wouldn't read too much into motivations here. Many vendors don't add or improve exception support on console and embedded platforms for the reason that there's just not a lot of demand for it from their customers. Of course, part of the reason that there's no demand for it is because these programmers are used to working on platforms without good exception support, so there's something of a chicken and egg problem here. Nonetheless, lack of interest from their customer base is real.

#28 swiftcoder   Senior Moderators   -  Reputation: 9635

Like
0Likes
Like

Posted 17 October 2012 - 11:46 AM

Nonetheless, lack of interest from their customer base is real.

That may apply to embedded hardware, consoles and such, but Android seems to be the elephant in the room here.

Google appears to have originally disabled exceptions/RTTI purely for performance reasons, since the compiler and toolchain always did support both, and the workarounds to re-enable those features were very popular.

Starting with NDK R5, Google officially enabled exceptions and RTTI. I guess their customer base was demanding...

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#29 L. Spiro   Crossbones+   -  Reputation: 12290

Like
1Likes
Like

Posted 17 October 2012 - 04:50 PM

Their customer base is made up of very few industry veterans. A huge share is indies, while much of the rest is start-up companies with little or no console experience.

Here, once again, we just disable exceptions and run-time type information. I do so with my personal engine as well.

Exceptions aren’t the only thing hit by the console developer’s mentality—templates are also discouraged with the exceptions of very basic ones. Especially forbidden is to typedef a template inside another template.


But, by this point, whether we are talking about exceptions or templates, we are no longer on-topic.


L. Spiro

Edited by L. Spiro, 17 October 2012 - 04:51 PM.

It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#30 Chindril   Members   -  Reputation: 170

Like
1Likes
Like

Posted 18 October 2012 - 12:38 PM

Another reason to use an init function or something similar is if a base class wants to call a virtual function in it's constructor. It will simply not work so you are forced to use an init function. This also goes for the destructor. I know if you need to do that you probably have some design issues, but in some rare cases it is warranted.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS