Сообщение Re[20]: Cоздание базового шаблона минуя специализацию от 29.10.2022 10:03
Изменено 29.10.2022 10:56 rg45
Re[20]: Cоздание базового шаблона минуя специализацию
Здравствуйте, so5team, Вы писали:
S>Могу ошибаться, но может быть есть способ объединить лучшее из двух миров?
S>Идея в том, что сейчас fmtlib просто инстанциирует тип formatter там, где ей это нужно. Наверное, можно создавать formatter не напрямую, а вызвав функцию-фабрику, которая уже и возвратит экземпляр formatter.
S>Функция-фабрика будет свободной функцией, которая может быть определена и в пространстве имен пользователя.
Вот такое решение мне нравится гораздо больше. С одной стороны, обеспечивается обратная совместимость с уже написанными форматтерами в виде специализаций. При этом появляются новые возможности, о которых говорилось выше:
В конце концов, с таким подходом пользователь может самостоятельно осуществить переход от форматтеров-классов к форматтерам-функциям, если очень хочется. А может использовать какие-то более сложные гибридные схемы. Вместо одной точки кастомизации теперь их целых три: специализация библиотечного шаблона класса; фабрики форматтеров; пользовательский форматтер. Пользовательский форматтер вообще можно навернуть с какой угодно сложностью и обеспечить еще 100500 точек кастомизации, специфичных для прикладной области. В целом гибкость и юзабельность существенно выше, чем в текущем подходе со специализациями.
S>Могу ошибаться, но может быть есть способ объединить лучшее из двух миров?
S>Идея в том, что сейчас fmtlib просто инстанциирует тип formatter там, где ей это нужно. Наверное, можно создавать formatter не напрямую, а вызвав функцию-фабрику, которая уже и возвратит экземпляр formatter.
S>Функция-фабрика будет свободной функцией, которая может быть определена и в пространстве имен пользователя.
Вот такое решение мне нравится гораздо больше. С одной стороны, обеспечивается обратная совместимость с уже написанными форматтерами в виде специализаций. При этом появляются новые возможности, о которых говорилось выше:
- можно определять пользовательские форматтеры в одном пространстве имен с пользовательскими типами,
можно предоставлять форматтеры по умолчанию для целых пространств имен
можно повторно использовать предопределенные наборы форматтеров для новых типов при помощи using-declarations
В конце концов, с таким подходом пользователь может самостоятельно осуществить переход от форматтеров-классов к форматтерам-функциям, если очень хочется. А может использовать какие-то более сложные гибридные схемы. Вместо одной точки кастомизации теперь их целых три: специализация библиотечного шаблона класса; фабрики форматтеров; пользовательский форматтер. Пользовательский форматтер вообще можно навернуть с какой угодно сложностью и обеспечить еще 100500 точек кастомизации, специфичных для прикладной области. В целом гибкость и юзабельность существенно выше, чем в текущем подходе со специализациями.
Re[20]: Cоздание базового шаблона минуя специализацию
Здравствуйте, so5team, Вы писали:
S>Могу ошибаться, но может быть есть способ объединить лучшее из двух миров?
S>Идея в том, что сейчас fmtlib просто инстанциирует тип formatter там, где ей это нужно. Наверное, можно создавать formatter не напрямую, а вызвав функцию-фабрику, которая уже и возвратит экземпляр formatter.
S>Функция-фабрика будет свободной функцией, которая может быть определена и в пространстве имен пользователя.
Вот такое решение мне нравится гораздо больше. С одной стороны, обеспечивается обратная совместимость с уже написанными форматтерами в виде специализаций. При этом появляются новые возможности, о которых говорилось выше:
В конце концов, с таким подходом пользователь может самостоятельно осуществить переход от форматтеров-классов к форматтерам-функциям, если очень хочется. А может использовать какие-то более сложные гибридные схемы. Вместо одной точки кастомизации теперь их целых три: специализация библиотечного шаблона класса; фабрики форматтеров; пользовательский форматтер. Пользовательский форматтер вообще можно навернуть с какой угодно сложностью и обеспечить еще 100500 точек кастомизации, специфичных для прикладной области. В целом гибкость и юзабельность существенно выше, чем в текущем подходе со специализациями.
S>Могу ошибаться, но может быть есть способ объединить лучшее из двух миров?
S>Идея в том, что сейчас fmtlib просто инстанциирует тип formatter там, где ей это нужно. Наверное, можно создавать formatter не напрямую, а вызвав функцию-фабрику, которая уже и возвратит экземпляр formatter.
S>Функция-фабрика будет свободной функцией, которая может быть определена и в пространстве имен пользователя.
Вот такое решение мне нравится гораздо больше. С одной стороны, обеспечивается обратная совместимость с уже написанными форматтерами в виде специализаций. При этом появляются новые возможности, о которых говорилось выше:
- можно определять пользовательские форматтеры в одном пространстве имен с пользовательскими типами,
можно предоставлять форматтеры по умолчанию для целых пространств имен
можно повторно использовать предопределенные наборы форматтеров для новых типов при помощи using-declarations
еще одна важная деталь: фабрика форматтера получает параметром объект и у теперь и форматтер теперь может быть чувствителен к свойствам объекта, для которого он создается.
В конце концов, с таким подходом пользователь может самостоятельно осуществить переход от форматтеров-классов к форматтерам-функциям, если очень хочется. А может использовать какие-то более сложные гибридные схемы. Вместо одной точки кастомизации теперь их целых три: специализация библиотечного шаблона класса; фабрики форматтеров; пользовательский форматтер. Пользовательский форматтер вообще можно навернуть с какой угодно сложностью и обеспечить еще 100500 точек кастомизации, специфичных для прикладной области. В целом гибкость и юзабельность существенно выше, чем в текущем подходе со специализациями.