Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Курилка, Вы писали:
К>>+ К>>Как сказал Хоар: Premature optimization is the root of all evil.
A>-1 за знание предмета.
A>Во-первых, это сказал Робет Флойд. Во-вторых это толкьо часть цитаты. А вот полностью A>"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." A>его высказывание имеет совсем другой смысл.
Какой?
Здравствуйте, adontz, Вы писали:
O>>>>??? Оно преобразуется в System.String.Concat(a, b, c, d) , так что непонятно, о чём вы. A>>>Да ну? Я между прочим не наобум сказал, а сгенерированный код поглядел O>>Код:
A>ОК, может быть для .Net я погорячился. Но в Си++ таких оптимизаций точно нет
Ваш с Владом диалог:
VD>Я тебе уже третий раз повторяю, что в Шапре подобный код выливается в вызов функции string.Concat(). А эффективнее нее уже ничего не найти.
Влад, учи матчасть a.Concat(b.Concat(c.Concat(d))) это мягко говоря не самый эффективный код.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Курилка, Вы писали:
К>>Не уместная ирония на мой взгляд
A>Я и на Си++ пишу и шаблоны использую. Ну и? К чему была фраза "Если для Вас в программировании есть только ООП языки и ассемблер, то мне грустно за Вас"? Тогда открой её истинный смысл.
Qui habet aures audiendi, audiat
Смысл ровно такой, какой там написан
Не густо, всего 1 ссылка на какого-то студента... A>В-третьих, какая разница кто сказал?
В принципе без разницы, ты минусы ставить начал, не я...
Соответственно тебе видней должно быть.
A>Суть в том, что кусок фразы вырванный из контекста стал автортетным оправданием отсутсвия оптимизации.
Суть в том, что многие адепты плюсов (и не только) сразу бегут в сторону оптимизации, не обращая внимания, что клиента в первую очередь интересует решение их бизнес-задач, а не оптимальность сборщика мусора и т.п., пока эти ньюансы не сказываются на работоспособности приложения.
P.S. Ничего не имею ни против плюсов, ни против шарпа, ни против любого другого языка (за искл., может быть, Оберона, СГ тут постарался просто ) просто уже наели оскомину одни и те же аргументы и той и другой стороны, когда надо в первую очередь решать задачи, а не меряться разными частями тела...
Здравствуйте, Курилка, Вы писали:
К>Не густо, всего 1 ссылка на какого-то студента...
Вообще-то о полном варианте фразы я впервые узнал из книжки, а не из Интернета
A>>В-третьих, какая разница кто сказал? К>В принципе без разницы, ты минусы ставить начал, не я...
Я поставил минус за "то, что кусок фразы вырванный из контекста стал автортетным оправданием отсутсвия оптимизации", а не за неправильное авторство.
К>Суть в том, что многие адепты плюсов (и не только) сразу бегут в сторону оптимизации, не обращая внимания, что клиента в первую очередь интересует решение их бизнес-задач, а не оптимальность сборщика мусора и т.п., пока эти ньюансы не сказываются на работоспособности приложения.
Это проблема слабозарактерность Project Manager, а не программистов. В серьёзном проекте угробить половину времени на распределение памяти "потому что мне кажется, что онон может тормозить и вообще стандартная реализация Г" просто никто не даст, как бы того ни хотелось.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Так и нужно было писать не "В том же SQL-е это сплошь и рядом.", а "В том же MS SQL Server-е это сплошь и рядом."
Это не единственный сервер. Просто про него я точно помню.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, adontz, Вы писали:
O>>??? Оно преобразуется в System.String.Concat(a, b, c, d) , так что непонятно, о чём вы.
A>Да ну?
Ну, да. Причем я точно помню, что где-то год назад тебле уже об этом говорил. Но ты даже усом не повел.
A>Я между прочим не наобум сказал, а сгенерированный код поглядел
Врешь.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>>>Врешь. A>>Мда. Приехали VD>Называю вещи своими именми. Ничего ты не смотрел. Иначе бы на стал писать столь откровнную ерунду.
Если уж на то пошло откровенная ерунда это то, что говоришь Выдрал какой-то куцый пример и обрадовался.
Складывать строки когда они так навиду не велика заслуга. Что-то я в более жизненных случаях никаких оптимизаций от компилятора не заметил. Так что я не понял что ты пытаешься доказать? Что компилятор в искуственно упрощённом коде может что-то оптимизировать? Ура!
using System;
namespace cstest
{
class CSTest
{
static string SomeFuncReturningString()
{
return"qwerty";
}
[STAThread]
static void Main(string [] args)
{
string a = "aaa";
string b = "bbb";
string c = "ccc";
string d = "ddd";
string e = SomeFuncReturningString() + SomeFuncReturningString() + SomeFuncReturningString() + SomeFuncReturningString();
}
}
}
Здравствуйте, adontz, Вы писали:
A>Если уж на то пошло откровенная ерунда это то, что говоришь Выдрал какой-то куцый пример и обрадовался. A>Складывать строки когда они так навиду не велика заслуга. Что-то я в более жизненных случаях никаких оптимизаций от компилятора не заметил. Так что я не понял что ты пытаешься доказать? Что компилятор в искуственно упрощённом коде может что-то оптимизировать? Ура!
Здравствуйте, Andrei N.Sobchuck, Вы писали:
A>>Мда, а автор похоже сам сидит на героине! Оказывается перегрузка операторов нужна, чтобы экономить 2 символа и писать + вместо add
ANS>Эта. А для чего еще она нужна?
Мне лично перегрузка нужна для того, чтобы не ломать голову над изобретением дополнительных идентификаторов и не забивать свою голову этими дополнительными тысячами идентификаторами ф-ий, которые надо держать в уме, работая над программой.
Ведь есть возможность поступать проще — семантически одинаковые действия называть одинаковыми именами.
Можно попытаться составить краткий списочек ситуаций, где удобно использование перезагрузки:
1. Имеются различные способы идентификации объекта, тогда мы перегружаем сигнатуру ф-ий для всех этих способов идентификации.
Например, я храню именованные элементы в коллекции. Могу достучаться до элемента как по имени (обычно, если нужен некий конкретный), так и по индексу (удобно в различных алгоритмах). Использую перегрузку оператора [] и вполне счастлив.
2. Преобразование, извлечение данных.
Предположим, что нам надо извлекать одни и те же данные из разного их представления. Вполне естественно назвать ф-ию извлечения одних и тех же данных одинаково, но перегрузить ее для различных типов-операндов.
3. Выполнение действия.
Мы умеем выполнять семантически одинаковые действия над различными объектами. Например — регистрируем их (каждый по-своему), или складываем в одну коллекцию (каждый завернут в собственный адаптер, но внешний метод — все-равно один).
Зачем называть идни и те же намерения разными идентификаторами?
4. Контексты, опции, условия.
Например, мы выполняем некие действия, которые могут зависеть или дополнятся условиями. В этом случае у нас есть перегрузка основного алгоритма — без опций. И еще несколько на каждую из опций или на их всевозможные сочетания.
Как пример — форматирование по умлочанию, или с заданными форматами, локалями, профайдерами форматов и т.д. и т.п.
Еще пример — создание динамической коллекции. Можно перегрузить конструктор опцией предварительного размера, если заранее известно будущее количество элементов в нем (избежим многократного перераспределения памяти)
5. Опции по-умолчанию.
Продолжение предыдущего пунктаю
Иногда этих опций может быть очень много. Даже на С++, где значения аргументов по-умолчанию поддерживаются компиляторами, я стараюсь экономно использовать эту возможность в случае non-inline функций. Зачем мне закидывать в стек десяток ненужных аргументов, тем более, что этот код лежит на вызывающей стороне? Очень удобно использовать перегрузку и банально порождать меньший объем кода.
Жаль, что в современных языках, построенных на процедурном подходе, нет такого понятия как "точка входа" в процедуру (очень удобная фича при программировании на ACME ). Ее наличие позволило бы весьма эффективно релизовывать перегрузку почти во всех описанных случаях, но в случаях опций по-умолчанию — то вообще им тут место.
------------
Перегрузка ф-ий позволяет вырабатывать нечто вроде спецификаций на систему. Т.е. мы определяем, что такие-то действия над объектами, или такие-то методы объектов называются именно так-то. Ну а затем перегрузки содержат всевозможные вариации. Собственно, эти вариации нужны обычно для удобства пользования этими объектами.
Надеюсь, ты не думал, что компилятор догадается о детерминированности функции SomeFuncReturningString() — это всё-таки довольно круто. Кстати, этим может заняться и рантайм.
В любом случае, к вопросу конкатенации строк это отношения не имеет
Здравствуйте, adontz, Вы писали:
A>>>Для того чтобы конкатекация была эффективной? Вовсе нет StringBuilder это излишество вызванное как раз неиспользованием перегрузки операторов. ANS>>Сомневаюсь, что даже использование перегрузки операторов поможет избавиться от этого излишиства.
A>Сомневаться не надо, я сам написал строковый класс на C++, который кроме всего прочьего оптимизировал конкатекацию без вмешательсва программиста.
. Согласен — рабочий вариант.
Кстати, вопрос к знатокам .Net. В Java (вроде начиная с 1.5) можно стринг билдер сделать взаимозаменяемым с потоком вывода (они поддерживают интерфейс Appendable). А как с этим дело в C#?
