У монитора родной цветовой охват близок к sRGB и поддерживается аппаратная калибровка. Он где-то между Apple LED Cinema Display 27" и NEC PA271W.
Dell U2711 с расширенным охватом и подсветкой на CCFL. Dell U2713HM скорее можно сранивать с Samsung S27A850.
Это относительно старая модель, анонсирована в начале прошлого года. Вот тема на iXBT. В России в официальной продаже доступен с лета. Рекомендованные цены в районе 42-44тр.
Обертки для методов создаются на этапе компиляции и имеют статическое время жизни, т.е. доступны всегда. Это накладывает некоторые ограничения на код, например, нельзя инициализироваться из сырого указателя на метод класса, полученного через переменную, но это можно пережить. Многие же параметры имеют динамическую природу и вычисляются во время выполнения программы. Их не получится запаковать во время компиляции, т.к. актуальных значений еще не существует.
Макросы ощутимо сокращают запись, указывается минимум необходимой информации: адрес функции и адрес объекта. Как написать так же кратко без них, не представляю.
Не понял, о чем речь во 2-м пункте. Это биндинг известных параметров к аргументам в момент связывания функции?
Если речь непосредственно про связывание (BC_BIND(...) из статьи), то это непринципиально, просто унификация синтаксиса. А если про класс, инкапсулирующий указатель на функцию (bc::function<...>), то очевидно, что вызывающая сторона, которая хранит объекты этого класса, понятия не имеет, что именно к ней прицепит клиент, поэтому есть какой-никакой выбор.
Ответ из двух частей:
1. Пишу это просто потому, что это возможно. Интересно поиграться с возможностями языка.
2. Похожая реализация (вариант для C++03, VS2010) в совокупности с умными указателями вынужденно применялась в системе сигнал/слот в одной компании, где не приветствовалась привязка не то, что к boost, но даже к stl.
boost/std::function тоже позволяют связываться как со свободными функциями, так и с методами классов. Не вижу в этом ничего необычного, обе возможности могут пригодиться. Например, если обработчику не требуется состояние, зачем его делать методом класса, и наоборот, если состояние требуется, то простой функцией уже не обойтись.
Вы не читали пост или не смотрели реализацию Loki::Functor, где используется динамическая аллокация памяти, от которой в данной реализации предлагается избавиться?
Статья не про то, что выбрать, а как еще можно сделать самому. Но если уж брать готовое, то лучше сразу из std или boost.
Легко, через escape-последовательности. Например:
Кстати, о коллизиях — эти строки дают одинаковый хэш.
Dell U2711 с расширенным охватом и подсветкой на CCFL. Dell U2713HM скорее можно сранивать с Samsung S27A850.
Не понял, о чем речь во 2-м пункте. Это биндинг известных параметров к аргументам в момент связывания функции?
Ответ из двух частей:
1. Пишу это просто потому, что это возможно. Интересно поиграться с возможностями языка.
2. Похожая реализация (вариант для C++03, VS2010) в совокупности с умными указателями вынужденно применялась в системе сигнал/слот в одной компании, где не приветствовалась привязка не то, что к boost, но даже к stl.
Статья не про то, что выбрать, а как еще можно сделать самому. Но если уж брать готовое, то лучше сразу из std или boost.
Делегаты, например? Для чего обычно используется boost/std::function?
Это не потребность, а возможность.