Здравствуйте, Курилка, Вы писали:
К>Возвращаясь к исходной статье, хоть она и не очень корректна, но доля правды там есть. Так вот, там говорится, что перегрузка как раз неявными автоматическими приведениями типов и опасна, т.е. такими ситуациями, когда программист затрудняется сказать, какая именно реализация оператора/функции из энного числа имеющихся будет использована. Как раз это и показал тебе Андрей
По этому приводятся примеры осуществлющие нефвные приведения не зависимо от перегрузки?
Есть языки с хорошими соглашениями по приведению типов. В том же Шарпе значимых проблем с приведением типов при преегрузке операторов. Ну, нет и все. Любой объект приводится к сроке за счет существования у него метода ToSting, так что всегда можно сложить что-то со строкой и получить конкатинацию. Приведения типов для других классов контролируются операторами приведения типов. Так что можно реализовато любую логику. И только от программиста зависит их логичность.
Если бы эта проблема существовала бы в действительности, то на форумах то идело появлялись бы вопросы связанные с этим. А где они?
В общем, еще раз говорю. Не путайте теплое с мягким. Неявные приведения итпов и проблемы с ними связанные это одна проблема. Использование перегрузки операторов — это другая. Они никак не связаны. Точно так же можно найти фатальный недостаток в перегрузке функций, так как при их выхове тоже могут случиться неявные приведения типов.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Quintanar, Вы писали:
A>>Математические операции неприменимы. Но вроде как должна быть операция соединения. Как лучше ее обозначить... Наверное все-таки +. Q>Чем лучше-то? Тем, что когда-то кто-то не подумав стал ее для этого использовать? Конкатенация объектов есть в математике (это суперпозиция функций, например) и она обладает определенными свойствами — например, ассоциативностью, нулевым элементом.
Ну да, суперпозиция обозначается пустым кружочком. Где он на клавиатуре? Нету.
Вообще, соединение массивов не такая уж часто используемая операция, посему можно использовать символьное имя. Правда о борьбе с синтаксическим оверхедом придется забыть
Но мне интересно, какие возражения против +?
Q>Вектор — это просто одномерный массив, а по простому отображение множества {1..N} в множество некоторых элементов.
Нет. Вектор — это направленный отрезок. И уж никак не отображение {1..N} в множество некоторых элементов (чем массив является на самом деле, т.е. функция заданная таблично). Вектор не обязательно должен быть реализован на базе массива, хотя чаще всего так и делается. Доступ к координатам вектора вообще используется редко, так как для него важны именно математические операции. И мне, кстати, никогда не нравилось наименование std::vector<int>... Уж лучше бы std::array<int>.
И вообще, я же написал, что все эти перечисленные структуры в принципе (в программировании) есть ни что иное, как массивы и списки, но с различной семантикой. Если вам нужен именно массив, то и используйте массив, а не вектор.
Q> В твоем примере сразу виден порочный подход к перегрузке операторов, типичный для "свободного" С++ника.
Типа, изобличил, да?
Q>Арифметическое произведение использовано для скалярного произведения, чем сразу же нарушаются все мыслимые свойства операции *, которые мы вправе от нее ожидать.
Почему оно является арифметическим? Потому что мы к работе с числам привыкли?
Q>Использовать * для векторного произведения тоже нельзя, поскольку векторное произведение не коммутативно.
А почему она обязана быть коммутативной?
Q>Матрица — это тоже самое, что вектор, только отображение будет из {1...N}*{1...M} -> A. Q>Сумма и разность, естественно, будут работать, поскольку это группа. Но умножение не коммутативно, что легко может ввести в заблуждение.
Опять же, матрица — это не отображение. Это набор m*n элементов, как бы это сказать, в m строках и n столбцах.
То, что вы называете отображением — это двумерный массив.
Мне вот интересно, человек работает с матрицами, а запись A*B его вводит в заблуждение... Да нет этой проблемы, какое тут может быть заблуждение?
Q>Есть аналог. В частности в теории грамматик. Естественно, арифметические операции над строками смысла не имеют, поэтому не надо использовать символ арифметической операции для конкатенации строк.
Опять же, что значит арифметическая операция? И почему она обязана быть коммутативной? Или может опять запись "ad" + "bc" вводит в заблуждение? Нет, проблем с этим нет. Потому как другого смысла, кроме как конкатенации, здесь и быть не может в принципе.
Q>Нет, все это частные случаи отображений в случае теории множеств.
Это не отображения.
Q>В математике есть определенная иерархия структур типа полугруппа, группа, ассоциативная группа, полукольцо, кольцо и т.д. Все что встречается на практике неизбежно попадает под одно из определений, так что особо думать не надо.
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Therion — Via Nocturna (Part I And Part II)";
Здравствуйте, adontz, Вы писали:
A>Собственно а кто сказал, что на нём все кому не лень пишут? На Си++ пишет не так уж много людей. Вот на "Си с классами" огромное количество.
А некоторые черезчур увлекаются "шаблонным" Си++
new RSDN@Home(1.1.4, 303) << new Message(); std::head::ear << "Therion — Seawinds";
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, VladGal, Вы писали:
VG>>Здравствуйте, Курилка, Вы писали:
К>>>Здравствуйте, VladGal, Вы писали:
VG>>>>Ага, а шаблоны (templates) — LSD 25. Всё это беспочвенные теоретические рассуждения, причём автор статьи похоже не знаком с вопросом
К>>>Факты? >>>>In general, overloading means that a function name or an operator has two or more distinct meanings. >>>>When you use it, the types of its operands are used by the language to determine which meaning should apply VG>>Чем не факт?
К>И? Хочешь сказать это не верно? В чём на твой взгляд ошибка? К>Возьмём к примеру тот же "+", который тут обсуждали — существует далеко не 1 вариант оператора и выбираемый определяется типом аргументов, т.е. для int это будет просто сложение, тогда как для std::string парой ассемблерных комманд скорее всего не обойдёшься, про вектора и матрицы я молчу... К>Так где твои факты? И кто не знаком с вопросом — тут ещё можно поспорить.
adontz кажеться писал уже на этут тему вот что:
Полная чушь! Суть как раз в том, что бы применять одно и тоже понятие к разным типам.
Здравствуйте, ansi, Вы писали:
A>Здравствуйте, Трурль, Вы писали:
Т>>В математике есть строки, а операция конкатенации обычно не обозначется (реже обозначется ||).
A>Дядя Страуструп еще пока не научил Си++ перегружать операцию "" и пробел... А обозначение || для конкатенации еще хуже, чем +.
Еще один аспект унифицированной объектной модели Scala – каждая операция является отправкой сообщения, то есть, вызовом метода. Например, сложение x+y интерпретируется как x.+(y), т.е. как вызов метода + с x в качестве объекта-приемника и y в качестве аргумента метода. Эта идея, впервые реализованная в Smalltalk, адаптирована к более традиционному синтаксису Scala следующим образом. Во-первых, Scala рассматривает имена операторов как обычные идентификаторы. Точнее, идентификатор – это либо последовательность букв и цифр, начинающаяся с буквы, либо последовательность операторных символов. Таким образом, можно определять, например, методы с именами +, <= или :: Далее, Scala трактует идентификатор, находящийся между двумя выражениями, как вызов метода. Например, в листинге 1 можно было бы использовать синтаксис операторов (arg startsWith "-") как "синтаксический сахар" для более традиционного синтаксиса (arg.startsWith("-")).
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladGal, Вы писали:
VG>adontz кажеться писал уже на этут тему вот что: VG>
VG>Полная чушь! Суть как раз в том, что бы применять одно и тоже понятие к разным типам.
VG>Присоединяюсь.
Т.е. фактов, кроме сказанного adontz нет? Замечательно
Тут (чтот не могу найти) указали, что больное место перегрузки — ну ни разу не обязательно оно одно и тоже понятие! То, что оно выглядит как "+", допустим, не гарантирует то, что оно не будет жёсткий диск форматировать. Конечно это ответственность программиста написавшего код, чтобы он (код) делал то, что записано. Но с неявными преобразованиями не всегда простым образом можно определить какой вариант будет предпочтён и что получится как результат 1 + "2" — 3 или "12".
Здравствуйте, Курилка, Вы писали:
К>Т.е. фактов, кроме сказанного adontz нет? Замечательно
Факт есть очень простой. Перегруженный оператор влияет не на конкретный класс, а на систему в целом. О того, что где-то перегрузили оператор в совсем другом месте может изменится поведения. Поэтому подходить к перегрузке надо ответсвенно. Это мощный, но вместе с тем сложный инструмент.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Курилка, Вы писали:
К>>Т.е. фактов, кроме сказанного adontz нет? Замечательно
A>Факт есть очень простой. Перегруженный оператор влияет не на конкретный класс, а на систему в целом. О того, что где-то перегрузили оператор в совсем другом месте может изменится поведения. Поэтому подходить к перегрузке надо ответсвенно. Это мощный, но вместе с тем сложный инструмент.
Не спорю, так и есть. Автор статьи как раз и писал (на мой взгляд), что не оглядываясь на последствия можно получить неожиданные (плачевные) сюрпризы. И по-твоему из этого VladGal имел право обвинить автора в незнании предмета?
На мой взгляд автор той статьи просто слишком сгущает краски — в плюсах много "опасных" мест, но никто же не перестаёт только из-за наличия грабель, которые умеешь обходить, на нём программировать?
P.S. хотя перестают (вспоминая про Vlad2 ), но всёж понимают что и на плюсах при соотв. оглядке вполне получается нормальный код.
Здравствуйте, Курилка, Вы писали:
К>Здравствуйте, VladD2, Вы писали:
VD>>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>>Демонстрация потенциального источника ошибок. Как и C с адресной арифметикой. Этот аргумент тебе знаком?
VD>>Ты путашь мякое с теплым. Ты продемонстрировал некотороую опасность автоматического приведения типов. И к оператору сложения строк это отношения не имеет. Так что твое подмигивание больше похоже на нервный тик.
К>Возвращаясь к исходной статье, хоть она и не очень корректна, но доля правды там есть. Так вот, там говорится, что перегрузка как раз неявными автоматическими приведениями типов и опасна, т.е. такими ситуациями, когда программист затрудняется сказать, какая именно реализация оператора/функции из энного числа имеющихся будет использована. Как раз это и показал тебе Андрей
Неявные преобразования типов относятся к характеристикам языков со слабой типизацией (weakly typed languages). Но, в реальности, ни один практичный язык не может быть на 100% сильно типизированным, поэтому такие маленькие отступления допустимы. Язык становится слаботипизированным, когда отклонения от правил типизации имеют глобальный характер, как в случае с указателями для C.
Но такие вещи, как волшебный оператор сложения строк и автоматическое преобразование типов, не добавляет красоты и стройности языку. Намного лучше, когда все подчиняется одному своду правил. Например, есть коллекции с оператором конкатенации (, & ++ — что угодно уникальное), а строка, как частный случай коллекции наследует этот оператор.
Здравствуйте, Курилка, Вы писали:
К>Не спорю, так и есть. Автор статьи как раз и писал (на мой взгляд), что не оглядываясь на последствия можно получить неожиданные (плачевные) сюрпризы. И по-твоему из этого VladGal имел право обвинить автора в незнании предмета?
Боюсь, что автор всё таки не знает предмета либо наталкивался на неуправляемых идиотов.
Unfortunately, given this new toy, programmers can seldom resist overusing it. The result is that all sorts of fundamentally different meanings get overloaded on the same name or operator.
К сожалению, получив новую игрушку, программисты редко могут удержатся от её черезмерного использования. Результатом является то, что все виды фундаментально различных понятий перегруженны под одним и тем же именем или оператором.
Диагноз из психбольницы какой-то Так и представляю себе программиста перегружающего + для сортировки. Эдакое
Здравствуйте, _vovin, Вы писали:
_>Неявные преобразования типов относятся к характеристикам языков со слабой типизацией (weakly typed languages). Но, в реальности, ни один практичный язык не может быть на 100% сильно типизированным, поэтому такие маленькие отступления допустимы.
Как это не может? Еще как может.
>Язык становится слаботипизированным, когда отклонения от правил типизации имеют глобальный характер, как в случае с указателями для C. _>Но такие вещи, как волшебный оператор сложения строк и автоматическое преобразование типов, не добавляет красоты и стройности языку. Намного лучше, когда все подчиняется одному своду правил. Например, есть коллекции с оператором конкатенации (, & ++ — что угодно уникальное), а строка, как частный случай коллекции наследует этот оператор.
Я уже писал, что кое-где так и сделано ввиде Классов Типов. Т.е. нельзя реализовать + не реализовав — и нельзя реализовать + от аргументов разных типов.
Здравствуйте, Quintanar, Вы писали:
Q>Как это не может? Еще как может.
Например какой язык строго типизированн и при этом более-менее широко применяется?
Q>Я уже писал, что кое-где так и сделано ввиде Классов Типов. Т.е. нельзя реализовать + не реализовав — и нельзя реализовать + от аргументов разных типов.
Вот то что нельзя, например, реализовать плюс от аргументов разных типов или плюс без минуса это очень плохо. Например у строки есть оператор += , но операции -= нету. У вектораров очевидно есть умножение (даже два), но нет ни одного деления. К строке я могу захотеть добавить символ, а к переменной типа int — тип short. Или даже к своему классу чисел повышенной точности int.
В результате, как я уже и говорил, любые формальные ограничения на перегрузку не могут выразить мысли, идеи программиста и в конечном итоге будут только мешать, а не помогать, останутся невостребованными. В конце концов академические примеры надуманных ошибок и мощные средства борьбы с надуманными ошибками от практики программирования весьма далеки.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Шахтер, Вы писали:
Q>>>>>Конструктор может позволить себе не заниматься такими мелочами, а сконцентрироваться на машине в целом. Ш>>>>Неверно. Нет такой вещи -- машина в целом. Это только на картинке у художника так бывает. В инженерии целое есть сумма составных частей и качество этого целого определяется качеством каждого элемента, даже самого маленького. A>>>Угу. И для каждого нового автомобиля заново придумывают болты и гайки? Гы-гы. Ш>>Автомобили бывают разные. Очень разные. Ш>>И болты и гайки тоже, между прочим.
A>Вот в том-то всё и дело, что очень разные автомобили собираются из одинаковых болтов и шает. К твоему сведенью, кроме формы корпуса и внутренней отделки ничего особо уникального в автомобилях нету — двигатель, тормоза, аммортизаторы, колёса можно увидеть и на других моделях.
Двигатель у камаза и у жигулей один и тот же? А колёса?
И тормоза одинаковые?
Здравствуйте, Курилка, Вы писали:
К>Т.е. фактов, кроме сказанного adontz нет? Замечательно К>Тут (чтот не могу найти) указали, что больное место перегрузки — ну ни разу не обязательно оно одно и тоже понятие! То, что оно выглядит как "+", допустим, не гарантирует то, что оно не будет жёсткий диск форматировать.
Странная логика. А что, из за того что можно сделать метод Add, который на самом деле удаляет из коллекции, нужно объявить методы героином? В чем, в этом отношении, разница между операторами и методами?
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Курилка, Вы писали:
К>>Т.е. фактов, кроме сказанного adontz нет? Замечательно К>>Тут (чтот не могу найти) указали, что больное место перегрузки — ну ни разу не обязательно оно одно и тоже понятие! То, что оно выглядит как "+", допустим, не гарантирует то, что оно не будет жёсткий диск форматировать.
AVK>Странная логика. А что, из за того что можно сделать метод Add, который на самом деле удаляет из коллекции, нужно объявить методы героином? В чем, в этом отношении, разница между операторами и методами?
Дак я не говорю же, что логика верная и у меня претензий к ней нет, наоборот — программер должен отвечать за свои действия, не будет же компьютер выполнять все действия за него?
Но почему из вот такой странной логики следует делать вывод что автор не разбирается в предмете — я не понял...
И разницу между операторами и методами откуда ты взял, осталось загадкой, "+" был выбран лишь как пример, не более.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Quintanar, Вы писали:
Q>>Как это не может? Еще как может.
A>Например какой язык строго типизированн и при этом более-менее широко применяется?
Q>>Я уже писал, что кое-где так и сделано ввиде Классов Типов. Т.е. нельзя реализовать + не реализовав — и нельзя реализовать + от аргументов разных типов.
A>Вот то что нельзя, например, реализовать плюс от аргументов разных типов или плюс без минуса это очень плохо. Например у строки есть оператор += , но операции -= нету. У вектораров очевидно есть умножение (даже два), но нет ни одного деления. К строке я могу захотеть добавить символ, а к переменной типа int — тип short. Или даже к своему классу чисел повышенной точности int.
Тут у тебя все намешано в кучу, если разложить по полочкам, проблема исчезает.
Во первых, сложение строк это операция конкатенации коллекций, а не арифмитическое сложение.
Соответственно, можно ввести операторы ++ и ++= для которых семантически никаких вычитаний по определению не требуется.
Далее, умножение векторов два рода: * и dotProduct. Для первого очень успешно опрелеляется /, для второго его нет по определению.
Добавление символа к строке это ни арифметическое сложение, ни конкатенация коллекций, а просто add элемента в коллекцию.
Сложение чисел отлично ложится на операцию + (Number, Number). Для частных случаев может быть создана специализация (например + (int, int)), для остальных — двойная диспетчеризация с последующим приведением чисел к одному вышестоящему общему типу.
A>В результате, как я уже и говорил, любые формальные ограничения на перегрузку не могут выразить мысли, идеи программиста и в конечном итоге будут только мешать, а не помогать, останутся невостребованными. В конце концов академические примеры надуманных ошибок и мощные средства борьбы с надуманными ошибками от практики программирования весьма далеки.
Формальные ограничения не нужны, но всегда нужно стремиться построить непротиворечивую модель операций и операторов, которая вести себя единообразно на всей системе.
Любой объект приводится к сроке за счет существования у него метода ToSting, так что всегда можно сложить что-то со строкой и получить конкатинацию. Приведения типов для других классов контролируются операторами приведения типов. Так что можно реализовато любую логику. И только от программиста зависит их логичность.
