а что такое антикафе?

а что такое антикафе?

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

аааа, прикольно :)

ну тут да, философия уже )

как я понял, без бенчмарков этот спор мы так и не разрешим

сейчас напишу на своей локальной машинке бенч по-быстрому. Там и оценим и кешируемость и так далее.

холивар и месилово

Любопытно

Любопытно

По другому у плюсовиков никак

В споре рождается истина

сейчас напишу на своей локальной машинке бенч по-быстрому. Там и оценим и кешируемость и так далее.

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

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

я буду тестить на O3

gcc и clang

но надо отметить, что вот это обращнеие к обьекту вектор и получение вектор->data() хорошо кешится

Сейчас у обычных итераторов есть просто указатель на данные. Разве прибавление одного уровня коственности может дать прибавку?

Сейчас у обычных итераторов есть просто указатель на данные. Разве прибавление одного уровня коственности может дать прибавку?

вот и мне КАЖЕТСЯ, что не даст сильно

что оно будет медленее оно ясно, но насколько

что оно будет медленее оно ясно, но насколько

+

По поводу питерской встречи. 21 марта в офисе оракл будет встреча с++ спб юзер групп. Можно туда завалиться и сделать спп чат аферпати

что оно будет медленее оно ясно, но насколько

в принципе если аллоцировать вектор в куче + аллокатор будет выделять место под data рядом, небольшой объём поместится в кэш линию) а вот если вектор на стеке, да ещё мы передаёт итераторы какому нибудь алгоритму, который для разыменования будет ходить в другой стекфрейм..

в принципе если аллоцировать вектор в куче + аллокатор будет выделять место под data рядом, небольшой объём поместится в кэш линию) а вот если вектор на стеке, да ещё мы передаёт итераторы какому нибудь алгоритму, который для разыменования будет ходить в другой стекфрейм..

суть в том, что просто закешится этот указатель на вектор->data и всё будет очень быстро

суть в том, что просто закешится этот указатель на вектор->data и всё будет очень быстро

ладно, я тоже жду тестов)

суть в том, что просто закешится этот указатель на вектор->data и всё будет очень быстро

А так я не додумал по поводу копирования, сломать не сломав текущую реализацию сходу не получается) Поэтому вдвойне жду какой-либо реализации))

А так я не додумал по поводу копирования, сломать не сломав текущую реализацию сходу не получается) Поэтому вдвойне жду какой-либо реализации))

А сломать не получится

А сломать не получится

по поводу с++ заранее всегда опасно рассуждать с полной уверенностью)

по поводу с++ заранее всегда опасно рассуждать с полной уверенностью)

С полной - безусловно опасно. Но я никак не могу найти кейсы, где бы это ломалось

С полной - безусловно опасно. Но я никак не могу найти кейсы, где бы это ломалось

поэтому ждём реализации) она и родит истину

что может сломаться я хз, по поводу просадки пефоманса еще и из-за кеша - ну да.

сам вектор может быть в одном месте, данные во втором а наш итератор с указателем на вектор в третьем.

с текущими итераторами понятное дело что этого третьего звена ввиде адреса на сам вектор нет, ну и минус одно место по кешу

этот кейс по сути: - вектор является полем класса обьект которого сконструирован хер знает где в начале (мб на стеке в каком нибудь main) - а потом мы где то далеко по стеку начинаем по нему бегать таким итератором )

ну и забегаем постоянно в начало стека к нашему вектору )

std::vector<int> vec; auto it = vec.begin(); auto vec2 = vec; И какое отношение имеет итератор it к vec2?

Никакого ровным счетом.

По поводу питерской встречи. 21 марта в офисе оракл будет встреча с++ спб юзер групп. Можно туда завалиться и сделать спп чат аферпати

?

http://pastebin.com/ypYyYy04

результаты (gcc 6.2.0 -O3): стандартные итераторы - average 650 ms, оффсет итераторы - average 740 ms

так что вопрос о перфомансе как бы и не стоит сильно

А почему они не могли сделать итераторы, не ломающиеся при реаллокации?

http://stackoverflow.com/questions/6438086/iterator-invalidation-rules

результаты (gcc 6.2.0 -O3): стандартные итераторы - average 650 ms, оффсет итераторы - average 740 ms

нифига себе не стоит. +15%

А почему они не могли сделать итераторы, не ломающиеся при реаллокации?

Зачем и как?

Казалось бы. это несложно

>казалось бы Да вот что-то нифига.

Зачем и как?

Почитай дискуссию чуть ниже, пожалуйста

нифига себе не стоит. +15%

да, 15 процентов это неплохо, абсолютно согласен. Но с другой стороны мы получаем итераторы, которые не инвалидируются при реаллокации

хотя я при выборе между этими двумя выберу скорость

Почитай дискуссию чуть ниже, пожалуйста

Я прочитал, и это просто не нужно.

Да, если не хочется ивалидировать храните индекс.

Но вообще идея в том, что если писать реально заботясь о скорости, то мы СНАЧАЛА сделаем reserve нужного размера и больше никогда в жизни не будем перевыделять память в векторе.

Если мы не знаем заранее, сколько нужно памяти, это не сработает

А если знаем, можно использовать array

Если мы не знаем заранее, сколько нужно памяти, это не сработает

Об этом и речь, что это misdesign если ты не знаешь сколько памяти.

А если знаем, можно использовать array

Ты не понял.

Речь не о статически известном количестве памяти, а об иммутабельном количестве памяти.

Разные вещи.

Об этом и речь, что это misdesign если ты не знаешь сколько памяти.

Данные могут поступаь из источника, который мы не контролируем. Например, из файла

Еще раз внимательно прочитай.

Или в вектор складываются результаты вычислений, количество которых заранее неизвестно

ты из файла прочитал число и выделил сразу нужное количество памяти.

Или в вектор складываются результаты вычислений, количество которых заранее неизвестно

Пример реальной задачи, пожалуйста приведи.

Где нельзя заранее выделить достаточно памяти.

ты из файла прочитал число и выделил сразу нужное количество памяти.

У меня в файле нет числа, там просто символы до нулевого байта, например

Пример реальной задачи, пожалуйста приведи.

Ходим по папкам, считаем количество файлов с заданным именем

Количество файлов — это вроде бы одна переменная :)

Ок, список файлов

Зачем тебе _одновременно_ весь список? Ты его наверное вывести хочешь, или по сети передать. Для этого весь список в памяти не нужен. А если по какой-то странной причине нужен — то есть разумное ограничение сверху.

К чему спор если есть deque. Выбирайте размер chunk = размеру кэш линии и всё. В худшем случае будете потреблять немного больше памяти. Вполне разумная альтернатива

непонятно как скатились к теме правильного выбора контейнера под задачу

У дека тоже итераторы ломаются

У дека тоже итераторы ломаются

по крайней мере не при реаллокации в следствии нехватки выделенного пространства. Просто не нужно посередине вставлять

ERROR: S client not available

от темы "безопасных" итераторов вектора и насколько оно дорого

от темы "безопасных" итераторов вектора и насколько оно дорого

какая разница, что обсуждать))

ну то что контейнеры над выбирать под задачу оно как то очевидно - разве не?

ну то что контейнеры над выбирать под задачу оно как то очевидно - разве не?

да) но почему бы это ещё раз не обсудить??

меня идея с "безопасными" итераторами зацепила исключительно в контексте: а можно ли дать такое джунам )

т.е. есть ли вообще хоть какой то смысл

пока не очень видно )

Они несложно пишутся для любого последовательного контейнера

т.е. есть ли вообще хоть какой то смысл

Не думаю, что стоит. Привыкнут писать невалидный код с точки зрения stl

А чем он невалидный?

тем что "такие" итераторы не инвалидируются

А чем он невалидный?

...

лично я за range_v3 подобную обработку данных, где data переносится с помощью move-ctors между копиями контейнеров в pipe подобном виде, трансформируясь по пути

Ребят, есть хороший способ для просмотра автоматически выведенных ссылок? Ну там посмотреть, rvalue или lvalue ссылка, с каким квалификатором она пришла и т.п. в тяжёлом шаблонном коде? Типа static_assert, но чтобы не останавливал компиляцию, а выводил какой нибудь warning вместе с нужной информацией... И вообще, как кто отлаживает шаблонный код?

Можно сделать темплейт с приватным конструктором, передсть в него эту ссылку и вызвать конструктор

Он выведет полный тип

Можно сделать темплейт с приватным конструктором, передсть в него эту ссылку и вызвать конструктор

Ну это ведь compile_time ошибка?

Ну да

Я не знаб других способов

Ну да

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

отлаживать шаблонный код - это целое искусство :) тут нужно кастовать разработчиков всяких Boost.MPL

я в ключевых точках делаю static_assert, но это уже отписали выше

еее отладка шаблонов. енабля_иф в помощь и статик_ассерт

я в ключевых точках делаю static_assert, но это уже отписали выше

я создал структуру с набором переопределнных static_assert, и оставляю static_assert по очереди, комментируя остальные. Думаю ужасный способ)

еее отладка шаблонов. енабля_иф в помощь и статик_ассерт

таки так и делаем )

знаю я любителя шаблонов @ZaiZuPro

вроде на какой то конфе был доклад про отладку шаблонов, может кто знает?

вроде на какой то конфе был доклад про отладку шаблонов, может кто знает?

тож чот было, но не помню. если найдешь, пиши, сделаем пост в новостной канал

случаем не что то связанное с clang AST ? )

случаем не что то связанное с clang AST ? )

вангую, что связано

вот так не получилось(( http://pastebin.com/KiYSkbSB