Объектно-ориентированное программирование на языке C++

Внимание!!!

FazaNaka — Tue, 08 Feb 2011 05:33:47 GMT

Сайт переезжает на новый движок, и другой сервер! В связи с этим активность сайта будет прекращена до 1 марта, так же будет остановлена рассылка статей ! После этого в меню появится пункт "вакансии" , мы производим набор журналистов и публикаторов, если Вы хотите участвовать в жизни портала и хотите заработать, зарегистрируйтесь и свяжитесь с Администрацией!
Общие вопросы можно задавать в этой теме !

Утечки памяти в программах на С/С++ — история нескольких багов

FazaNaka — Tue, 01 Feb 2011 11:49:53 GMT

Истории нескольких проблем, связанных с утечками памяти. Большинство таких проблем являются достаточно тривиальными, легко воспроизводятся, легко обнаруживаются соответствуюшим инструментарием, и исправляются. Но, временами, проблемы оказываются необычными, и требуют необычного подхода или решения…$CUT$

Кодопотерятор памяти

Очередное тестирование в QA выявило небольшую постоянную утечку памяти под нагрузкой в новой версии продукта. Воспроизведение не представляло проблемы, но первоначальный прогон программы под Valgrind не выявил утечек.

После некоторых раздумий была включена опция --leak-check=full и Valgrind начал отчитываться об утечках. Но среди ожидаемых утечек разного рода статических переменных, зачастую осознанно не освобождаемых, не находилось ничего, напоминающего утечку. Обычно при прогоне нескольких тысяч итераций несложно выделить аналогичное количество потерянных блоков памяти выделенных malloc-ом. В данном-же случае утечка на 10,000 запросов к серверу была минимальна.

После анализа стеков выделений памяти и отсева ожидаемых случаев, остался только один кандидат, который отвечал за несколько десятков потерянных блоков — количество, абсолютно не ассоциирующееся с 10,000 запросами. Но этому нашлось объяснение — выделения памяти происходили в классе строки STL, который активно использует memory pool для уменьшения количества выделений памяти. Поэтому вместо 10,000 потерянных блоков памяти Valgrind отчитывался о 40+. Стек вызовов выглядел примерно так:

==15882== 76,400 bytes in 8 blocks are definitely lost in loss record 2 of 3

==15882==      at 0x401B007: operator new(unsigned int) (vg_replace_malloc.c:214)

==15882==      by 0x40A40F0: std::__default_alloc_template
==15882==      by 0x40A3FFC: std::__default_alloc_template
==15882==      by 0x40A3B6B: std::__default_alloc_template
==15882==      by 0x40A9B67: std::string::_Rep::_S_create(unsigned int, 
std::allocator
==15882==      by 0x40A9C98: 
std::string::_Rep::_M_clone(std::allocator
==15882==      by 0x40A7A05: std::string::reserve(unsigned int) (in /usr/lib/libstdc++.so.5.0.3)

==15882==      by 0x8049826: std::basic_string
std::char_traits
std::allocator
==15882==      by 0x804956A: A::A(A const&) (class_a.cpp:20)

==15882==      by 0x80491BC: foo(int) (test.cpp:23)

==15882==      by 0x80492EA: main (test.cpp:32)

Вроде-бы источник утечки памяти был найден, но код выглядел абсолютно невинно — вызов функции с передачей ей временной копии объекта:

doSomething( condition ? Object( params ) : getObject() );

Мы были уже точно уверены, что память теряется в этой строке, и начали смотреть на код, генерируемый компилятором для данной строки. Вроде-бы все было на месте — вызов "basic_string::length()”, вызов конструктора класса параметра для одной ветви условия, вызов "Parent::getB()” и конструктора копирования для другой ветви, вызов собственно функции "A::create”, освобождения временных объектов — всё, кроме вызова деструктора временной копии класса — созданной на стеке, но содержащей внутри копию строки, которая и не освобождалась в результате!

110: return A::create(b1, b2, s.length() > 0 ? B(s) : getB());
 13d4: 83 ec 0c sub $0xc,%esp
 13d7: 8d 45 d8 lea 0xffffffd8(%ebp),%eax
 13da: 50 push %eax
 13db: e8 fc ff ff ff call std::basic_stringТак и не найдя вызов деструктора к коде, начали искать похожие проблемы, и практически сразу нашли "gcc 3.2 bug 9946 — object destructor not called, potentially causing a memory leak".



Проблема была в генерации кода для оператора "?:”, и решалась либо 
обновлением компилятора, либо косметическим изменением оператора "?:” на
 простой if().



// Есть функция, возвращающая константную ссылку на объект

const Object & getObject();



// Другая функция принимает объект по значению

void doSomething( Object obj );



// При вызове подобном нижеследующему, может произойти утечка памяти.

// Автоматически созданный на стеке экземпляр объекта может быть не освобожден,

// приводя к утечке памяти если экземпляр содержал динамически выделенную память.

doSomething( condition ? Object( params ) : getObject() );



Простая тестовая программа выводила следующее (обратите внимание на количество созданных и освобожденных экземпляров класса А):



main() start

A::A( 'on stack' )

B::B()

A::A( 'static instance' )

A::A( 'copy of static instance' )

B::boo()

B::~B()

A::~A( 'on stack' )

main() end

A::~A( 'static instance' )

Class A created 3 times and destroyed 2 times

Class B created 1 times and destroyed 1 times


Проблема происходила только при генерации 32-битного кода в gcc 3.2.3, и
 не происходила в 64 битном коде, или коде сгенерированном более 
поздними версиями компилятора.

Я — не я, и память не моя
Одно время я поддерживал и дорабатывал программу для сбора данных и 
передачи их на сервер. Эта программа работала на добром десятке 
платформ, в том числе на Linux. Так как программа была коммерческая, то 
компилировалась она компилятором, соответствующим минимальной 
поддерживаемой версии Linux, в нашем случае gcc 3.3.x, и предоставлялись
 исполняемые файлы.



В один прекрасный момент, в нашем отделе QA зарегистрировали и даже 
сумели воспроизвести (во время длительного, несколько дней, теста под 
большой нагрузкой) падение программы по причине нехватки памяти — 
процесс съедал 3GB памяти и благополучно падал, создавая core dump 
аналогичного объема. Причем взрывной рост использования памяти 
происходил буквально за 10-15 минут до печального конца, и в это время 
нагрузка процессора была порядка 12% (на сервере было 4 двух-ядерных 
процессора, так что один поток, крутящийся в цикле, как раз и должен 
использовать 12.5%).


Стек вызовов упавшего потока указывал на совершенно тривиальный код в 
конструкторе копирования, было только понятно, что это как-то связано с 
исключительными ситуациями.

(gdb) where
#0 0xffffe410 in __kernel_vsyscall ()
#1 0xb7dbd8d0 in raise () from /lib/libc.so.6
#2 0xb7dbeff3 in abort () from /lib/libc.so.6
#3 0xb7f86da5 in dlopen () from /usr/lib/libstdc++.so.5
#4 0xb7f86de2 in std::terminate () from /usr/lib/libstdc++.so.5
#5 0xb7f85e89 in __cxa_allocate_exception () from /usr/lib/libstdc++.so.5
#6 0xb78f7f07 in Uuid::Uuid () from .../lib32/libourlibrary.so
#7 0xb782409d in ...Попытки воспроизвести проблему с отладчиком памяти или отладочной 
версией исполняемых файлов не увенчались успехом — проблема исчезала. Да
 и само воспроизведение обходилось дорого — обычно требовалось 
тестировать процесс под нагрузкой в течение 2-4 суток, прежде чем 
возникала проблема воспроизводилась — а это задерживало тесты других 
компонент, требовавших эту-же инфраструктуру для тестов под нагрузкой.



Поиск похожих стеков вызовов не дал практически никаких результатов, и 
ситуация была тупиковая. Надо было как-то обнаружить причину утечки 
памяти без использования отладчика.



В одной реализации библиотеки выделения памяти для С++, с которой я 
сталкивался, каждый блок, выделяемый под новый экземпляр класса, в 
отладочной версии библиотеки помечался строкой, содержащей имя этого 
класса. Такой способ позволял легко определит по core dump-y, какие 
объекты того или иного типа были выделены. Я попробовал поискать строки,
 содержащиеся в core dump файле, запустив сначала программу «strings», а
 затем отсортировав с «sort».



Любопытно, но обнаружилось, что файл содержит 32,123,751 строк вида 
«++CCUNG0o» — только эти строки занимали около 275 MB в файле размером 3
 GB. При поиске этих строк в файле выяснилось, что каждая такая 
сигнатура начинала блок размером 96 байт (96b * 32,000,000 = 3Gb!!!)



Блоки начинались инвертированной строкой «++CCUNG0o» с нулем в начале 
(так как она инвертированная), и отличались только парой из четырех байт
 в разных местах, образуя, по-видимому, связанный список.



0x248b818: 0x00 0x2b 0x2b 0x43 0x43 0x55 0x4e 0x47 <<== строка «++CCUNG0o»

0x248b820: 0x30 0x6f 0xf8 0xb7 0x00 0x00 0x00 0x00

0x248b828: 0x6c 0xa8 0x78 0xb7 0x00 0x00 0x00 0x00

0x248b830: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

0x248b838: 0xa8 0x0e 0xd3 0xb7 0x3c 0xa2 0xfa 0xb7

0x248b840: 0xe8 0xae 0x82 0xb7 0x65 0x00 0x00 0x00

0x248b848: 0xc0 0x0e 0xd3 0xb7 0x38 0x9c 0xc8 0xb7

0x248b850: 0xf4 0x9b 0x04 0x08 0xe4 0x9c 0x04 0x08

0x248b858: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

0x248b860: 0x03 0x00 0x00 0x00 0xbe 0x80 0x79 0xb7

0x248b868: 0x58 0x80 0x79 0xb7 0x54 0xa9 0x78 0xb7

0x248b870: 0x98 0xb8 0x48 0x02 0x00 0x00 0x00 0x00



0x248b878: 0x00 0x2b 0x2b 0x43 0x43 0x55 0x4e 0x47 <<== строка «++CCUNG0o»

0x248b880: 0x30 0x6f 0xf8 0xb7 0x00 0x00 0x00 0x00

0x248b888: 0x6c 0xa8 0x78 0xb7 0x00 0x00 0x00 0x00

0x248b890: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

0x248b898: 0xa8 0x0e 0xd3 0xb7 0x3c 0xa2 0xfa 0xb7

0x248b8a0: 0xff 0xff 0xff 0xff 0x65 0x00 0x00 0x00

0x248b8a8: 0xc0 0x0e 0xd3 0xb7 0x38 0x9c 0xc8 0xb7

0x248b8b0: 0xf4 0x9b 0x04 0x08 0xe4 0x9c 0x04 0x08

0x248b8b8: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00

0x248b8c0: 0x03 0x00 0x00 0x00 0xbe 0x80 0x79 0xb7

0x248b8c8: 0x58 0x80 0x79 0xb7 0x54 0xa9 0x78 0xb7

0x248b8d0: 0xf8 0xb8 0x48 0x02 0x00 0x00 0x00 0x00



Поиск такой строки в Интернете поначалу не принес каких-либо полезных результатов, но потом обнаружилась одна ссылка на http://www.opensource.apple.com/ (к сожалению, уже не рабочая) со следующим фрагментом:

// This is the exception class we report -- "GNUCC++\0".
const _Unwind_Exception_Class __gxx_exception_class
= ((((((((_Unwind_Exception_Class) 'G'
 << 8 | (_Unwind_Exception_Class) 'N')
 << 8 | (_Unwind_Exception_Class) 'U')
 << 8 | (_Unwind_Exception_Class) 'C')
 << 8 | (_Unwind_Exception_Class) 'C')
 << 8 | (_Unwind_Exception_Class) '+')
 << 8 | (_Unwind_Exception_Class) '+')
 << 8 | (_Unwind_Exception_Class) '\0');Тогда я вернулся к стекам вызовов других потоков, и обнаружил очень 
подозрительный поток, явно работающий в цикле в момент падения — и этот 
цикл тоже занимается обработкой исключения:

(gdb) thread 20
[Switching to thread 20 (process 27635)]#0 0xb7e87921 in dl_iterate_phdr () from /lib/libc.so.6
(gdb) where
#0 0xb7e87921 in dl_iterate_phdr () from /lib/libc.so.6
#1 0x0804e837 in _Unwind_Find_FDE (pc=0xb782409c, bases=0xb70209b4) at ../../gcc/unwind-dw2-fde-glibc.c:283
#2 0x0804c950 in uw_frame_state_for (context=0xb7020960, fs=0xb7020860) at ../../gcc/unwind-dw2.c:903
#3 0x0804cfbf in _Unwind_RaiseException_Phase2 (exc=0xbfde3f38, context=0xb7020960) at ../../gcc/unwind.inc:43
#4 0x0804d397 in _Unwind_Resume (exc=0xbfde3f38) at ../../gcc/unwind.inc:220
#5 0xb78f82b0 in Uuid::Uuid () from /home/'work/lib32/libourlibrary.so
#6 0xb782409d in ...После этого мы начали смотреть внимательнее на исходный код, где 
вызывалось исключение, и предположили, что проблема лежит в операторе 
placement new, который использовался в данном участке кода. Простой тест
 подтвердил предположение — создание исключения в конструкторе объекта, 
вызванном из оператора placement new, приводил к бесконечному циклу и 
взрывной утечке памяти. Тест был простой — симуляция исключительной 
ситуации в проблемном участке кода, но к сожалению, совсем не простой в 
отрыве от контекста нашего приложения — небольшие тестовые программы 
проблему не воспроизводили. Так же оказалось, что данная проблема 
присутствует только в версии компилятора, которую мы использовали, то 
есть в gcc 3.4 проблема отсутствовала. На радостях, что конкретная 
проблема, уже обошедшаяся в копеечку, решена, дальнейшее расследование 
свернули.

Не совсем утечка
Однажды, после обновления программного продукта, предварительное 
тестирование у клиента обнаружило утечку памяти, не происходившую ранее.
 



Программа работала под Solaris, под нагрузкой, и использование памяти 
росло резкими скачками по 10-100 MB, при этом достаточно редко — 
временами раз в 2-3 дня, а временами 2-3 раза в день. Рано или поздно 
память, используемая процессом, вырастала до 2+ GB. При этом даже при 
снижении нагрузки до нуля, используемая память (значения RSS и VSS) 
никогда не уменьшалась.



Непосредственный доступ к серверам получить было нельзя (для настройки 
libumem, к примеру), а воспроизвести проблему в QA не получалось. Хорошо
 и то, что удалось получить обрезанный core dump файл — снимок памяти 
процесса. Но анализ core dump файла практически ничего не дал — стек 
вызовов показывал падение при выделении памяти из-за нехватки оной. При 
этом бОльшая часть памяти не использовалась — почти весь core dump файл 
был занят пустыми страницами по 4 KB, забитыми нулями.



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



При обновлении системы, одна из клиентских программ перестала посылать 
часть сообщений, предназначенных для мониторинга системы. По 
случайности, отсутствующие сообщения сигнализировали о закрытии 
транзакций, и они должны были чистить внутренние буферы. Соответственно,
 при повышении нагрузки, начинали накапливаться буферизованные 
сообщения, ждущие пары. По случайному совпадению, в данном случае 
сообщения были нетипично большими (десятки килобайт вместо сотен байт), и
 количество клиентских процессов было относительно велико (несколько 
десятков вместо обычных 2-5). Но на самом деле все эти параметры 
великолепно укладывались в ограничения, поддерживаемые системой (при 
условии нормального функционирования). И, хотя программа не ограничивала
 размер внутренних буферов, но она поддерживала механизм для очистки 
"потерянных” транзакций — все неполные сообщения старше 10 минут 
автоматически удалялись. И как раз этот счетчик всегда показывал 0 из-за
 ошибки — механизм был предназначен для практически невероятной 
исключительной ситуации, практически никогда не задействован, и 
недостаточно проверен. Сама очистка исправно работала, но была 
недостаточно эффективна из-за большой нагрузки на память, вызванной 
большим количеством клиентов и большим размером нестандартных сообщений.
 А диагностика проблемы оказалась сильно затруднена из-за неисправного 
счетчика в статистике.



Почему-же память не возвращалась при снижении нагрузки? Очень просто — 
стандартный диспетчер памяти процесса в Solaris только увеличивает 
адресное пространство процесса, и резервирует освобождаемую процессом 
память для повторного использования, оставляя страницы «занятыми» 
процессом с точки зрения стороннего наблюдателя.



В нашем случае, одиночные пики активности проблемных клиентов приводили к
 периодическим большим выделениям памяти, в большинстве случаев 
незаметных, так как не превышался предыдущий максимум. И только если 
последний максимум превышался, получалась очередная ступенька, которая 
уже никогда не уменьшалась. Через 10 минут после пика вся память 
освобождалась, но снаружи этого было не видно, только снимок памяти 
показывал, что большая часть памяти забита нулями и не используется.


Решение было простым даже до исправления проблемных клиентов и защиты от
 переполнения буферов — возраст "старых” транзакций был временно 
ограничен 30 секундами, и этого было вполне достаточно для своевременной
 вычистки буферов при данной нагрузке, с большим запасом. Но диагностика
 и поиск неисправности отняли немалое время, главным образом из-за 
некорректной статистики в логах.

Вместо эпилога
У кого были интересные случаи в практике — пишите!

Обертка для вызова функций по их адресу

FazaNaka — Wed, 26 Jan 2011 12:06:07 GMT

Доброго времени суток!
Было дело — делал я интерфейс для работы с модулями для USB от FTDI. Пришлось изрядно повозиться с подключением DLL-интерфейса. Разочаровавшись в возможностях автоматической линковки Microsoft Visual Studio 2008 (UPD: потом я разобрался с этой темой), я решил это делать вручную. По ходу дела ~~задолбался~~ очень надоело вручную подключать несколько десятков функций. И тогда я обратился к Google, C++ и шаблонам. И если подключение DLL в стиле C++ вопросов не вызвало, то$CUT$ удобный вызов подключенных функций в стиле «Error = FT_Open (Num, &_Handler)», где FT_Open- объект, удался не сразу. Итог (для таких вот функций) — под катом. Если вкратце — я сделал обертку вокруг указателя на функцию.

Постановка задачи

Сразу оговорюсь — я работаю в Windows XP Prof, Visual Studio. Это принципиально для получения адреса функции. Впрочем, при работе с указателями на функции это не важно.

Ну так вот, для тех, кто не в теме, вот последовательность для нахождения той самой функции FT_Open из FTD2XX.dll средствами WinAPI:

#include "FTD2XX.h" // библиотека от FTDI
typedef FT_STATUS (*pFT_Open) (int, FT_HANDLE *); // тип данных "функция FT_OPEN"

// ...

HMODULE hMod = LoadLibrary ("FTD2XX.dll"); // загрузка библиотеки - д. б. не ноль
pFT_Open pOpen = GetProcAddress (hMod, "FT_Open"); // получили адрес функции - также д. б. не ноль

// ...

FT_STATUS st = pOpen (0, &hDev); // вызываем функцию

// ...

FreeLibrary (hMod); // закрыли библиотеку

Это не беда, когда функция у вас одна, но в этой самой библиотеке я насчитал 51 функцию. И для каждой мне нужно сделать следующее:

typedef FT_STATUS (*pFT_Open) (int, FT_HANDLE *); // тип данных "указатель на функцию"
pFT_Open pOpen; // переменная "указатель на функцию"
pFT_Open pOpen = GetProcAddress (hMod, "FT_Open"); // получение адреса функции "FT_Open"

Особенно раздражает необходимость генерить кучу typedef. Да, я знаю, можно писать и без typedef, но это выглядеть будет ОМЕРЗИТЕЛЬНО!

Посему хочется как-то упростить себе жизнь:

Funct2Open = GetProcAddress (hMod, "FT_Open"); // получение адреса функции "FT_Open"

// ...

FT_STATUS st = Open (0, &hDev); // вызов функции

Решение

В ходе экспериментов и кипения мозгов я получил такой вот шаблон класса:

template typename Except = FunctPtrExceptionType, Except Value = FunctPtrExceptionDefValue>
class Funct2
{
public:
typedef Ret (*tfPtr) (Arg1, Arg2);
tfPtr fPtr;

public:
Funct2 (tfPtr Ptr = 0): fPtr (Ptr) {}

Funct2 &operator= (void *Ptr) { fPtr = reinterpret_cast Ret operator () (Arg1 A1, Arg2 A2) throw (Except) { if (!fPtr) throw Except (Value); return fPtr (A1, A2); }
}; // class Funct2

Думаю, тут все элементарно, но все-таки для непосвященных объясню.

Создается шаблон Funct2, которому первым параметром задается тип Ret, возвращаемый функцией. Следующими двумя параметрами — Arg1 и Arg2 — задаются типы аргументов функции. С целью универсиализации обработки ошибок задается тип исключения Except и его значение Value (параметры по умолчанию задаются #define FunctPtrExceptionType и #define FunctPtrExceptionDefValue).

В теле шаблона класса задается тип tfPtr «указатель на функцию с двумя параметрами» и сам указатель fPtr.

Конструктор по умолчанию задает нулевой указатель или конкретный адрес, если он задан. Также адрес может быть задан через перегруженный operator= (void *Ptr). Почему void * — потому что GetProcAddress () возвращает именно void *. Нет нужды перегружать его сигнатурой operator= (tfPtr Ptr) — компилятор и так понимает, о чем речь.

Ну и, наконец, перегружая operator (), мы добиваемся использования класса как функтора, а для пользователя класса — так и вообще простого вызова функции.

Удобно? Очень! Смотрите:

Результат

#include < Windows.h > // для GetProcAdress
#include < stdio.h > // для printf

// **
// ** Настройка исключений по умолчанию
// **

#define FunctPtrExceptionType int // тип данных для исключения по умолчанию
#define FunctPtrExceptionDefValue 0 // значение исключения по умолчанию

// **
// ** Указатель на функцию без аргументов
// **

template < typename Ret = void, typename Except = FunctPtrExceptionType, Except Value = FunctPtrExceptionDefValue >
class Funct0
{
public:
typedef Ret (*tfPtr) (void);
tfPtr fPtr;
public:
Funct0 (tfPtr Ptr = 0): fPtr (Ptr) {}
Funct0 &operator= (tfPtr Ptr) { fPtr = Ptr; return this; }
Ret operator () (void) throw (Except) { if (!fPtr) throw Except (Value); return fPtr (); }
};

// **
// ** Указатель на функцию с 1 аргументом
// **

template < typename Ret, typename Arg1, typename Except = FunctPtrExceptionType, Except Value = FunctPtrExceptionDefValue >
class Funct1
{
public:
typedef Ret (*tfPtr) (Arg1);
tfPtr fPtr;
public:
Funct1 (tfPtr Ptr = 0): fPtr (Ptr) {}
Funct1 &operator= (void *Ptr) { fPtr = reinterpret_cast Ret operator () (Arg1 A1) throw (Except) { if (!fPtr) throw Except (Value); return fPtr (A1); }
};

// **
// ** Указатель на функцию с 2 аргументами
// **

template < typename Ret, typename Arg1, typename Arg2, typename Except = FunctPtrExceptionType, Except Value = FunctPtrExceptionDefValue >
class Funct2
{
public:
typedef Ret (*tfPtr) (Arg1, Arg2);
tfPtr fPtr;
public:
Funct2 (tfPtr Ptr = 0): fPtr (Ptr) {}
Funct2 &operator= (void *Ptr) { fPtr = reinterpret_cast Ret operator () (Arg1 A1, Arg2 A2) throw (Except) { if (!fPtr) throw Except (Value); return fPtr (A1, A2); }
};

// **
// ** Примеры вызова функций
// **

int add (const int A, const int *B)
{ int C; C = A + *B; printf (" int add (const int %d, const int %d) = %d\n", A, *B, C); return C; }

void prn (void)
{ printf (" void prn (void)\n"); }

// **
// ** Точка входа
// **

void main (void)
{
int i, i2;
double d;
long l;
Funct0<> prner (prn);
Funct1< double, long *, int, 2 > longer;
Funct2< int, const int, const int * > adder;

adder = add;
longer = GetProcAddress (0, "Longer");

try
{
prner ();
i2 = 6;
i = adder (5, &i2);
d = longer (&l);
}
catch (int val)
{
switch (val)
{
case 2: printf (" *** не удалось определить адрес функции!\n"); break;
default: printf (" *** ошибка вызова функции!\n"); break;
}
}

Итог

Дизассемблер в режиме Release показал, что накладные расходы при вызове такой функции — проверка 0-го значение и в связи с этим еще один call. Я думаю, для современных PC это не беда.

Для совершенства тут можно как-то доработать тему исключений — было бы хорошо туда передавать текстовые строки, свои произвольные классы ошибок и т. п. Но лень я недостаточно хорошо знаю шаблоны, чтобы это реализовать.

Ну и, понятное дело, надо наклепать разных вариантов Funct для 3х, 4х и т. д. аргументов. Хорошо бы придумать какой-то макрос, который бы их генерил…

Ну и, еще более понятное дело, надо все это вынести в отдельный .H-файл.

Я надеюсь, кому-то сэкономил время. Буду благодарен за конструктивные комментарии!

P. S. По ходу эксплуатации вскрылась такая неприятная вещь, как соглашение о вызовах. Похоже, надо делать Funct0Stdcall, Funct0Cdecl; Funct1Stdcall, Funct1Cdecl…

Объективные недостатки С++

FazaNaka — Mon, 24 Jan 2011 11:16:04 GMT

Публикуется в рамках недели ненависти к С++ на хабре. Если вам все это еще не надоело, то добро пожаловать под кат.
Ранее уже были перечислены глупые причины для ненависти, поэтому я остановлюсь на реальных. Итак, за что же действительно стоит ненавидеть С++.
Причина первая, самая серьезная — грамматика. Язык С++ описывается контекстно зависимой грамматикой, следовательно алгоритм его разбора имеет высокую сложность. $CUT$Все это выливается в конечном счете в долгие билды и в отсутствие нормальных инструментов для анализа кода. Написать парсер С++ задача весьма нетривиальная, написать инкрементальный парсер, по всей видимости вообще невозможно, именно поэтому, нормальные инструменты для анализа и рефакторинга С++ отсутствуют, а при малейшем изменении в файле, компилятор делает так много лишней работы. Вот простой пример красоты синтаксиса С++:

// выбор типа на этапе компиляции
template...
Select

Красиво, правда? :)

Вторая причина, тоже очень неприятная — отсутствие модулей. С++ использует заголовочные файлы, так же как и Си, добро пожаловать в шестидесятые. Каждый заголовочный файл, анализируется столько раз, сколько раз он включается директивой include(upd: это не совсем верно, в комментариях меня поправили). В сочетании с первым пунктом, это выливается в неприлично долгие билды. Конечно, прекомпиляция заголовочных файлов решает эту проблему, но лишь от части. Во первых, настроить прекомпиляцию задача не простая, во вторых, она спасает от повторной обработки стандартных заголовочных файлов. Существуют еще и Ваши заголовочные файлы, которые нельзя прекомпилировать, так как они иногда меняются.

Третья причина — шаблоны. Механизм шаблонов — основное преимущество С++. В этом языке нет кортежей, нет вариантных типов, нет лямбда выражений(точнее не было), но все это можно реализовать с помощью шаблонов, что и было сделано. Шаблоны, это полный по Тьюрингу, функциональный язык программирования, который выполняет вычисления над типами во время компиляции. Правда круто? Но есть один нюанс — компиляторы С++ — не очень хороши в выполнении сложных шаблонных мата-программ. Если нормальный код на С++ компилируется просто долго, то код на С++, использующий boost::lambda, boost::spirit или boost::mpl, компилируется целую вечность. Обычно, время компиляции напрямую зависит от количества типов, с которыми приходится работать компилятору. Когда вы пишете

SomeType

компилятор инстанциирует шаблон, создает новый тип. Когда вы пишете —

boost::tuple

— компилятор инстанциирует как минимум 4 новых типа, так как тип myTyple — это мета-программа, которая рекурсивно вычисляет тип кортежа. Сколько шаблонов инстанциируется в следующем примере, мне страшно представить:

std::for_each(v.begin(), v.end(),
(
switch_statement(
_1,
case_statement<0>(std::cout << constant("zero")),
case_statement<1>(std::cout << constant("one")),
default_statement(cout << constant("other: ") << _1)
),
cout << constant("\n")
)
);

В недалеком будущем, благодаря проекту Clang, эта проблема может потерять актуальность.

Причина четвертая — сообщения об ошибках. Если вы пишете обычный код, то все замечательно, вы будете получать понятные сообщения об ошибках. Если вы используете STL и (особенно)Boost, то сможете наблюдать сообщения об ошибках на несколько экранов. Это не фича компилятора, это фича языка, недостаток дизайна. Пример — есть несколько перегрузок одной функции, которые используют идиому SFINAE, для более точного управления перегрузкой. Скажем, мы хотели добиться того, что-бы определенная перегрузка вызывалась тогда, когда у типа параметра есть определенный typedef или еще что-нибудь в этом роде. В случае, если компилятор не найдет нужную перегрузку, мы получим сообщение о том, что такой функции вообще нет. Все из-за того, что тогда, когда происходит substitution falure(которое is not an error), компилятор выбрасывает функцию из списка перегрузок.
Эту проблему хотели решить в C++ 0x с помощью концептов, но видимо не судьба. Поэтому, компилятор С++ всегда будет сообщать о том, что тип/функция отсутствует, вместо того, что-бы сообщить о том, что параметром шаблона может быть только определенный тип.

В принципе, все эти проблемы можно так или иначе обойти, настроить прекомпиляцию, купить хорошую IDE, не использовать библиотеки интенсивно использующие метапрограммирование на основе шаблонов и не писать такой код :)
В качестве примера того, как нужно писать на С++, можно привести webkit.

Многопоточный Observer на С++ (практика)

FazaNaka — Sun, 23 Jan 2011 06:35:25 GMT

Есть много вариаций на тему данного паттерна, но большинство примеров не подходит для многопоточных приложений.
В этой статье я хочу поделится опытом применения паттерна в многопоточных приложениях и опишу основные проблемы, с которыми мне приходилось сталкиваться.$CUT$

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

Если Вам необходимо готовое решение, обратите внимание на библиотеку Signals2, котрая включена в boost с мая 2009-го года.
Я не пытаюсь предоставить решение, которое можно было бы использовать в готовом виде. Но тем не менее, ознакомившись с материалом, можно обойтись без использования сторонних библиотек, в тех проектах, в которых они по каким-либо причинам не доступны или нежелательны (драйвера, низкоуровневые приложения и т.п.).

Предметная область

Действующие лица

NotificationSender — объект, рассылающий сообщения.
Как правило это рабочий поток, извещающий об изменении своего состояния, которое необходимо отобразить на пользовательском интерфейсе.
NotificationListener — объект, реализующий обработку уведомлений.
Как правило это объект, который управляет отображением части пользовательского интерфейса связанного с фоновой задачей.
Таких объектов может быть множество, при этом они могут подключаться/отключаться динамически (к примеру открытие далогового окна, где показываются детали выполнения задачи)
NotificationDispatcher — объект, управляющий подписчиками и рассылкой сообщений.

Взаимодействие между объектами

Рассылка сообщений всем подписчикам.
Процесс подписки/прекшащения подписки.
Время жизни объектов.
В данной статье описан метод синхронной рассылки сообщений. Это означает, что вызов функции SendMessage будет синхронным, и поток, вызывающий этот метод будет ожидать завершения обработки сообщений всеми подписчиками. В ряде случаев такой подход удобней ассинхронной рассылки, но при этом в нем есть трудности с прекращением подписки.

Простейшая реализация для однопоточной среды


 typedef unsigned __int64 SubscriberId;
class CSubscriber
{
public:
 virtual ~CSubscriber(){}
 virtual void MessageHandler(void* pContext) = 0;
 SubscriberId GetSubscriberId() {return (SubscriberId)this;}
};

class CDispatcher
{
private:
 typedef std::vectorpublic:
 SubscriberId Subscribe(CSubscriber* pNewSubscriber)
 {
 for(size_t i = 0; i < m_SubscriberList.size(); ++i)
 {
 if(m_SubscriberList[i]->GetSubscriberId() == pNewSubscriber->GetSubscriberId())
 {
 return 0;
 }
 }
 m_SubscriberList.push_back(pNewSubscriber);
 return pNewSubscriber->GetSubscriberId();
 }
 bool Unsubscribe(SubscriberId id)
 {
 for(size_t i = 0; i < m_SubscriberList.size(); ++i)
 {
 if(m_SubscriberList[i]->GetSubscriberId() == id)
 {
 m_SubscriberList.erase(m_SubscriberList.begin() + i);
 return true;
 }
 }
 return false;
 }
 void SendMessage(void* pContext)
 {
 for(size_t i = 0; i < m_SubscriberList.size(); ++i)
 {
 m_SubscriberList[i]->MessageHandler(pContext);
 }
 }
private:
 CSubscriberList m_SubscriberList;
};

Здесь уникальный идентификатор подписчика — адресс объекта подписчика, функция GetSubscriberId возвращает всегда одинаковое значение для одного объекта подписчика в не зависимости от преобразования типов.

Пример использования


 class CListener:
 public CSubscriber
{
 virtual void MessageHandler(void* pContext)
 {
 wprintf(L"%d\n", *((int*)pContext));
 }
};
int _tmain(int argc, _TCHAR* argv[])
{
 CDispatcher Dispatcher;
 CListener Listener1;
 CListener Listener2;
 Dispatcher.Subscribe(&Listener1);
 Dispatcher.Subscribe(&Listener2);
 for(int i = 0; i < 5; ++i)
 {
 Dispatcher.SendMessage(&i);
 }
 Dispatcher.Unsubscribe(Listener2.GetSubscriberId());
 Dispatcher.Unsubscribe(Listener1.GetSubscriberId());
 return 0;
}

Отключение подписчика внутри обработчика сообщений

В примере есть проблема, не связанная с многопоточностью. Эта проблема проявляется, когда мы пытаемся отписаться внутри обработчика MessageHandler. Данная проблемма будет решена копированием списка подписчиков перед вызовом MessageHandler.

Переходим к многопоточной среде

С одним потоком такой код будет работать довольно стабильно.
Давайте посмотрим что будет при работе нескольких потоков.


 CDispatcher g_Dispatcher;
DWORD WINAPI WorkingThread(PVOID pParam)
{
 for(int i = 0;;++i)
 {
 g_Dispatcher.SendMessage(&i);
 }
};
int _tmain(int argc, _TCHAR* argv[])
{
 ::CreateThread(NULL, 0, WorkingThread, NULL, 0, NULL);
 CListener Listener1;
 CListener Listener2;
 for(;;)
 {
 g_Dispatcher.Subscribe(&Listener1);
 g_Dispatcher.Subscribe(&Listener2);

 g_Dispatcher.Unsubscribe(Listener1.GetSubscriberId());
 g_Dispatcher.Unsubscribe(Listener2.GetSubscriberId());
 }
 return 0;
}

Рано или позно произойдет креш.
Проблема заключается в добавлении/удалении подписчиков и одновременной рассылке уведомлений (многопоточный доступ к CDispatcher::m_SubscriberList в нашем примере).
Здесь необходима синхронизация доступа к списку подписчиков.

Синхронизация доступа к списку подписчиков


 class CDispatcher
{
private:
 typedef std::vectorpublic:
 SubscriberId Subscribe(CSubscriber* pNewSubscriber)
 {
 CScopeLocker ScopeLocker(m_Lock);
 for(size_t i = 0; i < m_SubscriberList.size(); ++i)
 {
 if(m_SubscriberList[i]->GetSubscriberId() == pNewSubscriber->GetSubscriberId())
 {
 return 0;
 }
 }
 m_SubscriberList.push_back(pNewSubscriber);
 return pNewSubscriber->GetSubscriberId();
 }
 bool Unsubscribe(SubscriberId id)
 {
 CScopeLocker ScopeLocker(m_Lock);
 for(size_t i = 0; i < m_SubscriberList.size(); ++i)
 {
 if(m_SubscriberList[i]->GetSubscriberId() == id)
 {
 m_SubscriberList.erase(m_SubscriberList.begin() + i);
 return true;
 }
 }
 return false;
 }
 void SendMessage(void* pContext)
 {
 CScopeLocker ScopeLocker(m_Lock);
 for(size_t i = 0; i < m_SubscriberList.size(); ++i)
 {
 m_SubscriberList[i]->MessageHandler(pContext);
 }
 }
private:
 CSubscriberList m_SubscriberList;
 CLock m_Lock;
};

Синхронизация доступа была реализована при помощи объектов синхронизации (Critical section или Mutex).
Для большей переносимости и для того, чтобы не отвлекаться от сути происходящего, абстрагируемся от прямых вызовов платформенно-зависимых функций, типа EnterCriticalSection. Для этого служит класс CLock.
Для устойчивости к с++ исключениям удобно использовать технологию RAII, а именно класс CScopeLocker, который в конструкторе захватывает объект синхронизации, а в деструкторе освобождает его.
При такой реализации программа не будет падать, но нас поджидает еще одна неприятная ситуация.

Борьба с взаимной блокировкой потоков (deadlock)

Допустим у нас есть некий поток, выполняющий какую-то фоновую задачу и есть окно, где отображается ход выполнения этой задачи.
Как правило, поток посылает уведомление классу окна, который в свою очередь вызывает системную функцию SendMessage, которая инициирует какие-то действия в контексте оконной процедуры.
Системная функция SendMessage является блокирующей, она отсылает сообщение потоку окна и ждет пока тот его обработает.
Если подключение/отключение объекта-слушателя будет происходить также в контексте оконной процедуры (в потоке окна) возможна взаимная блокировка потоков, так называемый deadlock.
Такой deadlock может воспроизоводится крайне редко (в момент вызова Subscribe/Unsubscribe и одновременном вызове MessageHandler в отдельном потоке)
Следующий код эмулирует ситуацию с блокирующим вызовом системной ф-ции SendMessage.


 CDispatcher g_Dispatcher;
CLock g_Lock;
class CListener:
 public CSubscriber
{
 virtual void MessageHandler(void* pContext)
 {
 //Эмулируем блокирующий вызов SendMessage
 g_Lock.Lock();
 wprintf(L"%d\n", *((int*)pContext));
 g_Lock.Unlock();
 }
};
DWORD WINAPI WorkingThread(PVOID pParam)
{
 for(int i = 0;;++i)
 {
 g_Dispatcher.SendMessage(&i);
 }
};
int _tmain(int argc, _TCHAR* argv[])
{
 ::CreateThread(NULL, 0, WorkingThread, NULL, 0, NULL);
 CListener Listener1;
 CListener Listener2;
 for(;;)
 {
 //Эмулируем контекст оконной процедуры (обработчик оконного сообщения)
 g_Lock.Lock();
 g_Dispatcher.Subscribe(&Listener1);
 g_Dispatcher.Subscribe(&Listener2);
 g_Lock.Unlock();
 Sleep(0);
 g_Lock.Lock();
 g_Dispatcher.Unsubscribe(Listener1.GetSubscriberId());
 g_Dispatcher.Unsubscribe(Listener2.GetSubscriberId());
 g_Lock.Unlock();
 }
 return 0;
}

Проблема заключается в том, что главный поток захватывает глобальный объект синхронизации g_Lock (при аналогии с оконной процедурой — выполняется в контексте оконного потока), и затем вызывает метод Subscribe/Unsubscribe, который внутри пытается захватить второй объект синхронизации CDispatcher::m_Lock.
В этот момент рабочий поток посылает уведомление, захватив при этом CDispatcher::m_Lock в функции CDispatcher::SendMessage, и затем пытается захватить глобальный объект синхронизации g_Lock (при аналогии с оконом — вызывает системную функцию SendMessage).

Поток окна A -> B
Рабочий поток B -> A

Это можно назвать класическим deadlock-ом.
Проблема скрывается в функции CDispatcher::SendMessage().
Здесь должно соблюдаться правило — нельзя вызывать callback-функцию захватив при этом какой-либо объект синхронизации.
Итак, убираем блокировку при рассылке уведомлений.


 void SendMessage(void* pContext)
{
 CSubscriberList SubscriberList;
 {
 CScopeLocker ScopeLocker(m_Lock);
 SubscriberList = m_SubscriberList;
 }
 for(size_t i = 0; i < SubscriberList.size(); ++i)
 {
 SubscriberList[i]->MessageHandler(pContext);
 }
}

Контроль времени жизни подписчиков

После того, как мы убрали deadlock, появилась другая проблема — время жизни объектов-подписчиков.
У нас больше нет гарантии, что метод MessageHandler не будет вызван после вызова Unsubscribe, и по этому мы не можем удалять объект-подписчик непосредственно после вызова Unsubscribe.
В данной ситуации проще всего контролировать время жизни объектов-подписчиков с использованием счетчика ссылок.
Для этого можно исползовать технологию COM — унаследовать интерфейс CSubscriber от IUnknown и использовать ATL CComPtr для списка объектов-подписчиков, тоесть заменить std::vector Но такая реализация чревата дополнительными расходами на реализацию классов-подписчиков, так как в каждом из них должны быть реализованы методы AddRef/Release и ненужный QueryInterface, хотя если в проекте активно используется COM, то такой подход может иметь приемущество.
Для контроля времени жизни объектов-подписчиков с исползованием счетчика ссылок хорошо подойдут умные указатели.

Простая реализация для многопоточной среды


 typedef unsigned __int64 SubscriberId;
class CSubscriber
{
public:
 virtual ~CSubscriber(){}
 virtual void MessageHandler(void* pContext) = 0;
 SubscriberId GetSubscriberId() {return (SubscriberId)this;}
};
typedef boost::shared_ptr
class CDispatcher
{
private:
 typedef std::vectorpublic:
 SubscriberId Subscribe(CSubscriberPtr pNewSubscriber)
 {
 CScopeLocker ScopeLocker(m_Lock);
 for(size_t i = 0; i < m_SubscriberList.size(); ++i)
 {
 if(m_SubscriberList[i]->GetSubscriberId() == pNewSubscriber->GetSubscriberId())
 {
 return 0;
 }
 }
 m_SubscriberList.push_back(pNewSubscriber);
 return pNewSubscriber->GetSubscriberId();
 }
 bool Unsubscribe(SubscriberId id)
 {
 CSubscriberPtr toRelease;
 CScopeLocker ScopeLocker(m_Lock);
 for(size_t i = 0; i < m_SubscriberList.size(); ++i)
 {
 if(m_SubscriberList[i]->GetSubscriberId() == id)
 {
 toRelease = m_SubscriberList[i];
 m_SubscriberList.erase(m_SubscriberList.begin() + i);
 return true;
 }
 }
 return false;
 }
 void SendMessage(void* pContext)
 {
 CSubscriberList SubscriberList;
 {
 CScopeLocker ScopeLocker(m_Lock);
 SubscriberList = m_SubscriberList;
 }
 for(size_t i = 0; i < SubscriberList.size(); ++i)
 {
 SubscriberList[i]->MessageHandler(pContext);
 }
 }
private:
 CSubscriberList m_SubscriberList;
 CLock m_Lock;
};

В данной реализации я заменил «голый» указатель CSubscriber* на «умный» указатель со счетчиком ссылок, такой оказался в библиотеке boost.
Также в функцию Unsubscribe я добавил переменную toRelease для того, чтобы вызвать деструктор объекта-подписчика уже после вызова Unlock (нельзя вызывать callback-функцию, включая деструктор объекта подписчика, захватив при этом какой-либо объект синхронизации).
Cтоит обратить внимание на то, что в функции SendMessage происходит копирование списка умных указателей (после копирования все указатели увеличивают свои счетчики ссылок, а при выходе из функции уменьшают, что и контролирует время жизни объектов-подписчиков)

Тестируем


 CDispatcher g_Dispatcher;
CLock g_Lock;
class CListener:
 public CSubscriber
{
 virtual void MessageHandler(void* pContext)
 {
 //Эмулируем блокирующий вызов SendMessage
 g_Lock.Lock();
 wprintf(L"%d\n", *((int*)pContext));
 g_Lock.Unlock();
 }
};
DWORD WINAPI WorkingThread(PVOID pParam)
{
 for(int i = 0;;++i)
 {
 g_Dispatcher.SendMessage(&i);
 }
};
int _tmain(int argc, _TCHAR* argv[])
{
 ::CreateThread(NULL, 0, WorkingThread, NULL, 0, NULL);
 for(;;)
 {
 boost::shared_ptr boost::shared_ptr //Эмулируем контекст оконной процедуры (обработчик оконного сообщения)
 g_Lock.Lock();
 g_Dispatcher.Subscribe(pListener1);
 g_Dispatcher.Subscribe(pListener2);
 g_Lock.Unlock();
 Sleep(0);
 g_Lock.Lock();
 g_Dispatcher.Unsubscribe(pListener1->GetSubscriberId());
 g_Dispatcher.Unsubscribe(pListener2->GetSubscriberId());
 g_Lock.Unlock();
 }
 return 0;
}

Соптимизированная реализация для многопоточной среды

Как правило вызов функции SendMessage будет происходить намного чаще чем Subscribe/Unsubscribe. При большом количестве подписчиков узким местом может стать копирование списка подписчиков внутри SendMessage.
Копирование списка подписчиков можно перенести в функции Subscribe/Unsubscribe. Это будет похоже на методику из lock-free алгоритмов.
Объект CDispatcher будет хранить список подписчиков не на прямую, а при помощи умного указателя. Внутри функции SendMessage мы будем получать указатель на текущий список подписчиков и работать с ним. В функциях Subscribe/Unsubscribe мы будем каждый раз создавать новый список подписчиков и перенаправлять указатель внутри объекта CDispatcher на новый список подписчиков. Таким образом в то время, когда указатель на список подписчиков в объекте CDispatcher будет указывать уже на новый список подписчиков, ф-ция SendMessage по прежнему будет работать со старым списком. Так как старый список подписчиков никто не изменяет, то все будет работать стабильно в многопоточной среде.
В принципе, можно несколько модифицировать функции Subscribe/Unsubscribe и реализовать полностью lock-free алгоритм, но это уже другая тема.
Медот Unsubscribe является асинхронным и не гарантирует после своего завершения полное прекращение рассылки, половинное решение — подписчик получает уведомление о прекращении подписки при помощи ф-ции UnsubscribeHandler. Для реализации этого поведения добавлен промежуточный класс CSubscriberItem, который в своем деструкоторе вызывает ф-цию UnsubscribeHandler.


 namespace Observer
{
 //////////////////////////
 // Subscriber
 //////////////////////////
 typedef unsigned __int64 SubscriberId;
 class CSubscriber
 {
 public:
 virtual ~CSubscriber(){}
 virtual void MessageHandler(void* pContext) = 0;
 virtual void UnsubscribeHandler() = 0;
 SubscriberId GetSubscriberId() {return (SubscriberId)this;}
 };
 typedef boost::shared_ptr
 //////////////////////////////////////////////////////////////////////
 // Dispatcher
 ///////////////////////////////////
 class CDispatcher
 {
 private:
 class CSubscriberItem
 {
 public:
 CSubscriberItem(CSubscriberPtr pSubscriber)
 :m_pSubscriber(pSubscriber)
 {
 }
 ~CSubscriberItem()
 {
 m_pSubscriber->UnsubscribeHandler();
 };
 CSubscriberPtr Subscriber()const {return m_pSubscriber;}
 private:
 CSubscriberPtr m_pSubscriber;
 };
 typedef boost::shared_ptr typedef std::vector typedef boost::shared_ptr public:
 CDispatcher()
 {
 }
 private:
 CDispatcher(const CDispatcher&){}
 CDispatcher& operator=(const CDispatcher&){return *this;}
 public:
 SubscriberId Subscribe(CSubscriberPtr pNewSubscriber)
 {
 //Declaration of the next shared pointer before ScopeLocker
 //prevents release of subscribers from under lock
 CSubscriberListPtr pNewSubscriberList(new CSubscriberList());
 //Enter to locked section
 CScopeLocker ScopeLocker(m_Lock);
 if(m_pSubscriberList)
 {
 //Copy existing subscribers
 pNewSubscriberList->assign(m_pSubscriberList->begin(), m_pSubscriberList->end());
 }
 for(size_t i = 0; i < pNewSubscriberList->size(); ++i)
 {
 CSubscriberItemPtr pSubscriberItem = (*pNewSubscriberList)[i];
 if(pSubscriberItem->Subscriber()->GetSubscriberId() == pNewSubscriber->GetSubscriberId())
 {
 return 0;
 }
 }
 //Add new subscriber to new subscriber list
 pNewSubscriberList->push_back(CSubscriberItemPtr(new CSubscriberItem(pNewSubscriber)));
 //Exchange subscriber lists
 m_pSubscriberList = pNewSubscriberList;
 return pNewSubscriber->GetSubscriberId();
 }
 bool Unsubscribe(SubscriberId id)
 {
 //Declaration of the next shared pointers before ScopeLocker
 //prevents release of subscribers from under lock
 CSubscriberItemPtr pSubscriberItemToRelease;
 CSubscriberListPtr pNewSubscriberList;
 //Enter to locked section
 CScopeLocker ScopeLocker(m_Lock);
 if(!m_pSubscriberList)
 {
 //No subscribers
 return false;
 }
 pNewSubscriberList = CSubscriberListPtr(new CSubscriberList());
 for(size_t i = 0; i < m_pSubscriberList->size(); ++i)
 {
 CSubscriberItemPtr pSubscriberItem = (*m_pSubscriberList)[i];
 if(pSubscriberItem->Subscriber()->GetSubscriberId() == id)
 {
 pSubscriberItemToRelease = pSubscriberItem;
 }
 else
 {
 pNewSubscriberList->push_back(pSubscriberItem);
 }
 }
 //Exchange subscriber lists
 m_pSubscriberList = pNewSubscriberList;
 if(!pSubscriberItemToRelease.get())
 {
 return false;
 }
 return true;
 }
 void SendMessage(void* pContext)
 {
 CSubscriberListPtr pSubscriberList;
 {
 CScopeLocker ScopeLocker(m_Lock);
 if(!m_pSubscriberList)
 {
 //No subscribers
 return;
 }
 //Get shared pointer to an existing list of subscribers
 pSubscriberList = m_pSubscriberList;
 }
 //pSubscriberList pointer to copy of subscribers' list
 for(size_t i = 0; i < pSubscriberList->size(); ++i)
 {
 (*pSubscriberList)[i]->Subscriber()->MessageHandler(pContext);
 }
 }
 private:
 CSubscriberListPtr m_pSubscriberList;
 CLock m_Lock;
 };

}; //namespace Observer

Ссылки

Библиотека boost::signals2 статья
Умные указатели Джефф Элджер
Resource Acquisition Is Initialization (RAII) википедия
Комментарии к первой версии этой статьи можно найти здесь

Елена Сагалаева приняла участие в подкасте Радио Т

FazaNaka — Wed, 19 Jan 2011 16:28:05 GMT

На подкасте Радио Т номер 222 поговорили о языках программирования вообще и о C++ в частности.
Размышления на тему судьбы языка С++ стали особенно актуальны после недели ненависти к С++ на Хабрахабре.

Еще 5++ причин ненавидеть С++

FazaNaka — Wed, 19 Jan 2011 08:52:54 GMT

Признаюсь Вам — я ненавижу язык С++. Он просто выводит меня из себя.

Когда я встречаю эти три символа в заголовках статей на любимых ресурсах — еще терпимо, когда вижу в подопытном проекте файлы с расширением .cc и .cpp, .hh и .hpp (и еще .hxx и .cxx, у-ух, тысяча чертей!) — уже злюсь, а уж когда приходится читать, или, еще хуже, писать на нем — да я почти что истекаю ядом!$CUT$

Что ж, попробую заронить и в Вас искру священной ненависти.

0. С — это Вам не С с плюсами!

Ненавижу, когда код на чистом С, который сами Патриархи Керниган и Ритчи признали бы созвучным их Светлому Языку, кощунственно обзывают «С++» и бездумно заключают в файлы с одним из вышеуказанных нечестивых расширений, и, что самое страшное, и компилируют тоже как С++. Зачем?

1. С++ — это Вам не С с плюсами!

Это более чем весомая причина для ненависти. Многие авторы пособий, те самые отступники, кто продвигал язык в 90-е, утверждали, мол, что С++ — это «улучшенный» С, что можно, якобы, почти безболезненно перейти от С к С++!

Какой удивительный бред! Куда можно улучшить язык, который можно вручную транслировать в ассемблер и обратно (да, да, каюсь, ну приукрасил слегка)? Но им, похоже, удалось убедить в этом программирующие массы. В результате — не надо далеко ходить за примерами кода, который никоим образом не использует ни ООП, не нуждается в киллер-фичах С++, но от скудоумия ответственных лиц пишется на нем — а в сухом остатке мегатонны кода, которые замечательно бы смотрелись на суровом своей чистотой ANSI C.

Не стоит и говорить, что в таком же стиле любят воспитывать будущих программистов высшие учебные заведения. Форумы переполнены вопросами от нерадивых студентов, которые используют С++ для сугубо процедурного кода только из-за того, что в нем можно объявлять переменные в любом месте блока, а не в начале. Как это Вы собираетесь высекать свои мысли в граните кода, если не знаете на блок вперед, какие переменные Вам потребуются?

«Новые» возможности С++ разлагают неокрепшие умы юных программистов.
По тлетворному влиянию С++ может поспорить с Delphi/VB в 90-х и PHP в 2000-х.

Что же касается перехода — да, возможно, но отнюдь не безболезненно, тем более когда кажется, что остаешься чуть ли не в рам ках того же языка.

Лично я вижу три пути обучения программированию:
1) академический — от основ Computer Science — к функциональному, логическому и метапрограммированию;
2) инженерный — от аппаратных основ и Ассемблера к С и высокоуровневым языкам, параллельно изучаются мат. основы;
3) ремесленный (т.н. «быдлокодинг») — no comment;

Даже профессионал в силу мифологичности человеческого мышления обычно идет по списку снизу вверх, потрогав Бейсик/Паскаль/(Лого) в детстве, в отрочестве дойдя до понимания алгоритмов, работы с памятью, железом и средствами ОС, а в институте изучив, скажем, Лисп и Пролог, уже получает все средства, чтобы проникнуться, наконец, малым Дао на своем пути.

Но вот прожить весь путь с одним языком?

Главная проблема С++ в том, что этот язык напрасно замахивается на первую и третью область сразу, когда корни его растут из второй. Для первой области надо заново собрать международный комитет и полностью переделать язык с нуля (и здесь тоже могла бы висеть картинка с троллейбусом из батона), для третьей — небрежности не терпит, и кривая обучения будет крутовата. Причем, взобравшись на очередное плато, ученик не поймет, насколько он высоко залез, и бросится пробовать свои силы, думая, что это поможет ему взять очередную высоту, и т.д. до посинения и преждевременной смерти под кучей собственного кода.

2. Вы все еще знаете, что под капотом у Вашего компилятора С++? Тогда мы идем к Вам!

Язык С обязан был своей всемирной популярностью двум основным факторам:
1) идеологическая и синтаксическая целостность;
2) прямая связь с низкоуровневым программированием;

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

Шаблоны(!), позднее связывание, RTTI… Все это потребовало новый уровень абстракции, еще больше отдалило код «на бумаге» от кода «в железе». Да на счету одного только безобидного name mangling миллиарды сожженных нейронов и тонны сточенного о клавиатуру эпителия!

Отладка, реверсинг и ручная оптимизация «приплюснутого» кода требуют стойкости в истинной вере и прямых рук, но где, где их найти, когда юных «плюсовиков» развращают с малолетства?

В результате готовы «постигать» С++ люди, которые не знают, в какую сторону растет стек на их машине. В стародавние времена, когда правоверные программисты на С были в почете, мне рассказывали, таких казнили еще во младенчестве при помощи шнура от клавиатуры, а те, кто выжил, либо укреплялись в вере, либо с позором изгонялись к быдлокодерам, но и в изгнании сияли они отраженной искрой истинного света.

А С++-то быдлокодинга совсем не терпит, но как манит, манит его адептов!

3. Парадигма повержена? Да здравствует парадигма!

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

Но сама идея того, что можно из императивного языка сделать нестрогое подобие объектно-ориентированного, а затем сторонними библиотеками придать черты функционального, а потом использовать «это» как мультипарадигменный язык, порочна и б-гомерзка. А как реализуются эти нестройные расширения? Заглушки, и снаружи, и внутри. STL и его собратья хоть и придают языку (и среде) необходимую «мощь», но никак не целостность, и неотъемлемые теперь уже свойства языка реализованы и оформлены совершенно различными способами. Тогда уж можно и на голом С с препроцессором накрутить что угодно, что успешно и делается.

Кощунственно даже сравнивать С++ с метаязыками — его сила в гибкости, а не в изменчивости.

4. Синтаксис С++ убог

Все синтаксические изыски С++, по сравнению с С, меня лично всегда заставляли мучительно подозревать за ними наличие маниакального набора директив препроцессора. Хотя, времена, когда так и было (но очень недолго, когда код С++ перед компиляцей преобразовывался в С), безвозвратно прошли еще до распада СССР.

Посмотрим правде в глаза — то, как синтаксис С++ выражает его идеологию, сегодня вызывает ужас. Чтобы сделать код С++ читаемым, уже недостаточно прямых рук автора, нужна подсветка синтаксиса! А чтобы прочитать код, использующий STL или boost — буйство угловых скобок (про стандарт C++0x лучше умолчим), удвоенных двоеточий и преисполненных смысла слов — придется пожертвовать частью мозга, которая, при использовании более разборчивых в друзьях языков, могла бы заняться и более полезным делом.

Если бы С++ с самого начала родился бы без буквы С в своем названии, возможно, претензий к синтаксису ни у кого бы и не было.

5. Хотите ООП — так возьмите его живым!

А не довольствуйтесь метафизическим сношением с подобным Франкенштейном.

No, srsly. Вы вчера-сегодня выбрали С++, именно чтобы снимать сливки с использования ООП в своем проекте? ООП — это круто, Вы хотите найти идеальный баланс между проектированием, кодированием и (о, б-же!) сопровождением, начитались статей про модные в 90-х концепции? Передумайте, пока не поздно. На дворе не 95-й год, когда это еще прокатывало.

Есть, есть ниша, где С++ идеален и замены ему пока нет — это функционально богатые, монолитные проекты, требующие наивысшей производительности (и в которых ну совершенно нет места быдлокодингу).

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

Но С++ уже не место в мэйнстриме!

Есть, к примеру, замечательный язык Java, который обладает и ясным синтаксисом, и всеми необходимыми возможностями, да еще и транслируется в байткод удобоваримого формата. Есть не менее замечательный язык C#, который не отвечает за грехи своего предка, да и намного толерантнее, чем С++, к небрежному коду. А для промышленного языка это более чем критично.

С++ же обладает воистину удивительной особенностью — программист может обходиться процедурным по сути кодом, но он вынужден выбирать С++ вместо С или любого другого языка, только чтобы использовать элементы существующих industry-standard ООП-решений — например, обращаться через С++ — интерфейсы к стороннему коду и библиотекам.

За примерами далеко ходить не надо — в стеке технологий из Редмонда — DirectX и ATL/MFC. ~~Доколе?~~ Зачем? OpenGL и голое WinAPI отлично обходятся без плюсовых «наворотов» (Я умолчу об именах серьезных проектов, которые используют С, включая ядра всех популярных ОС и драйвера для них, популярные СУБД, полные тулчейны для множества языков, графические оболочки и даже, Вы не поверите, прикладное ПО!).

Нет, действительно достойные ООП-библиотеки и фреймворки существуют, взять тот же Qt, но в целом приятного мало — «ООП ради ООП» торжествует среди библиотек и превращается в «С++ ради С++» при выборе технологии для проекта, а хотелось бы думать, что мы — не те школьники, которых насильно обучили Delphi, потому что на нем окошки рисовать проще, или потому, что окошки можно рисовать только на нем.

Все эти годы, когда С++ доминировал на рынке, получается так, что он не выбирался низами, а насаждался верхами, и не всегда оправданно.

Вместо заключения

Я встречал мнение, что сила С++ — в сочетании его гибкости и нестрогого его соответствия канонам ООП, по сравнению с той же Java. Мол, не хотите — пишите вроде бы как бы и на С, а где надо — «раззудись плечо» и т.д.

Не могу полностью согласиться с таким аргументом при выборе языка — если действительно позволяет архитектура решения и действительно получилась гетерогенная система — так и пусть в каждом модуле будет использоваться наиболее подходящий язык и технологии, и будет поощряться хоть все что душе угодно, кроме размножения сущностей и ковровых бомбардировок велосипедами по воробьям!

То, что создатели С++ уже 20 с лишним лет пытаются отвечать желанию трудящихся усидеть на трех стульях сразу и накрыв одним языком всю предметную область, может быть поводом для уважения, но никак не должно влиять на выбор идеального инструмента для решения конкретной задачи.

Прошу не принимать данную заметку близко к сердцу, искать в ней личные оскорбления или требовать сатисфакции — отнюдь не это было моей целью.

Я всего лишь поделился с Вами тем, что тревожит меня при использовании данного языка и продуктов, так или иначе с ним связанных.

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

Язык Mt: C для высоконагруженных серверов

FazaNaka — Mon, 17 Jan 2011 08:44:53 GMT

Я хочу предложить к обсуждению идеи о том, как упростить написание серверных программ на C введением дополнительных языковых средств. Полагаю, что эта тема может быть интересна всем разработчикам, которым приходилось иметь дело с написанием многопоточного или асинхронного кода.

На данный момент я практически завершил написание инструментария — генератора парсеров, парсера C и частично C++, — который позволяет приступить к написанию транслятора, поддерживающего языковые расширения, о которых я здесь расскажу. Но перед тем, как продолжить работу, хотелось бы посоветоваться с коллегами по цеху и найти единомышленников.$CUT$

Речь пойдёт о многотопоточных асинхронных серверах. Асинхронных — то есть использующих логику обслуживания клиентов, основанную на событиях (epoll/kqueue), при которой одним потоком одновременно обслуживается множество клиентов. Многопоточных — значит готовых использовать преимущества современных многоядерных процессоров, выполняя параллельное обслуживание соединений несколькими потоками в рамках одного процесса.

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

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

Идеи довольно простые, поэтому, чтобы не создавать ощущения сложности, перечислю основные тезисы по дополнениям к C. Эти дополнения я буду называть «языком Mt».

Итак, Mt — это:

Автоматическое управление мьютексами для синхронизации доступа к объектам;
Асинхронные цепочки обработки, записываемые как обычные последовательные функции;
Аннотирование — дополнительное описания элементов программы для статического анализа исходных текстов;
Встроенный механизм подсчёта ссылок;
Заимствование наиболее полезных возможностей из C++;
Совместимость с C, жёсткая привязка к C ABI. Первоначальная реализация — транслятор из Mt в C.

Поясню, почему в качестве базы выбран C, а не C++. Основная причина — существенно более высокая сложность C++ с точки зрения семантического анализа исходных текстов. На протяжении последнего года я предпринял попытку написать парсер C++ и систему статического анализа C++-кода. Результат — парсер C и разбор семантики в стиле C дались довольно легко, а разбор C++ далёк от завершения: объём работы слишком велик. Поэтому я решил, что можно добиться хороших практических результатов, опираясь на чистый C и дополнив его теми возможностями C++, которые достаточно просты в реализации.

Далее расскажу о каждом дополнении подробнее. Некоторые примеры кода привожу на C++, потому что так их легче соотносить с эквивалентным кодом на Mt.

1. Автоматическое управление мьютексами

Рассмотрим распространённую схему обработки запросов. Пусть у нас есть некоторый объект класса MyFrontend, представляющий собой реализацию нашего сервера. После получения и декодирования запроса от клиента мы вызываем метод серверного объекта processRequest(). Этот метод выполняет некоторые операции, вызывающие изменение внутреннего состояния сервера. Положим для примера, что в результате обработки запроса увеличивается счётчик кол-ва запросов num_requests:

class MyFrontend
{
private:
Mutex state_mutex;
unsigned num_requests;

public:
void processRequest ()
{
state_mutex.lock ();
++ num_requests;
state_mutex.unlock ();
}
};

Mt освобождает нас от необходимости ручной синхронизации:

async object MyFrontend
{
private:
unsigned num_requests;

public:
async void processRequest ()
{
++ num_requests;
}
};

async object объявляет класс объектов, безопасных с точки зрения многопоточности. Такие объекты будем называть асинхронными. Приведённый пример кода на Mt транслируется в код, эквивалентный приведённому примеру на C++.

Теперь допустим, что для обработки запроса MyFrontend должен вызвать метод doSomething() объекта MyBackend, передав ему в качестве параметра счётчик обращений к бэкэнду num_back. Кроме того, мы не хотим задумываться о возможности взаимоблокировок и хотим, чтобы всё работало с нерекурсивными мьютексами. Для этого нам нужно освобождать state_mutex перед обращением к MyBackend:

class MyFrontend
{
private:
Mutex state_mutex;
unsigned num_requests;
unsigned num_back;
MyBackend *backend;

public:
void processRequest ()
{
state_mutex.lock ();
++ num_back;
unsigned tmp_num_back = tmp_num_back;
state_mutex.unlock ();

backend->doSomething (tmp_num_back);

state_mutex.lock ();
++ num_requests;
state_mutex.unlock ();
}
};

То же самое на Mt:

async object MyFrontend
{
private:
unsigned num_requests;
unsigned num_back;
MyBackend *backend;

public:
async void processRequest ()
{
call backend->doSomething (++ num_back);
++ num_requests;
}
};

Транслятор Mt самостоятельно вставляет операции со state_mutex и вводит временную переменную для передачи параметра. Оператор call введён для того, чтобы подчеркнуть, что на время вызова асинхронного метода другого объекта мы освобождаем блокировку state_mutex. Кроме того, это позволяет нам явно запретить вызов асинхронных методов в выражениях.

Помимо приведённых примеров автоматизируется ряд других случаев использования блокировок: ожидание событий (события обычно используются в паре с мьютексом, защищающим условие завершения ожидания), вызов асинхронного метода объекта из другого метода того же объекта.

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

2. Асинхронные цепочки обработки

На мой взгляд, это наиболее интересная и необычная идея. Объясню на примере, иллюстрирующем работу реального сервиса.

Допустим, наш сервер — это фронтэнд фотохостига. Мы хотим реализовать отдачу клиентам HTML-страниц с фотографиями пользователей. На странице отображается информация из анкеты владельца фотографии и сама фотография. Фотографии могут смотреть только друзья владельцев фото. Таким образом, для того, чтобы ответить на HTTP-запрос, нужно собрать нужную информацию, опросив ряд внутренних сервисов.

Алгоритм обработки запроса:

Отправить серверу проверки авторизации cookie пользователя, чтобы идентифицировать его (check_auth);
После проверки авторизации отправить серверу, обслуживающему социальный граф, запрос на проверку, являются ли пользователи друзьями (check_friends);
Отправить в хранилище анкетных данных запрос на владельца фотографии (get_userinfo);
После получения ответов от check_friends и get_userinfo сформировать HTML-страницу и отправить её клиенту.

Операция 2 может быть выполнена только после получения ответа на запрос 1. Запрос 3 не зависит от запросов 1 и 2 и мы хотим, чтобы он выполнялся параллельно с ними.

Сделаем набросок реализации на C. В этот пример можно не вчитываться. Его задача — показать, насколько громоздка ручная реализация даже такой несложной асинхронной цепочки обработки:

// Структура состояния асинхронной цепочки.
typedef struct {
// "Родительский" класс, управляющий счётчиком ссылок.
MReferenced parent_referenced;
// Блокировка на доступ к элементам состояния.
MMutex state_mutex;

uint64_t owner_id;
uint32_t photo_id;

// Если 'true', то прерываем цепочку.
bool cancel;

// Получили ответ от get_userinfo?
bool got_userinfo;
// Карма владельца фото (анкетные данные).
uint32_t owner_carma;

// Получили ответ от check_friends?
bool got_friends;
} HttpPhotoData;

static void http_photo_data_init (HttpPhotoData *data)
{
m_referenced_init ((MReferenced*) data);
m_mutex_init (&data->state_mutex);

data->cancel = false;
data->got_userinfo = false;
data->got_friends = false;
}

static void http_photo__get_userinfo_ret (uin32_t owner_carma,
void *_data);

static void http_photo__check_auth_ret (uint64_t client_id,
void *_data);

static void http_photo__end (HttpPhotoData *data);

// Точка входа в асинхронную цепочку.
void http_photo (char *cookie_str,
uint64_t owner_id,
uint32_t photo_id)
{
HttpPhotoData *data = m_malloc (sizeof (HttpPhotoData));
http_photo_data_init (data);

data->owner_id = owner_id;
data->photo_id = photo_id;

{
m_referenced_ref ((MReferenced*) data);

MCallbackDesc cb;
m_callback_desc_init_refdata (&cb, http_photod__get_userinfo_ret, data);

get_userinfo (&cb, owner_id);
}

{
m_referenced_ref ((MReferenced*) data);

MCallbackDesc cb;
m_callback_desc_init_refdata (&cb, http_photod__check_auth_ret, data);

check_auth (&cb, cookie_str);
}

m_referenced_unref ((MReferenced*) data);
}

// Ответ от get_userinfo.
static void http_photo__get_userinfo_ret (uint32_t owner_carma,
void *_data)
{
HttpPhotoData *data = (HttpPhotoData*) _data;

m_mutex_lock (&data->state_mutex);

if (data->cancel) {
m_mutex_unlock (&data->state_mutex);
return;
}

data->owner_carma = owner_carma;
data->got_userinfo = true;

if (data->got_friends) {
// Все данные для ответа собраны, отвечаем клиенту.
http_photo_end (data);
}

m_mutex_unlock (&data->state_mutex);
}

// Ответ от check_auth.
static void http_photo__check_auth_ret (uint64_t client_id,
void *_data)
{
HttpPhotoData *data = (HttpPhotoData*) _data;

m_referenced_ref ((MReferenced*) data);

MCallbackDesc cb;
m_callback_desc_init_refdata (&cb, http_photo__check_friends_ret, data);

check_friends (&cb, client_id, data->owner_id);
}

// Ответ от check_friends.
static void http_photo__check_friends_ret (bool friends,
void *_data)
{
HttpPhotoData *data = (HttpPhotoData*) _data;

m_mutex_lock (&data->state_mutex);
if (data->cancel) {
m_mutex_unlock (&data->state_mutex);
return;
}

data->got_friends = true;

if (!friends) {
// Отказано в доступе. Прерываем цепочку.
data->cancel = true;
m_mutex_unlock (&data->state_mutex);
return;
}

if (data->got_userinfo) {
// Все данные для ответа собраны, отвечаем клиенту.
http_photo_end (data);
}

m_mutex_unlock (data->state_mutex);
}

// Отправка ответа клиенту.
static void http_photo_end (HttpPhotoData *data)
{
photo_send_page (data->owner_id, data->photo_id, data->owner_carma);
}

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

Эквивалентная реализация на Mt:

async chain void http_photo (char *cookie_str,
uint64_t owner_id,
uint32_t photo_id)
{
async call GetUserinfoCall get_userinfo (owner_id);

async call check_auth (cookie);
gives uint64_t client_id;

async call check_friends (client_id, owner_id)
gives bool friends;

if (!friends) {
// Доступ запрещён
return;
}

GetUserinfoCall gives uint32_t owner_carma;

// Отправляем HTTP-ответ со страницей фото.
photo_send_page (owner_id, photo_id, owner_carma);
}

Обратите внимание, что мы практически полностью освободились от рутинной работы по организации нужного порядка исполнения. Кроме того, сгенерированный C-код можно будет использовать в многопоточных программах.

В приведённом примере использованы два новых оператора:

Оператор async call описывает асинхронный вызов. Функции, которые можно использовать с этим оператором, должны иметь особую сигнатуру: первый параметр — callback, который будет вызван по завершении вызова. Callback завершения должен обязательно быть вызван при любом исходе, будь то успешное выполнение вызова, внутренняя ошибка или таймаут.
Оператор gives задаёт точку, в которой нужно дождаться завершения указанного асинхронного вызова. gives вводит в область видимости список возвращаемых вызовом значений. Если операторы async call и gives должны быть разнесены, то в async call вызов именуется и в gives указывается имя вызова (см. GetUserinfoCall в приведённом примере).

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

Основная работа, которую выполняет Mt при трансляции асинхронных цепочек в C, заключается в следующем:

Определяет набор переменных, которые нужно хранить в структуре состояния цепочки (HttpPhotoData);
Дробит функцию на более мелкие. Точками разрыва являются операторы async call;
Обеспечивает нужный порядок выполнения, преобразуя операторы C, нарушенные операторами async call и gives, в эквивалентные асинхронные конструкции по фиксированным правилам.

Можно показать, что каждая из этих операций хорошо поддаётся автоматизации.

Параллельное выполнение сложных цепочек операций, непредставимых одной функцией в Mt, можно реализовать, использовав несколько разных асинхронных цепочек. То есть если ветвления в цепочке так сложны, что их не удаётся описать одной функцией, то можно построить описание как композицию нескольких функций.

С помощью Mt мы можем описывать циклы и условные переходы, разрываемые ожиданием ответов от асинхронных вызовов, в такой же простой и привычной форме, как при написании обычного кода. Допустим, мы хотим поискать значение в трёх независимых кэшах поочерёдно:

async chain void search (int key)
{
for (int i = 0; i < 3; i++) {
async call search_cache (key, i /* cache id */)
gives int value;

if (value > 0) {
printf ("VALUE: %d\n", value);
break;
}
}
}

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

3. Аннотирование

Аннотирование — это введение в код дополнительной вспомогательной информации с помощью аннотирующих слов. Аннотирующие слова могут стоять везде, где могут стоять квалификаторы const и volatile. Все аннотирующие слова начинаются с символа '$'. Примеры:

int * $nonnull ptr; // указатель не может быть равен NULL
MyObject * $heap myobj; // объект должен быть выделен с помощью аллокатора

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

4. Заимствование возможностей C++

С точки зрения реализации транслятора, наиболее сложной особенностью C++ по сравнению с C является зависимость семантического значения языковых конструкций от типов данных аргументов. Это касается, в первую очередь, правил перегрузки имён функций (включая перегрузку операторов) и правил выбора шаблонов с учётом частичных специализаций. Такая зависимость означает, что для того, чтобы определить, какая именно функция или шаблон используется в варыжении, нужно вывести типы данных всех аргументов функции или шаблона. Это, в свою очередь, требует полной и точной реализации правил приведения типов. Всё это составляет довольно значительный объём работы.

В то же время, перегрузка имён — спорное свойство языка. Например, от неё отказались создатели языка Go, о чём есть содержательная запись в FAQ.

В Mt не будет перегрузки имён функций и перегрузки операторов, множественного наследования, исключений, RTTI. Шаблоны без частичной специализации реализовать не так сложно, и этого достаточно для того, чтобы можно было создавать обобщённые контейнерные классы, поэтому шаблоны целесообразно включить в язык. В отсутствие перегрузки имён шаблоны станут гораздо более простым и лаконичным инструментом: таких возможностей для метапрограммирования, как в C++, не будет.

5. Ссылки и слабые ссылки

Отсутствие перегрузки операторов не даёт возможность реализовать в Mt удобные аналоги «умных указателей», таких как std::auto_ptr и boost::shared_ptr. Взамен на уровне языка предлагается механизм подсчёта ссылок:

int @a; // ссылка
int @@b; // слабая ссылка

В базовом варианте используется простой подсчёт ссылок. Счётчики ссылок встроены
в каждый синхронный или асинхронный объект Mt (object и async object). При таком подходе к управлению ссылками программисту следует избегать создания циклических ссылок, которые приводят к утечке памяти. Для разрыва циклов используются слабые ссылки. В перспективе можно предусмотреть возможность использования более сложного сборщика мусора, но сейчас я не вижу в этом необходимости.

В отсутствие перегрузки операторов нет необходимости поддерживать в Mt ссылки C++ (вида int &a).

Отмечу, что реализация ссылок на уровне языка позволяет получить более полный и удобный механизм, чем можно построить на шаблонах C++.

Заключение

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

Транслятор языка Mt — проект с открытым исходным кодом. В данный момент он существует в виде парсера подмножества языка C++ и живёт в svn-репозитории mync.svn.sourceforge.net/svnroot/mync/trunk под рабочим названием «scruffy».

Если у вас есть мысли и идеи по добавлению или изменению определённых свойств языков С/C++, то предлагаю их озвучить: возможно, пришло время для их практической проверки.

Приглашаю к участию в проекте. Если вы ищете тему для самостоятельной работы, которая могла бы дать новые знания и опыт, а в случае успеха превратиться в качественный и успешный продукт, то компилятор нового языка может стать отличным выбором. Если же проблемы, на которые нацелен Mt, для вас не очень актуальны, то, возможно, вас заинтересует разработка парсера C++ и системы статического анализа программ на C/C++.

Вместе мы сможем больше!

Благодарю за внимание.

Время выполнения операций в C++ под Linux

FazaNaka — Thu, 13 Jan 2011 17:08:24 GMT

Сегодня речь пойдёт об использовании clock_gettime в качестве секундомера для определения времени выполнения разных участков Вашего кода. Если Вы всё это уже знаете, или предпочитаете использовать gprof или другой профайлер, то смело можете пропускать данный топик, если же Вас это заинтересовало — добро пожаловать под хабракат.$CUT$

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

Однажды, во время написания очередного теста, понял что простого вывода времени этапа тестирования мне недостаточно и решил написать небольшой класс.
Начнём с теории.

clock_gettime. Кто это и с чем его едят

Данная функция описана в

int clock_gettime(clockid_t clock_id, struct timespec *tp);

Функция изменяет значения полей в структуре tp, на текущие показатели часов. Каких часов, спросят наиболее искушённые? Тех чей тип был указан в clock_id.
По давней традиции функция возвращает 0 если выполнена успешно, и -1 если что-то привело к неудаче(соответственно в errno записывается код ошбки).

Структура timespec состоит всего из 2х полей:

struct timespec
{
__time_t tv_sec; /* Seconds. */
long int tv_nsec; /* Nanoseconds. */
};

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

Из не разобранного остались лишь типы часов. Разберём и их. Описаны они в

#define CLOCK_REALTIME 0
#define CLOCK_MONOTONIC 1
#define CLOCK_PROCESS_CPUTIME_ID 2
#define CLOCK_THREAD_CPUTIME_ID 3
#define CLOCK_MONOTONIC_RAW 4
#define CLOCK_REALTIME_COARSE 5
#define CLOCK_MONOTONIC_COARSE 6

CLOCK_REALTIME — системные часы, со всеми их плюсами и
минусами. Могут быть переведены вперёд/назад, да и вставные секунды
иногда попадаются. Но иногда и их достаточно.
CLOCK_MONOTONIC — сродни системным часам, но, в
отличии от них, представляют собой постоянно увеличивающийся счётчик, в
связи с чем, естественно, не могут быть переведены. Обычно равно
аптайму системы.
CLOCK_PROCESS_CPUTIME_ID — возвращает время
затрачиваемое процессором относительно нашего приложения. В нашем
случае, используя эти часы мы получим время затраченое процессором на
работу с нашим приложением в независимости от других задач системы.
CLOCK_THREAD_CPUTIME_ID — похоже на CLOCK_PROCESS_CPUTIME_ID но более частный случай, так как следит за временем затрачиваемым на текущий поток.
CLOCK_MONOTONIC_RAW — то же что и CLOCK_MONOTONIC, но в отличии от первого не подвержен изменению через NTP.

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

Программная часть не несёт ничего гениального, а местами, и вовсе выглядит по индуски.

Класс GetWorkTime

Для начала описал будущий класс. Думаю назначение переменных и и функций-членов понятны из названий.

GetWorkTime.h

#include
class GetWorkTime
{
private:
bool isCounterStarted;
bool isCounterWorkComplete;

clockid_t clockID;
timespec startTime, endTime;

public:
GetWorkTime(clockid_t clockID = CLOCK_REALTIME);
virtual ~GetWorkTime(){};

void setClockID(clockid_t clockID);
void countingStart();
void countingEnd();

unsigned long long getWorkTimeInNanoseconds();
unsigned long long getWorkTimeInSeconds();
};

Реализация тоже не отличается гениальностью — всё ожидаемо.

GetWorkTime.cpp

#include "GetWorkTime.h"

#include #include
GetWorkTime::GetWorkTime(clockid_t clockID)
{
isCounterStarted = false;
isCounterWorkComplete = false;

setClockID(clockID);
}

void GetWorkTime::setClockID(clockid_t clockID)
{
switch (clockID)
{
#ifdef _POSIX_MONOTONIC_CLOCK
case CLOCK_MONOTONIC:
case CLOCK_MONOTONIC_RAW:
#endif
#ifdef _POSIX_CPUTIME
case CLOCK_PROCESS_CPUTIME_ID:
#endif
#ifdef _POSIX_THREAD_CPUTIME
case CLOCK_THREAD_CPUTIME_ID:
#endif
case CLOCK_REALTIME_COARSE:
case CLOCK_MONOTONIC_COARSE:
this->clockID = clockID;
break;

default:
this->clockID = CLOCK_REALTIME;
}
}

void GetWorkTime::countingStart()
{
if (!isCounterStarted)
{
isCounterStarted = true;
isCounterWorkComplete = false;

clock_gettime(clockID, &startTime);
}
else
perror("WARNING: Счётчик уже запущен\n");
}

void GetWorkTime::countingEnd()
{
if (isCounterStarted)
{
clock_gettime(clockID, &endTime);

isCounterStarted = false;
isCounterWorkComplete = true;
}
else
perror("WARNING: Невозможно остановить не запущен\n");
}

unsigned long long GetWorkTime::getRealNanosecondsCount(timespec time)
{
return (unsigned long long)time.tv_sec * 1000000000 + time.tv_nsec;
}

unsigned long long GetWorkTime::getCurrentTimeInNanoseconds()
{
clock_gettime(clockID, &currentTime);

return getRealNanosecondsCount(currentTime);
}

unsigned long GetWorkTime::getCurrentTimeInSeconds()
{
clock_gettime(clockID, &currentTime);

return (unsigned long)currentTime.tv_sec;
}

unsigned long long GetWorkTime::getWorkTimeInNanoseconds()
{
if (isCounterWorkComplete)
return getRealNanosecondsCount(endTime) - getRealNanosecondsCount(startTime);
else
perror("ERROR: Невозможно узнать время выполнения не запустив, а затем остановив, счётчик.\n");

return 0;
}

unsigned long GetWorkTime::getWorkTimeInSeconds()
{
if (isCounterWorkComplete)
return (unsigned long)endTime.tv_sec - startTime.tv_sec;
else
perror("ERROR: Невозможно узнать время выполнения не запустив, а затем остановив, счётчик.\n");

return 0;
}

Тесты

Для демонстрации работы написал небольшую обёртку вызывающую счётчик для разных задач и с разными часами.

Функция testTime последовательно пытается определить чистое нулевое время замера(интервал между началом отсчёта и окончанием без использования класса-обёртки), после чего замеряет тот же интервал, но уже с использованием класса.
Далее считается сколько времени займёт создание класса, ресурсоёмкая задача и sleep(0).

Результаты работы на моей машине приведены ниже.

CLOCK_REALTIME
Текущее время: 1294839189719051200нс, 1294839189с
clock_gettime(clockID, &startTime);clock_gettime(clockID, &endTime); выполнилось за: 439нс, 0с
counter.countingStart();counter.countingEnd(); выполнилось за: 465нс, 0с
Создание и удаление объекта GetWorkTime заняло: 71454нс, 0с
Выполнение for (int i = 0; i < 1000000000; i++) testDouble = testDouble / M_PI;: 7397920416нс, 8с
Выполнение sleep(0) заняло: 11040нс, 0с

CLOCK_MONOTONIC
Текущее время: 533621337167908нс, 533621с
clock_gettime(clockID, &startTime);clock_gettime(clockID, &endTime); выполнилось за: 450нс, 0с
counter.countingStart();counter.countingEnd(); выполнилось за: 465нс, 0с
Создание и удаление объекта GetWorkTime заняло: 1943нс, 0с
Выполнение for (int i = 0; i < 1000000000; i++) testDouble = testDouble / M_PI;: 6847570003нс, 7с
Выполнение sleep(0) заняло: 993нс, 0с

CLOCK_MONOTONIC_RAW
Текущее время: 533628051394051нс, 533628с
clock_gettime(clockID, &startTime);clock_gettime(clockID, &endTime); выполнилось за: 442нс, 0с
counter.countingStart();counter.countingEnd(); выполнилось за: 450нс, 0с
Создание и удаление объекта GetWorkTime заняло: 2043нс, 0с
Выполнение for (int i = 0; i < 1000000000; i++) testDouble = testDouble / M_PI;: 6810908498нс, 6с
Выполнение sleep(0) заняло: 979нс, 0с

CLOCK_PROCESS_CPUTIME_ID
Текущее время: 19781932013нс, 19с
clock_gettime(clockID, &startTime);clock_gettime(clockID, &endTime); выполнилось за: 667нс, 0с
counter.countingStart();counter.countingEnd(); выполнилось за: 693нс, 0с
Создание и удаление объекта GetWorkTime заняло: 2353нс, 0с
Выполнение for (int i = 0; i < 1000000000; i++) testDouble = testDouble / M_PI;: 6579920922нс, 7с
Выполнение sleep(0) заняло: 1292нс, 0с

CLOCK_THREAD_CPUTIME_ID
Текущее время: 26361905552нс, 26с
clock_gettime(clockID, &startTime);clock_gettime(clockID, &endTime); выполнилось за: 622нс, 0с
counter.countingStart();counter.countingEnd(); выполнилось за: 641нс, 0с
Создание и удаление объекта GetWorkTime заняло: 2281нс, 0с
Выполнение for (int i = 0; i < 1000000000; i++) testDouble = testDouble / M_PI;: 6587131651нс, 6с
Выполнение sleep(0) заняло: 1210нс, 0с

rdtsc()
startTime = rdtsc(); endTime = rdtsc();выполнилось за: 91 тактов
Создание и удаление объекта GetWorkTime заняло: 3353 тактов
Выполнение for (int i = 0; i < 1000000000; i++) testDouble = testDouble / M_PI;: 14028721707 тактов
Выполнение sleep(0) заняло: 1113 тактов

Ах да, чуть не забыл, добавьте Вашему gcc ключик -lrt для того что бы clock_gettime заработал.

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

О ненависти к С++

FazaNaka — Wed, 12 Jan 2011 09:44:48 GMT

С++ or not C++, C++ или Java/Python/Ruby? Как часто вы задаёте или слышите подобные вопросы? Не хотелось бы поднимать очередной холивар — по моему мнению, умные люди давно должны были бы прийти к выводу, что при выборе языка нет той серебряной пули, которая бы поставила окончательную точку, — у каждого языка есть свои плюсы и минусы и чаще всего проблемы в прокладке между клавиатурой и стулом.$CUT$

Я сам программирую на С++, поскольку решаемые задачи требуют достаточно хорошей скорости обработки данных. На одном из тематических блогов встретил эмоциональную статью в защиту С++. Там больше даже понравились комментарии, чем статья — в них собран весь тот букет аргументов против С++, который редко где можно встретить в одном месте. И главное, что автор пытается парировать выпады — прямо дуэль какая-то. Все что там написано может использоваться как евангелистам C++, так и его противникам языка.

Взял на себя смелость перевести статью и пару комментариев к ней.

Но прежде чем читать, посмотрите, пожалуйста, на прекрасную карту языка С++ (The C++ Lands). Особая благодарность за карту Алёне Сагалаевой:

Оригинал статьи «C++ Hating» (автор Dean Michael Berris)
Статья о закате С++ «A skeptic’s history of C++» (автор Chad Perrin)

У меня представился случай прочитать на сайте TechRepublic интересную. хорошо написанную, но совершенно неточную и провокационную статью. Эта писанина одна из тех, что пытаются предсказать смерть С++ и победу других, не столь мощных, языков. Я, как С++ разработчик, который любит этот язык со всеми его скелетами в чулане, могу заявить, что появление подобных статей — это плохой знак и признак невежественности технических блогеров.

Не буду вдаваться в детали — если вам интересно, то оригинал можно найти по ссылке. Разберу только отрывок, на который не могу не отреагировать.

Можно считать, что дни С++ сочтены. Альтернатива, которая наиболее подходит для решения схожих задач — это Objective-C. Другой вариант — Objective Caml, язык который регулярно приводится в качестве примера для высоко-производительных задач и по некоторым показателям часто опережает С++. На нем можно писать кратко и структурировано, предоставляет разработчикам более понятные и интересные модели, которые порой отсутствуют в языках того же уровня. Язык D также можно назвать конкурентом, хотя его проприетарные корни могут помешать его широкому применению. В языке Go от Google много спорных компромиссов, но без сомнения его возможности дают большое преимущество при создании некоторого типа программного обеспечения, включая параллелизм.

Однако, исходя из уроков истории, С++ будет еще долгое время занимать свою нишу. Он годами использовался при разработке операционок. Без спору, С++ дает некоторые преимущества перед С для некоторых видов систем, в которых критична производительность и уже существуют наработки. Но сила подобных наработок лежит в сопровождении их разработчиками, которые игнорируют альтернативы, и эта та особенность, которую не легко можно обойти потенциальным конкурентам.
потенциальными конкурентами.

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

Давайте посмотрим, что он на самом деле говорится в статье и попробуем прочитать между строк.

Можно считать, что дни С++ сочтены. Альтернатива, которая наиболее подходит для решения схожих задач — это Objective-C.

К сожалению, автор не указал какие задачи имеются в виду. Он привёл пример браузеров. Так-что давайте познакомимся с этим поближе.

Cказано, что существует множество альтернатив С++ для разработки браузеров, высокопроизводительных программ, настольных приложения и высоконагруженных серверных систем. Давайте, перечислим несколько успешных продуктов на рынке, которые написаны на C++ и объясним для чего был выбран именно С++.

Google Chrome — кроссплатформенный браузер, первый по скорости и производительности. Если вы захотите заменить язык программирования, на котором он написан, то придется использовать тот язык, который портируется на многие платформы. Я говорю не только о Mac OSX, Windows или Linux — также имею в виду Android (проверьте, Google TV — это Android с портированным Chrome).
Adobe Creative Suite — системы, работающие с видео, аудио и графикой очень требовательны к производительности. Если вы захотите портировать продукты Adobe, то вам придется использовать язык, при помощи которого можно создавать программы использующие наименьшее количество ресурсов компьютера при выполнения простых задач создания/редактирования, и при этом оставляют достаточно ресурсов для выполнения других задач системы. Ох, и конечно же необходимо что-бы программа работала как на OS X, так и на Windows.
Microsoft Office — широко распространенная, расширяемая, встраиваемая и самая нашпигованная фичами система. При портировании Microsoft Office, нужно чтобы в результате не получился монстр и программа быстро реагировала на ваши действия. Вы должны быть уверены, что можно будет написать мощные расширения, которые смотрелись как одно целое с программой.
World of Warcraft — и здесь я рассматриваю не только десктопного клиента, который перерабатывает огромное количество событий, следует куче правил, отрисовывает графику и делает еще кучу всего связанного с игрой. Подумайте также о серверной части. Нужны ли еще какие-либо слова об этой прекрасной программе?

Я даю вам возможность самим назвать хотя бы один другой язык программирования, который позволяет написать программы подобные этим и предоставить тот же уровень функциональности, стабильности, расширяемости, портабельности. Прежде, чем вы назовёте С, хочу напомнить, что С — это подмножество С++, и в случае если подразумеваете чистый С, то удачи вам и пожелание не сойти с ума, в случае если не используете абстракции, которые предоставляет С++.

Другой вариант — Objective Caml, язык который регулярно приводится в качестве примера для высоко-производительных задач и по некоторым показателям часто опережает С++. На нем можно писать кратко и структурировано, предоставляет разработчикам более понятные и интересные модели, которые порой отсутствуют в языках того же уровня.

Вы действительно думаете, что C++ это только объектно-ориентированый язык и ничего более? Сила С++ не только в поддержке объктно-ориентированого программирования — фактом является то, что в С++ можно использовать много разных парадигм, которые делают язык достаточно мощным. Теперь о тестах. Каждый должен понимать, что микро-тесты предназначены для тестирования только одного из аспектов работы системы. Настоящие тесты — это те, что испытывают систему в реальных условиях.

Если говорить о высокопроизводительном коде, то здесь большую роль играет используемый компилятор, а не используемый язык высокого уровня. Это верно для всех компилируемых языков. Легко можно сказать, что один язык лучше другого, если инструменты первого лучше, чем у второго, но в реальности производительность продукта в большей степени зависит от нескольких вещей — железа, компиляторов и кода. Одна из основных причин низкой производительности некоторых программ — это плохой код. Например, когда выбирается алгоритм без учёта реальной ситуации, входных данных,… Если сравнивать пузырьковую сортировку в C++ и поразрядную сортировку в OCaml, то, возможно, программа на OCaml будет более быстрой.

Говоря об эстетике, то это дело вкуса. Поэма, написанная на французском, не будет для меня прекрасна, поскольку я не читаю/говорю/пишу на французском — и тут уже не важно насколько она прекрасна для другого человека. То же самое и для C++ — я видел (и надеюсь, что писал) прекрасный код на C++, но программист на Java или С будет, возможно, иного мнения, поскольку они не знают язык так же как я.

Большая часть вопросов об эффективности и профессиональности связана не только с техническими особенностями, но и теми знаниями и их обмен между разработчиками. Вы не можете сказать, что вы профессионал в C++, если это не подтвердят коллеги по цеху.

У некоторых может возникнуть мнение, что прочитанная книга о С++, даст вам право считать себя профессионалом, но также, как и в случае с другими языками, профессионализм и эффективность приходят только с опытом.

Язык D также может составить конкуренцию, хотя его проприетарность может помешать широкому применению. Язык Go от Google, содержит много спорных компромиссов, но без сомнения его конструкции дают большое преимущество при создании некоторого типа программного обеспечения, включая параллелизм.

Цитируя Джона Дворака (John Dvorak) — «ерунда все это».

Если считаете, что проприетарность может мешать широкому применению, то взгляните на Java, который стал новым Cobol’ом в мире бизнеса. Вспомните об ассемблере x86 — он тоже проприетарен. Существует много закрытых языков программирования, которые широко применяются, проприетарность не помеха: что реально имеет значение — это техническая сторона. Хакеры которые выбирают только те инструменты, которыми будут пользоваться. Если вы хотите продать мне мышеловку, то и она должна быть достаточно хороша, чтобы я решил потратить на неё деньги.

По поводу параллельности, то реальная проблема в том, что основная часть программистов не знает как писать эффективные параллельные программы. Вот где загвоздка. И не имеет значения, какой язык используется. Недостаток знания в предмете, машинных архитектурах, шаблонах разнообразного доступа к данным, в совокупности с ограничениями на ресурсы — вот, что делает параллельное программирование «сложным». Даже когда упоминается Erlang или Go, то все-равно не эффективно писать приложения, когда вы делаете это неправильно и не используете идиомы и шаблоны для параллельных программ.

Однако, исходя из уроков истории, С++ будет еще долгое время занимать свою нишу. Он годами использовался при разработке операционок. Без спору, С++ дает некоторые преимущества перед С для некоторых видов систем, в которых критична производительность и уже существуют наработки. Но сила подобных наработок лежит в сопровождении их разработчиками, которые игнорируют альтернативы, и эта та особенность, которую не легко можно обойти потенциальным конкурентам.
потенциальными конкурентами.

B cнова — фигня все это.

Разработчики, использующие С++ каждый день, не живут в вакууме. Мы знаем о Ruby, Python, Haskell, Lisp, JavaScript, Java и даже такие новомодные языки как Erlang, Go, Lua и т. д. Причиной, по которым организации используют С++ для создания хороших С++ приложений, — является то, что С++ работает и позволяет делать вещи, которые могут делать и другие небольшие языки. Я буду первым, кто признает, что C++ не столь продуктивен, когда необходимо работать с задачами для которых предназначен Lisp, но чтобы вы знали, при использовании современных фич С++, таких как метапрограммирование на шаблонах, можно решать и эти задачи.

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

Заключение

Я смотрю на количество слов в статье — их около 2000. Этот вид ненависти к С++ разжигает меня и заставляет защищаться, но давайте я взгляну в будущее. Причина, по которой считаю С++ мощным инструментов — это не только та, что я потратил на его изучении и использовании много времени. Это далеко не правда, есть другая причина — я очень многого достиг, начав применять С++.

Я слышал много критики в адрес С++ от разных людей. CEO, HR менеджеров, разработчиков, бизнес партнёров и даже С++ программистов. Но причина, по которой С++ стандартизирован ISO, причина по которой процветает рынок приложений на этом языке — это его не ограниченность дизайном — так случилось, что язык был спроектирован с учетом лучших и случайно попавших плохих частей прошлых языков для представления многогранного инструмента для создания хороших приложений. Много что можно сделать с++, намного больше, что можно сделать на других языках.

Если и есть одна критика в сторону C++, то это его неправильное понимание. Если каждый потратит на его изучение столько же времени как на Ruby/Python/JavaScript, то я уверен, что это поменяет представление о языке. Существует много хороших книг о С++ — одна из них Programming: Principles and Practice using C++. Прежде, чем стучать на C++ снова, прочитайте эту книгу и расскажите о слабостях C++ — и будет нормальным, если вы поблагодарите меня потом.

Об авторе Dean Michael Berris:

Я программист по профессии, специализирующийся на разработке высокопроизводительных сетевых приложений на С++. Много читаю, пишу и дискутирую о том, что мне близко. Особенно интересуюсь разработками в параллельном программировании и высокопроизводительными системами, в особенности построенных на языке С++.

Пара критических комментариев к статье и ответы на них.

Программируя на С++ очень легко попасть в ловушки. На нем сложно программировать, поскольку многие вещи просто скрыты от разработчика компилятором (например, компилятор создает по умолчанию конструктор копирования, и если он не был явно создан, то это ведет к побайтовому копированию указателей и может привести в аварии в программе. Даже программа, которая большую часть времени работает нормально, может нести в себе ошибку неправильного использования удаленного указателя. Очень сложно программировать на С++, когда поджимают сроки и, особенно, когда в команде присутствуют новички.

У С++ намного меньше поддерживаемых библиотек, по сравнению например, в Java. Это означает, что каждый раз приходится реализовывать простые вещи, которые уже есть в других языках.

Очень большая платформозависимость. Нужно приложить много усилий для портирования с Unix на Windows и обратно.

С++ можно применять для академических проектов, в которых важна гибкость языка и есть достаточно времени, чтобы привести программу к идеальному виду.

Это все равно, что называть молоток хорошим, но опасным инструментом, когда вы не умеете им пользоваться.

Но посмотрите на С++ с той стороны, где он напрямую работает с железом. Ещё, вы говорите о «базовых вещах», но не каждый язык имеет четкое представление, что есть «базовая вещь». В С++ базовым является выделение памяти, средства работы с памятью (указатели), типы (классы, структуры, примитивные типы), объекты этих типов (объекты первого класса), управляющие структуры и функции, такие синтаксические конструкции как namespace’ы, модификаторы типов, и все те инструменты для создания модулей и библиотек.

Если вы не любите работать с низкоуровневыми инструментами, то учите STL, используйте Boost, изучайте Loki или ACE. Если вы не понимаете, что такое указатели, то не сможете применять даже С в реальных программах и ничего не добьётесь от С++.
Для С++ существует множество библиотек для разных вещей. Вы можете также использовать уже написанные С библиотеки.

Я не уверен, что вы используете C++ в рабочих проектах и обидно слушать от вас нападки тем, кто использует С++ уже продолжительное время. Но предполагаю, что коль вы считаете, что для С++ имеется меньше библиотек, чем для Java, то не удивлён вашим словам о том, что C++ «полезный инструмент для академических разработок».

Если вы сравниваете С++ c молотком, то существует по крайней мере 5 разных приспособлений и насадок к нему и непонятно какую из них выбрать. Выбрав неверный, вы отобьете себе руки. Да, если выберите правильный, то сможете работать быстрее, но какова вероятность выбора правильного молотка?

C++ был одним из моих инструментов более 10 лет. Я участвовал в больших проектах и некоторые из них все еще используются. Однако, было много проектов, которые останавливалиcь еще до своего завершения — выходили за рамки отпущенного времени и бюджета. После этого команда java программистов реализовывала ту же функциональность в течение 2 недель и без существенных багов. Даже производительность java версии была выше (с++ код не был оптимизирован).

Я видел опытных программистов делающих глупые ошибки, которые так легко совершить, но трудно найти в С++.

Портирование кода с unix на windows — это полный кошмар. Причудливые конструкции с шаблонами имеют большой шанс не быть скомпилированными на другой платформе.

Портирование с windows на unix тоже не сахар.

STL хороша и делает программирование проще и библиотека поддерживается всеми компиляторам. Она предоставляет много «базовых вещей», такие как контейнеры, необходимые нам для реализации бизнес логики. Но помимо хорошего дизайна и удобных штучек, ее сообщения об ошибках просто ужасны. STL может немного различаться на разных платформах, что может привести к проблемам при портировании.
Мы используем ACE/TAO фрейморк, но и с ним возникали проблемы на windows платформе, хотя заявляется, что библиотека платформонезависимая.

Мы тестируем, как Boost может использоваться в наших проектах.

Проблема заключается в том, что мы уже имеем 3 разный фреймворка (2 из них внутренние разработки), которые уже используются и не могут быть просто заменены другим без переписывания большого количества кода — нам это не позволяет бюджет. Написание 4го приведет еще к большей путанице (проблема cвязана не с++, а с непредсказуемой сложностью добавления фунциональности и растущем временем на рефакторинг кода)

Каждый язык имеет свои хорошие и плохие стороны. Очень важно выбрать правильный для проекта.

Хотя C++ предоставляет достаточную гибкость по сравнению с другими языками, но это не тот инструмент для задач, где нужна скорость разработки.

Извините, но инструмент, который вы описали не имеет ничего общего с молотком.
О том, что разработка на С++ более дорога, говорит больше о команде, чем о языке программирования, не правда ли? Я не уверен о каком тип программ вы говорите, но если речь идет о сетевом приложении (я это понял по использованию ACE/TAO), то не вижу где могут возникнуть проблемы. Зная ACE и профессионально используя его ранее, я уверен, что вы быстро реализуете требуемую функциональность, поскольку это уже готовый фреймворк.

Когда вы говорите о глупых ошибках, то на самом деле это зависит от человека пишущего код. Я написал клиента к memcache с нуля за 1 неделю, используя современный C++ стиль, и библиотека все еще используется в том месте, где я ее написал (подсказка: ищите по ключевому слову memcache++). Переписал сервер с нуля за два месяца, 1 месяц использовал для тестирования и улучшений, и это при том, что работал один — сервер может обрабатывать около 5k запросов в секунду (RPS), при этом используется не более 60% CPU и средняя нагрузка 2:1 для СPU. И мне трудно понять, почему многие испытывают сложно с++, когда мне удается делать подобные вещи.

Уверен, что не я один имею такой же положительный опыт.

Портирование на другую платформу — это только вопрос использования стандартных языковых конструкций. Это также подразумевает использование абстракций, которые скрывают от программиста платформозависимые вещи. Пишите библиотеки и при этом думайте о том как она будет поддерживаться.

Если говорить о сообщениях об ошибках, то это обязанность компилятора. Cогласен, GCC ужасен в этом плане. Но другие компиляторы могут выводить диагностику лучше, чем GCC — я имею в виду clang — он должен выстрелить в скором времени. MSVC 10 тоже может давать хорошие сообщения.

О вашем проекте я должен сказать, что вы должны нанять эксперта, который знает что делать в подобной ситуации. Наймите BoostPro и обучите вашу команду использовать современные С++ подходы, а не те, что были десятилетие назад.

Я знаю хорошие и плохие стороны C++, и они не имеют ничего общего с проблемами человека, который программирует на нем. Если вам нужна быстрая разработка, то вы должны улучшить ваши процессы и изучить используемые инструменты. Я искренне сомневаюсь, что существует язык программирования, который может помешать кому-либо быстро прототипировать.