Здравствуйте, alpha21264, Вы писали:
A>6) so5team! Ты прочитал фразу (в другом сообщении), что поскольку в реальных программах большинство параметров const, A>то слово const лучше убрать, а использовать не-const. Тогда контроль за параметрами останется, а мусор исчезнет.
Это верное замечание, кстате.
Из-за этого существуют языки, где по умолчанию const, а mutable надо прописывать явно.
A>Мне не нужны модификаторы const, потому что я не делаю такого рода ошибок. Мне костыль не нужен.
Лично мне const помогает реже совершать описку "=" вместо "==". ))
Здравствуйте, vdimas, Вы писали:
V>Это верное замечание, кстате.
Разговор шел конкретно в контексте языка C++.
Если кто-то может в очередном стандарте поменять так, что в C++ все ссылки и указатели в параметрах автоматически станут ссылками/указателями на const, то я буду очень и очень удивлен такому развитию событий.
Здравствуйте, vdimas, Вы писали:
A>>Мне не нужны модификаторы const, потому что я не делаю такого рода ошибок. Мне костыль не нужен.
V>Лично мне const помогает реже совершать описку "=" вместо "==". ))
Я для таких случаев константу пишу слева, а переменную справа.
Здравствуйте, vdimas, Вы писали:
A>>Мне не нужны модификаторы const, потому что я не делаю такого рода ошибок. Мне костыль не нужен.
V>Лично мне const помогает реже совершать описку "=" вместо "==". ))
Для этого в gcc существует отдельное предупреждение.
Я в Go пошли еще дальше. В этом языке "=" не является оператором (его нельзя использовать в выражениях) а условие if-а и цикла обязано быть bool (int не является bool и к bool не приводится).
Здравствуйте, alpha21264, Вы писали:
A>5) so5team! Ты прочитал фразу (в другом сообщении), что из-за бесполезных варнингов теряются полезные?
Эта фраза вызывает удивление и непонимание.
Потому, что в тех проектах, в которых я устанавливаю правила (или способен влиять на установленные правила), количество бесполезных варнингов равно нулю. Поэтому все оставшиеся — полезные.
Полагаю, другие участники дискуссии имеют схожий опыт.
А ты почему-то не такой, как все. Этот факт вызывает удивление и беспокойство.
Здравствуйте, alpha21264, Вы писали:
V>>Лично мне const помогает реже совершать описку "=" вместо "==". )) A>Я для таких случаев константу пишу слева, а переменную справа.
Не всегда сравниваются константы.
И да, константа не сильно отличается по семантике от const-переменной, особенно в инлайных ф-ях при распространении констант вдоль иерархии вызовов. ))
Здравствуйте, Pzz, Вы писали:
V>>Лично мне const помогает реже совершать описку "=" вместо "==". )) Pzz>Для этого в gcc существует отдельное предупреждение.
Согласен. Достаточно взять в двойные скобки if((a=b)) чтобы использовать присвоение как bool-выражение.
Pzz>Я в Go пошли еще дальше. В этом языке "=" не является оператором (его нельзя использовать в выражениях) а условие if-а и цикла обязано быть bool (int не является bool и к bool не приводится).
У этой медали две стороны. ))
Особенно учитывая возможность переопределения операторов в С++.
Здравствуйте, vdimas, Вы писали:
V>У этой медали две стороны. )) V>Особенно учитывая возможность переопределения операторов в С++.
Если бы директором был я, я бы сильно ограничил возможности переопределения операторов. В частности, я бы требовал, чтобы операторы сравнения, как и операторы || и && всегда возвращали bool. И, вероятно, разрешил бы только переопределять операторы <, <= и ==, считая, что > — это отрицание <= и т.п. (если честно, я бы пошел и дальше, и ограничился бы только переопределением < и ==, с автовыводом <=, но ведь в C++ нельзя напрасно терять и такта процессора...).
Здравствуйте, vdimas, Вы писали:
V>>>Лично мне const помогает реже совершать описку "=" вместо "==". )) A>>Я для таких случаев константу пишу слева, а переменную справа.
V>Не всегда сравниваются константы.
Здравствуйте, Pzz, Вы писали:
Pzz>Если бы директором был я, я бы сильно ограничил возможности переопределения операторов. В частности, я бы требовал, чтобы операторы сравнения, как и операторы || и && всегда возвращали bool. И, вероятно, разрешил бы только переопределять операторы <, <= и ==, считая, что > — это отрицание <= и т.п. (если честно, я бы пошел и дальше, и ограничился бы только переопределением < и ==, с автовыводом <=, но ведь в C++ нельзя напрасно терять и такта процессора...).
В С++ можно терять такты процессора, если задача позволяет.
Но если задача не позволяет, то должен быть способ выразить всё то же самое, но эффективно. Предложенное тобой ограничение по операторам может очевидным образом этому препятствовать.
Здравствуйте, serg_joker, Вы писали:
_>В С++ можно терять такты процессора, если задача позволяет. _>Но если задача не позволяет, то должен быть способ выразить всё то же самое, но эффективно. Предложенное тобой ограничение по операторам может очевидным образом этому препятствовать.
Может препятствовать.
Я хочу сказать, что очень бы было желательно, чтобы операции сравнения были алгебраичны. В том смысле, что a < b равносильно b > a и равносильно !(a >= b). И из a < b && b < c следует, что a < c.
И это важнее, чем несколько тактов процессора.
Очень редко бывает так, чтобы требования быстроты и сложности применялись к коду одновременно. И там, где есть требование быстроты, можно поднапрячься и обойтись без перегрузки операторов — скорее всего, речь идёт о небольшой доле кода.
А вот в сложном коде язык должен помогать, а не усложнять жизнь. И ради этого можно пожертвовать несколькими тактами процессора.
Здравствуйте, hi_octane, Вы писали:
_>Тут главное чтобы язык не дай бог не получил "стандартную библиотеку физических типов", а позволял гибко объявлять это всё внутри проекта. Потому что в разных областях физики или химии одинаковые буквы могут значить ну очень разное.
Здравствуйте, Pzz, Вы писали:
Pzz>Очень редко бывает так, чтобы требования быстроты и сложности применялись к коду одновременно. И там, где есть требование быстроты, можно поднапрячься и обойтись без перегрузки операторов — скорее всего, речь идёт о небольшой доле кода.
Ну вот возьмём простой класс — std::string, хочу я его во всяких контейнерах держать, сравнивать и вообще не церимониться.
и есть у меня код:
if (s1 > s2) { ... }
вот ты бы хотел, чтобы условие разворачивалось в (!(s1 < s2 ) || (s1 == s2)) с удвоением сложности?
или чтобы нужно было писать gteaterthan(s1,s2) ?
С моей точки зрения, код не выглядит слишком уж экзотичным. Во вполне прикладном и высокоуровневом коде сравниваются строки, контейнеры, кортежи, варианты, опшналы и много чего другого, я бы не хотел, чтобы мне вместо читабельных математических символов пришлось использовать что-то другое.
Но и плата за !((v1 < v2) || (v1 == v2)) — это не несколько тактов.
Здравствуйте, serg_joker, Вы писали:
_>вот ты бы хотел, чтобы условие разворачивалось в (!(s1 < s2 ) || (s1 == s2)) с удвоением сложности?
Удобно когда есть дефолты. Т.е. для типичной структуры с набором полей это не требуется. А там где есть экономия — там делаем более оптимальные имплементации.
Кстати, этот самый <=> как раз это и делает, как я понял.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, ·, Вы писали:
·>Удобно когда есть дефолты. Т.е. для типичной структуры с набором полей это не требуется. А там где есть экономия — там делаем более оптимальные имплементации.
Тут вопрос что такое "типично". Если структура содержит ту же самую std::string, то вся аргументация про удвоение сложности остаётся в силе. А современная "типичная" структура зачастую содержит что-то такое тяжёлое.
Как по мне, очень опасное с т.з. производительности поведение по умолчанию.
·>Кстати, этот самый <=> как раз это и делает, как я понял. <=> относится к этой же проблематике, но делает не совсем это. Для вычисления любого из синтезированных операторов требуется один вызов <=>.
Здравствуйте, ·, Вы писали:
·>Удобно когда есть дефолты. Т.е. для типичной структуры с набором полей это не требуется. А там где есть экономия — там делаем более оптимальные имплементации. ·>Кстати, этот самый <=> как раз это и делает, как я понял.
Именно так.
Поэтому, в случае недефолта иногда выгоднее по старинке расписать отдельно операции <, > и т.д., т.к. сравнение на простое меньше иногда в 2-3 раза дешевле полноценного <=>.
Здравствуйте, Marty, Вы писали:
_>>Тут главное чтобы язык не дай бог не получил "стандартную библиотеку физических типов", а позволял гибко объявлять это всё внутри проекта. Потому что в разных областях физики или химии одинаковые буквы могут значить ну очень разное.
M>А namespace'ы на что?
Здравствуйте, alpha21264, Вы писали:
_>>>Тут главное чтобы язык не дай бог не получил "стандартную библиотеку физических типов", а позволял гибко объявлять это всё внутри проекта. Потому что в разных областях физики или химии одинаковые буквы могут значить ну очень разное.
M>>А namespace'ы на что?
A>Чтобы запутать себя и других.
команды по тяге двигателя в программном обеспечении Mars Climate Orbiter использовали единицу измерения силы ньютон (международная система единиц (СИ)), в то время как программное обеспечение на Земле, которое создавало эти команды, использовало британскую единицу измерения (фунт-сила)[1].
Если не ошибаюсь, там ошиблись примерно из-за того, что "все учли": Британцы учли, что пишут для американцев, поэтому перевели числа в американские единицы измерения. А американцы учли, что для них писали британцы, и решили, что они в британских единицах.
И еще. Уже 21 век, но по-прежнему происходят косяки в ПО, из-за путаницы в кодировках текстовых файлов. И попадаются видеофайлы с неправильным aspect ratio (сплющенные).
Хоть, к статической типизации это уже не имеет отношения. Но здесь есть нерешенные проблемы. Хотя здесь последствия от багов не большие.
Здравствуйте, serg_joker, Вы писали:
_>вот ты бы хотел, чтобы условие разворачивалось в (!(s1 < s2 ) || (s1 == s2)) с удвоением сложности? _>или чтобы нужно было писать gteaterthan(s1,s2) ?
Нет. Я ведь ясно написал , я не хочу, чтобы операции сравнения стали вдвое дороже. Я хочу, чтобы они были алгебраичны. И чтобы на это мог рассчитывать в первую очередь человек, но и компилятор тоже.
Как это технически реализовать, я не знаю. Возможно, C++ way — это добавить операцию сравнения с тремя вариантами ответа (пресловутую <=>), из коториой компилятор бы вывел все остальные. Смущает в этом подходе то, что C++ старается наделить глубоким смыслом все возможные сочетания непечатных символов, напоминающих шум из модема при отсутствии error correction.
