Здравствуйте, Marty, Вы писали:
M>Здравствуйте! M>Обнаружил, что таких операторов в плюсах нет M>Интересно, а с чего?
Ну, наверное потому, что у всех булевских операторов типы операндов могут быть очень многообразны, а тип результата всегда строго bool. Ну, например, каким должен быть результат оператора &&= для двух операндов типа int? Вот чтобы избежать всяких подобных вопросов, эти операторы и не стали вводить.
А ещё нет булевского XOR. Наверное потому, что для операндов булевского типа его результат всегда совпадает с результатом оператора !=, а для операндов других типов опять возникают всякие неудобные вопросики.
--
Справедливость выше закона. А человечность выше справедливости.
R>А ещё нет булевского XOR. Наверное потому, что для операндов булевского типа его результат всегда совпадает с результатом оператора !=, а для операндов других типов опять возникают всякие неудобные вопросики.
Да, тут у меня тоже возник вопрос — битовый XOR по приоритету между OR и AND, а логический XOR, который не равно, имеет приоритет выше AND
Здравствуйте, rg45, Вы писали:
R>Ну, наверное потому, что у всех булевских операторов типы операндов могут быть очень многообразны, а тип результата всегда строго bool. Ну, например, каким должен быть результат оператора &&= для двух операндов типа int? Вот чтобы избежать всяких подобных вопросов, эти операторы и не стали вводить.
Кстати, а почему ты считаешь, что результат должен быть строго типа bool? Для || и && такого требования нет
1 The && operator groups left-to-right. The operands are both contextually converted to bool ([conv]). The result is true if both operands are true and false otherwise. Unlike &, && guarantees left-to-right evaluation: the second operand is not evaluated if the first operand is false.
2 The result is a bool. If the second expression is evaluated, the first expression is sequenced before the second expression ([intro.execution]).
1 The || operator groups left-to-right. The operands are both contextually converted to bool ([conv]). The result is true if either of its operands is true, and false otherwise. Unlike |, || guarantees left-to-right evaluation; moreover, the second operand is not evaluated if the first operand evaluates to true.
2 The result is a bool. If the second expression is evaluated, the first expression is sequenced before the second expression ([intro.execution]).
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, rg45, Вы писали:
R>Ну, наверное потому, что у всех булевских операторов типы операндов могут быть очень многообразны, а тип результата всегда строго bool. Ну, например, каким должен быть результат оператора &&= для двух операндов типа int? Вот чтобы избежать всяких подобных вопросов, эти операторы и не стали вводить.
Таким же, как a = a && b; Со всем связанным с этим комплексом неудобных вопросов.
Но судя по тому, что Марти обнаружил отсутствие операторов &&= и ||= где-то, насколько я понимаю, примерно на сороковом году жизни, наверное они и вправду бывают нечасто нужны.
Здравствуйте, Marty, Вы писали:
M>Да, тут у меня тоже возник вопрос — битовый XOR по приоритету между OR и AND, а логический XOR, который не равно, имеет приоритет выше AND
Более смешно то, что в разных языках, произошедших от Си, по-разному расставлены приоритеты похожих операций.
Здравствуйте, Pzz, Вы писали:
Pzz>Таким же, как a = a && b; Со всем связанным с этим комплексом неудобных вопросов.
Pzz>Но судя по тому, что Марти обнаружил отсутствие операторов &&= и ||= где-то, насколько я понимаю, примерно на сороковом году жизни, наверное они и вправду бывают нечасто нужны.
Ну да, непротиворечивые правила можно было бы придумать. Тем не менее, всё равно существовала бы другая чаша весов, на которой находился бы принцип наименьшего удивления. И эта другая чаша оказывается несколько тяжелее, чем в случае других операторов.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Marty, Вы писали:
M>>Обнаружил, что таких операторов в плюсах нет
M>>Интересно, а с чего?
Pzz>Сколько ты перед тем написал плюсового кода, не зная, что таких операторов в плюсах нет? Наверное, их нет потому, что они не слишком нужны.
Здравствуйте, rg45, Вы писали:
Pzz>>Но судя по тому, что Марти обнаружил отсутствие операторов &&= и ||= где-то, насколько я понимаю, примерно на сороковом году жизни, наверное они и вправду бывают нечасто нужны.
R>Ну да, непротиворечивые правила можно было бы придумать. Тем не менее, всё равно существовала бы другая чаша весов, на которой находился бы принцип наименьшего удивления.
Мне нравится подход Go. Там нет автоматического приведения целочисленных типов.
Даже вот такая конструкция:
type int Oranges
type int Apples
type int Fruits
var o Oranges
var a Apples
var f Ftuits
f = o + a
Вызовет ошибку времени компиляции при попытке сложить яблоки с апельсинами без явного приведения типов.
Хотя все три типа определены через int, это три разных типа (но приводимых друг к другу).
Pzz>type int Oranges
Pzz>type int Apples
Pzz>type int Fruits
Pzz>var o Oranges
Pzz>var a Apples
Pzz>var f Ftuits
Pzz>f = o + a
Pzz>
Pzz>Вызовет ошибку времени компиляции при попытке сложить яблоки с апельсинами без явного приведения типов.
Ну тут палка о двух концах. Ровно с тем же успехом она не позволит выполнить и вполне осмысленное действие, например, разделить километры на часы. В С++, конечно, приходится делать больше телодвижений, но полнота контроля получается больше. А тут получается по принципу: "делай, что тебе говорят и будь счастлив".
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, Нomunculus, Вы писали:
Pzz>>Сколько ты перед тем написал плюсового кода, не зная, что таких операторов в плюсах нет? Наверное, их нет потому, что они не слишком нужны.
Н>Зато есть офигеть какой нужный spaceship — <=>
Пипец какой. Я не знал.
В принципе, идею понять можно.
if (a < b)
return -1;
if (a > b)
return 1;
returm 0;
Выглядит как-то несимметрично. И такое сравнение с тремя вариантами ответов — это одна ассемблерная команда для целочисленных типов (и еще одна-две, чтобы нормализовать результат). И такое сравнение очень часто встречается.
Но заводить для него еще один мутный оператор...
А почему нет оператора, который возвращает за раз частное и остаток от деления? Тоже тот случай, когда результат даёт одна ассемблерная команда, а по-сишному надо писать две строки (которые развернутся в две одинаковые команды, если компилятор достаточно наивен).
Здравствуйте, rg45, Вы писали:
Pzz>>Вызовет ошибку времени компиляции при попытке сложить яблоки с апельсинами без явного приведения типов.
R>Ну тут палка о двух концах. Ровно с тем же успехом она не позволит выполнить и вполне осмысленное действие, например, разделить километры на часы. В С++, конечно, приходится делать больше телодвижений, но полнота контроля получается больше. А тут получается по принципу: "делай, что тебе говорят и будь счастлив".
Можно явно привести.
Альфа бы, конечно, сказал, что он умный и никогда не будет складывать яблоки с апельсинами, и ему лишний контроль не нужен.
Но бывает так, что работаешь, например, со сложной иерархией структур, и в них есть битовые поля, и в разных структурах они разные (с разным назначением битов). Ну, к примеру, иерархия дескрипторов USB. В Configuration Descriptor у поля bMAttributes свои биты, в Endpoint Descriptor — свои, а поля одинаково называются. Немудрено и напутать.
А если обозвать их разными типами, то (1) не перепутаешь (2) не надо даже как-то в комментариях особо выделять, какие биты к чему относятся, это выражено в самом коде.
Но так да. Если делишь километры на часы, придется сказать компилятору, что ты понимаешь, что делаешь.
Здравствуйте, Pzz, Вы писали:
Pzz>Можно явно привести.
Ну вот этого как раз и не хотелось бы. Это примерно то же самое, как при работе с типизированными указателями на каждый чих приходилось бы приводить их к void*.
Pzz>Альфа бы, конечно, сказал, что он умный и никогда не будет складывать яблоки с апельсинами, и ему лишний контроль не нужен.
Pzz>Но бывает так, что работаешь, например, со сложной иерархией структур, и в них есть битовые поля, и в разных структурах они разные (с разным назначением битов). Ну, к примеру, иерархия дескрипторов USB. В Configuration Descriptor у поля bMAttributes свои биты, в Endpoint Descriptor — свои, а поля одинаково называются. Немудрено и напутать.
Pzz>А если обозвать их разными типами, то (1) не перепутаешь (2) не надо даже как-то в комментариях особо выделять, какие биты к чему относятся, это выражено в самом коде.
Ну это понятно. Это старый добрый паттерн Strong Typedef, полезность которого не вызывает вопросов. Некоторый дискомфорт всё же возникает по поводу того, что этот паттерн гвоздями прибит к языку. Возможно, это просто с непривычки.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, rg45, Вы писали:
Pzz>>Можно явно привести.
R>Ну вот этого как раз и не хотелось бы. Это примерно то же самое, как при работе с типизированными указателями на каждый чих приходилось бы приводить их к void*.
Ну, через void* можно что угодно к чему угодно привести, без какого-либо контроля.
В данном случае компилятор всё же не даст сделать какую-то полную дичь. Например, сравнить число со строкой.
R>Ну это понятно. Это старый добрый паттерн Strong Typedef, полезность которого не вызывает вопросов. Некоторый дискомфорт всё же возникает по поводу того, что этот паттерн гвоздями прибит к языку. Возможно, это просто с непривычки.
Не раздражает. В рееальном коде редко встречается.
Здравствуйте, Pzz, Вы писали:
R>>Ну вот этого как раз и не хотелось бы. Это примерно то же самое, как при работе с типизированными указателями на каждый чих приходилось бы приводить их к void*.
Pzz>Ну, через void* можно что угодно к чему угодно привести, без какого-либо контроля.
Ну так вот именно. В т.ч. и сложить яблоки с апельсинами. Почему я и говорю, что не хотелось бы, чтоб это становилось обычным паттерном проектирования/кодирования. Когда подобные приведения размазаны толстым слоем по всему коду, не заметить бессмысленное действие — как два пальца об асфальт. Сам паттерн Strong Typedef обесценивается при этом.
--
Справедливость выше закона. А человечность выше справедливости.
А зачем здесь еще и `operator==` как default?
Вроде бы если мы декларируем `operator<=>` как default, то и операторы равенства/неравенства автоматически выводятся.
