[prog.c++] Пример использования шаблонов для создания C-шных коллбэков из методов C++-ных классов

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

Итак, есть известная чисто-С-шная библиотека http_parser, которую много кто использует (в том числе и мы в RESTinio). Для работы с ней нужно создать у себя в программе экземпляр типа http_parser и экземпляр типа http_parser_settings. Где http_parser_settings должен содержать набор указателей на С-шные коллбэки, которые будут вызываться во время парсинга HTTP-сообщений.

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

Решалась эта задача в два этапа.

[prog.c++] В склерозник: интересная серия статей про распознавание типа указателя на функцию посредством шаблонов

Утащу к себе в склерозник, дабы затем проще искать было:

• Deconstructing function pointers in a C++ template
• Deconstructing function pointers in a C++ template, the noexcept complication
• Deconstructing function pointers in a C++ template, vexing variadics
• Deconstructing function pointers in a C++ template, the calling convention conundrum
• Deconstructing function pointers in a C++ template, trying to address the calling convention conundrum
• Deconstructing function pointers in a C++ template, addressing the calling convention conundrum
• Deconstructing function pointers in a C++ template, returning to enable_if

[prog.c++] Продолжение истории про parent/child и удаление child-а из метода самого child-а

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

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

Все-таки вот такое:

void child::some_method() {    ... // Some actions.    delete this; // The last action of the method. }

можно контролировать лишь в самых тривиальных случаях. А по мере того, как some_method усложняется и/или погружается куда-то ниже в стек вызовов, вероятность возникновения use after free стремительно приближается к единице. И можно быть уверенным, что в один прекрасный момент use after free таки произойдет.

Под катом небольшой рассказ о схеме, которая была применена для того, чтобы сохранить режим взаимодействия parent и child, но при этом защититься от use after free.