how bad is killing bugged programs?

hello
It happens so often, while developing, to be forced to break a running program (eg when a loop can't exit).
I'm wondering, int that case, what could happen:
1: if an opened file is not being closed correctly?
2: if an instantiated object's destructor (which contains, say, some delete statements) is not called?
3: if a library (eg SDL) is not being shut down correctly?

Here is a more specific question:
I'm developing a non professional chat software using SDL, and initializing it to enable the unicode encoding, and some key control stuff.
It happens a strange thing: sometimes I play with a videogame (armagetron) which uses the same library. Before I've started programming with SDL, I could type (in game) special chars using the ALT-GR + KEY combination, but now I cannot do that.
May it be related to the fact I'm sometimes forced to shut down (kill) my bugged program?
(OS is Linux Ubuntu 6.06 LTS)

thank you

1: if an opened file is not being closed correctly?
2: if an instantiated object's destructor (which contains, say, some delete statements) is not called?
3: if a library (eg SDL) is not being shut down correctly?

1. Depends. If your system is coming down your OS should clean up the open handle.

2. std::auto_ptr's have fixed this issue by guaranteeing that they will be cleaned up. In fact using std::auto_ptr's in a constructor is probably the best place to use them. If you throw from the constructor the pointers will be cleaned up. I don't like std::auto_ptr's copy semantics but they do have their uses. Boost provides an entire library that is far more robust than std::auto_ptr. I would look into it.

3. This can cause major issues if the system is not coming down. Again if the system is coming down, your OS will clean up so your code theoretically can be restarted as if nothing happened. Of course we don't live in a perfect world so if this happens a lot I would say your chances of a perfect cleanup are not that good. If you leave COM in a mess it is very possible that it will not work correctly the next time you try to use it. IE: You can bail incorrectly from a DirectX application and hose DX. This necessitates a reboot in order to use DirectX again.


In short you should always make every attempt to clean up your memory footprint.

thanks Bubba, ragards

Originally Posted by carlorfeo

It happens a strange thing: sometimes I play with a videogame (armagetron) which uses the same library. Before I've started programming with SDL, I could type (in game) special chars using the ALT-GR + KEY combination, but now I cannot do that.

First, it is only an assumption that this problem stems from SDL, but let's use that assumption for a moment.

It is possible that you are making some buggy calls which are disrupting SDL in other applications. But if this is so, then the problem is with SDL, not you. Libraries which maintain state which is global to all applications have to be robust against client errors. They are like an operating system in certain ways, and it is their responsibility to deal with anything clients might throw at them.

So, even if your code has a bug, this should not be causing this problem with SDL. I would report this as a bug (again, assuming this problem is because of SDL, which is not proven).