Сегодня на конференции библиотеки Boost Андрей Александреску, автор книги «Современный дизайн C ++ и Loki C ++» библиотека, выступила с докладом под названием «Итераторы должны работать» (видео, слайды) о том, почему итераторы плохи, и у него было лучшее решение.
Я пытался прочитать слайды презентации, но ничего не смог извлечь из них.
Во-первых, чтобы ответить на ваши вопросы:
Большой вклад Андрея здесь в том, чтобы просто сказать: полностью отказаться от концепции итераторов, рассматривать диапазоны не только как удобную оболочку, но и как основную конструкцию. Другие языки уже сделали это (многие концепции Андрея просто повторяют итераторы .NET LINQ или Python), но все они предлагают только диапазоны вывода. Андрей приводит аргументы в пользу разных типов диапазонов, как и в случае с обычными категориями итераторов.
В этом свете странно, что он начинает с насмешек над произвольностью этих категорий итераторов.
Я также думаю, что его примеры отключены, особенно его копирование файлов: да, вариант с итератором - это огромное улучшение по сравнению с кодом 1975 года. Он сокращает цикл со сложным условием прерывания до одного оператора. На самом деле он не согласен с синтаксисом. Что ж, извините: мы говорим здесь о C ++ - конечно синтаксис уродливый. И да, использование здесь диапазонов является улучшением, но только синтаксически.
Еще думаю, что у Андрея find реализация выключена. Что он действительно определяет, так это операцию DropUntil (именование сложно!) От LINQ. Операция find действительно должна возвращать либо один, либо ноль элементов (или итератор!). На мой взгляд, избегание итераторов здесь бесполезно, так как мы могли бы изменить значение напрямую, а не копировать его. Возврат одноэлементного диапазона здесь только добавляет накладные расходы без каких-либо преимуществ. Делать это по-Андреевски плохо, потому что тогда название метода просто неправильное и вводящее в заблуждение.
При этом я практически во всем согласен с Андреем. Итераторы, хотя и являются моей любимой концепцией из информатики, безусловно, представляют собой большую синтаксическую нагрузку, и многие диапазоны (особенно бесконечные генераторы) могут (и должны) быть удобно реализованы без них.
while( true ), но насколько значительны эти накладные расходы?
- person wilhelmtell; 09.04.2010
find - да, название не указано; но это потому, что здесь для ясности он отражает STL, который также вызывает эту функцию find. И если вы посмотрите на презентацию, то на самом деле демонстрируется сбой идиомы копирования файлов, когда член аудитории неправильно понимает код - чего не происходит с кодом C, который, несмотря на все, более понятен.
- person Eamon Nerbonne; 30.12.2010
find может отражать STL, но он немного - но фундаментально - отличается по своему поведению. Но я согласен, что вводить новое имя в презентации было бы неудобно. (3) Я первый, кто согласен с тем, что (а) C ++ «удобен для экспертов» и (б) его синтаксис - отстой. - Тем не менее, он маскирует сложность лучше, чем C, также в этом примере.
- person Konrad Rudolph; 31.12.2010
find и файле IO, потому что в оставшихся трех абзацах я подтверждаю аргументы Андрея
- person Konrad Rudolph; 01.01.2011
Я согласен с ним в том, что итераторы в большинстве своем уступают диапазонам, и я не знаю, подберут ли «что-нибудь получше».
«Добро - враг лучшего», как обычно, играет здесь большую роль. Итераторы полезны и прочно укоренились, поэтому трудно понять, сможет ли что-то лучшее, например диапазоны, заменить их в разумные сроки.
Андрей временами может быть немного провокационным. Итераторы - разумная концепция и довольно фундаментальная в том смысле, что и биты. Но так же, как большинство битов в C ++ не являются логическими значениями, а являются частью более крупных типов, с большинством итераторов следует обращаться на высоком уровне. Андрей прав в том, что подходящим уровнем для этого является объект диапазона. Но не все диапазоны правильно отображаются как диапазоны итератора, как показывает дозорный istream_iterator. Это просто хитрость для создания искусственного конечного итератора. Однако я не думаю, что его идеи будут подхвачены реализацией. C ++ 1x будет иметь такое же значение, как и C99.
C ++ 0x уже делает первые шаги:
Переход к диапазонам без потери какой-либо функциональности итератора (подумайте обо всех комбинациях категорий итераторов, константности и rvalue-ness) является трудным, особенно если вы пытаетесь учитывать бесконечные и изменяемые диапазоны.
Нет, неплохие, на самом деле очень умная идея. Однако они не идеальны, и в концепции итератора есть возможности для улучшения.
Он решает ряд реальных проблем с итераторами. Например, во многих случаях утомительно (также подвержено ошибкам) запрашивать два отдельных объекта, итератора, из одного контейнера, а затем передавать их как еще два отдельных объекта в алгоритм. Почему бы не пропустить ни одного предмета? Даже std::pair<iterator, iterator> будет грубым диапазоном, которым легче манипулировать - один объект, а не два. Кроме того, неплохо было бы рассмотреть a range is an iterator. Собственно, Андрей и предлагает. Кстати, некоторые из этих проблем уже решены с помощью Boost . Диапазон.
Я ожидал, что это произошло, но это будет не революция, а скорее эволюция.
Я думаю, что мы должны использовать диапазоны рядом с итераторами, т.е. мы должны выбирать путь эволюции, а не путь революции.
Разве Андрей не пытается провести скрытый маркетинг для языка D (в настоящее время он работает с ним) ...?
Андрей заявляет, что с контейнерами все в порядке, но итераторы уродливы, не интуитивно понятны, подвержены ошибкам и опасны, их сложно реализовать (ну, последнее кажется довольно верным ...) И что у нас есть в C ++ ... указатели ? Разве они не уродливы /.../ опасны? Но мы с радостью приняли их и живем с ними.
Какой из них писать более интуитивно:
for(auto i=foo.begin();i!=foo.end();++i)
bar(*i);
or
for (auto r=foo.all(); !foo.empty(); foo.popFront())
bar(r.front());
Концепцию итераторов можно дополнять диапазонами и другими идеями, но я думаю, что они нашли свое место и не подлежат замене.
Как и любой API или функция, неправильное использование может создать множество проблем с идентификацией. Итераторы использовались во многих проектах, но всегда сохраняли необходимую заботу, требуемую в соответствии с их характеристиками. Его использованию должно предшествовать хорошее понимание их ограничений. Итераторы могут быть очень полезны при правильном использовании.
Эти вопросы связаны:
Есть ли способ проверить, действителен ли итератор?
Следует ли мне предпочесть итераторы над константами итераторами?
Я не согласен и с Андреем, и с Конрадом, и со мной :-)
Самая фундаментальная концепция - это интерфейс, а не итератор, и это довольно очевидно в любой работе, которую кто-либо делает сегодня (которая связана с кросс-библиотекой, кросс-языками, кросс-компилятором, кросс-ОС, кросс-платформенностью, вы перекрестно называете Это :-)
Ни итератор, ни диапазон (кроме использования на уровне исходного кода) не предлагают ничего, кроме чистого и простого, ненавязчивого или навязчивого, не разделяемого или разделяемого, не уникального или уникального: указателя! Чистый указатель на типизированные данные просто универсален, и вы можете сделать данные изменяемыми или неизменяемыми и многое другое. Весь интерфейс - это просто еще один уровень косвенного обращения к нему, при этом он удобен для машин и компиляторов всех видов, а также гораздо безопаснее, поскольку итераторы и использование диапазона относятся к деталям реализации.
В этом смысле IEnumerable и IQueryable делают наполовину `` правильные вещи '' TM, но они явно уступают в своих концепциях итерации и многого другого по сравнению с тем, что вы можете делать с STL, сохраняя контроль и т. и, следовательно, лучшая, более чистая модель). Дело в том, что с интерфейсами вы можете построить любую абстракцию, которую хотите и удовлетворить, ну, вероятно, противоречивую, но по существу простую: оптимальное и нейтральное во время выполнения или компиляции представление данных и код (черт возьми, это важно для алгоритмов, компиляторов, виртуальных машин и тому подобного) .
Можно даже оптимизировать его для «динамических» / компонентных систем вплоть до встраивания «времени выполнения» (к черту HotSpot VM :-) .. В этом смысле прогресс до 1975 года минимален, о чем свидетельствует огромная рабочая нагрузка в индустрии взаимодействия (это повсюду посмотрите, в том числе этот сайт, использование проприетарных и открытых технологий и т. д., в идеализме информатики, ну, такого типа "работы" взаимодействия не должно существовать, если оно есть) ..
Я думаю, что у разработчиков C ++ будут свои руки, чтобы обеспечить полную рабочую поддержку C ++ 0x без реализации новых нестандартных парадигм.
Единственный аргумент, который я вижу в этой презентации, - это неспособность определять диапазоны, и предложение c ++ 0x «Диапазон для оператора», похоже, в какой-то степени устраняет эту проблему. возможно, это не должно быть аргументом в пользу того, что итераторы должны / не должны использоваться вообще, но более того, в каких ситуациях следует / не следует их использовать?
