Здравствуйте, Oyster, Вы писали:
O>Здравствуйте, StanislavK, Вы писали:
A>>>Например если в шаблонный класс для подсчёта корней уравнения вместо double подставить какой-нибудь класс для вычислений с повышенной точностью вместо double, то код шаблонного класса не надо будет менять. SK>>Согласен, для чисел это полезно, но в общем, не нужная фича.
O>Согласен, для ходьбы ноги полезны, но в общем ненужная фича
Убедил, против твоих аргументов ничего не прокатит.
Здравствуйте, VladD2, Вы писали:
VD>И для них использование "+" как оператора конкатинации совершенно нормально и общепринято. В том же SQL-е это сплошь и рядом.
Здравствуйте, cranky, Вы писали:
C>Здравствуйте, Nose, Вы писали:
N>>Здравствуйте, cranky, Вы писали:
C>Хм, вроде что-то у Александреску было насчёт списка типов. Может подойдёт для объявления функций с произвольным числом параметров?
Решения от Александреску плохи тем, что далеко работают не на всех компиляторах. Для стандартной библиотеки -- не пойдет..
Да и решение там... тот же самый десяток макросов с разным количеством параметров. Хотите больше -- дописывайте
N>>не знаю, по-моему ничего страшного с "+", к тому же уже привычное старое решение... N>>Никаких глюков, напрягов и пр. от него не знаю -- не встречался. C>Также как и некоторые не встречались с memory leak.
Ты встречался? расскажи
А последний мемори лик я видел уже больше года назад
N>>Читаемо, удобно и стандартно. C>Стандартно, конечно, только это единичный случай неправильного использования перегрузки и вообще, исключение из правил.
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Quintanar, Вы писали:
Q>>Вопреки сложившемуся мнению, программы можно писать вообще без ООП, хотя это, конечно, требует несколько большего интеллекта.
A>Угу. На ассемблере. И перегрузки операторов там нету
Если для Вас в программировании есть только ООП языки и ассемблер, то мне грустно за Вас
Здравствуйте, Quintanar, Вы писали:
Q>Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>>Дело-то как раз в том, что на плюсовиков (по моим наблюдениям) перечисленные мелочи не так уж сильно и влияют, если речь идёт о серьёзных делах. И "километровые объявления шаблонных типов" — не проблема, а естественное следствие самих шаблонов (не хочешь — не пользуй). И управление памятью — не проблема, а полезная фича. А закорючки... у любого языка свои закорючки. Даже у LISP.
Q>Скажите честно, зачем вам управлять памятью? Вы пишете real time систему или игру, на худой конец? Ведь математик не изобретает каждый раз все с нуля, а использует имеющийся базис, чтобы идти вперед и не иметь дела с посторонними в общем-то вещами. И так везде. Если сильно надо, можно откатиться назад и пересмотреть основы — написать свой GC, свою систему классов и т.п. Но как правило, это не нужно.
+
Как сказал Хоар: Premature optimization is the root of all evil.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, VladD2, Вы писали:
VD>>И для них использование "+" как оператора конкатинации совершенно нормально и общепринято. В том же SQL-е это сплошь и рядом. ANS>
Здравствуйте, adontz, Вы писали:
A>По эффективности никакой. По способу использования — более прозрачно, менее заметно. Оптимизация конкатекации чаще подключается без явного использования.
Ну, и зачем что-то неявное через ухо когда можно просто взять класс заточенный под конкретную задачу?
Я видил много С++-ного кода. И в болшинстве случаев никто даже не задумывался над тем, что конкатинация может быть тормозом.
A>Это не шутка Просто такие оптимизации доступны только Си++ шаблонам.
A>Например есть выражение A>
A>string x = a + b + c + d.
A>
Я тебе уже третий раз повторяю, что в Шапре подобный код выливается в вызов функции string.Concat(). А эффективнее нее уже ничего не найти.
Вдумки поскипаны.
... << RSDN@Home 1.2.0 alpha rev. 591>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Кодёнок, Вы писали:
Кё>Здравствуйте, cranky, Вы писали:
Кё>>>Есть еще cons. Это почти то же, но образуется всегда список-пара: Кё>>>1 :: 2 = (1 2) Кё>>>(1 2) :: 3 = ((1 2) 3) Кё>>>(1 2) :: (3 4) = ((1 2) (3 4))
C>>Интересный какой cons. А что это за язык? И возможна ли в нём не-двоичная нотация списков, типа такого: (1 2 3)?
Кё>Не помню, по-моему Erlang. А списки *теоретически* всегда представляются как пары (на самом деле они часто реализованы напрямую, тем не менее суть операций car и cdr — именно работа с парой).
Это так, просто в лиспе (cons 1 2) == '(1 . 2), т.е. получаем точечный список (пару в данном случае), в кудре последнего конса которого будет не указатель на след. конс, как в нормальном списке, а атом. Оттого меня и заинтересовало, как в языке, в котором результат конса представляется как простой список аргументов, записываются обычные списки переменного размера.
Кё>Т.е. (1 2 3 4) это (cons 1 (cons 2 (cons 3 (cons 4 ())))), поэтому car — первый элемент пары будет 1, cdr — второй элемент, будет списком.
Здравствуйте, VladD2, Вы писали:
VD>Ну, и зачем что-то неявное через ухо когда можно просто взять класс заточенный под конкретную задачу? VD>Я видил много С++-ного кода. И в болшинстве случаев никто даже не задумывался над тем, что конкатинация может быть тормозом.
Но она может. А так как думать всё равно никто не начнёт неявные оптимизации предпочтительнее.
VD>Я тебе уже третий раз повторяю, что в Шапре подобный код выливается в вызов функции string.Concat(). А эффективнее нее уже ничего не найти.
Влад, учи матчасть a.Concat(b.Concat(c.Concat(d))) это мягко говоря не самый эффективный код.
VD>Вдумки поскипаны.
Сдерживай свои негативные эммоции. Это не выдумки а описание реального кода. И если лично ты не понял идеи это не значит, что идея глупа.
Здравствуйте, VladD2, Вы писали:
A>>Да, только мы избавляемся от явного использования этого хранилища в большинстве случаев. VD>Осталось только выяснить зачем это делать. Мысли лучше выражать явно.
Явно лучше выражать неочевидные мысли. Ты же не пишешь
// А здесь мы увеличивает значение счётчика на единицу
i++
Как ты сам признался об оптимизации конкатекация думают мало. Так лучше предложить оптимизацию которая будет неявно подключатся, чем заставлять людей думать.
Здравствуйте, Курилка, Вы писали:
A>>Угу. На ассемблере. И перегрузки операторов там нету К>Если для Вас в программировании есть только ООП языки и ассемблер, то мне грустно за Вас
Ага. Забавно. Ну давай — перечисли тогда языки которые позволяют расширить сознание как у тебя
Здравствуйте, adontz, Вы писали:
VD>>Я тебе уже третий раз повторяю, что в Шапре подобный код выливается в вызов функции string.Concat(). А эффективнее нее уже ничего не найти.
A>Влад, учи матчасть a.Concat(b.Concat(c.Concat(d))) это мягко говоря не самый эффективный код.
??? Оно преобразуется в System.String.Concat(a, b, c, d) , так что непонятно, о чём вы.
Здравствуйте, Курилка, Вы писали:
К>+ К>Как сказал Хоар: Premature optimization is the root of all evil.
-1 за знание предмета.
Во-первых, это сказал Робет Флойд. Во-вторых это толкьо часть цитаты. А вот полностью
"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."
его высказывание имеет совсем другой смысл.
Здравствуйте, adontz, Вы писали:
VD>>Я тебе уже третий раз повторяю, что в Шапре подобный код выливается в вызов функции string.Concat(). А эффективнее нее уже ничего не найти.
A>Влад, учи матчасть a.Concat(b.Concat(c.Concat(d))) это мягко говоря не самый эффективный код.
Ну ты все-таки посмотри во что выливается string x = a + b + c + d, а не начинай сразу хохмить.
Здравствуйте, adontz, Вы писали:
O>>??? Оно преобразуется в System.String.Concat(a, b, c, d) , так что непонятно, о чём вы.
A>Да ну? Я между прочим не наобум сказал, а сгенерированный код поглядел
Код:
using System;
namespace ConsoleApplication100
{
class Class1
{
[STAThread]
static void Main(string[] args)
{
string a = "a";
string b = "b";
string c = "c";
string d = "d";
string e = a + b + c + d;
}
}
}
Здравствуйте, adontz, Вы писали:
A>Здравствуйте, Курилка, Вы писали:
A>>>Угу. На ассемблере. И перегрузки операторов там нету К>>Если для Вас в программировании есть только ООП языки и ассемблер, то мне грустно за Вас
A>Ага. Забавно. Ну давай — перечисли тогда языки которые позволяют расширить сознание как у тебя
Не уместная ирония на мой взгляд
Просто замыкаться на чём-то имхо есть не лучший способ получения знаний. Тот же Vlad2 хоть и не очень любит ФП, но признаёт что там есть определённое число идей вполне полезных для применения, которые перекочёвывают во многие популярные языки.
Кстати те же плюсы (которыми ты вроде бы не брезгуешь) всё дальше и дальше отходят от ООП, тот же Александреску это в своей книжке продемонстрировал (хоть и не совсем чтобы большими буквами ).
И умение специалиста в программировании прежде всего должно состоять в том, чтобы он знал не какуют-то только одну пардигму (ООП в данном случае), а имел целый набор и применял их по мере надобности. Кстати, а шаблоны ты не применяешь?
Перечислять языки не стану — расширение твоего сознания это прежде всего твоя задача (если она у тебя есть, конечно).
Здравствуйте, Oyster, Вы писали:
O>>>??? Оно преобразуется в System.String.Concat(a, b, c, d) , так что непонятно, о чём вы. A>>Да ну? Я между прочим не наобум сказал, а сгенерированный код поглядел O>Код:
ОК, может быть для .Net я погорячился. Но в Си++ таких оптимизаций точно нет
Здравствуйте, Курилка, Вы писали:
К>Не уместная ирония на мой взгляд
Я и на Си++ пишу и шаблоны использую. Ну и? К чему была фраза "Если для Вас в программировании есть только ООП языки и ассемблер, то мне грустно за Вас"? Тогда открой её истинный смысл.