Как не хватает деструкторов или зачем счётчик ссылок в AS3/Java/#ANY_GC_LANG#

Начиная ещё с java разработчики языков использющих сборщик мусора катрегорически отказываются реализовывать деструкторы или какие-нибудь другие инструменты для реализации RAII. Тем временем сборщик мусора решает проблему управления только одним ресурсом - памятью, выделенной в куче. Остальные ресурсы, такие как дескрипторы файлов, сокетов, сетевых портов и кучи других нужных вещей остаются безконтрольными. Вся ответственность за такие ресурсы лежит на программисте и компилятор не может ничем помочь. Мне, например, только что пришлось изобретать счётчик ссылок для совместного использования текстуры в видеопамяти. Пока ей пользовался один объект всё было просто - он знал, когда надо текстуру создать, когда удалить. Когда же захотелось пооптимизировать и пользоваться одной текстурой из нескольких графических объектов, то тупой копипаст дал неприятную ошибку. Достаточно, чтобы текстура стала не нужна только одному и она удаляется, и наплевать, что она нужна ещё в куче мест. Вечная жизнь меня тоже не устраивает, так как память на мобильниках не резиновая, а объекты появляются и пропадают часто. Вот так в 2014 году приходится решать концептуальную проблему, решённую в C++ году в 90-м если не раньше.

Android SDL2 crash on lock

В процессе написания игры под андроид с использованием SDL2 всплыла следующая ошибка. Периодически игра не хотела запускатсья или восстанавливаться, показывая чёреный экран. Ошибка воспроизводится при использовании дефолтного манифеста. Если во время игры нажать кнопку блокировки, то у SDL activity вызовется onDestroy(), что приведёт к завершению всего приложения и остановке потока нативного кода. Вот только вместо обычного события завершения

SDL_QUIT

вам придёт

SDL_APP_TERMINATING

Лично я до встречи с этой проблемой о таком событии вообще ничего не слышал и в документации не встречал. Поэтому корректно это событие не обрабатывалось, окно и рендер не удалялись, OpenGL контекст не закрывался и при разблокировке приложение не могло запуститься вновь.
Выхода два: обрабатывать событие как завершение приложения или вообще не закрываться при блокировке. Первый вариант не удачен, потому что это ломает парадигму использования андроидом. После разблокировки приложение должно продолжить работу. Поэтому нам надо чтобы onDestroy у активити вообще не вызывался. По этому поводу идём на stackoverflow и добавляем в манифест:

android:configChanges="orientation|keyboardHidden|screenSize"

Всё, теперь приложение будет продолжать работу, не обращая внимания на блокировку экрана.

Для англоязычных коллег / For English speaking programmers

My android SDL2 game crashed sometimes and showed black screen. If user press lock button onDestroy() method called and instead of

SDL_QUIT

event

SDL_APP_TERMINATING

event was sent to native code. I didn't know about this event because there is no any notes in documentation about it. So this event wasn't processed and renderer wasn't destroyed on application quit. You can process this event and exit correctly or add

android:configChanges="orientation|keyboardHidden|screenSize" 

 to android manifest to prevent onDestroy() method call. This solution was found at stackoverflow.