Comments 6
позволяют достаточно гибко обнаруживать наличие методов, как подходящих, так и строго соответствующих заданной сигнатуре
Наличие метода вообще-то не говорит о том что он реализован, например там может быть заглушка которая кидает исключение not implemented или возвращает всегда ошибку и еще помечен как depricated. В чем полезность такого механизма, кроме самой возможности его реализации?
0
скорее всего - static_assert() в библиотеках для более удобочитаемых сообщений об ошибках. ну или общие библиотеки которые могут вызывать возможно по разному поименованные схожие методы. ну к примеру, есть классы с clear() и Clear() в двух разных библиотеках, а нам надо шаблон который будет работать с любой из них.
0
если у тебя в коде какая то заглушка которая кидает ошибку то ты что то сделал не так
0
UFO just landed and posted this here
Например, вы делаете универсальный метод который будет сериализовать переданную сущность в строкуДля такого метода подобные приёмы не нужны. Более того они вредны. Вместо того что бы сделать отдельные шаблоны serialize для каждого исторического пласта, вы хотите всё запихать в метод который должен учесть всё накопленную историю, а по возможности и будущую.
то вы об этом узнаете при прогоне юнит-тестовЭто в идеале да. Но на практике скорее всего пока не наступите не узнаете.
0
Sign up to leave a comment.
Обнаружение наличия функциональности в C++ на этапе компиляции