Оказалось, что организовать вызов Perl-скриптов из C/C++ (MS Visual C++ 2010) достаточно просто:

1. Прописываем в Include Directories и Library Directories проекта путь к Perl\CORE:

   

2. Добавляем perl512.lib в Linker->Input->Additional Dependencies.

   

3. Ниже приведен пример кода, вызывающего perl из консольного приложения C++. Обращу внимание на два момента: a) #pragma warning (disable:4005) для подавления сообщения компилятора “‘ENOTSOCK’ : macro redefinition“; b) если опустить вызов PERL_SYS_INIT(0, NULL), то на шаге perl_parse получим Access Violation.

   #include "stdafx.h" //avoid warning C4005: 'ENOTSOCK' : macro redefinition #ifdef _MSC_VER #pragma warning ( disable : 4005 ) #endif #include PerlInterpreter *my_perl; int _tmain(int argc, _TCHAR* argv[]) { PERL_SYS_INIT(0, NULL); my_perl = perl_alloc(); perl_construct(my_perl); perl_parse(my_perl, NULL, argc, argv, NULL); perl_run(my_perl); perl_destruct(my_perl); perl_free(my_perl); return 0; }

===
Перепечатка материалов блога разрешается с обязательной ссылкой на blog.coolsoftware.ru

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

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

Подходящая структура для быстрого поиска в списке интервалов называется “Дерево Интервалов” (Interval Tree) или “Дерево Отрезков”. Хорошее описание (англ.), а также пример реализации я нашел тут: http://www.drdobbs.com/cpp/interval-trees/184401179.

Теория

Коротко описание структуры дерева отрезков и алгоритма поиска приведу на примере: пусть есть список именованных отрезков:

a=[75, 76], b=[75, 79], c=[75, 84],
d=[76, 80], e=[79, 80], f=[79, 83],
g=[79, 91], h=[80, 84], i=[80, 90],
j=[83, 84], k=[84, 85], l=[91, 92],
m=[91, 92]

Выпишем координаты вершин отрезков, отсортированные по-возрастанию:

X = {75, 76, 79, 80, 83, 84, 85, 90, 91, 92}

Массив X содержит 10 элементов: X[0], X[1], …, X[9].
Возьмем среднее значение (медиану): 83 = X[m], m = (9-0) div 2.

Возможны три варианта расположения отрезков относительно медианы:
1. отрезки, которые содержат медиану.
2. отрезки, которые лежат слева от медианы.
3. отрезки, которые лежат справа от медианы.

Создадим узел дерева, который будет включать в себя значение медианы (дискриминант = 83) и список всех отрезков, которые содержат медиану:

R = {83, [c, f, g, h, i, j]}

Оставшиеся отрезки слева от R: {a, b, d, e} и справа от R: {k, l, m}.

Построим левый узел дерева для отрезков {a, b, d, e}, находящихся левее медианы, рассматривая вершины слева от медианы: {75, 76, 79, 80}. Получим: O = {76, [a, b, d]}.
Аналогично правый узел для отрезков {k, l, m} и вершин {84, 85, 90, 91, 92}: U = {90, []}. Обратите внимание на возможность существования узлов, не содержащих отрезков.
Продолжая процесс рекурсивно, получим следующие узлы:
N = {75, []}, P = {79, [e]}, S = {84, [k]}, V = {91, [l, m]}, Q = {80, []}, T = {85, []}, W = {92, []}.

      R
   /     \
  O       U
 / \     / \
N   P   S   V
     \   \   \
      Q   T   W

     R
   /   \
  O     U
   \   / \
    P S   V

Алгоритм поиска выглядит следующим образом. Начинаем с вершины дерева. Сравниваем дискриминант текущего узла с искомым значением q. Если они равны (случай 1), то выводим все отрезки, на которые указывает текущий узел, и завершаем процесс. Если дискриминант текущего узла больше, чем q (случай 2), то перебираем все отрезки, на которые указывает текущий узел, и выводим такие, которые содержат q. Затем переходим к левому узлу. Если дискриминант текущего узла меньше, чем q (случай 3), то аналогично перебираем все отрезки текущего узла и выводим те, которые содержат q, а затем переходим к правому узлу.

В двух последних случаях (когда дискриминант узла не равен q) нужен перебор отрезков, на которые указывает узел. Этот перебор можно оптимизировать, если иметь два отсортированных массива отрезков: первый массив AL должен быть отсортирован по возрастанию левой (меньшей) координаты отрезка, а второй массив DH должен быть отсортирован по убыванию правой (большей) координаты отрезка. Для узла R из нашего примера:

AL = {c, f, g, h, i, j}
DH = {g, i, j, h, c, f}

Тогда, если дискриминант узла больше q (случай 2), то перебираем отрезки из массива AL до тех пор, пока левая координата отрезка  не будет больше q. Если дискриминант узла меньше q (случай 2), то перебираем отрезки из массива DH до тех пор, пока правая координата отрезка не будет меньше q.

Практика

Реализацию дерева интервалов можно взять на github: https://github.com/coolsoftware/ITree.
Класс itree в itree.h.

За основу я взял реализацию Yogi Dandass, в которую добавил некоторые недостающие (ommited) определения, исправил пару багов и существенно оптимизировал построение дерева (метод construct_tree).

Баг 1 в методе itree::construct_tree. Код ниже вызывал выход за границы массива.

std::sort(&(al[list_start]),
    &(al[list_start + list_size]), comp_for_al);
std::sort(&(dh[list_start]),
    &(dh[list_start + list_size]), comp_for_dh);

Он заменен на следующее:

std::sort(al.begin()+list_start,
  al.begin()+list_start+list_size,
  comp_for_al);
std::sort(dh.begin()+list_start,
  dh.begin()+list_start+list_size,
  comp_for_dh);

Баг 2 в методе query_iterator::init_node. Если value == cur_node->discrim, то требуется проверка, что cur_node->size != 0, а иначе возможен выход за границы массива.

void init_node(void)
{
    index = 0;        
    while (cur_node != NULL)
    {
        if (value < cur_node->discrim)
        {
            if ((cur_node->size != 0) &&
                ((*p_al)[cur_node->start]->low() <= value))
                return;
            else
                cur_node = cur_node->left;
        }
        else if (value > cur_node->discrim)
        {
            if ((cur_node->size != 0) &&
                ((*p_dh)[cur_node->start]->high() >= value))
                return;
            else
                cur_node = cur_node->right;
        }
        else //(value == cur_node->discrim)
        {
            if (cur_node->size == 0) //VIT 2014 bugfix!
            {
                cur_node = NULL;
            }
            return;
        }
    }
}

===
Перепечатка материалов блога разрешается с обязательной ссылкой на blog.coolsoftware.ru

Обновился LockLib на GitHub: https://github.com/coolsoftware/LockLib.

1. Классы VLock, VRWLock, VLockPtr, VReadLockPtr, VWriteLockPtr теперь “uncopyable”, то есть их нельзя скопировать (см. Листинг 1: Ошибка 1 и Ошибка 2). Запрет на копирование осуществляется путем наследования этих классов от VUncopyable. При компиляции кода, содержащего запрещенное копирование, будет выдано сообщение ошибке:

VLock.h(62): error C2248: ‘VUncopyable::VUncopyable’ : cannot access private member declared in class ‘VUncopyable’

2. Конструктор класса VRWLock объявлен с ключевым словом explicit для того, чтобы исключить неявное создание экземпляра этого класса при вызове функции (см. Листинг 1: Ошибка 3). При компиляции кода, содержащего такое неявное создание VRWLock, будет выдано сообщение об ошибке:

TestLock.cpp(184): error C2664: ‘RWFunc’ : cannot convert parameter 1 from ‘int’ to ‘const VRWLock &’
          Reason: cannot convert from ‘int’ to ‘const VRWLock’
          Constructor for class ‘VRWLock’ is declared ‘explicit’

Листинг. 1.

void RWFunc(const VRWLock&)
{
    //do something here
    //...
} 
    
VLock lock1;
VLock lock2 = lock1; //Ошибка 1
VRWLock rwlock1;
VRWLock rwlock2 = rwlock1; //Ошибка 2
RWFunc(1); //Ошибка 3

===
Перепечатка материалов блога разрешается с обязательной ссылкой на blog.coolsoftware.ru

LockLib это набор классов для организации доступа к разделяемым ресурсам в программе на C++ под Windows.
Исходники доступны на GitHub: https://github.com/coolsoftware/LockLib.

class VLock

Класс VLock используется как альтернатива CRITICAL_SECTION (на самом деле это “обертка” над CRITICAL_SECTION).

void Lock(int lPosition, volatile LONG * lpThreadLock = NULL)

Блокировка ресурса для монопольного использования. Если ресурс уже кем-то заблокирован, то происходит ожидание когда ресурс снова станет свободен и его удастся заблокировать.

Параметр lPosition служит для идентификации места вызова метода Lock и может использоваться при отладке.

Необязательный параметр lpThreadLock служит для подсчета вызовов метода Lock в текущем потоке. Подробности смотрите ниже в разделе посвященном lpThreadLock.

void Unlock(volatile LONG * lpThreadLock = NULL)

Снятие блокировки.

static void OutputDebugLocks()

При отладке и оптимизации приложений иногда нужно видеть список всех существующих блокировок и статистику по ним: сколько в данный момент активных блокировок, в каком месте они заблокированы. Посмотреть такую статистику можно вызвав OutputDebugLocks. Эта статистика доступна в Debug-версии приложении, когда объявлен _DEBUG, или когда объявлен макрос DEBUG_LOCK.

volatile LONG * lpThreadLock

Проблема с блокировками в много-поточном приложении связана с тем, что поток, который установил блокировку, может быть остановлен с помощью TerminateThread. В этом случае Unlock не будет вызван никогда и блокировка ресурса “повиснет”, а другие потоки, которые попытаются заблокировать этот ресурс, также “повиснут”.
Чтобы разрулить эту ситуацию, необходимо вести подсчет блокировок для каждого потока и вызывать Unlock после TerminateThread.

VLock lock;
 
unsigned int __stdcall LockThreadProc(void * lpParam)
{
    lock.Lock(1, reinterpret_cast(lpParam)); //lock resource
 
    //do something here
 
    lock.Unlock( reinterpret_cast(lpParam)); //unlock resource
 
    //contuinue working
 
    return 0;
}

class VRWLock

Класс VRWLock позволяет реализовать стратегию блокировки ресурса “один писатель - много читателей”.

VRWLock(LONG lMaxReaders = 65535, DWORD dwSpinCount = 1000, DWORD dwTimeout = 5)

Конструктор класса VRWLock имеет следующие параметры:

lMaxReaders - максимальное количество читателей, которые могут одновременно читать ресурс (не должно быть = 0!). Значение по-умолчанию 65535.

dwSpinCount - количество неудачных попыток блокировки ресурса (занятого), после которых происходит переключение контекста с небольшой задержкой, определяемой параметром dwTimeout (в миллисекундах).

void LockRead(int lPosition, volatile LONG * lpThreadLock = NULL)

Блокировка ресурса читателем. Если ресурс занят писателем или превышено максимальное количество читателей, то происходит ожидание освобождения ресурса, когда удастся его заблокировать. Смотрите описание параметров в описании метода Lock класса VLock.

void LockWrite(int lPosition, volatile LONG * lpThreadLock = NULL)

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

void ReLockWrite(int lPosition, volatile LONG * lpThreadLock = NULL)

Изменение статуса блокировки с читателя на писателя. Если ресурс не занят ни читателем ни писателем, то действие функции аналогично LockWrite (блокировка писателем). Если ресурс занят одним читателем, то происходит переключение его статуса с читателя на писателя. Если ресурс занят писателем или более чем одним читателем, то происходит ожидание момента, когда ресурс будет не занят писателями и занят не более чем одним читателем. Смотрите описание параметров в описании метода Lock класса VLock.

void Unlock(volatile LONG * lpThreadLock = NULL)

Снятие блокировки.

static void OutputDebugLocks()

Вывод статистики блокировок (см. выше описание одноименного метода для класса VLock).

class VLockPtr, class VReadLockPtr, class VWriteLockPtr

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

1. Нет необходимости делать явный вызов Unlock (а это часто, как показывает практика, забывают сделать).
2. В случае возбуждения исключения между вызовами Lock и Unlock ресурс может оказаться занят “навсегда”. А при использования RAII, деструктор класса-обертки, а следовательно и Unlock, будет вызван и в случае исключительной ситуации.

VLockPtr - RAII класс-обертка над VLock.

VReadLockPtr - RAII класс-обертка над VRWLock::LockRead.

VWriteLockPtr - RAII класс-обертка над VRWLock::LockWrite.

unsigned int __stdcall LockPtrThreadProc(void * lpParam)
{
    {
        VLockPtr lockptr(&lock, 1, reinterpret_cast(lpParam)); //lock resource
 
        //do something here
 
    } //unlock will be done here
 
    //contuinue working
 
    return 0;
}

===

Перепечатка материалов блога разрешается с обязательной ссылкой на blog.coolsoftware.ru

Вылезла сегодня с утра ошибка при компиляции любого проекта в  Visual Studio 2010:

LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt

Установка в свойствах проекта Linker->Enable Incremental Linking значения NO (/INCREMENTAL:NO) на помогла.

Полез смотреть, что же поменялось за последнее время. Оказалось вечером с авто-обновлениями винды поставился .NET Framework 4.5.1. Он то и нагадил!

1. Снес .NET Framework 4.5.1. Visual Studio перестал запускаться.
2. Установил .NET 4.0. Visual Studio починился, все проекты стали компилироваться нормально.
3. Слетел Mysql .Net Connector. Переустановил. Причем, Repair не помог, сделал сперва Remove, потом Install.

===
Перепечатка материалов блога разрешается с обязательной ссылкой на blog.coolsoftware.ru

Понадобилось мне поднять max_connections в MySQL, который по-умолчанию был установлен инсталлером в C:\Program Files\MySQL\MySQL Server 5.6.
В этом каталоге лежит my-default.ini, который я переименовал в my.ini и прописал в нем max_connections=250. Перезапустил сервис MySQL - не работает! select @@max_connections возвращает 100. Не видит MySQL моего my.ini.
Полчаса потратил на поиски откуда же MySQL читает настройки. Поэтому и решил написать это сообщение здесь - вдруг кому-нибудь поможет и сэкономит время.

Оказывается сервис запускается с параметром –defaults-file=”C:\ProgramData\MySQL\MySQL Server 5.6\my.ini”. Вот, значит, где находится my.ini.

===
Перепечатка материалов блога разрешается с обязательной ссылкой на blog.coolsoftware.ru

Выложил на github perl-скрипты, которые я использую для автоматического изменения номера билда в проектах на Visual C++, а также генерации файлов xxx-build.txt с информацией о версии и контрольной суммой (MD5). Взять можно тут: https://github.com/coolsoftware/PerlVCBuildScripts

Использовать просто:

1. Нужно создать файл с информацией о билде (build-файл) в каталоге Release (где будет создан exe или dll). Например, мой проект называется HTTPGet, имя исполняемого (генерируемого) файла HTTPGet.exe, значит имя build-файла должно быть HTTPGet-build.txt. Вот как выглядит структура каталогов проекта:

HTTPGet \
  HTTPGet.sln
  HTTPGet.aspr
  Release \
    HTTPGet-build.txt
    HTTPGet.exe

Содержимое build-файла должно быть таким:

1.0.0.0
http://127.0.0.1/HTTPGet.exe
HTTPGet.exe
b9f2c07999dcafe9fe544a00521829c1

Первая строка - версия приложения (будет автоматически обновляться при сборке).
Вторая строка - URL для скачки последней версии.
Третья строка - имя файла.
Четвертая строка - MD5-подпись (будет автоматически обновляться при сборке).

Я использую build-файлы в функции авто-обновления в приложениях. Реализацию этой функции я выложу как-нибудь позже.

2. Нужно прописать в Pre-Build Event->Command Line вызов:

perl $(ProjectDir)..\incbuild.pl $(ProjectDir) $(Configuration)

а в Post-Build Event->Command Line прописать:

perl $(ProjectDir)..\makebuildinfo.pl $(TargetPath)

Если вы используете ASProtect для упаковки/защиты приложения, то можно прописать путь к вашему ASPR-проекту, чтобы ASProtect был вызван автоматически при сборке:

perl $(ProjectDir)..\makebuildinfo.pl $(TargetPath) $(ProjectDir)..\$(TargetName).aspr

===
Перепечатка материалов блога разрешается с обязательной ссылкой на blog.coolsoftware.ru

1. Скачиваем boost с официального сайта http://www.boost.org/. Текущая версия на момент написания поста: 1.53.0.

2. Распаковываем архив на диск (я распаковал в c:\boost\boost_1_53_0).

3. Запускаем Visual Studio Command Prompt (2010).

4. Переходим в каталог boost и собираем bjam запустив bootstrap.bat.

5. Собираем boost командой: bjam toolset=msvc-10.0 variant=debug,release threading=multi link=static runtime-link=static

6. Пьем кофе… Ждем завершения…

===
Перепечатка материалов блога разрешается с обязательной ссылкой на blog.coolsoftware.ru

В C++ под Windows есть два способа обработки исключений - традиционный для C++ с пом. try/catch и т.н. структурная обработка исключений или SEH. Основная разница между ними в том, что с помощью try/catch можно реализовывать для разных типов исключений C++ различную реакцию (поведение), а структурная обработка  исключений способна отловить ситуации, которые с пом. catch не ловятся, например, Divide By Zero или Access Violation. SEH - это механизм, предоставляемый операционной системой и на самом деле try/catch реализуется также через него.

Одновременно в одной и той же процедуре использовать оба метода обработки исключений (try/catch и SEH) нельзя. Но можно использовать в одной процедуре try/cath, а в другой SEH.

Оба метода обработки исключений не идеальны и имеют свои достоинства и недостатки.

Основной недостаток try/catch заключается в том, что он не позволяет отловить и обработать все ошибки, а также не показывает место возникновения ошибки. Впрочем, в книжке Джеффри Рихтера (Windows для профессионалов. Создание эффективных Win32-пpилoжeний с учетом специфики 64-разрядной версии Windows) приводится способ перехвата структурных исключений:

1. Нужно создать класс CSE для идентификации структурного исключения:

#include <eh.h>
#include <stdexcept>
 
class CSE
{
public:
    static void MapSEToCE(){ _set_se_translator(TranslateSEToCE); }
    operator DWORD() { return (m_er.ExceptionCode);}
 
private:
    CSE(PEXCEPTION_POINTERS pep)
    {
        m_er = *pep->ExceptionRecord;
        m_context = *pep->ContextRecord;
        if (m_er.ExceptionCode == 0xe06d7363)
        {
            printf("C++ Exception: Code 0x%x, Address 0x%x\n", m_er.ExceptionCode, m_er.ExceptionAddress);
        }
        else
        {
            printf("SEH Exception: Code 0x%x, Address 0x%x\n", m_er.ExceptionCode, m_er.ExceptionAddress);
        }
    }
    static void _cdecl TranslateSEToCE(UINT deEC,PEXCEPTION_POINTERS pep)
    {
        throw CSE(pep);
    }
 
private:
    EXCEPTION_RECORD m_er;
    CONTEXT m_context;
};

2. Для каждого потока надо вызвать один раз CSE::MapSEToCE(), после чего можно обрабатывать структурные исключения как обычные исключения C++:

int DivideByZero()
{
    int x = 100;
    int y = 0;
    return x / y;
}
 
void ThrowException()
{
    throw std::out_of_range("out_of_range");
}
 
void TestCSE()
{
 
    CSE::MapSEToCE();
    try
    {
        //DivideByZero();
        ThrowException();
    }
    catch (CSE se)
    {
        switch(se)
        {
            case EXCEPTION_INT_DIVIDE_BY_ZERO:
                printf("Divide by zero!\n");
                break;
        }
    }
    catch (std::exception & e)
    {
        printf("std::exception: %s\n", e.what());
    }
}

3. Компилировать нужно с опцией /EHa. В противном случае _set_se_translator не сработает и исключения SEH с помощью catch (…) отлавливаться не будут, а компилятор (Visual Studio 2010) выдаст следующее предупреждение:
warning C4535: calling _set_se_translator() requires /EHa

SEH способен отлавливать все исключения и, что важно на мой взгляд, показывать место возникновения ошибки (ExceptionAddress), а также позволяет продолжить выполнение программы с прерванного места. Но, к сожалению, при возникновении исключения C++ в обработчике (фильтре) SEH документированными способами нельзя узнать тип исключения C++ и получить его текст ошибки. Ниже описан недокументированный способ.

Все исключения C++ в фильтре SEH имеют один и тот же код 0xe06d7363. При этом поле NumberParameters содержит 3 (для 32-разрядных приложений), ExceptionInformation[1] указывает на объект-исключение C++, а ExceptionInformation[2] указывает на структуру _ThrowInfo (ExceptionInformation[0] не интересно). _ThrowInfo относится к так называемым Predefined C++ Types. Для использования предопределенных типов не нужно подключать никаких .h файлов. При редактировании IDE Visual Studio подчеркивает их красным цветом и пишет: Error: identifier “_ThrowInfo” is undefined. Но при этом все успешно компилируется и выполняется :-)

Ниже приведен SEH-фильтр, который способен анализировать исключения C++ и выводить информацию об исключении (what()). Стоит отметить, однако, что хотя эта процедура успешно работает в Visual Studio 2010, но нет никаких гарантий, что в будущем Microsoft не поменяет структуру _ThrowInfo.

#include <eh.h>
#include <stdexcept>
 
LONG ExceptionFilter(PEXCEPTION_POINTERS pEP, const char * file, const char * function, int line)
{
    PEXCEPTION_RECORD pER = pEP->ExceptionRecord;
    if (pER->ExceptionCode == 0xe06d7363)
    {
        if (pER->NumberParameters == 3)
        {
            const _ThrowInfo * pThrowInfo = (_ThrowInfo*)pER->ExceptionInformation[2];
            if (pThrowInfo != NULL)
            {
                const _CatchableTypeArray * pTypeArray = pThrowInfo->pCatchableTypeArray;
                if (pTypeArray != NULL)
                {
                    const _TypeDescriptor * pExceptionDesc = (_TypeDescriptor*)&typeid(std::exception);  
                    for (int i = 0; i < pTypeArray->nCatchableTypes; i++)
                    {
                        const _CatchableType * pCatchableType = pTypeArray->arrayOfCatchableTypes[i];
                        if (pCatchableType != NULL && pExceptionDesc == pCatchableType->pType)
                        {
                            std::exception * e = (std::exception*)pER->ExceptionInformation[1];
                            printf("File: %s\nFunction: %s\nLine: %i\nC++ Exception: %s\n", file, function, line, e->what());
                            return EXCEPTION_EXECUTE_HANDLER;
                        }
                    }
                }
            }
        }
        printf("File: %s\nFunction: %s\nLine: %i\nC++ Exception (code 0x%x at 0x%x)\n", file, function, line, pER->ExceptionCode, pER->ExceptionAddress);
        return EXCEPTION_EXECUTE_HANDLER;
    }
    else
    {
        printf("File: %s\nFunction: %s\nLine: %i\nSEH Exception (code 0x%x at 0x%x)\n", file, function, line, pER->ExceptionCode, pER->ExceptionAddress);
        return EXCEPTION_EXECUTE_HANDLER;
    }
}
 
int main(int argc, char* argv[])
{
    __try
    {
        //DivideByZero();
        ThrowException();
    }
    __except(ExceptionFilter(GetExceptionInformation(), __FILE__, __FUNCTION__, __LINE__))
    {
        //handle exception here
    }
 
    return 0;
}

В заключении хочу отметить, что ExceptionAddress для исключений C++ не имеет особого смысла, потому что указывает всегда на один и тот же адрес внутри функции __CxxThrowException(), которая выполняется каждый раз, когда вызывается исключение с помощью throw.

===
Перепечатка материалов блога разрешается с обязательной ссылкой на blog.coolsoftware.ru

Как говорится, век - живи, век учись.

Захотелось мне вынести инициализацию данных класса в виртуальную функцию init(), с тем, чтобы классы-наследники могли переопределить ее и добавить в инициализацию что-то своё. Примерно так:

class C1
{
protected:
    int m_count;
    virtual void init() { m_count = 1; }
public:
    C1() { init(); }
    inline int count() const { return m_count; }
};
 
class C2: public C1
{
protected:
    virtual void init() { C1::init(); m_count = m_count+1; }
public:
    C2() : C1() {}
};
 
int _tmain(int argc, _TCHAR* argv[])
{
    C1 c1;
    _tprintf(_T("C1 count: %i\n"), c1.count());
    C2 c2;
    _tprintf(_T("C2 count: %i\n"), c2.count());
    return 0;
}

Результат получается такой:

C1 count: 1
C2 count: 1

Опа! Оказывается переопределенная в классе C2 функция init() не вызывается. Получается, что если вызвать из конструктора класса виртуальную функцию этого же класса, то обычный метод вызова виртуальных функций через vtable задействован не будет - функция будет вызвана как если бы они была не-виртуальной. По-моему такое поведение не выглядит логичным, поэтому от вызова виртуальных функций из конструктора лучше отказаться.

PS. Из деструктора вызывать виртуальные функции тоже не следует.

По поводу того, что при вызове виртуальных функций из конструктора (и деструктора) не используется vtable, - тут я, похоже, был не прав. vtable используется, только в конструкторе класса C1 (см. пример) используется vtable класса C1, а не класса-потомка C2 - вот в чем дело. Аналогично, в деструкторе C1 также используется vtable класса С1.

===
Перепечатка материалов блога разрешается с обязательной ссылкой на blog.coolsoftware.ru