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

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

Быстрое округление вместо медленного floor()

    Заметка для начинающих пользователей math.h в высокопроизводительных вычислениях. Судя по гуглу проблема известная, но не смотря на то, что я себя новичком в этих вопросах не считаю, о таких неприятностях не догадывался.
    Речь пойдёт о floor. Вообще говоря, описанные проблемы производительности свойственны многим функциям, но я напоролся именно  на floor. Если коротко, то floor работает медленно. Настолько медленно, что в моём сеточном методе моделирования жидкости floor оказался в первых строках профайлера. Дело в том, что floor делает множество проверок на ситуации типа NaN, inf и может изменять глобальную переменную errno для сообщения о ошибке. Всё это занимает бОльшую часть времени работы функции. Во многих задачах всё это совершенно не нужно, а нужна только  скорость. Под катом пара вариантов решения проблемы: собственный fastFloor и настроки компилятора.

Запрет на создание не константных объектов

В процессе обдумывания одной безумной идеи, про которую я пока никому не расскажу, появилась интересная задачка. Необходимо запретить пользователю класса создавать не константные объекты.  Зачем? Надо. Ради спортивного интереса.

Решений тут есть несколько. Я опишу один из ненормальных, но теоретически интересных.

Qt Виджет выбора цвета (ColorPicker)

Виджет выбора цвета, ColorPicker
В процессе написания простого редактора картинок понадобилось написать виджет выбора цвета из палитры. Дизайнер нарисовал вот такую штуку:

Предполагается, что по клику на квадратик должен выбираться соответствующий цвет. Как такое реализовать с точки зрения программиста?
Под катом самое простое и короткое возможное решение.

Property C++: Upgrade

Как я и думал, публикация идей на хабре – хорошая штука. В комментариях к предыдущей статье я нашёл несколько очень важных замечаний.
Первое, самое очевидное – никак не проверяется вызов init в конструкторе. То есть если программист забыл проинициализировать свойства, то компилятор ничего не скажет, а падение в рантаме в коде класса Property – весьма непонятная для дебага ошибка.

Property C++

Наверное, все любители языка C++, которые использовали другие языки, такие как C#, удивляются: почему же в плюсах нет property. Ведь это действительно удобное средство, позволяющее полностью контролировать доступ к членам класса. В общем и я недавно заинтересовался данным вопросом. Подумав, полистав Страуструпа и наконец, погуглив, я пришёл к выводу, что property можно реализовать средствами языка. Думаю многие уже видели разнообразные реализации, например, от microsoft, но для кого-то, надеюсь, это будет интересным открытием.