Новый цикл for в C++11

@Dennis Ritchie · Регистрация: 27.07.2014

Студворк — интернет-сервис помощи студентам

С новым for'ом, умеющим работать с range, перебирать элементы контейнеров стало ещё проще и удобнее.

C++
1
2
3
4
5
6
7
8
9
10
11
/* Этот пример мне абсолютно понятен */
// C++98
for( vector<double>::iterator i = v.begin(); i != v.end(); ++i ) {
    total += *i;
}
 
/* Что происходит здесь, мне непонятно */
// C++11
for( auto d : v ) {
    total += d;
}

Приведите, пожалуйста, пример кода, который показывает работу цикла for в C++11.

@Dennis Ritchie · 17.12.2014, 03:58 **[ТС]**

Сообщение от DrOffset

Fixed.

Нет, совсем не fixed.

Просто авторы некоторых олимпиадных задач придумывают какую-нибудь изощрённую задачу, затем пишут её решение через векторы, засекают время работы программы, а потом переписывают решение с массивами. А потом наступает самый интересный момент: автор выставляет такое время в тестирующей системе, чтобы решение с вектором не прошло, а с массивом спокойно пролезло бы. Вот так-то.

@DrOffset · 17.12.2014, 03:58

Сообщение от Cra3y

З.Ы.: можно не значит нужно

Это как посмотреть.

@Dennis Ritchie · 17.12.2014, 03:59 **[ТС]**

Сообщение от Cra3y

если ОООЧЕЕНЬ хочется то можно так

Так не хочется, ибо так для меня непонятно.

@_Ivana · 17.12.2014, 04:07

Если верить

Сообщение от DrOffset

Прямой адресный доступ это как раз то, что обеспечивает стандартный вектор. Операция индексации вектора - эквивалентна таковой операции обычного массива.

то мне трудно понять, как вектор может не пролезть там, где пролез массив. Разве что может "эквивалентна" - в смысле асимптотической сложности, что тоже доступ к n-му элементу порядка за О(1), но в массиве - за пару тактов, а в векторе - за 500 независимо от n?

@DrOffset · 17.12.2014, 04:11

Сообщение от Dennis Ritchie

А потом наступает самый интересный момент: автор выставляет такое время в тестирующей системе, чтобы решение с вектором не прошло, а с массивом спокойно пролезло бы. Вот так-то.

Без детального рассмотрения задачи все эти выводы могут оказаться ложными. Вот я о чем говорю.
Хочешь, давай сюда код, можно разобрать почему он вдруг стал просаживаться.

Важно понимать, что вектор реализован с помощью тех же самых массивов, а не с помощью какого-то колдунства. Да, там есть определенный дополнительный код, который в некоторых моментах, может дать задержку (например инициализация значениями по-умолчанию), но в большинстве случаев дело все-таки в том, что вектор был неправильно\неоптимально применен.

Огромное количество разоблачительных статей в интернете, содержали либо откровенную ложь, либо неправильный способ замера, либо неэквивалентный код. Случаи, где вектор действительно проседает, можно по пальцам пересчитать.
Очень важно делать выводы на доказуемых объективных фактах, а не на догадках и видимом поведении, и уж тем более не на мифах из интернета.

Добавлено через 2 минуты

Сообщение от _Ivana

то мне трудно понять, как вектор может не пролезть там, где пролез массив.

Вот я и говорю, что в 99% случаев из 100% он на самом деле пролезает, просто был неправильно применен. Такое случается довольно часто, чтобы считать это тенденцией. Случаев, когда вектор действительно не лезет только потому, что он вектор - единицы.

@Dennis Ritchie · 17.12.2014, 04:14 **[ТС]**

Сообщение от _Ivana

то мне трудно понять, как вектор может не пролезть там, где пролез массив.

Разница во времени есть в миллисекундах. Если количество элементов массива огромное, то этого хватит, чтобы отправить решение в TL. Тут даже scanf и std::cin имеют значения, printf и std::cout, '\n' и std::endl, массив и вектор.

@_Ivana · 17.12.2014, 04:16

Значит, ничего нового под луной - надо просто научиться правильно их готовить

А перед этим еще бы неплохо узнать что это вообще такое за зверь

И чем он не массив и чем он не список

И зачем он тогда нужен вообще

(Я не намекаю на ликбез в этой теме, просто мысли вслух, Страуструп вон лежит до сих пор неоткрыванный, хотя там запросто STL может отсутствовать

)

Добавлено через 1 минуту
Dennis Ritchie, далеко не факт, что это основная причина. Может вы не увидели алгоритм, который с цаутами и векторами со свистом бы прошел, а влезли еле-еле, сэкономив на копейках.

@DrOffset · 17.12.2014, 04:21

Сообщение от Dennis Ritchie

printf и std::cout

printf действительно быстрее работает, чем std::cout. А вот ты знаешь почему? Если нет, то это плохо. Т.к. первое, что ты должен был выяснить, после того как увидел разницу - причину. Настоящую причину такого поведения. А как только ты узнаешь причину, то у тебя появится возможность сделать так, чтобы std::cout начал обгонять printf.

@_Ivana · 17.12.2014, 04:26

Не по теме:

Мне недавно одна знакомая квалифицированная бабка поведала, что в своих проектах реального времени под микроконтроллеры иногда применяет отладочную печать в консоль принтф-ами (в дебаг моде), а в релизе условной компиляцией не инклюдит стдио. Но суть не в этом, а в том, что если тебе не надо принтф-ить флоаты и даблы, можно подынклюдить его без этих опций - и он станет в несколько раз легче и существенно быстрее :)

@Dennis Ritchie · 17.12.2014, 04:32 **[ТС]**

Сообщение от DrOffset

А как только ты узнаешь причину, то у тебя появится возможность сделать так, чтобы std::cout начал обгонять printf

std::ios_base::sync_with_stdio
По-моему, в полной мере std::cout не будет обгонять printf никогда (за исключением нескольких случаев).

Сообщение от DrOffset

Т.к. первое, что ты должен был выяснить, после того как увидел разницу - причину.

std::cout очищает буфер после выполнения: я так понял.

Добавлено через 3 минуты

Сообщение от DrOffset

Очень важно делать выводы на доказуемых объективных фактах, а не на догадках и видимом поведении, и уж тем более не на мифах из интернета.

Хорошо. Попробуйте решить данную задачу с векторами:
МюМатрица
Если получится, то я признаю, что я дурак.

@_Ivana · 17.12.2014, 04:33

Можно попробовать сначала набить весь стринг в памяти а потом зацаутить его в файл за один раз. Не факт, что будет иметь смысл, но и не исключаю пока.

@Dennis Ritchie · 17.12.2014, 04:39 **[ТС]**

Очень интересно узнать, сколько времени вам придётся "кряхтеть", чтобы решить "простенькую" олимпиадную задачку.

@DrOffset · 17.12.2014, 04:48

Dennis Ritchie,
Во-первых std::cout - это глобальная переменная, определенная в библиотеке c++ runtime. Из-за этого теряется главное преимущество, многие вызовы не могут быть встроены.
Во-вторых потоки ввода вывода используют класс io-буфера с виртуальным интерфейсом. Это дизайн, нацеленный на расширение, но плата за это - снижение производительности. Виртуальные вызовы сами по себе накладнее обычных и встроится они не могут в силу неизвестности типа и возможности потенциальной замены конкретного объекта io-буфера.
В третьих, сама реализация io-буфера для нас скрыта, там может, скажем, предусмотрена межпоточная синхронизация при выводе на экран. В однопоточном окружении она не используется, но свою степень задержки привносить может. Конечно с таким же успехом ее может там и не быть. Это зависит от реализации.
А еще сам факт того, что это именно буферизированный ввод\вывод. Т.е. данные, сперва записываются в некий буфер, а потом уже сбрасываются в "устройство". printf конечно тоже буферизированный, но он может записать туда несколько аргументов одним махом, а std::cout - нет.

Ускорить std::cout можно, например, заменив стандартный буфер на свой, например реализовав ввод-вывод через api системы, чтобы исключить промежуточные вызовы из crt. Есть шанс если не перегнать, то хотя бы сравнятся засчет того, что printf все-таки приходится осуществлять парсинг форматной строки, а std::cout обладает нужной информацией о типах сразу.
А то, что std::endl срасывает буфер - это меньшая из всех проблем

@Dennis Ritchie · 17.12.2014, 04:56 **[ТС]**

Сообщение от DrOffset

Во-первых...

Монолитно написано.

@DrOffset · 17.12.2014, 04:59

Не по теме:

Сообщение от Dennis Ritchie

Попробуйте решить данную задачу с векторами

Обязательно, я даже зарегистрировался. Но только завтра. У меня на часах 5 утра, бодрствую уже 23 часа и через 5 часов на работу :)

@maxillion · 17.12.2014, 05:14

Сообщение от Dennis Ritchie

Теперь я понял, почему никто не использует новый синтаксис цикла for, потому что он написан специально под std::vector

Это не так , он написан для типов у которых определены функции begin() и end(), возвращающие итераторы.

Добавлено через 1 минуту
А также применим к C-массивам и спискам инициализаторов.

@Dennis Ritchie · 17.12.2014, 17:32 **[ТС]**

Сообщение от maxillion

Это не так , он написан для типов у которых определены функции begin() и end(), возвращающие итераторы.

Т. е. STL.

Сообщение от DrOffset

Обязательно, я даже зарегистрировался.

Буду ждать.

Добавлено через 12 часов 11 минут
DrOffset, чтобы решить эту задачу нужно использовать трёхмерный массив и операцию XOR (^).

@ForEveR · 17.12.2014, 17:54

Сообщение от Dennis Ritchie

Т. е. STL.

Нет. Любая сущность, у которой есть функции-члены begin/end (или же присутствует перегрузка свободных функций begin/end, которая может быть найдена используя ADL).
Возвращаемый данными фукнциями тип должен следовать концепции итератора конечно же.

MrGluck · 17.12.2014, 19:48

Сообщение от Dennis Ritchie

По старинке неинтересно. Теперь я понял, почему никто не использует новый синтаксис цикла for, потому что он написан специально под std::vector.

Он написан для всех контейнеров, поддерживающих методы begin() и end()

Добавлено через 2 минуты
Кстати, либа pugixml поддерживает данную концепцию. Можно перебирать все атрибуты или детей с помощью range-base for, что неописуемо удобно.

Выдрано с неё:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
// Range-based for loop support
template <typename It> class xml_object_range
{
public:
    typedef It const_iterator;
    typedef It iterator;
 
    xml_object_range(It b, It e): _begin(b), _end(e)
    {
    }
 
    It begin() const { return _begin; }
    It end() const { return _end; }
 
private:
    It _begin, _end;
};

Добавлено через 33 минуты
Вот тут пользовательский класс, использующий проход по итераторам.
Подсчитать средний балл студента

Новые блоги и статьи Все статьи Все блоги /
Установка статуса документа по условию Maks 05.07.2026 Алгоритм из решения ниже реализован на нетиповом документе "НарядПутевка" разработанного в КА2. Задача: в табличной части "Материалы" документа при записи автоматически устанавливать статус. . .	Сезонность и суточность закисления почв anaschu 04.07.2026 200 часов это все равно моловато. Есть ситуации, но нестандартные, когда смена происходит за 5 лет. Но обычно это 50 лет и более. Наверное, закисление почвы происходит сезонно в средней. . .	В чем ценность человеческого опыта в глобальном смысле? kumehtar 03.07.2026 Возможно, ценность человека не в том, что он однажды достигает мудрости, а в том, что он становится носителем карты пути. Он знает не только истину, но и последовательность внутренних изменений,. . .	интеграция AnyLogic с самописным REST API и переход на Odoo anaschu 03.07.2026 Успешная интеграция AnyLogic с самописным REST API и переход на промышленную Odoo WMS Сегодня проделал огромный путь от простой симуляции физических процессов до построения полноценной. . .
Поиск всех путей на ориентированном графе. Linux dcc0 02.07.2026 Переработка старого кода из моей статьи. Через несколько переработок от PHP кода к C89 (надеюсь, 89). Но довольно запутанно получилось. Код для Linux. Но если убрать time и то, что с ним. . .	Сам себя обучал rest api anaschu 02.07.2026 Педагогический лайфхак: Почему чистый REST API для ученика намного круче, чем готовые библиотеки Когда мы отказались от капризного JAR-файла AnyLogic и переписали код на стандартный HttpClient,. . .	rest api anylogic - выполнение модели на своём русском сайте anaschu 02.07.2026 Как подружиться с AnyLogic Cloud API, победить провайдеров и развернуться Java-бэкенд в Docker на бесплатном хостинге: Двухдневный лог борьбы Всем привет! Хочу поделиться свежим (и довольно. . .	Где деньги лежат kumehtar 02.07.2026 Это - японская подводная лодка I-52 (тип C2, кодовое имя Momi) вышла из Японии в марте 1944 года с миссией в оккупированную немцами Францию (Лорьян). Это была одна из «Янаги»-миссий по обмену. . .

@_Ivana 4949 / 2289 / 287 Регистрация: 01.03.2013 Сообщений: 5,991 Записей в блоге: 32
	17.12.2014, 04:16
	Значит, ничего нового под луной - надо просто научиться правильно их готовить А перед этим еще бы неплохо узнать что это вообще такое за зверь И чем он не массив и чем он не список И зачем он тогда нужен вообще (Я не намекаю на ликбез в этой теме, просто мысли вслух, Страуструп вон лежит до сих пор неоткрыванный, хотя там запросто STL может отсутствовать ) Добавлено через 1 минуту Dennis Ritchie, далеко не факт, что это основная причина. Может вы не увидели алгоритм, который с цаутами и векторами со свистом бы прошел, а влезли еле-еле, сэкономив на копейках. 0

@_Ivana
	17.12.2014, 04:26
	Не по теме: Мне недавно одна знакомая квалифицированная бабка поведала, что в своих проектах реального времени под микроконтроллеры иногда применяет отладочную печать в консоль принтф-ами (в дебаг моде), а в релизе условной компиляцией не инклюдит стдио. Но суть не в этом, а в том, что если тебе не надо принтф-ить флоаты и даблы, можно подынклюдить его без этих опций - и он станет в несколько раз легче и существенно быстрее :) 0

@_Ivana 4949 / 2289 / 287 Регистрация: 01.03.2013 Сообщений: 5,991 Записей в блоге: 32
	17.12.2014, 04:33
	Можно попробовать сначала набить весь стринг в памяти а потом зацаутить его в файл за один раз. Не факт, что будет иметь смысл, но и не исключаю пока. 0

@Dennis Ritchie 555 / 148 / 58 Регистрация: 27.07.2014 Сообщений: 2,446
	17.12.2014, 04:39 [ТС]
	Очень интересно узнать, сколько времени вам придётся "кряхтеть", чтобы решить "простенькую" олимпиадную задачку. 0

@DrOffset 19501 / 10106 / 2461 Регистрация: 30.01.2014 Сообщений: 17,825
	17.12.2014, 04:48
	Dennis Ritchie, Во-первых std::cout - это глобальная переменная, определенная в библиотеке c++ runtime. Из-за этого теряется главное преимущество, многие вызовы не могут быть встроены. Во-вторых потоки ввода вывода используют класс io-буфера с виртуальным интерфейсом. Это дизайн, нацеленный на расширение, но плата за это - снижение производительности. Виртуальные вызовы сами по себе накладнее обычных и встроится они не могут в силу неизвестности типа и возможности потенциальной замены конкретного объекта io-буфера. В третьих, сама реализация io-буфера для нас скрыта, там может, скажем, предусмотрена межпоточная синхронизация при выводе на экран. В однопоточном окружении она не используется, но свою степень задержки привносить может. Конечно с таким же успехом ее может там и не быть. Это зависит от реализации. А еще сам факт того, что это именно буферизированный ввод\вывод. Т.е. данные, сперва записываются в некий буфер, а потом уже сбрасываются в "устройство". printf конечно тоже буферизированный, но он может записать туда несколько аргументов одним махом, а std::cout - нет. Ускорить std::cout можно, например, заменив стандартный буфер на свой, например реализовав ввод-вывод через api системы, чтобы исключить промежуточные вызовы из crt. Есть шанс если не перегнать, то хотя бы сравнятся засчет того, что printf все-таки приходится осуществлять парсинг форматной строки, а std::cout обладает нужной информацией о типах сразу. А то, что std::endl срасывает буфер - это меньшая из всех проблем 2