Comments 24
>Также использование шаблонов в коде не всем понравится, поэтому все завернуто в макросы. Между тем макросы скрывают большое количество шаблонов и код выглядит довольно аккуратно.
Мне вот шаблоны нравятся намного больше, чем макросы :-)
Мне вот шаблоны нравятся намного больше, чем макросы :-)
Мне тоже нравятся больше шаблоны, однако подобного рода шаблоны лучше спрятать в макросы:
Почему это не завернуть в шаблонную функцию? На мой взгляд invokerTable<decltype(&Class::func), &Class::func>(«func») выглядит не так лаконично, как METHOD(func).
{
#m,
(InvokeMem)&Invoker<decltype(&m)>::invoke<&m>,
Invoker<decltype(&m)>::argCount(),
Invoker<decltype(&m)>::types()
}
Почему это не завернуть в шаблонную функцию? На мой взгляд invokerTable<decltype(&Class::func), &Class::func>(«func») выглядит не так лаконично, как METHOD(func).
Как это выглядит сейчас — отлично поддается заворачиванию в шаблоны функций, выводящие тип. Ну да, напишите вы дважды имя функции — как имя члена класса и как строчку с именем. Это не страшно и даёт гибкость в возможности несоответствия имени экспортируемой функции и реализации.
Кстати, в С++ нет шаблонных функций, есть шаблоны функций :-) И шаблон сам по себе не является типом.
Кстати, в С++ нет шаблонных функций, есть шаблоны функций :-) И шаблон сам по себе не является типом.
В boost не хотите предложить?
Boost в таком виде не примет. Один из аспектов философии boost в том, что код должен работать на любой платформе и любом компиляторе. Использование C++11 уже не вписывается.
А кстати, есть что-нибудь типа boost, но более расширенное? (без ограничений на компиляторы и т.п.)
Или хотя-бы какой-то сайт который собирает ссылки на такие библиотеки (типа общесистемных или language emulation features).
Интересно до чего еще додумались люди в мире С++:)
Или хотя-бы какой-то сайт который собирает ссылки на такие библиотеки (типа общесистемных или language emulation features).
Интересно до чего еще додумались люди в мире С++:)
Буст активно использует С++11, особенно концепты
Вписывается:
svn.boost.org/trac/boost/wiki/BoostEvo
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.
Посмотрите покачественее, что есть в C++11, а то использование Bool, вместо std::integral_constant как-то уже пугает, пять же свой велосипед вместо std::decay. Ваш Converter очень весело будет вести при конвертации строк с пробелами, будет теряться все после первого пробела. Хотя не совсем понял откуда вызывается helper::convert. Частое использование const_cast пугает очень сильно, но особо не разбирался для чего именно так.
Согласен, Bool — пережитки прошлого. Decay тоже весьма правильное замечание. Спасибо за наводку!
Convert пока нигде не вызывается, в ходе работы пришлось закомментить, пока не восстановил функциональность. Вообще должно работать в более безопасной функции с автоматическим приведением типов Api::invoke.
Convert пока нигде не вызывается, в ходе работы пришлось закомментить, пока не восстановил функциональность. Вообще должно работать в более безопасной функции с автоматическим приведением типов Api::invoke.
>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{};
Вот это позабавило :-) Почему не 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{};
if (const auto result = any_cast(&operand)) return *result;
throw std::bad_cast{};
Отсутствие return в конце функции\метода — плохая практика
Абсолютно согласен насчет std::runtime_error, bad_cast более уместно.
Второе замечание, как мне кажется, делает код менее читаемым.
Второе замечание, как мне кажется, делает код менее читаемым.
Еще бы я отметил, что в исключениях недостаточно подробностей: «не соответствует число аргументов». Пока вы вызываете одну функцию с двумя аргументами, передав ей три, понять, что не так, легко, но когда это вылетит из глубины какой-то библиотеки… Подумайте о тех, кто будет это отлаживать.
Более информативным было бы сообщение:
«Не соответствует количество аргументов функции ${name}: ожидается ${expected}, найдено ${actual}»
Более информативным было бы сообщение:
«Не соответствует количество аргументов функции ${name}: ожидается ${expected}, найдено ${actual}»
Вообще не рекомендуется кидать исключения с префиксом bad, они считаются системными. Сделано правильно, но я бы лучше сделал своё исключение.
Когда планируете писать документацию? Без нее это еще одна никому не нужная поделка на коленке.
Честно говоря ме это всё равно не нужно, но, первое что я понял — я ничего не понял. Если уж заявляете что сделали универсальный биндинг ко многим скриптовым языкам, так покажите хороший пример, где сразу будут видны все достоинства, а не эти шаблонные закорючки.
Честно говоря ме это всё равно не нужно, но, первое что я понял — я ничего не понял. Если уж заявляете что сделали универсальный биндинг ко многим скриптовым языкам, так покажите хороший пример, где сразу будут видны все достоинства, а не эти шаблонные закорючки.
А также возможность загрузить информацию о типах из плагинов прямо в рантайме. Для этих целей binding библиотеки не подходят.Не совсем понял, о чем речь. При помощи Luabind можно сделать so/dll, при загрузке которого в Lua появятся типы (классы), привязанные в этом файле.
Sign up to leave a comment.
Универсальная метасистема на C++