29 replies to this topic

[InvalidPointer]

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.

[simpler]

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.

[BitMaster]

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.

[InvalidPointer]

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.

[Bregma]

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.

[swiftcoder]

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.

[SiCrane]

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.

[swiftcoder]

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...

[L. Spiro]

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.

[Chindril]

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.