Russian Qt Forum

Добрый день

Увидел такой приемчик

C++ (Qt)
 
static struct StepTy {
} step MAYBE_UNUSED;
 
static struct EmptyTy {
} empty MAYBE_UNUSED;
 

Макруха для понту, можно не обращать внимания

C++ (Qt)
 
#ifdef __GNUC__
  #define MAYBE_UNUSED __attribute__((used))
#else
  #define MAYBE_UNUSED
#endif
 

И оказывается, "пустые" структуры очень лихо юзаются  :)

Используются. Ну и ?

То Вы такой продвинутый, а для меня это было маленьким открытием. Типа "во, блин, и так можно" :)

Сказать "вау!"  - это единственная причина создания этой темы?

Бредовая тема, если честно.

Объясните, пожалуйста, а для чего нужны пустые структуры?

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

C++ (Qt)
struct BBox {
 BBox( void ) {}
 BBox( EmptyTy ) : lower(inf), upper(-inf) {}
 ..
};
..
BBox box(empty);

Структура не пустая: есть конструкторы и судя по второму конструктору, присутствуют поля lower и upper.

В первом сообщение показаны 2 структуры, и мне не понятно зачем они вообще нужны? Какую роль выполняют :)

Второй конструктор BBox принимает аргумент EmptyTy (пустая структура из первого сообщения)

В общем как то используются, а как он объяснить не может :)
Приведите полный код структуры использующей пустую структуру :)

Пример использования: O Boost Multi-index Containers (http://habrahabr.ru/post/160009/#habracut)

Вижу :)

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

Если вы ещё раз внимательно посмотрите на этот пример, то вы заметите: нигде не используются объекты типов-тэгов.

Другими словами, этим структурам вообще не нужны определения (не нужны туловища).
Достаточно будет forward declaration.
И поэтому этот пример не может быть примером использования пустышек.
---------------------------------------


Вот настоящий пример использования пустышек:


В рамках с++03 реализация имитации variardic template (функций с переменным количеством аргументов, с сохранением типо безопасности):


Здесь можно указать от 1 до 3х аргументов.

Arg - это механизм, способный принять ссылку любого объекта и проконтролировать типо безопасность.
(при извлечении будет выполнена проверка квалификаторов и типов)

При вызове функции Foo, все не указанные аргументы по умолчанию превратятся в пустышку SEmpty.

Внутри туловища функции Foo ожидают, что часть аргументов может быть пустышками.
Там умеют корректно обработать "отсутствие аргумента".

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

И поскольку, функция не шаблонная, её можно сделать виртуальной.

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

Это open-sources которые я сейчас прикручиваю. Не вижу где я ошибаюсь :) Пример из буста намного сложнее, но смысл тот же: пустышка "натравливает" на вызов именно этой ф-ции/метода, где знают что делать. 

Под извлечением имелась ввиду "инстанциация"? Но ведь ф-ция не template. Непонятно, объясните.

Спвсибо

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

В том примере используется информация о типе (название типа), но не используются объекты этого типа (объекты типов-пустышок нигде не использовались. Вообще не были созданы).

А в этом случае, вам достаточно лишь forward declaration.
А вот определение типа - избыточно.

Пример:

http://rextester.com/RQSPH39005




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

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

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

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



Под "извлечением" подразумевалось "извлечение".

Здесь нужно немножко понимать, как работает механизм Arg.

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


К сожалению, сделать это не возможно.

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


Это будет работать. Но это не надежно, потому что  теряется контроль за типами аргументов.

Вот если бы было тоже самое, но с сохранением проверок типов и квалификаторов...

И тогда на сцену выходит механизм Arg.
Он запоминает ссылки на аргументы любых типов, и выполняет проверки типов и квалификаторов.

Причем доступен режим, при котором в релизе все проверки будут удалены. И получится тот же самый void*.
А есть режимы, когда он будет постоянно кидаться ассертами, или исключениями.

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


Изначально, я разработал механизм Arg, что бы с его помощью построить динамический делегат:



В отличие от статических делегатов,
таких как TConnector или std::function, динамический Connetor не является продуктом шаблона.

Это обычный класс. Весьма простой в использовании.
Он умеет нацеливаться на любые функци, функции-члены, функторы времени выполнения.

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

Очевидный юзкейс исключений - наследоваться от std::exception.

Использование же пустышок для этих целей - не очевидный, и не профессиональный ход.