Как стать автором
Обновить

Комментарии 12

Ок, вы изобрели свой SOAP
Не верю что нет для этой цели стандартной библиотеки, yfghbvth axis.apache.org/axis/
Если речь идет просто о вызове произвольных функций, то для этого есть libFFI, притом портируемая и с минимальными зависимостями.
Спасибо за наводку, буду знать.
НЛО прилетело и опубликовало эту надпись здесь
а потом другой программист подумал что это опечатка и убрал лишний $ и все сломалось. лучше уж использовать call_user_func
Ожидал увидеть свою реализацию Qtшных сигналов и слотов :)
Код тырили и на форумах расспрашивали?
Видно по коду очень хорошо, учитывая, как намешан boost и stl из C++11. Если парсинг xml сделать например на pugixml, то boost можно выкинуть полностью, то что вы используете из boost, имеет либо аналоги в stl, либо реализуется совсем просто тем же stl. Но больше всего конечно убило полное непонимание variadic templates и логики работы и места назначения generate_sequence. FunctionCaller реализуется вариадиками без напрягов и не требует специализаций по кол-ву аргументов.

Уж простите, но сначала стоит выучить C++11 (если уж используете его), потом учить других.

У вас в итоге получилась каша из C++03, C++11, boost.
Амм… Простите, что?

Я же написал: сделаем сначала новым стандартом, а потом тоже самое — старым.
Видно по коду очень хорошо, учитывая, как намешан boost и stl из C++11

Покажите с++11 часть, где используется boost, кроме конечно, InvokeParser — и об этом я специально упомянул — парсинг строки не важен, по сути:
Если парсинг xml сделать например на pugixml,

Ага, заменить одну библиотеку — другой.
Следующий пункт:
Но больше всего конечно убило полное непонимание variadic templates и логики работы и места назначения generate_sequence.

Покажите, как правильно, пожалуйста.
И ещё:
FunctionCaller реализуется вариадиками без напрягов и не требует специализаций по кол-ву аргументов.

Старый стандарт, покажите, как вы будете вариадики в старом стандарте использовать и сразу же скажите об этом комитету по стандартизации — они, ведь, обманули — вариадики-же были и до нового стандарта, не правда ли?
И ещё:
boost можно выкинуть полностью, то что вы используете из boost, имеет либо аналоги в stl, либо реализуется совсем просто тем же stl

Вы предлагаете свой boost::function_traits написать? Зачем? Это не сложно(файлик boost\trunk\boost\type_traits\function_traits.hpp содержит около 175 строчек несложных примеров использования частичной специализации шаблона) и отвлекает от решения задачи.

У вас в итоге получилась каша из C++03, C++11, boost.

Мешал только C++03 и boost(не учитываем InvokeParser), а не {C++03, boost, C++11} и {C++03, C++11}, и {boost, C++11}.

Уж простите, но сначала стоит выучить C++11 (если уж используете его), потом учить других.

Уж простите, сначала вы научите всех, как внимательно читать статью, а потом расскажите, как использовать вариадики в старом стандарте, а потом посоветуете для парсинга маленькой xml заменить одну библиотеку на другую.
Если я правильно понял пример, то было бы целесообразно для обозначениия типов использовать не строки а числа. Очевидно что это добавит лишний маппинг в InvokeParser, не то что бы это накладно по производительности, но это означает что нужно делать для каждого типа два маппинга, один и InvokeParser, второй в TypeHelper. Я дума это не так стращно как сравнивать строки для каждого вызова функции.
По сути, сравнивать можно только при DEBUG, так как несоответствие типов происходит только по вине программиста(т.е, задал неправильный callback) — если производительность настолько важна. Но это немножко запутанно, так как придётся оговариваться — «этот тип обозначаем через 0, а этот через 1 и в TypeHelper::name() возвращаем для всех числовых типов 0, потому что смотри выше… и т.д.». Да, Вы абсолютно правы и если производительность совсем критична, и сравнивать типы на соответствие нужно при каждом вызове(кстати, можно сравнивать только первый раз, так как типы с++-функции не поменяются в рантайме… хм..), а не только при определённом DEBUG, то мапить типы можно и на char(unsigned char, если 128 типов о_О не хватает). В любом случае — это вопрос оптимизации, которая, к сожалению, в большинстве случаев приводит к менее читаемому коду…
char(unsigned char, если 128 типов о_О не хватает) — не обращайте внимания, глупость:)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации