Здравствуйте, Videoman, Вы писали:
V>Я описал просто точку кастомизации. Из нее можно подлезть и сделать как угодно.
Я тоже не вдавался в детали, но сделал акцент на том, что в любом случае, вызовы пользовательских функций должны выполняться по неквалифицированным именам, чтобы задействовать ADL, это ключевой момент при любых постановке и дизайне, как мне кажется.
V>Я не повторял детали, которые мы до этого тут обсуждали. Можно же сделать и так: V>parse(...., my::parse_as<type_t>()); V>format(...., my::format_as<type_t>());
Ну вот этот вариант близок к тому, о чем я говорил здесь
: использование фейкового параметра при неквалифицированном вызове заставит компилятор заглянут в пространство имен my и найти там функции обработки встроенных типов (а также для типов из сторонних библиотек и std:). Для UDT же процедуры обработки удобнее всего определить в тех же пространствах имен, что и сами типы, наверное, хотя чисто технически можно и в пространстве имен my — компилятор заглянет и туда, и туда, при таком подходе.
V>Тогда ADL начнет работать по полной. Если дашь конкретику чего хочется получить и время, то я постараюсь показать полный код. Или я опять не понял вопроса?
Здравствуйте, rg45, Вы писали:
R>Ну я уже запал на вариант с фабрикой
Тут натолкнулся на проблему с подходом со враппером и не char-строками. Не могу понять что fmt не нравится и почему не находится перегрузка. Толи c wrapper-ом что-то не то, толи ещё что-то. Кстати с wrapper-ом точно что-то не то, т.к. T&& у wrapper(T&& t) не является универсальной ссылкой. Наверное должно быть так:
Еще есть вариант что библиотека fmt обрабатывает стандартные типы внутри себя, без использования fmt::formatters, и из-за этого вся последовательность логики ломается.
Здравствуйте, Videoman, Вы писали:
V>Здравствуйте, rg45, Вы писали:
R>>Ну я уже запал на вариант с фабрикой
V>Тут натолкнулся на проблему с подходом со враппером и не char-строками. Не могу понять что fmt не нравится и почему не находится перегрузка. Толи c wrapper-ом что-то не то, толи ещё что-то. Кстати с wrapper-ом точно что-то не то, т.к. T&& у wrapper(T&& t) не является универсальной ссылкой. Наверное должно быть так:
Еще есть вариант что библиотека fmt обрабатывает стандартные типы внутри себя, без использования fmt::formatters, и из-за этого вся последовательность логики ломается.
Выглядит как недоработка библиотеки. Смотрю исходники, нет перегрузки format/vformat для широких строк... Судя по всему, твоя ошибка случается потому что по ходу пъесы wchar_t подменяется на char (смотри using format_string), ну и далее от этого все идет в разнос
Здравствуйте, Videoman, Вы писали:
V>Кстати с wrapper-ом точно что-то не то, т.к. T&& у wrapper(T&& t) не является универсальной ссылкой. Наверное должно быть так:
Еще есть вариант что библиотека fmt обрабатывает стандартные типы внутри себя, без использования fmt::formatters, и из-за этого вся последовательность логики ломается.
Все верно, wrapper<T> не использует механизм perfect forwarding непосредственно, но он перенимает результаты использования perfect forwarding у функции wrap как эстафетную палочку. Если ты будешь создавать объект wrapper<T> непосредсвенно, минуя функцию wrap, то T — это тот тип, которым ты параметризовал шаблонный класс wrapper, и ни о каких perfect forwarding ссылках, конечно же, не может быть и речи при таком использовании. Если же ты создаешь объект wrapper<T> через функцию wrap, то T — это тип, выведенный при матчинге настоящей perfect forwarding ссылки, являющейся параметром функции wrap. В этом случае Т — это может быть как тип объекта, так и lvalue сылка на объект и результат будет ровно таким же, как если бы функция возвращала бы результат напрямую, без враппинга — T wrap(T&&):
Здравствуйте, vopl, Вы писали:
V>Выглядит как недоработка библиотеки. Смотрю исходники, нет перегрузки format/vformat для широких строк... Судя по всему, твоя ошибка случается потому что по ходу пъесы wchar_t подменяется на char (смотри using format_string), ну и далее от этого все идет в разнос
Вот тоже склоняюсь к такому выводу. Видимо там дизайн в угоду микрооптимизаций в ущерб гибкости.