Временно отменить специализацию и создать базовый вариант шаблона для int-а, что бы код выдал: "base template".
Задачка неожиданно возникла во время игр с std::format. Ребята в комитете придумали, что кастомные форматеры, это специализации классов. Ну сделал я специализацию для своего класса, который тоже является специализацией библиотечного шаблона. А как мне теперь вызвать реализацию по умолчанию для базового шаблона ? Или я что-то не то делаю
Здравствуйте, Videoman, Вы писали:
V> Ну сделал я специализацию для своего класса
Все, тут твоя специализация становится тем единственным классом с которым ты работаешь, никакого понятия(знания) о "базовой" реализации нет и быть не должно )
Если есть какой то код находящийся в этой "базовой" реализации который хочется заюзать, значит вытаскивай его на уровень выше:
Здравствуйте, _niko_, Вы писали:
__>...
__>Но все же
obj.base_api::print();
— это говорит о том что тут что то пошло не так и лучше бы перепроектировать
Это же не я, это стандартная библиотека такую свинью подложила, std. Вот эти вот классы, они в std определены и специализировать мне их предлагают по стандарту. А я говорил, что люди принимающие стандарты, по ходу вообще не думают, последнее время.
Конструктивная критика: почему они сделали классы, почему не функции, как это сделал я в свое время в своей библиотеке форматирования. Если сделать форматер для всех наследников какого-то класса еще можно, с помощью SFINAE, то ADL для специализаций классов не работает и нет возможности определять форматеры в своём пространстве имен, оставляя возможность вызывать базовые из std.
Здравствуйте, Videoman, Вы писали:
V>Возможен ли сабж в принципе? Что-то туплю. Хочется примерно следующего:[ccode] V>Временно отменить специализацию и создать базовый вариант шаблона для int-а, что бы код выдал: "base template".
Вот прямо в такой формулировке, думаю, что невозможен — потому что в таком случае возникает две различные версии одной и той же специализации, а это нарушение ODR. Нужно думать, какие тут можно костыли прикрутить.
Здравствуйте, rg45, Вы писали:
R>Вот прямо в такой формулировке, думаю, что невозможен — потому что в таком случае возникает две различные версии одной и той же специализации, а это нарушение ODR. Нужно думать, какие тут можно костыли прикрутить.
Наверное вопрос в этом, как выкрутится теперь. Ситуация простая. У std::formatter есть специализация для вывода std::chrono::duration<>. У меня в библиотеках везде используется своя специализация времени:
using reftime_t = std::chrono::duration<int64, std:ratio<1, 10000000>>;
Стандартные возможности форматирования огромны, но мне хочется их расширить для своего типа времени и переиспользовать. Таким образом объявляя
Здравствуйте, Videoman, Вы писали:
V>Наверное вопрос в этом, как выкрутится теперь. Ситуация простая. У std::formatter есть специализация для вывода std::chrono::duration<>. У меня в библиотеках везде используется своя специализация времени:
Поскольку в C++ нет strong typedef, то компилятор C++ не может отличить ваш reftime_t от каких-либо других алиасов для std::chrono::duration.
ИМХО, тут напрашивается одно из двух:
— либо вы делаете свой reftime_t таки strong typedef-ом для std::chrono::duration, чтобы это был именно что другой тип на уровне C++. И тогда делаете для своего типа нужную вам специализацию std::formatter (наследуясь от std::formatter<std::chrono::duration<...>>);
V>Это же не я, это стандартная библиотека такую свинью подложила, std. Вот эти вот классы, они в std определены и специализировать мне их предлагают по стандарту.
Специализации определённых в std шаблонов добавлять можно. Нельзя добавлять свои новые имена.
Если явно не запрещено, программа может добавить специализацию шаблона для любого шаблона класса стандартной библиотеки в пространство имен std при условии, что (а) добавленное объявление зависит по крайней мере от одного определенного в программе типа и (б) специализация соответствует требованиям стандартной библиотеки для оригинальный шаблон .
Здравствуйте, so5team, Вы писали:
S>И тот, и другой способы геморройные. Разве что для первого способа можно задействовать какую-то готовую библиотеку с реализацией strong typedef.
Всё это очевидно. Тут больше вопросы к тем, кто принимает какое в std.
Свою проблему я решил, т.к. оказывается, что всю работу делает специализация formatter<std::time_t> и все вызовы в итоге приводят туда, а любой chrono тип приводится к time_t. Но это просто везение. А что делать, если это не так, по прежнему остается загадкой. С таким дизайном стандартной библиотеки, будем надеяться, что стандартных форматеров хватит всем, на все случаи жизни.
Здравствуйте, so5team, Вы писали:
S>Если вы хоте вести речь в таком тоне, то позвольте встречный вопрос: а что лично вы сделали, чтобы в стандарт попало что-то более вменяемое?
Ответ на это вопрос выходит за рамки топика. Не знаю что вам не нравится в тоне. Конструктивную критику я уже высказал: т.к. у меня была реализация точно такого же функционала с точно таким же синтаксисом, но она была построена на функциях, т.к. к ним применим ADL, а с ним возможна кастомизация форматирования для каждого конкретного неймспейса. Давайте лучше заниматься каждый своим делом, но желательно так, что бы те кто пользуются этими результатами не страдали, а были довольны тем, как замечательно мы с вами все за них продумали.
σ>>Да вроде в std нельзя добавлять специализаций, не зависящих от program-defined type (https://timsong-cpp.github.io/cppwp/n4868/namespace.std#2)
V>Специализации определённых в std шаблонов добавлять можно. Нельзя добавлять свои новые имена.
V>Если явно не запрещено, программа может добавить специализацию шаблона для любого шаблона класса стандартной библиотеки в пространство имен std при условии, что (а) добавленное объявление зависит по крайней мере от одного определенного в программе типа и (б) специализация соответствует требованиям стандартной библиотеки для оригинальный шаблон .
И шо, std::chrono::duration<int64, std:ratio<1, 10000000>> удовлетворяет условию (а)?
Да согласен, слишком упростил пример. У меня на самом деле перекрывается специализация std::chrono::time_point<reference_clock>, где reference_clock уже точно мой класс.
Здравствуйте, Videoman, Вы писали:
V>Конструктивную критику я уже высказал: т.к. у меня была реализация точно такого же функционала с точно таким же синтаксисом, но она была построена на функциях, т.к. к ним применим ADL, а с ним возможна кастомизация форматирования для каждого конкретного неймспейса.
V>Конструктивная критика: почему они сделали классы, почему не функции, как это сделал я в свое время в своей библиотеке форматирования. Если сделать форматер для всех наследников какого-то класса еще можно, с помощью SFINAE, то ADL для специализаций классов не работает и нет возможности определять форматеры в своём пространстве имен, оставляя возможность вызывать базовые из std.
Здравствуйте, Videoman, Вы писали:
S>>Если вы хоте вести речь в таком тоне, то позвольте встречный вопрос: а что лично вы сделали, чтобы в стандарт попало что-то более вменяемое?
V>Ответ на это вопрос выходит за рамки топика.
А вот это все еще в рамках топика?
Это же не я, это стандартная библиотека такую свинью подложила, std. Вот эти вот классы, они в std определены и специализировать мне их предлагают по стандарту. А я говорил, что люди принимающие стандарты, по ходу вообще не думают, последнее время.
V>Не знаю что вам не нравится в тоне.
Поведение в стиле "вот у меня все было по уму, а в std включили хз что"
V>Конструктивную критику я уже высказал: т.к. у меня была реализация точно такого же функционала с точно таким же синтаксисом, но она была построена на функциях, т.к. к ним применим ADL, а с ним возможна кастомизация форматирования для каждого конкретного неймспейса.
И где здесь критика? Я не увидел ни ссылки на исходники вашей библиотеки, в которой можно было бы посмотреть на альтернативный подход. Ни описания деталей этого подхода здесь. Более того, здесь видно как вы сами путаетесь в показаниях, т.к. у вас сперва reftime_t -- это синоним для стандартного std::chrono::duration, а потом оказывается, что все несколько не так.
Здесь же наблюдается какое-то брюзжание из категории "меня не спросили".
std::format взялся не на пустом месте. Много лет в OpenSource была fmtlib, автор которой потратил туеву хучу времени и сил на то, чтобы выложить это в OpenSource, снабдить документацией, среагировать на огромное количество issues, принять кучу pull-request-ов, выслушать в свой адрес всякое-разное. А потом еще и принять участие в формировании предложения в стандарт, и пройти вместе с другими соавторами через процесс включения в стандарт.
Причем процесс включения в стандарт был открытым, высказывать свои замечания/предложения к предложению можно было еще до того, как std::format стандартизировали.
Я это все к тому, что вмешаться в процесс можно было раньше. Если не на стадии развития fmtlib, так на стадии прохождения пропозала через комитет.
Так что если кто-то вопрошает, а почему в стандарте вот такое, когда можно было бы вот так, то ответ очень простой: потому что тот, кто знает как "вот так" не приложил никаких усилий к тому, чтобы его знание тем или иным образом было доведено до комитета.
И тут не суть важно, была ли у вас такая цель и желание, или не было. Ситуация с тем, что попадает в стандарт C++, проста: кто приложил усилия, тот и добился (или нет). И так оно уже лет 30, можно было бы и привыкнуть.
Здравствуйте, so5team, Вы писали:
S>Конструктивная критика должна, как минимум, идти в https://stdcpp.ru/
Если все программисты будут сидеть на stdcpp.ru, то кто и когда будет делать всё остальное. Искренне считаю, что то, что вы предлагаете, постоянно сидеть на форуме С++ и мониторить все предложения, анализировать их и проверять — не возможно на практике.
S>Здесь же наблюдается какое-то брюзжание из категории "меня не спросили".
Вот именно брюзжание — у вас. Я просто задал интересующий меня вопрос, для того что бы удостовериться что я не пропускаю очевидное решение столкнувшись с проблемой. Дальше я просто удивился, что нужной, как мне кажется, не только лично мне, кастомизации не предусмотрено ни в каком виде — всё. Ну посетовал немного, это запрещено на RSDN?
S>std::format взялся не на пустом месте. Много лет в OpenSource была fmtlib, автор которой потратил туеву хучу времени и сил на то, чтобы выложить это в OpenSource, снабдить документацией, среагировать на огромное количество issues, принять кучу pull-request-ов, выслушать в свой адрес всякое-разное. А потом еще и принять участие в формировании предложения в стандарт, и пройти вместе с другими соавторами через процесс включения в стандарт.
Знаем знаем как всё там не на пустом месте. Ребята из Microsoft запилили библиотеку для своих личных нужд и пропихнули её в стандарт, т.к. могли.
S>Причем процесс включения в стандарт был открытым, высказывать свои замечания/предложения к предложению можно было еще до того, как std::format стандартизировали.
Теоретически. Законы вот по такому же принципу воде принимаются, однако на практике на что-то влиять практически не возможно. Приходится довольствоваться тем что есть.
S>Я это все к тому, что вмешаться в процесс можно было раньше. Если не на стадии развития fmtlib, так на стадии прохождения пропозала через комитет.
Я прекрасно понимаю что такое решение получено в процессе консенсуса. Оно вообще по результату может полностью не устраивать все стороны которые его, вроде бы, принимали. Но зачем так яростно его защищать, даже если там есть очевидные недостатки
Здравствуйте, σ, Вы писали:
V>>Как с таким подходом как в std сделать свою кастомизацию форматирования int, например?
σ>А как через ADL сделать?
Как такое сделать дня базовых типов я не знаю. А можно кто-то в комитете продумает за меня ?!. В своём решении я, во всяком случае, могу это сделать. Для остальных классов можно хотя бы дать возможность не подключать заголовки стандартных форматеров, а использовать свои.