Кодовство

Чтобы не забыть команды WinDBG

2011-06-28T11:30:00.002+04:00

нужно записать их все сюда.

Примерно в таком порядке я их и использую при отладке минидампов из OCA:

!sym noisy	Включает подробный лог поиска и загрузки символов
.reload /f MyApplication.exe	Перезагружает символы для MyApplication.exe. Предыдущая команда позволяет посмотреть откуда и почему не грузит.
.symopt+0x40	Разрешить грузить даже unmatched PDB файлы
kb	Показать наконец стек

Сжатие старых файлов

2010-05-27T11:07:00.002+04:00

В очистке диска начиная с Windows XP появилась бесполезная возможность сжимать "старые" файлы. Из-за того что система оценивает сколько на этом можно выйграть места приходится долго ждать пока появится возможность удалить всё остальное. Я всё время забываю путь в реестре, где это отключается. Запишу тут (Windows XP):

Включается


Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\Compress old files]
@="{B50F5260-0C21-11D2-AB56-00A0C9082678}"
"Priority"=dword:0000012c
"StateFlags"=dword:00000000

Выключается


Windows Registry Editor Version 5.00

[-HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\VolumeCaches\Compress old files]

jpeg lossless rotation & crop

2010-02-10T09:47:00.001+03:00

При просмотре фотографий часто выясняется, что держать фотоаппарат боком - не лучшая идея. Приходится разворачивать снимки. Раньше я всегда поворачивал такие изображения только на время просмотра и не сохранял (или сохранял в PNG, что сильно увеличивало размер файла), так как при повторном сохранении в JPEG картинка ухудшится (а мой фотоаппарат сохраняет фотографии именно в JPEG). От этого я особенно не любил встроенный просмотрщик в Windows XP, который при повороте сразу пересохранял изображение.
Оказывается люди придумали решение этой проблемы: jpegtran, который обеспечивает lossless rotation и crop.
Оказалось также, что есть куча программ, которые это используют, вот список.
При помощи gwenview я и развернул и пересохранил большинство своих фотографий. Правда следует учесть что делал я это в gwenview из kde3, gwenview из kde4 (версии 4.3.1) при повороте меняет изображение, что можно заметить даже по пятнам в вычитании двух изображений в GIMP. Насколько я знаю и нагуглил, ImageMagic тоже не умеет вращать или обрезать JPEG без потерь, так что придётся старый gwenview оставить. Под Windows вероятно самым доступным приложением является Irfanview с плагином.

Планшет G-Pen 560 и openSUSE 11.2

2010-02-01T20:53:00.003+03:00

Случилось мне прикручивать планшет G-Pen 560 под openSUSE 11.2. Сам планшет без драйверов отлично работает и в Windows и в GNU/Linux как мышка, или как тычпад. Однако ценность планшета именно в абсолютном позиционировании и разной степени давления.
Сначала я попытался делать аналогично инструкции, однако с поправками на дистрибутив. WizardPen есть в OBS и доступен тут, поэтому никакой возни со сборкой и установкой. После загрузки и установки x11-input-wizardpen-0.7.0.alpha2-2.1.x86_64.rpm и x11-input-wizardpen-tools-0.7.0.alpha2-2.1.x86_64.rpm запустил калибровку:


wizardpen-calibrate /dev/input/wizardpen

При этом калибровка попросит ткнуть сначала в один угол планшета, потом в противоположный ему и выдаст подобные строки для xorg.conf:


Driver  "wizardpen"
Option  "Device"   "/dev/input/wizardpen"
Option  "TopX" "329"
Option  "TopY" "500"
Option  "BottomX" "11836"
Option  "BottomY" "8910"
Option  "MaxX" "11836"
Option  "MaxY" "8910"

Далее выяснилось что в openSUSE 11.2 файла xorg.conf уже нет, и всё работает автоматически и без него. Тем не менее, я создал xorg.conf при помощи Sax2 и вставил в него эти строки. После перезапуска исков, они стали падать при любой активности планшета.
Добрые люди подсказали что теперь всем заведует HAL, поэтому мучить нужно его. Я удалил ненужный более xorg.conf (если работает без него, значит пусть и работает дальше).
После этого открыл /etc/hal/fdi/policy/99-x11-wizardpen.fdi, переименовал ключ info.product из "TABLET DEVICE" в "Aiptek" (надо будет разобраться на досуге зачем) и изменил значения остальных ключей в соответствии с тем, что выдала калибровка. Получился такой файл:


<?xml version="1.0" encoding="ISO-8859-1" ?> 
<deviceinfo version="0.2"> 
<device> 
    <!-- "info.product" MUST match the name of your tablet: --> 
    <!-- grep -i name /proc/bus/input/devices               --> 
    <match key="info.product" contains="Aiptek"> 
    <merge key="input.x11_driver" type="string">wizardpen</merge> 
    <merge key="input.x11_options.SendCoreEvents" type="string">true</merge> 

    <!-- Modify these configurations accordingly --> 
    <!-- Use "man wizardpen" for the full-set of --> 
    <!-- configurable options                    --> 
    <merge key="input.x11_options.TopX" type="string">329</merge> 
    <merge key="input.x11_options.TopY" type="string">500</merge> 
    <merge key="input.x11_options.BottomX" type="string">11836</merge> 
    <merge key="input.x11_options.BottomY" type="string">8910</merge> 
    <merge key="input.x11_options.TopZ" type="string">75</merge> 
    <merge key="input.x11_options.debugyn" type="string">0</merge> 
    </match> 
</device> 
</deviceinfo>

В TopZ регулируется чувствительность к касанию, настраивается индивидуально.
Воткнул планшет и он заработал как надо! Правда GIMP думает что это Aiptek, но это не суть важно.

Крабозябры в IRC

2010-01-22T19:42:00.009+03:00

Меня уже несколько раз спрашивали, и уже надоело объяснять каждый раз заново. Поэтому ответ будет лежать тут, пока не понадобится мне в очередной раз.

Дано: люди, пишущие гигантской длины сообщения в IRC с кириллицей.
Проблема: люди видят крабозябры вместо обрезанного сообщения.

Как написано в RFC 1459 на 8й странице,
а также в RFC 2812 и
RFC 2813
на 6й странице:


IRC messages are always lines of characters terminated with a CR-LF
(Carriage Return - Line Feed) pair, and these messages SHALL NOT
exceed 512 characters in length, counting all characters including
the trailing CR-LF. Thus, there are 510 characters maximum allowed
for the command and its parameters. There is no provision for
continuation of message lines.

Это ограничение довольно быстро достигается в случае длинных сообщений, кроме того перед непосредственно сообщением идёт также служебная информация протокола, которая тоже занимает место в этих 510 байтах. Например, в случае отправки сообщения в канал это выглядит как:

PRIVMSG #имяканала :имя сообщения\r\n

по двоеточию сервер догадывается, с какого места идёт собственно сообщение. Все лишние байты сервер попросту обрежет. Более того, при передаче другому клиенту сообщение ещё более сократится, чтобы вместить служебную информацию (кто сказал) и все равно уместиться в 510 байт.

логин!идент@маска PRIVMSG #имяканала :имя сообщения\r\n

Бороться с нехваткой байт под длинное сообщение можно по-разному. Большинство клиентов либо обрезает сообщение перед отправкой до 512 байт, либо отправляет как есть и тогда его обрезает уже сервер. Некоторые (например, XChat и некоторые скрипты к mIRC) разбивают сообщение на несколько и отправляют их подряд.

Ситуация усугубляется тем, что в UTF-8 кодировке символы кириллицы представляются двумя байтами. Если разрезать сообщение посреди символа, то такая последовательность байт уже не будет правильной unicode-последовательностью и у многих клиентов возникают проблемы с корректным отображением такой строки. И если WeNet и Rusnet используют однобайтовые кодировки, то на Freenode используется именно UTF-8 и пользователи нередко начинают выяснять отношения.

Для иллюстрации вышесказанного я нашел свой старый эксперимент по написанию IRC-бота, перенастроил его на FreeNode и дописал следующий код на команду "sayit":


if(order == "sayit")
{
   // в этой строке 540 байт (UTF-8)
   const char bigline[] = "КрабозябраПридиКрабозябраПридиКрабозябраПриди"
"КрабозябраПридиКрабозябраПридиКрабозябраПридиКрабозябраПридиКрабозябраПриди"
"КрабозябраПридиКрабозябраПридиКрабозябраПридиКрабозябраПридиКрабозябраПриди"
"КрабозябраПридиКрабозябраПридиКрабозябраПридиКрабозябраПридиКрабозябраПриди";
   send_private_message(bigline, channel);
}

540 байт это явно больше 510. Моя реализация send_private_message не обрезает сообщения и посылает его как есть. Таким образом, в данном случае обрезание выполняется сервером, который рассылает это сообщение клиентам.

Для демонстрации я взял IRC-клиенты, находящиеся у меня под рукой: KVIrc (версии 3.4.3 и 4 из svn), XChat (версия 2.8.6), Konversation (версия 1.2). Интересно было бы проверить ещё на mIRC, но у меня его нет.

Заведя бота и клиентов на уединённый канал, я несколько раз дал боту комманду "sayit", затем попытался отправить очень длинные строки из каждого клиента и проанализировал результаты.

KVIrc

Этот используемый мной клиент - лучший выбор когда нужно читать. В нём корректно отобразились все строки, посланные всеми клиентами (с учётом укорачивания, конечно). К сожалению, отправляемые строки сам клиент режет по 512 байт, ничуть не заботясь о границах символов. Надеюсь, это кто-нибудь исправит, или хотя бы напишет скрипт.

XChat

Этот клиент успешно делить длинные сообщения на несколько, что делает выбором тех, кто пишет. Сообщения от бота он тем не менее пережил нормально, видимо обрезалось удачным для алгоритма образом. А вот длинные сообщения от KVIrc и konversation он показал крабозябрами.

konversation

Этот клиент корректно показал сообщения от kvirc, но показал крабозябры от бота. Сам он умеет делить сообщения на несколько, но это совершенно не спасает от проблемы обрезания сообщения сервером после добавления имени и маски.

Вывод

Дело с клиентами IRC обстоит как всегда печально. Повтор одного и того же длинного сообщения несколько раз заставляет клиенты то показывает его правильно, то неправильно. Это видимо зависит от того, как трактует их алгоритм преобразования байт в символы. Если вы хотите избежать выяснения у кого клиент хуже, и что вы пишете-таки в UTF-8 - пишите сообщения покороче.

Qt 4.6.1

2010-01-20T11:38:00.005+03:00

Тролли ударными темпами делают свою библиотеку. Казалось бы недавно только вышел 4.6.0, как уже готов bug-fix release (changelog). В основном эта версия чинит производительность (открытие файла наконец не вызывает stat) и лики. Также починили waitForConnected под Windows, что радует.
С нетерпением ждём следующих версий.

Сообщения об ошибках

2009-11-23T11:02:00.002+03:00


int main()
{
long long long int a;
}

Компилятор Microsoft:


error C2632: '__int64' followed by 'long' is illegal

Скучно и как-то казённо. Вот g++/mingw - другое дело:


error: ‘long long long’ is too long for GCC

Abstraction penalty

2009-10-15T12:33:00.007+04:00

В порыве философствования на тему «throw – это по сути то же goto» поймал себя на мысли о том, что думаю об исключениях как о дорогостоящей операции. А вдруг это premature optimization? Решил написать быстрый и простой сферический тест в вакууме.

void makeExceptions(int times)
{
   for (int i = 0; i < times; ++i)
   {
       try
       {
           throw std::exception();
           int a = 0;
           a++;
       }
       catch (std::exception&)
       {
       }
   }
}

_Winnie C++ Colorizer

Начав писать такую ерунду, я уже не мог остановиться и решил заодно проверить производительность конструкций BOOST_FOREACH и Q_FOREACH, от просмотра реализации которых мне хочется рвать волосы на заднице.
Начал я с простого for:

void makeForeachFor(int times)
{
   const int size = 10;
   int a[size];
   for (int i = 0; i < times; ++i)
   {
       for (int j = 0; j < size; ++j)
       {
           a[j] = 0;
       }
   }
}

_Winnie C++ Colorizer

И BOOST_FOREACH:

void makeForeachBoost(int times)
{
   const int size = 10;
   int a[size];
   for (int I = 0; I < times; ++i)
   {
       BOOST_FOREACH(int x, a)
       {
           x = 0;
       }
   }
}

_Winnie C++ Colorizer

Я специально помести его в innermost loop, чтобы сильнее проявили себя накладные расходы на создание и выход из цикла.
Сам массив я выбрал маленьким умышленно, чтобы он влез в любой кэш и не влиял на производительность.
Также есть свой foreach и в Qt. В отличие от BOOST_FOREACH, он не умеет работать с обычными массивами например и копирует контейнер перед использованием. Для Qt-контейнеров это не страшно, так как они все copy-on-write, но для обычных это просто недопустимо. Поэтому я также протестировал эти две реализации foreach на QVector.

void makeForeachBoostQt(int times)
{
   const int size = 10;
   QVector<int> a(size);
   for (int i = 0; i < times; ++i)
   {
       BOOST_FOREACH(int x, a)
       {
           x = 0;
       }
   }
}

void makeForeachQt(int times)
{
   const int size = 10;
   QVector<int> a(size);
   for (int i = 0; i < times; ++i)
   {
       Q_FOREACH(int x, a)
       {
           x = 0;
       }
   }
}

_Winnie C++ Colorizer

Исходный код файла
Собирал я его под Windows при помощи MinGW и компилятора от 2005 студии:
gcc version 3.4.5 (mingw-vista special r3)
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.42 for 80x86
и под Linux:
gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux)

Результаты замеров (среднее время в миллисекундах). Использовался 64битный Linux и 32битная Windows XP, процессор - Intel Core2 6420:

Cборка	Exceptions	for	Boost	Boost(QVector)	Q_FOREACH
linux-64-O0	3.590	0.0350	0.4330	0.4590	0.1360
linux-64-O2	3.600	0	0	0.0400	0.5700
win32-cl	2.828	0.0312	0.6719	0.6656	0.5844
win32-cl-O2	2.812	0	0.0125	0.0141	0.0734
win32-mingw-O0	0.843	0.0532	0.5672	0.6656	0.1937
win32-mingw-O2	0.844	0.0109	0.0125	0.0266	0.0546

Да, всё как и ожидалось. 3микросекунды на исключение это конечно немало, но если обрабатывать ими действительно ошибочные ситуации, а не строить на них логику программы (файла нет? Исключение! Пользователь нажал "отмена"? Исключение!), то вобщем-то не так уж и много. Хотя goto быстрее, да.
С другой стороны оказалось что оптимизаторы довольно агрессивно оптимизируют реализации foreach. Конечно, их ни в коем случае нельзя использовать в innermost loop, а для более высокого уровня вложенности они действительно упростят код (и усложнять хождение по шагам в отладчике).
Конечно полученные цифры не являются какой либо истиной в какой либо истанции, это всего лишь сферический тест в вакууме. Однако я для себя выводы сделал - и то и то можно без опаски применять, когда пишется например GUI или другой не библиотечный и не критичный ко времени выполнения код (98% кода). Что и требовалось доказать.

Чистое мыло

2009-09-23T17:50:00.004+04:00

Видя в интернете изображения мыла с подписью "GMail", думал что это такая шутка.
Оказалось, Google действительно раздаёт такие мыльца на своих конференциях.
Теперь и я обладатель такого:

Тестирование с помощью CxxTest

2009-08-29T22:02:00.007+04:00

Я вообще не отношу себя к адептам Test Driven Development, но считаю тесты довольно важной и удобной штукой. Правда дальше самопальных тестов к отдельным функциям и классам, выполняемых по #ifdef-у или в отдельном консольном проект дело не шло. Но ведь надо пользоваться чем-нибудь общепринятым, да и вообще уделять тестам больше внимания. Подумав так, решил встроить-таки хотя бы несколько тестов в свой дипломный проект.
В прошлый раз, когда я пытался приучить себя к тестам, меня отпугнула замороченость CppUnit (клона jUnit для C++), поэтому в этот раз я начал с обзора других средств для тестирования кода на C++.
Вообще я немного поковырял googletest, UnitTest++, и даже Boost Test Library, но речь сейчас не о них.
В конце концов, я искал простое и функциональное решение, безо всяких дурацких регистраций тестов и прочей ненужной синтаксической ерунды.
В конце концов я выбрал CxxTest.

CxxTest

Основные преимущества:

Не требует RTTI и шаблонов.
Не требует механизма исключений для работы (но может их отлавливать при необходимости).
Не зависит и не требует никаких внешних библиотек.
Не требует вручную регистрировать тесты (вот оно!).
Распространяется как набор заголовочных файлов и исходного кода (ну ещё препроцессор отдельно), не требуется сборка никаких библиотек.

Итак, как же с ним работать.

Тесты организуются в наборы (suite). Каждый набор представляется классом, наследуемым от CxxTest::TestSuite. Тестами в наборе считаются все функции, имя которых начинается с "test" (в любом регистре, напимер test1, Test_Function).
Если нужно делать инициализацию/деиницилизацию уровня набора, то в нём объявляются статические функции createSuite и destroySuite.
Созданный заголовочный файл отдаётся генератору на Perl (cxxtestgen.pl) или Python (cxxtestgen.py), который генерирует исходный файл с точкой входа. В этот файл включается созданный заголовочный файл с тестами

cxxtestgen.py --error-printer -o runner.cpp MyTestSuite.h

Этот исходный файл потом собирается как угодно в приложение, которое и является тестом.
Для тестов есть много разнообразных макросов с говорящими названиями: TS_ASSERT, TS_ASSERT_EQUALS, TS_ASSERT_DELTA или даже TS_ASSERT_THROWS_ANYTHING.

Итак, заголовочный файл может выглядеть примерно таким образом:

include <cxxtest h>

class MyTestSuite : public CxxTest::TestSuite
{
public:
 void testAddition( void )
 {
     TS_ASSERT( 1 + 1 > 1 );
     TS_ASSERT_EQUALS( 1 + 1, 2 );
 }

 void testMultiplication( void )
 {
     TS_ASSERT_EQUALS( 2 * 2, 5 );
 }
};

Запустив этот "тест", можно увидеть:

# ./test
Running 2 tests.
test.h:15: Expected (2 * 2 == 5), found (4 != 5)
Failed 1 of 2 tests
Success rate: 50%

Кроме того, если передать генератору параметры --gui=Win32Gui или --gui=QtGui, то программа соберётся со страшным графическим интерфейсам из одного прогресс-бара. Мне подобное не нужно, но кому-то это может показаться удобно, например если тестов в файле много и они выполняются очень долго.

Интеграция с CMake

Так как я использую CMake в качестве системы сборки, то прикручивать тесты буду именно к ней.
В CMake нашелся модуль для "поиска" и использования CxxTest. Но модуль какой-то невнятный и неудобный — искать не умеет, исполняемые файлы создаёт только из получившегося после препроцессора исходного файла, то есть никаких других файлов ни прилинковать, никаких других исходников не добавить. Если тесты тянут по зависимостям функции из других файлов это недопустимо.
В итоге я немного переделал код, найденный в wiki сайта CxxTest и получил такой макрос:


SET(CXXTEST_EXECUTABLE ${PROJECT_SOURCE_DIR}/3rdparty/cxxtest/cxxtestgen.pl)

MACRO(unit_test NAME CXX_FILE FILES)
SET(PATH_FILES "")
# Мне это не нужно, но если файлы расположены в
# другом каталоге то может понадобиться
#FOREACH(part ${FILES})
#    SET(PATH_FILES "${CMAKE_CURRENT_SOURCE_DIR}/${part}" ${PATH_FILES})
#ENDFOREACH(part ${FILES})
SET(PATH_FILES ${FILES})

SET(CXX_FILE_REAL "${CMAKE_CURRENT_SOURCE_DIR}/${CXX_FILE}")
SET(CXXTEST_OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/${NAME}.cxx")
ADD_CUSTOM_COMMAND(
OUTPUT "${CMAKE_CURRENT_BINARY_DIR}/${NAME}.cxx"
COMMAND ${CXXTEST_EXECUTABLE} --error-printer -o "${CXXTEST_OUTPUT}" ${CXX_FILE_REAL}
DEPENDS "${FILE}")
SET_SOURCE_FILES_PROPERTIES(${CXXTEST_OUTPUT} PROPERTIES GENERATED true)

ADD_EXECUTABLE("${NAME}" "${CXXTEST_OUTPUT}" ${PATH_FILES})
TARGET_LINK_LIBRARIES("${NAME}" ${CXXTEST_LINK_LIBS})
ADD_TEST("${NAME}" "${EXECUTABLE_OUTPUT_PATH}/${NAME}")
ENDMACRO(unit_test)

Таким макросом пользоваться удобнее. Во первых, можно задать несколько исходных файлов, не только один заголовок. Во-вторых, можно компоновать получающийся исполняемый файл любыми библиотеками, достаточно перед вызовом макроса задать переменную CXXTEST_LINK_LIBS.

Интеграция с CTest

Команда ADD_TEST в макросе добавляет тест для CTest.
Чтобы CTest вообще работал, перед применением его команд в CMake надо вызвать ENABLE_TESTING().
Ну и для каждого заголовочного файла с тестом вызывать созданный макрос unit_test.
После сборки проекта, можно запустить тесты несколькими способами.

make test — выполняет все тесты, выводит о них Passed или Failed. Это можно вставить в скрипты сборки и не вспоминать о них пока тесты не поломаются.
Непосредственный запуск CTest: ctest, более подробный ctest -v или даже ctest -vv.
Если CMake создаёт проект для Visual Studio, то создаётся отдельный проект для тестов, который можно запустить.

Всё хорошо, всё работает, осталось только приучить себя писать тесты...
Дополнительные материалы:

Руководство CMake

Руководство CTest

Руководство CxxTest

Пустые деструкторы и auto_ptr

2009-08-13T17:05:00.003+04:00

Думал некоторое время над довольно простой вещью.
Допустим, у нас есть некоторый класс, который объявлен заранее и используется каким-нибудь "умным" указателем:


class B; // forward declare

class A
{
public:
    A();
private:
    auto_ptr<B> b;
};

Такое описание мы включаем в header, в cpp соответственно включаем и header, где описан B. Всё правильно, для создания указателя компилятору не нужно видеть описание класса.
Проблема в том, что я не объявил у класса A деструктор. Так как "умные" указатели вызывают для указателя delete в своём деструкторе, нас ждёт проблема: при вызове delete компилятор должен видеть определение класса, чтобы вызвать ему деструктор или перегруженный оператор delete (если определения класса нет - получаем Undefined Behaviour, хотя например g++ показывает warning). Соответственно, если в одном из исходников, куда мы включаем свой header, включён файл с определением B, а в другой - нет, то мы прямо-таки нарываемся на нарушение ODR:

Если бы в классе A был объявлен деструктор, то инстанцирование деструктора auto_ptr<B> было бы произведено там, а там у нас есть определение B.
Если же деструктора у A нет, то создаётся деструктор по умолчанию, который вызывает деструктор auto_ptr<B>. Но создаётся он во всех файлах, куда включён header с A. Какую потом реализацию выберет компоновщик неизвестно.

Таким образом, опять приходим к прописным истинам:

Объявлять пустые деструкторы в такой ситуации однозначно нужно.
Или же не выпендриваться и включать все нужные заголовки, а потом пить чай пока проект собирается.
Пользоваться boost::scoped_ptr вместо std::auto_ptr, так как в boost проверяется, может ли компилятор удалить объект (и получаем ошибку компиляции в случае неудачи).

Кодировки и BOM

2009-08-12T13:37:00.001+04:00

Довольно забавно обстоит дело с обработкой компилятором от Microsoft строковых литералов в программах на C++. В случаях с символами, попадающими в первые 7 бит (ANSI) всё ясно - всегда всё нормально. Но с родной кириллицей всё веселее.
И редактор студии, и компилятор умеют определять используемую кодировку. Вот только редактор делает это лучше.
Пример: есть файлы в UTF-8 без BOM, созданные под GNU/Linux, с программой на Qt. g++ сохраняет кодировку в литералах и в памяти программы строка оказывается в кодировке UTF-8. И перевести её потом в QString можно при помощи fromUtf8.
Компилятор же от Microsoft не видя BOM считает, что кодировка файла соответствует локали и тоже оставляет строковые литералы как есть. Но, так он неверно определяет кодировку, вместо unicode-литералов (это те, которые L"текст") в памяти получается мусор.
Пример:


MessageBox(0, L"Привет", L"Мир", MB_OK);

Если же файл сохранить с BOM, то тогда компилятор догадывается что это UTF-8 и переводит обычные строки в локальную кодировку, зато и unicode-строки воспринимает правильно. И прощай один код для двух платформ, придётся пользоваться fromLocal8Bit под Windows и fromUtf8 под GNU/Linux.
Кроме того, g++ хоть и формально умеет работать с UTF-8, но к BOM относится враждебно, отказываясь компилировать, что опять же не позволяет использовать один исходник для обеих платформ.

Вывод: либо смириться и не использовать кириллицу в исходном коде, либо не использоваться Unicode-литералы и пользоваться QString::fromUft8 везде.

Примечание: Стандарт не разрешает использовать национальные символы даже в литералах, вместо этого надо указывать код символа (например '\320'), так что лучше кириллицу в исходниках не использовать вовсе. С другой стороны Qt предлагает удобные утилиты и классы для перевода. Другое дело что это почти всегда неудобно, особенно когда программа пишется только для русскоязычных пользователей и возиться с переводом того что можно сразу сделать на русском не хочется.

Методички для института

2009-08-06T17:45:00.000+04:00

В этом году я в добровольно-принудительном порядке написал две простеньких методички своему родному институту.
Оказалось что писать - дело нелёгкое, нудное. Оказывается, писать текст и код так, чтобы было понятно даже идиоту нелегко. Слишком многое всё равно остаётся за рамками рассмотрения. Ещё сложнее совместить простоту и функциональность - да, код ещё должен выполнять задание. В общем, писатель из меня никудышный.

Тем не менее, что-то всё же получилось и кому-нибудь может пригодиться.

Первая методичка - про реализацию COM посредством ATL в MSVS. Тут я даже сподобился на интуитивно-понятные видеоматериалы (тут всё очень мелко, но в архиве видео с нормальным разрешением):

Внутри архива - презентация, методичка, проекты к методичке и презентации, а также видео:
Скачать методичку по COM и ATL.7z

Вторая методичка - про автоматизацию MS Office через COM из всё той же MSVS. Тут меня уже на видео не хватило, но проекты и методичку в архиве вы найдёте:

Скачать методичку по MS Office из MSVS.7z

Про переводы строк

2009-08-06T15:34:00.001+04:00

Писал сегодня получение информации о системе в windows-части диплома. Была задача получить при помощи Windows API несколько значений и запихнуть их в QString-и, которые используются далее по коду.
Казалось бы, что сложного? Написал вот такой код:


// Определяем имя компьютера
char computerName[200]={0};
DWORD dummy = sizeof(computerName)/sizeof(char);
GetComputerNameA(computerName, &dummy);
computer = QString::fromLocal8Bit(computerName);
// Определяем текущий каталог
char currentDir[400]={0};
GetCurrentDirectoryA(sizeof(currentDir)/sizeof(char), currentDir);
curdir = QString::fromLocal8Bit(currentDir);

Всё хорошо, всё компилируется... и ничего не показывает. В соответствующих строках - пусто.

Перечитываю код - вроде всё верно, должно работать. Значит начинаем отладку.
Отладка, как обычно, начинается с полной пересборки проекта. Rebuild - это просто обязательное действие. Оно гарантирует что мы не будем искать ошибку в неправильном коде, который слинковался в результате ошибки компоновки с приращением
(incremental linking) или неправильно разрешенными зависимостями между файлами.

Конечно же пересборка проблему не устранила. Попытка пройтись по шагам в построчном отладчике тоже ничего не дала - проект собран в release, код перемешан и указатель прыгает как бешенный по каждому F10 (Step over).

Зато просмотр окна disassemble (Alt+8) выявил, что функции наши не вызываются вовсе. Как будто и нет этого кода...
И действительно, получившийся EXE не зависит от функций GetComputerNameA , GetCurrentDirectoryA и прочих.

Чтобы убедиться что в эту ветку кода вообще заходит управление, добавил перед вышеприведённым кодом
искусственный бряк:


__asm int 3;

Эта инструкция предназначена для останова в отладчике.

Проект успешно брякнулся, значит код в этой ветке исполняется. Тут моё подозрение пало на компоновщик, и я некоторое время изучал его опции. Всё было верно.

Круг подозреваемых всё более сужался. Было ясно, что что-то происходит при компиляции. Первая мысль была про неверную оптимизацию,
но я её сразу отбросил.
Подумав некоторое время, я стёр строку комментария "// Определяем имя компьютера".
На моё счастье я забыл описать переменную computer выше и получил ошибку.
Но чудо: ошибка указывала на строку с другим номером!

После этого стало всё ясно:

файл изначально писался под linux-ом и переводы строк были обычные для unix-систем (\n).
эту часть файла я дописывал под windows, вставив из другого файла (\r\n).
компилятор запутался в разных переводах строк и не посчитал за перевод строки символы после комментария. Таким образом, следующие строки считались продолжением однострочного комментария...

Проблема решилась в меню File->Advanced Save Options указанием Line Endings и сохранением файла.

Мораль:

переводы строк тоже имеют значение и могут запутать компилятор.
Умение пользоваться инструментарием вроде Dependency Walker или встроенного дисассемблера MSVS сильно ускоряет локализацию проблемы.

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