Софт
религиозносишное
31.03.11 15:37 // оригинал
Вставил свои две копейки на тему "каазлы адобы, прочь от нашего стандартного memcpy".
гуглеаппное
30.03.11 14:18 // оригинал
Ну надо же, гугль наконец-то раскачался и включил в Google Apps здоровущую пачку сервисов, ради которых еще приходилось держать отдельный gmail-аккаунт - и ридер, и пикаса, и прочий редко используемый хлам (за исключением трех крайне нужных Health, PowerMeter, Profiles). Переход пока, правда, не автоматический, администратору нужно несколько раз ткнуть на кнопку и приготовиться к разрешению возможных кофликтов, если адреса из домена использовались в каких-то гуглевских сервисах.
классвьюшнопобедное
29.03.11 14:34 // оригинал
При разборе косяков с ClassView в 2010-й студии было сразу понятно, что предпосылки проблемы восходят к тем уже далеким временам, когда один здоровый монолитный проект был разнесен по десятку dll. Первый подход был кривоват, полезли перекрестные ссылки подпроектов, которые через некоторое время пришлось разрулить железной рукой, при этом поперли кросс-ссылки инклюдов, которые разруливались в основном через активное использование forward-описаний классов (что, конечно, подпорки, но гораздо проще и быстрее долгого выстраивания правильного порядка инклюдов - опять же, не всегда достижимого).
В сочетании же с пространствами имен простое forward-описание приходится превращать в более громоздкие конструкции. Т.е., если в MyClass1 используется указатель на MyClass2, а живут они в разных пространствах имен, выглядеть это будет так:
namespace NS2
{
class MyClass2;
}
namespace NS1
{
class MyClass1
{
//...
MyClass2* m_pXXX;
};
}
Кроме того, в описании классов/функций из dll активно использовался вполне традиционный подход с выносом __declspec(dllexport/dllimport) в макросы, чтоб убрать поддержку двух наборов хедеров:
#ifdef MYDLLIMP
#define MYDLLEXP __declspec(dllexport)
#else
#define MYDLLEXP __declspec(dllimport)
#endif
После чего можно использовать это как
class MYDLLEXP MyClass
{
//...
};
MYDLLIMP определялся только в проекте, где класс нужно было экспортировать, так что в реализации класс оказывался с dllexport, а в пользовательских проектах с dllimport.
Именно эти две вещи и сломали ClassView. Крышеснос с непопаданием в место с описанием случился от MYDLLEXP - ну не врубался новый IntelliSense в эти макросы между ключевым словом class и именем класса. Пришлось чуть подправить:
#ifdef MYDLLIMP
#define MYDLLEXP dllexport
#else
#define MYDLLEXP dllimport
#endif
class __declspec(MYDLLEXP) MyClass
{
//...
};
Теперь все стало лучше, __declspec все-таки воспринимался как валидное ключевое слово, а что там внутри него, ClassView, к счастью, не волновало.
Ну а дубли в дереве возникли от сочетания forward-описаний с пространствами имен - каждое такое описание добавляло лишнюю строчку в дерево классов. Причем дубль возникал даже при описании дружественного класса из того же пространства имен:
namespace NS1
{
class MyClass1
{
friend class MyClass3;
};
}
Причина была понятна сразу, на устранение ушло несколько месяцев неспешных поисков (поскольку жить это особо не мешает, лишь тревожит чувство прекрасного).
Сначала искал подходящие настройки, потом подходящие прагмы, остановился же в итоге на следующем варианте, за который даже немного стыдно:
//stdafx.h
#ifndef __class
#define __class class
#define __struct struct
#endif
//myclass1.h
namespace NS2
{
__class MyClass2;
}
namespace NS1
{
class MyClass1
{
friend __class MyClass3;
//...
MyClass2* m_pXXX;
};
}
Поскольку еще из опыта с __declspec стало понятно, что у ClassView особые отношения с макросами, был применен тот же подход, но уже в мирных целях, и этот грязный хак вполне прокатил - компилятору пофиг, в дереве чисто.
классвьюшное
27.03.11 16:18 // оригинал
Когда я только начинал работать с Visual C, ClassView был отличной штукой. Но за прошедшие полтора с лишним десятка лет он не особо улучшился, а местами даже усложнил жизнь - особенно последняя версия.
С мелкими проектами, конечно, проблем нет, а вот на больших, где число классов идет на сотни, все становится довольно скучно. Собсно говоря, всего-то и нужно от отображения списка классов - дать возможность создавать в нем иерархии и раскладывать классы по папкам. Если мне память не изменяет, в районе какой-то из первых .net студий эта возможность появилась, причем в первых реализациях классы в папки можно было переносить, а не копировать (оставляем за скобками такую мелочь, как стабильный вылет одной из версий студии при переносе классов в папки через меню, а не через перетаскивание мышкой). Но в какой-то момент (кажется, в 2005 студии) перенос заменили копированием, что сделало практическую пользу от папок в крупных проектах минимальной. Ну да, туда можно вытащить наиболее часто используемые классы, но перетряхнуть так весь список классов практически нереально - если в случае переноса классы, не сгруппированные по папкам, сразу на виду, то тут фиг разберешь, все ли уже посчитаны, или нет.
На помощь пришли пространства имен - по счастью, ClassView их понимает и умеет использовать для группировки классов. В конце концов, и с точки зрения логики проекта полезно было рассортировать классы, ну а то, что непосредственным поводом для этого стала такая сугубо косметическая вещь, как их отображение в дереве - да и ладно.
На некоторое время все устаканилось, но когда подоспела 2010 студия, обновленный IntelliSense сошел на нашем проекте с ума, а аккуратно отсортированное дерево классов превратилось в страх и ужас - часть классов засветилась там по нескольку раз, при этом клик на имени класса запросто мог выкинуть не на полное, а на forward-описание, а клик по функциям и просто игнорироваться. Пришлось разбираться, но об этом уже в следующий раз.
студийное
26.03.11 20:09 // оригинал
Ну надо же, в VS 2010 SP1 все-таки включили внешний help-вьювер, прислушались к стонам. Надо будет глянуть, насколько он лучше H3Viewer, если вообще.
атишноконтрастное
19.03.11 17:11 // оригинал
В последнюю неделю при просмотре любимых сериалов совершенно достала пренеприятная скачкообразная смена уровня освещенности вскоре после смены сцены. Поначалу винил кодеров, но эффект стал вылезать на видео с разных трекеров. Ну а вспомнив, что как раз с неделю назад обновил атишные драйверы, полез в их настройки. И увидел там в разделе видео толпу улучшайзеров, которых раньше не было. Настроек много, (бес)полезность каждой проверять еще лениво, но главный виновник обнаружился сразу - включение динамического контраста. Совершенно антигуманное изобретение, как-то включал его на мониторе, исплевался - и нате, тихо врубили по умолчанию.
цветовое
19.03.11 12:35 // оригинал
IE9 стал третьим браузером под Windows с поддержкой цветовых профилей - причем сразу ICC4, в отличие от Safari и FireFox с ICC2 (в FF некоторое время назад случился даунгрейд с ICC4 на ICC2). Тем, кто слышит про все это в первый раз, проще всего зайти на эту страницу и увидеть разницу воочию. К сожалению, FF по-прежнему остается единственным браузером, в котором можно включить принудительное использование цветовых профилей для текстовой части страницы и untagged-изображений из предположения, что они готовились в RGB (что справедливо для подавляющего большинства веб-картинок). Последнее, впрочем, принципиально только для счастливых владельцев мониторов с расширенным цветовым охватом (а точнее, для их незначительного подмножества, которое как-то волнует адекватность выводимой картинки, остальные будут просто восторгаться "сочностью" цветов).
эпплозащитное
31.01.11 19:12 // оригинал
Лично я в полном восторге от этого.
синхронизаторское
18.12.10 15:21 // оригинал
Что-то штатный ffшный Sync перестал радовать в последнее время - при синхронизации четвертой беты с третьей теряет закладки, разложенные на панели закладок (а так сложилось исторически, что у меня все закладки собраны как раз в папках, разложенных по этой панели). Так что вернулся к старому доброму xmarks, раз уж они передумали умирать и даже кому-то недавно продались.
фастфорвардное
25.11.10 21:38 // оригинал
Не прошло и восьми лет, как Соколиный Глаз открыл для себя кнопку Fast Forward в Опере и прикрутил к своим страницам код, дающий ей дышать. Вот не выпендривался бы с », само бы работало все эти годы.