Microsoft Visual Studio

Про Qt5 и VisualStudio 2012

Если в двух словах, то со связкой указанной в заголовке - счастья не получил, откатился на VS2010.

Если подробно:

  • Qt - собирается без проблем, работает.
  • qmake делает прекрасные работоспособные Makefiles
  • qmake -tp vc - делает .vcxproj которые зовут компилятор от 2010-й версии (нет, я не туп, пути стоят нормально, QMAKESPEC=win32-msvc2012) и проекты не собираются, линкер ругается что у меня мои объектники от 2010, а библиотеки - от 2012.
  • Предыдущую проблему поборол: QMAKESPEC=win32-msvc2010 qmake -tp vc, при первом открытии проекта его апгрейдим на 2012. Достает, но уже привык.
  • Макросы для отладчика (показ Q-types по человечески) - установились, но не заработали.
  • Последняя капля: при попытке прикрутить иконку к .exe (обычным способом: RC_FILE=resource.rc в .pro) - все сломалось с ошибкой "VTRES : fatal error CVT1100: duplicate resource. type:ICON, name:1, language:0x0409". Судя по гуглению, это привет от конверсии проекта из 2010 в 2012, этот самый .rc оказывается в двух местах прописан.
Короче, поживу с 2010-м вижуалом до Qt 5.0.1. Хотя 2012-й мне нравится больше.

Q: InstallShield Limited Edition и вообще про инсталляторы.

Прошу прощения что я не о выборах, но вот такие вот практические вопросы.

Вопрос номер раз

  1. Visual Studio 2010, хочу сделать проект изготавливающий инсталлятор. Ну значит New Solution - и там есть пимпа "Enable InstallShield LE".
  2. Жму в пимпу, мне предлагают этот InstallShield скачать. Скачиваю, запускаю инсталлятор.
  3. Инсталлятор инсталлирует, говорит что надо Studio перезапустить.
  4. Перезапускаю. Одновременно прилетает письмо с серийником.
И вот теперь имею проблему:
  • Куда нужно сунуть серийник - просто не понимаю. Все меню облазил, не нашел.
  • InstallShield-проект создать нельзя. Не создается, failed и все.
Кто виноват и что делать?

Про существование NSIS знаю, но хотел попробовать с InstallShield, чтобы вообще понимать чего хотеть.

Вопрос номер два

Посмотрел, а как себя ведут разные варезы, уже установленные на машине. Вижу следущее

  1. Те, кто использует MS-овский рантайм от VS2005 или 2008 - те, преимущественно, честно приносили redistributable и куда-то его ставили, в каталоге приложения msvc*.dll нету.
  2. А вот пользователи рантайма от 2010 - имеют его у себя в директории с приложением по большей части.
Считается ли второй способ вежливым к юзеру? Там цена вопроса, конечно, мегабайт или около того, Qt-шных DLL-ей у меня будет в разы больше, поэтому это вопрос именно принципа, а не экономии юзерского диска.

О семантике C++

В продолжение кулуарного разговора с Highload++, навеянного 26-м слайдом презентации Андрея Аксенова.

Вот такой вот код:

class someShit{
        char *m_sBuffer;
        size_t m_iLimit, m_iCounter;
};
void someShit::try1()
{
 
...

О компиляторах и процессорах: AVX

Армянское радио Нас спрашивают:

Как измениться производительность intrinsic варианта на Core-i7, если поменять
_mm_dp_ps на _mm256_dp_ps
_mm_blend_ps на _mm_blend256_ps

То-есть насколько вырастить производительность если мы совсем на AVX переедем и будет обрабатывать по 8 float за проход? А то слухи разные ходят... от 0% до 200% роста.

Отвечаем:

Если игнорировать возможную нечетность размера данных, то код получается таким:

ALIGN1(32) float
...

Visual Studio .sln/.vcproj generator?

По многочисленным просьбам трудящихся, я поставляю вместе с LibRaw еще и .sln/.vcproj файлы для MS Visual Studio.

Генерирую я их с помощью Qmake и все более-менее работает, но:

  • Иногда (когда Юпитер в Рыбах?) в sln-файле вместо относительных путей оказываются полные, приходится ручками чистить.
  • Проекты содержат AdditionalIncludeDirectories указывающие (абсолютным путем) на mkspecs от моего Qmake.
  • Можно сгенерировать проект для 32-бит, вроде бы можно (хотя не пробовал) для 64 бит, а вот под две платформы сразу - не умеет.
  • Была еще проблема с зависимостями (exe - dll), ибо зависимости ловятся искуственным интеллектом, но вроде я научился добиваться от него счастья.
  • Достали win32:/unix: конструкции в .pro-файлах, блин.
Короче, неаккуратненько, неровно висят.

Попробовал CMake и счастья еще меньше, проекты ALL_BUILD и ZERO_CHECK раздражают мое эстетическое чувство. При этом проблема абсолютных путей не решена, а дальше я копать не стал и CMake снес.

Что я упустил? Какой еще есть варез, который нагенерирует мне sln/vcproj из простых текстовых файлов?

О консистентности

Чтобы на времени компиляции убедиться в том, что у нас MS Visual C++ 2008 SP1+, нужно забабахать вот такое вот:
#if defined(_MSC_VER) && _MSC_VER == 1500 && _MSC_FULL_VER >= 150030729

Ну ладно, ну вот лично я бы две старших цифры в _MSC_VER занял бы под major версию, а две младших - под minor (сервис-паки, то-се), ну ладно, пусть будет два макроса.

Опять-таки, ладно, что MS Visual C++ 2008 это на самом...

...может задолбать небольшого слона....

Все-таки я продолжаю считать, что кавардак с многочисленными несовместимыми рантаймами не украшает Microsoft Windows вообще и MSVC в частности.

Ситуация:

  • Свежий Qt 4.7.2, собранный (в Нокии) MSVC 2008
  • Мой варез, который я собираю лично MSVC 2010
До вчерашнего дня у меня был Qt 4.7.1 собранный самостоятельно (тем же MSVC 2010) и все было отлично. Заменяю Qt на DLL, собранные в Нокии, qmake (перегенерация мейкфайлов т.е. ключи компиляции гарантированно правильные), перекомпилирую, и что имею:
  • В целом
  • ...

Ну кто так строит.....

С лета у меня висела плавающая бага, все руки не доходили.

Суть в том, что в LibRaw внутри аллоцируется кусок памяти, отдается вызвавшему приложению, а оно, когда с ним наиграется, должно освободить его путем банального free()

И что бы вы думали, в некоторых ситуациях берет и падает в этом самом месте. Не у всех, у меня от одного только пользователя был багрепорт, который впрочем воспроизводился и у меня.

Оказалось

  • У Microsoft есть две библиотеки для работы с памятью, нормальная и отладочная. Ну, нормально, у всех так.
  • Но аллоцируемое этими библиотеками - несовместимо между собой. То что одна malloc(), то другая не может free(). Ну тоже понятно.
  • Но при этом - нет никаких проблем слинковать в приложение сразу две эти библиотеки. Релизный DLL тянет с собой релизную, отладочный код приложения - отладочную.
Ну а дальше - понятно, что релизный DLL аллоцировал, то отладочное приложение освободить не может, а может только упасть.

Дети, это нельзя понять, это надо запомнить.

Избаловались мы в юниксах с этими самыми

LD_PRELOAD=/path/to/debug-malloc.so ./myapp
А, да, сухой остаток, сижу выпиливаю в LibRaw зеркальный вызов, который будет освобождать аллоцированное строго правильным освободителем. Две строчки кода, блин.
Subscribe to Microsoft Visual Studio