Сообщение Re[36]: Когда это наконец станет defined behavior? от 11.05.2023 20:24
Изменено 11.05.2023 20:27 rg45
Re[36]: Когда это наконец станет defined behavior?
Здравствуйте, kov_serg, Вы писали:
_>1. этот модификатор создаёт дополнительный тип. На ровном месте число сущностей удваивается, а в случае контейнеров может и учетверяться и так далее. Для их обработки приходится писать разные методы
Не согласен. Сам по себе модификатор const не вынудает писать дополнительные метода, дает возможность программисту предоставить разные версии функций-членов для константного и неконстантного объектов — только если это нужно! Конечно, в каких-то простейших случаях могут возникать похожие на вид-функции члены, которые выглядят как дублирование, но это очень поверхностный взгляд, это во-первых. Во-вторых, это не является ни общим случаем, ни, тем более единственным — все зависит от семантики и дизайна класса. Например, во многих случаях бывает достаточно одной только версии — константной. Кроме того никто не запрещает константным версиям возвращать неконстантные указатели и ссылки. Как пример — все методы доступа к данным умных указателей стандартной библиотеки: get(), operator*, operator-> и пр. — все эти методы существуют только в одном варианте — в константном, а ссылки и указатели возвращают в соответствии с типом указателя. Если у тебя регулярно возникает необходимость определения всех возможных комбинаций const/volatile/lvalue-/rvalue-reference, нужных и ненужных, то, возможно, у тебя какие-то системные проблемы с составлением дизайна. По этому пункту ты меня не убедил.
_>2. сам по себе он не гарантирует неизменность данных. в некоторых случаях даже нет возможности это отловить
В каких-то случаях гарантирует (в well-formed программе), если модификатор относится непосредственно к объекту. В каких-то случаях, если модификатор пришел со ссылкой, у него просто другая семантика — но он является средством выдачи прав на чтение/запись. То, что он не гарантирует неизменности, не означает, что он бесполезен. По этому пункту тоже не убедил.
_>3. очень узкоспециализированный (пытается описать только неизменность)
Так так и должно быть — const ни на что, кроме константности влиять и не должен. Опять не убедил.
_>4. заставляет компилятор заниматься ненужным анализом и творить чудеса UB-строения
Ну вот, опять "заставляет". Не "заставляет", а "дает возможность".
Дальше вообще какая-то фантастика пошла. Не убедил ни по одному пункту.
_>1. этот модификатор создаёт дополнительный тип. На ровном месте число сущностей удваивается, а в случае контейнеров может и учетверяться и так далее. Для их обработки приходится писать разные методы
Не согласен. Сам по себе модификатор const не вынудает писать дополнительные метода, дает возможность программисту предоставить разные версии функций-членов для константного и неконстантного объектов — только если это нужно! Конечно, в каких-то простейших случаях могут возникать похожие на вид-функции члены, которые выглядят как дублирование, но это очень поверхностный взгляд, это во-первых. Во-вторых, это не является ни общим случаем, ни, тем более единственным — все зависит от семантики и дизайна класса. Например, во многих случаях бывает достаточно одной только версии — константной. Кроме того никто не запрещает константным версиям возвращать неконстантные указатели и ссылки. Как пример — все методы доступа к данным умных указателей стандартной библиотеки: get(), operator*, operator-> и пр. — все эти методы существуют только в одном варианте — в константном, а ссылки и указатели возвращают в соответствии с типом указателя. Если у тебя регулярно возникает необходимость определения всех возможных комбинаций const/volatile/lvalue-/rvalue-reference, нужных и ненужных, то, возможно, у тебя какие-то системные проблемы с составлением дизайна. По этому пункту ты меня не убедил.
_>2. сам по себе он не гарантирует неизменность данных. в некоторых случаях даже нет возможности это отловить
В каких-то случаях гарантирует (в well-formed программе), если модификатор относится непосредственно к объекту. В каких-то случаях, если модификатор пришел со ссылкой, у него просто другая семантика — но он является средством выдачи прав на чтение/запись. То, что он не гарантирует неизменности, не означает, что он бесполезен. По этому пункту тоже не убедил.
_>3. очень узкоспециализированный (пытается описать только неизменность)
Так так и должно быть — const ни на что, кроме константности влиять и не должен. Опять не убедил.
_>4. заставляет компилятор заниматься ненужным анализом и творить чудеса UB-строения
Ну вот, опять "заставляет". Не "заставляет", а "дает возможность".
Дальше вообще какая-то фантастика пошла. Не убедил ни по одному пункту.
Re[36]: Когда это наконец станет defined behavior?
Здравствуйте, kov_serg, Вы писали:
_>1. этот модификатор создаёт дополнительный тип. На ровном месте число сущностей удваивается, а в случае контейнеров может и учетверяться и так далее. Для их обработки приходится писать разные методы
Не согласен. Сам по себе модификатор const не вынуждает писать дополнительные методы, а дает возможность программисту предоставить разные версии функций-членов для константного и неконстантного объектов — только в том случае, если это нужно! Конечно, в каких-то простейших случаях могут возникать похожие на вид-функции члены, которые выглядят как дублирование, но это очень поверхностный взгляд, это во-первых. Во-вторых, необходимость создания разных методов не является ни общим случаем, ни, тем более единственным — все зависит от семантики и дизайна класса. Например, во многих случаях бывает достаточно одной только версии — константной. Кроме того никто не запрещает константным версиям возвращать неконстантные указатели и ссылки. Как пример — все методы доступа к данным умных указателей стандартной библиотеки: get(), operator*, operator-> и пр. — все эти методы существуют только в одном варианте — в константном, а ссылки и указатели возвращают в соответствии с типом указателя. Если у тебя регулярно возникает необходимость определения всех возможных комбинаций const/volatile/lvalue-/rvalue-reference, нужных и ненужных, то, возможно, у тебя какие-то системные проблемы с составлением дизайна. По этому пункту ты меня не убедил.
_>2. сам по себе он не гарантирует неизменность данных. в некоторых случаях даже нет возможности это отловить
В каких-то случаях гарантирует (в well-formed программе), если модификатор относится непосредственно к объекту. В каких-то случаях, если модификатор пришел со ссылкой, у него просто другая семантика — но он является средством выдачи прав на чтение/запись. То, что он не гарантирует неизменности, не означает, что он бесполезен. По этому пункту тоже не убедил.
_>3. очень узкоспециализированный (пытается описать только неизменность)
Так так и должно быть — const ни на что, кроме константности влиять и не должен. Опять не убедил.
_>4. заставляет компилятор заниматься ненужным анализом и творить чудеса UB-строения
Ну вот, опять "заставляет". Не "заставляет", а "дает возможность".
Дальше вообще какая-то фантастика пошла. Не убедил ни по одному пункту.
_>1. этот модификатор создаёт дополнительный тип. На ровном месте число сущностей удваивается, а в случае контейнеров может и учетверяться и так далее. Для их обработки приходится писать разные методы
Не согласен. Сам по себе модификатор const не вынуждает писать дополнительные методы, а дает возможность программисту предоставить разные версии функций-членов для константного и неконстантного объектов — только в том случае, если это нужно! Конечно, в каких-то простейших случаях могут возникать похожие на вид-функции члены, которые выглядят как дублирование, но это очень поверхностный взгляд, это во-первых. Во-вторых, необходимость создания разных методов не является ни общим случаем, ни, тем более единственным — все зависит от семантики и дизайна класса. Например, во многих случаях бывает достаточно одной только версии — константной. Кроме того никто не запрещает константным версиям возвращать неконстантные указатели и ссылки. Как пример — все методы доступа к данным умных указателей стандартной библиотеки: get(), operator*, operator-> и пр. — все эти методы существуют только в одном варианте — в константном, а ссылки и указатели возвращают в соответствии с типом указателя. Если у тебя регулярно возникает необходимость определения всех возможных комбинаций const/volatile/lvalue-/rvalue-reference, нужных и ненужных, то, возможно, у тебя какие-то системные проблемы с составлением дизайна. По этому пункту ты меня не убедил.
_>2. сам по себе он не гарантирует неизменность данных. в некоторых случаях даже нет возможности это отловить
В каких-то случаях гарантирует (в well-formed программе), если модификатор относится непосредственно к объекту. В каких-то случаях, если модификатор пришел со ссылкой, у него просто другая семантика — но он является средством выдачи прав на чтение/запись. То, что он не гарантирует неизменности, не означает, что он бесполезен. По этому пункту тоже не убедил.
_>3. очень узкоспециализированный (пытается описать только неизменность)
Так так и должно быть — const ни на что, кроме константности влиять и не должен. Опять не убедил.
_>4. заставляет компилятор заниматься ненужным анализом и творить чудеса UB-строения
Ну вот, опять "заставляет". Не "заставляет", а "дает возможность".
Дальше вообще какая-то фантастика пошла. Не убедил ни по одному пункту.