Здравствуйте, kaa.python, Вы писали:
KP>Попалась на глаза довольно интересная (правда пока что глючная) библиотечка для C++, позволяющая делать, например, так:
KP>
Что мог бы делать этот код:
1. Первая мысль: создать новый вектор, вычесть из каждого элемента 2, и выкинуть результат:
vec — 2; => {-1,0,1}
2. Потом подумал, что наверное это отсечь два последних элемента, и выкинуть результат:
vec — 2; => {1}
3. Потом почитал коменты, и понял, что это удаление двойки, и перезапись vec :
vec — 2; => vec={1,3}
4. Не могу понять, почему это не удалить двойку и выкинуть результат:
vec — 2; => {1,3}
P.S. за модифицирующий оператор минус я бы предложил бы [CENSORED]
Здравствуйте, kaa.python, Вы писали:
KP>Попалась на глаза довольно интересная (правда пока что глючная) библиотечка для C++, позволяющая делать, например, так:
Автор стебётся, библиотека прекрасно поднимает настроение:
++pair // pair.first
pair++ // pair.second
stack++ // stack.top()
stack-- // stack.pop()
rg / value // да-да-да, и так тоже можно
rg % value //
rg / rg // это не равно 1 :)
А про перегруженные операторы С++ (и Ц подобные языки) уже давно обогнал(и) всех своей очевидностью.
Особенно запись оператора присваивания любого математика в ступор введет.
Здравствуйте, omgOnoz, Вы писали:
O>А про перегруженные операторы С++ (и Ц подобные языки) уже давно обогнал(и) всех своей очевидностью. O>Особенно запись оператора присваивания любого математика в ступор введет.
По поводу присваивания согласен — значок должен был быть другой. Но как это относится к выделенному?
EP>По поводу присваивания согласен — значок должен был быть другой. Но как это относится к выделенному?
Да их могут использовать, как угодно, это не как не контролируется языком.
Здравствуйте, Abyx, Вы писали:
A>потом когда в IO library стали использовать <<, это тоже было нормально. variadic templates не было, и это был единственный нормальный способ писать в поток. cout.write(1).write(2); как-то не смотрится. A>люди повозмущались (что за cout shift-left 1), но в конце концов привыкли.
Здравствуйте, rusted, Вы писали:
R>Здравствуйте, Abyx, Вы писали:
A>>потом когда в IO library стали использовать <<, это тоже было нормально. variadic templates не было, и это был единственный нормальный способ писать в поток. cout.write(1).write(2); как-то не смотрится. A>>люди повозмущались (что за cout shift-left 1), но в конце концов привыкли.
R>Кстати, почему тогда запятую (operator,) для этого не выбрали?
потому что с одним оператором проще чем с двумя.
реализация стандартной библиотеки проще, реализация пользовательских операторов проще.
Здравствуйте, kaa.python, Вы писали: KP> vec — 2; KP> vec << 4;
здесь нарушена логика полностью
во-первых запись должна быть вида
vec -= 2
vec <<= 4
раз она как-то меняет вектор, а не просто возвращает результат
во-вторых увидев запись vec << 4 я бы предположил, что к каждому элементу вектора будет применена операция << 4 и возвращен вектор таких значений
vec — 2 логично понимать что 2 будет преобразовано к вектору и будет отнята двойка от всех элементов вектора
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, kaa.python, Вы писали:
KP>>Здравствуйте, Abyx, Вы писали:
A>>>п*ц. я понимаю что автор кода идиот, но как же печально, что находятся люди которым нравится писать угловые скобочки и прочие закорючки вместо нормальных человеческих слов. A>>>кулхацкеры млин.
KP>>А ты понимаешь, что бывает мнение отличное от твоего? И то что в ряде языков, подобный синтаксис считается нормальным, а не проявленим "кулхацкерства млин".
A>конечно бывает. A>есть идиоты, и да, у них тоже есть какие-то мнение.
A>я надеюсь что ты понимаешь что мнения бывают правильные и неправильные.
А ещё бывают субьективные оценочные суждения, про которые нельзя сказать, правильно или нет. Ну типа "мне нравятся брюнетки".
Не надо пытаться свои вкусовые предпочтения навязывать людям. Это занятие контрпродуктивное.
Здравствуйте, omgOnoz, Вы писали: O>Другой поток мыслей: O>Рассмотрим KP>> vec << 4; O>как стримовую операцию. Т.е. в конец стрима мы добавляем значение 4
а где тут стрим?
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, rusted, Вы писали:
R>>Здравствуйте, Abyx, Вы писали:
A>>>потом когда в IO library стали использовать <<, это тоже было нормально. variadic templates не было, и это был единственный нормальный способ писать в поток. cout.write(1).write(2); как-то не смотрится. A>>>люди повозмущались (что за cout shift-left 1), но в конце концов привыкли.
R>>Кстати, почему тогда запятую (operator,) для этого не выбрали?
A>потому что с одним оператором проще чем с двумя. A>реализация стандартной библиотеки проще, реализация пользовательских операторов проще.
Не понятно чем и что проще. И так же два оператора и так:
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>1. Тут ведь всегда проход по всем элементам (ибо упорядоченность видимо не предполагается)? Слишком много для такой краткой нотации — в итоге на ровном месте будет плодится неэффективность — которую ты даже не заметишь
Здравствуйте, kaa.python, Вы писали:
EP>>1. Тут ведь всегда проход по всем элементам (ибо упорядоченность видимо не предполагается)? Слишком много для такой краткой нотации — в итоге на ровном месте будет плодится неэффективность — которую ты даже не заметишь
. KP>Мы говорим об идее, или о реализации? Реализация может быть сколь угодно корявой, идея — нет.
Я думал об реализации.
Ок, если об идеи — то в чём именно тут основная фишка по твоему мнению?
1. Некий DSL для часто используемых операций? Да — это бывает полезно, но только в чём тут новизна?
2. Или использование ad-hoc адаптации ко всему а-ля "using namespace std::rel_ops;"/Boost.Assign? Такая идея мне не нравится — предпочитаю ADL. (хотя Boost.Assign использую в юнит-тестах).
3. Навешивание мутирующих и дорогих операций на "чистый" operator- ? Нет уж, спасибо. Было бы хоть немного интересно если бы например "v1 — 1 — 2" представлял view оригинального range'а, а-ля boost::adaptors::filtered, оптимизированный на основе разбора expression tree — то есть не два chained filtered, а один. (и то, я бы operator- тут не использовал и выбрал бы ADL, а не ad-hoc).
Здравствуйте, kaa.python, Вы писали: KP>И получим Scala. Но, нельзя, не знаю даже, жаль или нет. __>>бред, короче говоря KP>Повторюсь — речь идет не о реализации, а об идее.
функциональные языки берут отличную концепцию неизменяемых обьектов, но наталкиваются на проблемы с коллекциями. очень накладно иметь неизменяемые коллекции. единственный доступный воркэраунд вокруг этого — отложенные вычисления и развитый синтаксис обработки коллекций. это не для удобства сделано. это сделано потому, что по другому все тормозить будет невероятно. современные компиляторы я думаю, могут подобрать структуры для коллекций на основе анализа использования ее. будет ли подбор удачный? за какое время будут выполняться операции? как говорил Гомер Симпсон: науке это неизвестно.
когда нам нужно гарантированное время мы берем С++. если мы попытаемся работать с коллекциями без отложенных вычислений все будет тормозить. попробуйте, например, с помощью этой мощной библиотеки quicksort написать.
в принципе, если нам нужно посчитать опердень, при этом параллельно запутав синтаксисом и странными багами всех остальных программистов, то эта библиотека сгодится.
