Здравствуйте, 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>Здравствуйте, Abyx, Вы писали:
A>>я понимаю что автор кода идиот, но как же печально, что находятся люди которым нравится писать угловые скобочки и прочие закорючки вместо нормальных человеческих слов. A>>кулхацкеры млин.
KP>А ты понимаешь, что бывает мнение отличное от твоего? И то что в ряде языков, подобный синтаксис считается нормальным, а не проявленим "кулхацкерства млин".
конечно бывает.
есть идиоты, и да, у них тоже есть какие-то мнение.
я надеюсь что ты понимаешь что мнения бывают правильные и неправильные.
если какие-то люди несколько десятков лет назад решили что << это такая красивая стрелочка-елочка, и лучшее использовать ее, чем `shl`. это нормально. на один символ короче, меньше зарезервированных слов.
потом в С++ была проблема с A<B<C> >, но ктож знал про С++
потом когда в IO library стали использовать <<, это тоже было нормально. variadic templates не было, и это был единственный нормальный способ писать в поток. cout.write(1).write(2); как-то не смотрится.
люди повозмущались (что за cout shift-left 1), но в конце концов привыкли.
хотя мнения есть разные. кто-то вроде А. Степанова считает что математические операторы надо использовать только пол назначению, и никак иначе.
и тут в 2013 году на форум притаскивают какую-то говнобиблиотеку, где автор предлагает писать
vector<T> x; x << y;
я это читаю и думаю, это логический сдвиг каждого элемента влево, или сдвиг элементов вектора влево?
а оказывается это push_back.
при этом много лет назад люди изобрели Boost.Assignment
vector<T> x; x += y;
который популярностью вроде особо не пользовался, но кто-то может привык к такому применению +=.
причем в Boost.Assignment была перегружена запятая, и можно писать
x += y, z;
что несколько короче чем x << y << z; в Range Operators
btw, в С++11 добавление нескольких элементов можно реализовать очень просто, без expression-trees — через initializer list
Здравствуйте, kaa.python, Вы писали:
KP>В целом, ощущение двоякие, с одной стороны можно лаконичнее написать код, так v.push_back(foo) выглядит не так красиво как vec << foo, а с другой стороны, дополнительные потенциальные ошибки и усложнение гугления.
я понимаю что автор кода идиот, но как же печально, что находятся люди которым нравится писать угловые скобочки и прочие закорючки вместо нормальных человеческих слов.
кулхацкеры млин.
Здравствуйте, kaa.python, Вы писали:
KP>Попалась на глаза довольно интересная (правда пока что глючная) библиотечка для C++, позволяющая делать, например, так:
KP>[ccode] KP> vec — 2; KP> vec << 4; KP>[/code]
и что это значит?
Здравствуйте, Abyx, Вы писали:
A>Здравствуйте, kaa.python, Вы писали:
KP>>Здравствуйте, Abyx, Вы писали:
A>>>п*ц. я понимаю что автор кода идиот, но как же печально, что находятся люди которым нравится писать угловые скобочки и прочие закорючки вместо нормальных человеческих слов. A>>>кулхацкеры млин.
KP>>А ты понимаешь, что бывает мнение отличное от твоего? И то что в ряде языков, подобный синтаксис считается нормальным, а не проявленим "кулхацкерства млин".
A>конечно бывает. A>есть идиоты, и да, у них тоже есть какие-то мнение.
A>я надеюсь что ты понимаешь что мнения бывают правильные и неправильные.
А ещё бывают субьективные оценочные суждения, про которые нельзя сказать, правильно или нет. Ну типа "мне нравятся брюнетки".
Не надо пытаться свои вкусовые предпочтения навязывать людям. Это занятие контрпродуктивное.
1. Тут ведь всегда проход по всем элементам (ибо упорядоченность видимо не предполагается)? Слишком много для такой краткой нотации — в итоге на ровном месте будет плодится неэффективность — которую ты даже не заметишь
.
2. Если нужна краткая нотация для часто используемых операций — имхо лучше завести отдельные типы, а не делать ad-hoc'и.
3. В документации автор приводит "аналог":
Здравствуйте, omgOnoz, Вы писали:
O>Это не печаль, без просмотра http://volnitsky.com/project/ro/ — в написанном коде черт ногу сломит
А вот Scala-разработчики с тобой бы не согласились. В целом, ощущение двоякие, с одной стороны можно лаконичнее написать код, так v.push_back(foo) выглядит не так красиво как vec << foo, а с другой стороны, дополнительные потенциальные ошибки и усложнение гугления.
Здравствуйте, Abyx, Вы писали:
A>я понимаю что автор кода идиот, но как же печально, что находятся люди которым нравится писать угловые скобочки и прочие закорючки вместо нормальных человеческих слов. A>кулхацкеры млин.
А ты понимаешь, что бывает мнение отличное от твоего? И то что в ряде языков, подобный синтаксис считается нормальным, а не проявленим "кулхацкерства млин".
Здравствуйте, kaa.python, Вы писали:
KP>Попалась на глаза довольно интересная (правда пока что глючная) библиотечка для C++, позволяющая делать, например, так:
Автор стебётся, библиотека прекрасно поднимает настроение:
++pair // pair.first
pair++ // pair.second
stack++ // stack.top()
stack-- // stack.pop()
rg / value // да-да-да, и так тоже можно
rg % value //
rg / rg // это не равно 1 :)
Здравствуйте, kaa.python, Вы писали: KP> vec — 2; KP> vec << 4;
здесь нарушена логика полностью
во-первых запись должна быть вида
vec -= 2
vec <<= 4
раз она как-то меняет вектор, а не просто возвращает результат
во-вторых увидев запись vec << 4 я бы предположил, что к каждому элементу вектора будет применена операция << 4 и возвращен вектор таких значений
vec — 2 логично понимать что 2 будет преобразовано к вектору и будет отнята двойка от всех элементов вектора
Здравствуйте, VladFein, Вы писали:
VF>удалить второй элемент VF>или VF>удалить элемент равный 2 VF>В Вашем, строго говоря, не совсем удачном примере значения элементов совпадают с их индексами...
Сложно в серьез воспринимать людей, у которых второй элемент std::vector имеет индекс 2
Здравствуйте, kaa.python, Вы писали:
KP>Попалась на глаза довольно интересная (правда пока что глючная) библиотечка для C++, позволяющая делать, например, так:
KP>
Я согласен с классиками, рекомендующими сохранять естественную семантику операторов и не прибегать к их перегрузке по чем зря. ИМХО, библиотеки общего применения не должны игнорировать "Принцип наименьшего удивления", и использование именованных функций было бы более предпочтительным в данном случае.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, rusted, Вы писали:
R>Здравствуйте, Abyx, Вы писали:
A>>потом когда в IO library стали использовать <<, это тоже было нормально. variadic templates не было, и это был единственный нормальный способ писать в поток. cout.write(1).write(2); как-то не смотрится. A>>люди повозмущались (что за cout shift-left 1), но в конце концов привыкли.
R>Кстати, почему тогда запятую (operator,) для этого не выбрали?
потому что с одним оператором проще чем с двумя.
реализация стандартной библиотеки проще, реализация пользовательских операторов проще.
Здравствуйте, omgOnoz, Вы писали: O>Другой поток мыслей: O>Рассмотрим KP>> vec << 4; O>как стримовую операцию. Т.е. в конец стрима мы добавляем значение 4
а где тут стрим?
Здравствуйте, kaa.python, Вы писали:
KP>А ты понимаешь, что бывает мнение отличное от твоего?
Не понимает. Но в этом разделе я в 99% случаев согласен с его мнением. KP>И то что в ряде языков, подобный синтаксис считается нормальным, а не проявленим "кулхацкерства млин".
А в русском-непечатном и не такой синтаксис есть. И? Давай его в плюсы тащить?
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, kaa.python, Вы писали:
KP>Попалась на глаза довольно интересная (правда пока что глючная) библиотечка для C++, позволяющая делать, например, так:
Увы и ах, получилось крайне неоднозначно
KP>
KP>#include <ro/ro.h>
KP>using namespace ro;
KP>int main() {
KP> vector<int> vec {1,2,3};
KP> vec - 2; // take 2 ? drop 2 ? вычесть 2 из аждого элемента ?
KP> vec << 4; // WTF??? Сделать каждому элементу вектора сдвиг влево? сделать rotate left на 4 позиции?
KP> for (int x: vec) {
KP> cout << x << " ";
KP> }
KP> cout << endl;
KP>}
KP> KP>
>> ./a.out
KP>1 3 4
KP>
KP>При сборке требует флага -std=c++11, Clang не собирается
Всё-таки я не сторонник J style (это там где весь код сплошняком из спецсимволов). Если напихать такого в слишком больших количествах, Вы сами через месяц перестанете понимать, что здесь написано.
Здравствуйте, igna, Вы писали:
I>А я наоборот не понимаю, какой интеллектуал придумал использовать слова для обозначения арифметических операций вроде "ADD b TO c GIVING a".
I>Если бы математики не использовали специальных обозначений, а только "нормальные человеческие слова", они бы до сих пор не сильно далеко от арифметики ушли. Квантовой физики тоже скорее всего не существовало бы. Формализация понятий и использование специальных символов для их обозначения это великая вещь.
ИМХО Вас тут заносит в другую сторону Естественно никто не предлагает нормальную арифметику записывать словами. Но и перегружать операторы, прикручивая к ним абсолютно неочевидную семантику — тоже очень плохо. Код должен легко читаться. Я например с большим удовольствием в питоне использовал "and" и "or" вместо && и || в С++. Читать гораздо легче.
Здравствуйте, Мишень-сан, Вы писали:
МС>ИМХО Вас тут заносит в другую сторону Естественно никто не предлагает нормальную арифметику записывать словами. Но и перегружать операторы, прикручивая к ним абсолютно неочевидную семантику — тоже очень плохо. Код должен легко читаться. Я например с большим удовольствием в питоне использовал "and" и "or" вместо && и || в С++. Читать гораздо легче.
Во-первых, предлагает. "ADD b TO c GIVING a" это не фантазия, а Cobol. Во-вторых, как раз использовать "and" и "or" вместо && и || на мой взгляд не стоит, поскольку & и | это принятые в математике обозначения, а не нечто взятое с потолка.
KP>А ты понимаешь, что бывает мнение отличное от твоего? И то что в ряде языков, подобный синтаксис считается нормальным, а не проявленим "кулхацкерства млин".
Щас прибегут Vamp или enji скажут, что ты не прав :D
Здравствуйте, UA, Вы писали:
UA>Как то нелогично -2 и << 4, почему не + 4? UA>или уже делали >> 2 и << 4
Согласен, так было бы более однообразно. Думаю что автор берет в качестве аналогий аналогичные операторы из библиотеки в каком-то другом, знакомом ему языке.
Посмотрел примеры. Неплохо.
Но не понравился мап (*), если типы совпадают то исходный контейнер изменяется, если разные — то создается новый. Вроде фильтр (|) тоже изменяет исходный контейнер. Не функционально, не иммутабельно, опасно.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, UA, Вы писали:
UA>>Как то нелогично -2 и << 4, почему не + 4? UA>>или уже делали >> 2 и << 4
KP>Согласен, так было бы более однообразно. Думаю что автор берет в качестве аналогий аналогичные операторы из библиотеки в каком-то другом, знакомом ему языке.
Просто в С++ перегрузка операторов не настолько гибкая чтобы навешивать произвольные операции. Это хорошо и плохо одновременно.
А про перегруженные операторы С++ (и Ц подобные языки) уже давно обогнал(и) всех своей очевидностью.
Особенно запись оператора присваивания любого математика в ступор введет.
Здравствуйте, omgOnoz, Вы писали:
O>А про перегруженные операторы С++ (и Ц подобные языки) уже давно обогнал(и) всех своей очевидностью. O>Особенно запись оператора присваивания любого математика в ступор введет.
По поводу присваивания согласен — значок должен был быть другой. Но как это относится к выделенному?
EP>По поводу присваивания согласен — значок должен был быть другой. Но как это относится к выделенному?
Да их могут использовать, как угодно, это не как не контролируется языком.
Здравствуйте, Abyx, Вы писали:
A>потом когда в IO library стали использовать <<, это тоже было нормально. variadic templates не было, и это был единственный нормальный способ писать в поток. cout.write(1).write(2); как-то не смотрится. A>люди повозмущались (что за cout shift-left 1), но в конце концов привыкли.
Здравствуйте, 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 написать.
в принципе, если нам нужно посчитать опердень, при этом параллельно запутав синтаксисом и странными багами всех остальных программистов, то эта библиотека сгодится.
Здравствуйте, _NN_, Вы писали:
_NN>А "vec — 2" создавал бы новый контейнер не изменяя оригинальный.
Лучше CoW view или просто view _NN>Ну и неясно чем "vec << 4" лучше "vec += 4";
Оба хуже.
Переубедить Вас, к сожалению, мне не удастся, поэтому сразу перейду к оскорблениям.
Здравствуйте, Ops, Вы писали:
Ops>Здравствуйте, omgOnoz, Вы писали:
O>>Да их могут использовать, как угодно, это не как не контролируется языком.
Ops>Это контролируется людьми, использующими библиотеки. Как видишь, большинство тут рекламируемую либу не хочет.
Интересная == рекламируемая? Единственное, что я на этом сайте действительно рекламирую — так это Rust. Кстати, кто еще не читал про этот замечательный язык, прошу сюда (вот это была реклама). А либа — не более чам занятная штукенция, которую в реальный проект я (как, впрочем, и >50% содержимого BOOST-а) не включил бы.
Здравствуйте, kaa.python, Вы писали:
KP>Здравствуйте, omgOnoz, Вы писали:
O>>Это не печаль, без просмотра http://volnitsky.com/project/ro/ — в написанном коде черт ногу сломит
KP>А вот Scala-разработчики с тобой бы не согласились. В целом, ощущение двоякие, с одной стороны можно лаконичнее написать код, так v.push_back(foo) выглядит не так красиво как vec << foo, а с другой стороны, дополнительные потенциальные ошибки и усложнение гугления.
Мужчина , ну вы не правы.
1] Во первых, без прочтения документации, откуда значть, что :
1) rg — value -> rg // erase all elements equal to value
2) rg << value -> rg // append value to range
Хочу заментить, что в С/С++ операторы (-) и (<<) имеют совсем другие значения.
2] Во вторых , при чем тут "Scala-разработчики", в названии ветки форума ничего нету со совом — Scala.
Здравствуйте, Abyx, Вы писали:
A>я понимаю что автор кода идиот, но как же печально, что находятся люди которым нравится писать угловые скобочки и прочие закорючки вместо нормальных человеческих слов.
А я наоборот не понимаю, какой интеллектуал придумал использовать слова для обозначения арифметических операций вроде "ADD b TO c GIVING a".
Если бы математики не использовали специальных обозначений, а только "нормальные человеческие слова", они бы до сих пор не сильно далеко от арифметики ушли. Квантовой физики тоже скорее всего не существовало бы. Формализация понятий и использование специальных символов для их обозначения это великая вещь.
