Универсальная метасистема на C++

[Hertz]

>Также использование шаблонов в коде не всем понравится, поэтому все завернуто в макросы. Между тем макросы скрывают большое количество шаблонов и код выглядит довольно аккуратно.
Мне вот шаблоны нравятся намного больше, чем макросы :-)

[occash]

Мне тоже нравятся больше шаблоны, однако подобного рода шаблоны лучше спрятать в макросы:

{
    #m,
    (InvokeMem)&Invoker<decltype(&m)>::invoke<&m>,
    Invoker<decltype(&m)>::argCount(),
    Invoker<decltype(&m)>::types()
}

Почему это не завернуть в шаблонную функцию? На мой взгляд invokerTable<decltype(&Class::func), &Class::func>(«func») выглядит не так лаконично, как METHOD(func).

[Hertz]

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

Кстати, в С++ нет шаблонных функций, есть шаблоны функций :-) И шаблон сам по себе не является типом.

[occash]

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

[NeoCode]

В boost не хотите предложить?

[occash]

Boost в таком виде не примет. Один из аспектов философии boost в том, что код должен работать на любой платформе и любом компиляторе. Использование C++11 уже не вписывается.

[NeoCode]

А кстати, есть что-нибудь типа boost, но более расширенное? (без ограничений на компиляторы и т.п.)
Или хотя-бы какой-то сайт который собирает ссылки на такие библиотеки (типа общесистемных или language emulation features).
Интересно до чего еще додумались люди в мире С++:)

[DancingOnWater]

Буст активно использует С++11, особенно концепты

[occash]

Boost использует С++11, но в boost всегда можно получить ту же функциональность и без него.

[DancingOnWater]

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

[Balthasar]

Вписывается:

svn.boost.org/trac/boost/wiki/BoostEvo

However, it is ultimately the decision of the library developer which versions of C++ to support and how.

New libraries will not be rejected because they lack support for older platforms, particularly if new language or library features are integral to the library interface or design. An example would be a library that cannot provide a usable interface without use of a new C++ feature.

[AxisPod]

Посмотрите покачественее, что есть в C++11, а то использование Bool, вместо std::integral_constant как-то уже пугает, пять же свой велосипед вместо std::decay. Ваш Converter очень весело будет вести при конвертации строк с пробелами, будет теряться все после первого пробела. Хотя не совсем понял откуда вызывается helper::convert. Частое использование const_cast пугает очень сильно, но особо не разбирался для чего именно так.

[occash]

Согласен, Bool — пережитки прошлого. Decay тоже весьма правильное замечание. Спасибо за наводку!
Convert пока нигде не вызывается, в ходе работы пришлось закомментить, пока не восстановил функциональность. Вообще должно работать в более безопасной функции с автоматическим приведением типов Api::invoke.

[Hertz]

>throw std::runtime_error(«Bad cast»);
Вот это позабавило :-) Почему не std::bad_cast{}?

Возможно этот код:
nonref* result = any_cast(&operand);
if (!result) throw std::runtime_error(«Bad cast»);
return *result;

Лучше бы выглядел так:
if (const auto result = any_cast(&operand)) return *result;
throw std::bad_cast{};

[DancingOnWater]

if (const auto result = any_cast(&operand)) return *result;
throw std::bad_cast{};

Отсутствие return в конце функции\метода — плохая практика

[Hertz]

А обоснование будет? Чем throw не return?

[DancingOnWater]

А обоснование будет?

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

[occash]

Абсолютно согласен насчет std::runtime_error, bad_cast более уместно.
Второе замечание, как мне кажется, делает код менее читаемым.

[Mingun]

Еще бы я отметил, что в исключениях недостаточно подробностей: «не соответствует число аргументов». Пока вы вызываете одну функцию с двумя аргументами, передав ей три, понять, что не так, легко, но когда это вылетит из глубины какой-то библиотеки… Подумайте о тех, кто будет это отлаживать.

Более информативным было бы сообщение:
«Не соответствует количество аргументов функции ${name}: ожидается ${expected}, найдено ${actual}»

[AxisPod]

Вообще не рекомендуется кидать исключения с префиксом bad, они считаются системными. Сделано правильно, но я бы лучше сделал своё исключение.

[Cupper]

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

[starius]

А также возможность загрузить информацию о типах из плагинов прямо в рантайме. Для этих целей binding библиотеки не подходят.

Не совсем понял, о чем речь. При помощи Luabind можно сделать so/dll, при загрузке которого в Lua появятся типы (классы), привязанные в этом файле.