Здравствуйте, adontz, Вы писали:
A>Полная чушь! Суть как раз в том, что бы применять одно и тоже понятие к разным типам.
>>>Overloading function names saves time during writing by saving keystrokes and, more significantly, saves the mental effort of thinking up unique names.
A>Ещё раз убеждаемся, что автор понятия не имеет, зачем нужна перегрузка операторов.
A>Дальше даже читать не интересно. Видно, что автор не разбирается в вопросе
Не стоит брызгать слюной, поскольку критика справедлива. С++ вариант перегрузки не накладывает никаких ограничений _вообще_. Т.е. перегруженный оператор может делать, буквально, что угодно, и о никакой "общности понятий" речь идти не может. Но есть и другие подходы к перегрузке, которые реализованы, например, в языке Haskell. Там мы не сможем нарушить некоторые аксиомы связанные с перегружаемой функцией или операцией и поэтому + всегда будет вести себя как + — т.е. мы не сможем перегрузить его для каких-то противоестественных целей.
Не соглашусь. В данном конкретном случае есть некоторое удобство, однако в целом, это поощряет использование перегрузки для всего, что угодно, без всякой привязки к смыслу. Мне больше импонирует Haskell'овский подход. Там можно наложить ограничения на перегрузку для того, чтобы перегружаемые функции или операнды вели себя более предсказуемо.
Здравствуйте, adontz, Вы писали:
ANS>>И вообще, нечего тут сокращать, ибо для конкатенации множества строк всё равно прийдётся StringBuilder создавать.
A>Для того чтобы конкатекация была эффективной? Вовсе нет StringBuilder это излишество вызванное как раз неиспользованием перегрузки операторов.
Сомневаюсь, что даже использование перегрузки операторов поможет избавиться от этого излишиства.
Здравствуйте, Кодёнок, Вы писали:
Кё>Есть еще cons. Это почти то же, но образуется всегда список-пара: Кё>1 :: 2 = (1 2) Кё>(1 2) :: 3 = ((1 2) 3) Кё>(1 2) :: (3 4) = ((1 2) (3 4))
Интересный какой cons. А что это за язык? И возможна ли в нём не-двоичная нотация списков, типа такого: (1 2 3)?
C>Да всё понятно. Но таки конкатенация — никаким боком не сложение, даже в программировании. И, на мой взгляд, это неправильно, когда в стандартной библиотеке (хорошо, что не в самом языке) для строк применяется оператор+. Если нет более подходящего, тогда уж лучше функции concat или strcat. Ведь никто не будет с аналогичной целью вводить + для векторов?
Не сложение, конечно, если строго говорить. Но вот в сознании программиста -- вполне естественно "складывать" строки, не коряво звучит. Привычка?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
A>>Для того чтобы конкатекация была эффективной? Вовсе нет StringBuilder это излишество вызванное как раз неиспользованием перегрузки операторов. ANS>Сомневаюсь, что даже использование перегрузки операторов поможет избавиться от этого излишиства.
Сомневаться не надо, я сам написал строковый класс на C++, который кроме всего прочьего оптимизировал конкатекацию без вмешательсва программиста.
Здравствуйте, opossum, Вы писали:
O>В приводимой статье вообще нет слова dispatch, а есть Heroin и drug, O>что выдает ее явно популистско-провокационный характер.
Здравствуйте, Quintanar, Вы писали:
A>>Дальше даже читать не интересно. Видно, что автор не разбирается в вопросе Q>Не стоит брызгать слюной, поскольку критика справедлива. С++ вариант перегрузки не накладывает никаких ограничений _вообще_. Т.е. перегруженный оператор может делать, буквально, что угодно, и о никакой "общности понятий" речь идти не может.
А Си++ вообще довольно много свободы даёт и требует мозгов чтобы этой свободой надлежащим образом распорядится. Например та же адресная арифметика. Кому эта свобода бьёт в голову, те на Си++ не пишите. Кто же заставляет?
Почему-то мне не приходит в голову сопоставлять перегруженным операторам неочевидные понятия. Кому приходит, то и виноват!
Тут есть два выхода: не писать на C# или научится правильно пользоваться перегрузкой. Кого на что хватает тот такой путь и выбирает
Здравствуйте, Nose, Вы писали:
N>Здравствуйте, cranky, Вы писали:
C>>Да всё понятно. Но таки конкатенация — никаким боком не сложение, даже в программировании. И, на мой взгляд, это неправильно, когда в стандартной библиотеке (хорошо, что не в самом языке) для строк применяется оператор+. Если нет более подходящего, тогда уж лучше функции concat или strcat. Ведь никто не будет с аналогичной целью вводить + для векторов?
N>Не сложение, конечно, если строго говорить. Но вот в сознании программиста -- вполне естественно "складывать" строки, не коряво звучит. Привычка?
Наверно. N>Кроме того, типичное применение (псевдокод) :
strcat("Error",toString(errNum)," while proc....",toString(objNum))
И ничем не хуже плюсов, и для плюсов вполне реально сделать.
N>Идеологически правильный вариант грозит нечитаемым кодом...
N>П.С. так и тянуло сказать "оверхед"
Здравствуйте, adontz, Вы писали:
A>А Си++ вообще довольно много свободы даёт и требует мозгов чтобы этой свободой надлежащим образом распорядится. Например та же адресная арифметика. Кому эта свобода бьёт в голову, те на Си++ не пишите. Кто же заставляет? A>Почему-то мне не приходит в голову сопоставлять перегруженным операторам неочевидные понятия. Кому приходит, то и виноват! A>Тут есть два выхода: не писать на C# или научится правильно пользоваться перегрузкой. Кого на что хватает тот такой путь и выбирает
Ну все, пошла обычная песня. Любители С++ уперлись в некую мнимую свободу С++ и в упор не видят, что есть и другие виды свободы. Например, свобода не думать об управлении памятью, свобода не думать, что означает данная закорючка в данном контексте, свобода не разбирать километровые объявления шаблонных типов и т.д. Полную свободу предоставляет, кстати, не С++, а С — на нем можно реализовать все, что угодно, без нелепых ограничений С++.
Что вам приходит в голову, ведомо только вам одному. То, что вы считаете логичным и понятным, может оказаться совершенно нелогичным и непонятным для других.
Здравствуйте, Oyster, Вы писали:
O>Как вариант... но StringBuilder всё равно выходит функциональнее и [немного] эффективнее (надо же в таком случае внутри хранить некий список конкатенируемых строк, даже скорее дерево, — накладные расходы на это). O>А вообще идея хорошая
На самом деле если не мучать себя реализацией, то можно сделать так
string a = b + c + d + e;
оптимизируется
string a;
for (...)
{
a += "abcd";
}
не оптимизируется
string_result b;
for (...)
{
b += "abcd";
}
string a = b;
оптимизируется.
string_result это просто vector< some_smart_ptr<string> >
Всё это делается очень на основе очень простой идеи
Именно string_builder с явным методом add не нужен, а сам класс строки не перегружен лишними вещами. Я именно на такой реализации и остановился.
С другой стороны как продолжение идеи конечно неплохо было бы кое что перенести в compile time, но на фоне копирования строк это копейки.
N>вместо 3-х знаков "+"... не страшно? N>Идеологически правильный вариант грозит нечитаемым кодом...
Идеологически правильный вариант — выбрать другое обозначение для операции конкатенации. Ибо конкатенация по сути — это слияние списков, а не сложение.
Quintanar,
> Полную свободу предоставляет, кстати, не С++, а С — на нем можно реализовать все, что угодно, без нелепых ограничений С++.
Это шутка? Если нет, можно конкретный пример того, что реализуемо на C, но не реализуемо на C++? Т.к. обратные примеры можно привести легко (начиная со статического полиморфизма и возможности вычислений на этапе компиляции).
Posted via RSDN NNTP Server 2.0 beta
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, cranky, Вы писали:
C>Надо придумать, чтобы было так:
strcat("Error",toString(errNum)," while proc....",toString(objNum))
И ничем не хуже плюсов, и для плюсов вполне реально сделать.
Для плюсов тогда будет функция с переменным числом параметров. Операторы хотя бы безопасно можно сделать, а тут...
Или написать 30 прототипов?
не знаю, по-моему ничего страшного с "+", к тому же уже привычное старое решение...
Никаких глюков, напрягов и пр. от него не знаю -- не встречался.
Читаемо, удобно и стандартно.
А теоретизирование насчет идеологии ни к чему не ведет.
N>>вместо 3-х знаков "+"... не страшно? N>>Идеологически правильный вариант грозит нечитаемым кодом...
Q>Идеологически правильный вариант — выбрать другое обозначение для операции конкатенации. Ибо конкатенация по сути — это слияние списков, а не сложение.
Ну это совсем идеалистический вариант — представление строки списком, всё-таки нечто с рандомным доступом подошло бы лучше.
Здравствуйте, Quintanar, Вы писали:
Q>Ну все, пошла обычная песня. Любители С++ уперлись в некую мнимую свободу С++ и в упор не видят, что есть и другие виды свободы. Например, свобода не думать об управлении памятью, свобода не думать, что означает данная закорючка в данном контексте, свобода не разбирать километровые объявления шаблонных типов и т.д.
Ага. Свобода не ходить на выборы, свобода когда только один сорт кофе, свобода не думать короче. Это не свобода. Это Богом данное право не напрягать свой мозг. К свободе оно отношения не имеет, оно имеет отношение к лени, экономии времени, низкой квалификации, но никак не к свободе.
Q>Что вам приходит в голову, ведомо только вам одному.
Нет. У меня есть образование. Например по формуле F = am я понимаю, что сила равная произведению ускорения на массу. Человек вроде вас боится, что за формулой F = am может скрываться, что мощность равная силе тока умноженной на напряжение, но увы любой кто не с Луны свалился и не ставит себе целью выпендриться такими обозначениями пользоваться не станет.
Вам мешает перегрузка? Не пользуйтесь! Но зачем хаять тех кто умеет пользоватся и делает это?
Давайте тогда хаять систему распределения памяти в Си++! Конечно! Какой-то дурак не знал что такое вектор, сделал new MyClass[38] и не сделал delete[]. Чем не повод? Система распределения памяти в Си++ полный отстой! Она не накладывает ограничений! Какие там ещё могут быть лозунги? А ну да! Все переходим на .Net!
Множественно наследование? О ужас! Заставлять человека писать или не писать virtual при наследовании. Какое напряжение мозга! Отменим multiple inheritance! В Хаскеле оно есть? Если нету, то я раз за этот язык — он полон ограничений усиливающих свободу не думать.
Короче хватит Думаешь, что ты умее тех кто, например, разрабатывает Си++? Си++ не сразу стал таким, какой он есть. 90% того что в нём реализовано добавили при утверждении очередного стандарта и не от нечего делать, а потому что в этом была необходимость. В Object Pascal'е который был с TurboPascal перегрузки операторов не было, в Delphi добавили. Думаешь зависть к Си++? Нет! Насущная необходимость!
Так что перегрузка операторов нужна.
Стоит ли её ограничивать? Нет, не стоит! Никакое формальное ограничение не выразит человеческую мысль. В результате будь такое ограничение введённым в современный промышленный язык им бы всё равно никто не стал пользоваться. Да, да, современный промышленный язык, на котором пишут сложные системы, а не богом забытый на котором пишут одни энтузиасты.
Здравствуйте, Nose, Вы писали:
N>Здравствуйте, cranky, Вы писали:
C>>Надо придумать, чтобы было так:
strcat("Error",toString(errNum)," while proc....",toString(objNum))
И ничем не хуже плюсов, и для плюсов вполне реально сделать.
N>Для плюсов тогда будет функция с переменным числом параметров. Операторы хотя бы безопасно можно сделать, а тут... N>Или написать 30 прототипов?
Хм, вроде что-то у Александреску было насчёт списка типов. Может подойдёт для объявления функций с произвольным числом параметров?
N>не знаю, по-моему ничего страшного с "+", к тому же уже привычное старое решение... N>Никаких глюков, напрягов и пр. от него не знаю -- не встречался.
Также как и некоторые не встречались с memory leak. N>Читаемо, удобно и стандартно.
Стандартно, конечно, только это единичный случай неправильного использования перегрузки и вообще, исключение из правил. N>А теоретизирование насчет идеологии ни к чему не ведет.
Здравствуйте, cranky, Вы писали:
Q>>Идеологически правильный вариант — выбрать другое обозначение для операции конкатенации. Ибо конкатенация по сути — это слияние списков, а не сложение.
C> Ну это совсем идеалистический вариант — представление строки списком, всё-таки нечто с рандомным доступом подошло бы лучше.
Это не совсем идеалистический вариант, кое-где так и сделано. Кроме того, никто не говорит о том, что обязательно нужно представлять строку списком, речь идет о том, что конкатенация по сути — это слияние списков, а не арифметическре сложение, и логично для этого использовать другое обозначение.
Здравствуйте, adontz, Вы писали:
A>Ага. Свобода не ходить на выборы, свобода когда только один сорт кофе, свобода не думать короче. Это не свобода. Это Богом данное право не напрягать свой мозг. К свободе оно отношения не имеет, оно имеет отношение к лени, экономии времени, низкой квалификации, но никак не к свободе.
Бла-бла-бла. Один кофе только у любителей С++. Другие выбирают между разными языками и смотрят как реализованы идеи там.
A>Нет. У меня есть образование. Например по формуле F = am я понимаю, что сила равная произведению ускорения на массу. Человек вроде вас боится, что за формулой F = am может скрываться, что мощность равная силе тока умноженной на напряжение, но увы любой кто не с Луны свалился и не ставит себе целью выпендриться такими обозначениями пользоваться не станет.
Да ну. Как раз наоборот, вы застряли на уровне ньютоновской механики, в то время как давно уже открыта теория относительности. Можно,конечно, пытаться адаптировать устаревшую теорию к новым знаниям, но стоит ли. Это ведет только к лишним усложнениям когда-то стройной системы.
A>Вам мешает перегрузка? Не пользуйтесь! Но зачем хаять тех кто умеет пользоватся и делает это? A>Давайте тогда хаять систему распределения памяти в Си++! Конечно! Какой-то дурак не знал что такое вектор, сделал new MyClass[38] и не сделал delete[]. Чем не повод? Система распределения памяти в Си++ полный отстой! Она не накладывает ограничений! Какие там ещё могут быть лозунги? А ну да! Все переходим на .Net!
Да не отстой, поскольку ее фактически нет и каждый вправе сделать свою, но и смысла для 98% задач в ней мало. Для любой программы, где производительность не стоит на не просто 1-м, а 1-м в квадрате месте, GC будет справляться неплохо.
A>Множественно наследование? О ужас! Заставлять человека писать или не писать virtual при наследовании. Какое напряжение мозга! Отменим multiple inheritance! В Хаскеле оно есть? Если нету, то я раз за этот язык — он полон ограничений усиливающих свободу не думать.
Вопреки сложившемуся мнению, программы можно писать вообще без ООП, хотя это, конечно, требует несколько большего интеллекта.
A>Короче хватит Думаешь, что ты умее тех кто, например, разрабатывает Си++? Си++ не сразу стал таким, какой он есть. 90% того что в нём реализовано добавили при утверждении очередного стандарта и не от нечего делать, а потому что в этом была необходимость. В Object Pascal'е который был с TurboPascal перегрузки операторов не было, в Delphi добавили. Думаешь зависть к Си++? Нет! Насущная необходимость!
Object Pascal намного хуже С++, о нем речи вообще быть не может.
A>Так что перегрузка операторов нужна. A>Стоит ли её ограничивать? Нет, не стоит! Никакое формальное ограничение не выразит человеческую мысль. В результате будь такое ограничение введённым в современный промышленный язык им бы всё равно никто не стал пользоваться. Да, да, современный промышленный язык, на котором пишут сложные системы, а не богом забытый на котором пишут одни энтузиасты.
Странно слышать это от сторонника языка, где нельзя даже создать новый оператор. С++ учиться и учиться гибкости у того же Lisp'a.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
>>>>Overloading function names saves time during writing by saving keystrokes and, more significantly, saves the mental effort of thinking up unique names. A>>Мда, а автор похоже сам сидит на героине! Оказывается перегрузка операторов нужна, чтобы экономить 2 символа и писать + вместо add ANS>Эта. А для чего еще она нужна?
Как минимум, она позволяет писать обобщённые конструкции, которые оперируют семантикой перекрываемых операторов. Нпаример, в STL часто пользуются перекрытием operator() для подмены функции функтором. Другой пример, перекрытие operator->() для smart-указателей.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
StringBuilder это излишество вызванное как раз неиспользованием перегрузки операторов.
Ну это совсем идеалистический вариант — представление строки списком, всё-таки нечто с рандомным доступом подошло бы лучше.
