Здравствуйте, lpd, Вы писали:
lpd>На мой взгляд — обычный C++ это баланс производительностью, удобством и простотой, с возможностью ручного ассемблера.
Рыдал. Не шути так больше.

Здравствуйте, lpd, Вы писали:

lpd>Модель акторов это очень хорошо. Однако она не всегда применяется, а передача объекта в другой поток встречается на каждом шагу, и тут указатели удобны.

А что у тебя за механизм передачи данных между потоками? ) Есть конечно специфические варианты прокидывания данных через систему (типа использования PostMessage в винде или что-то подобное), которые позволяют передать указатель и не позволяют объект. Но это как бы далеко не лучший способ организации межпоточного взаимодействия. Если же у тебя всё организовано по нормальному, внутри приложения, то непонятно откуда возьмётся разница в передаче между указателем и самим объектом.

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

Это как раз самый базовый сценарий. Обработка массива данных. И именно на нём максимально сильно дохнут всякие там Java/C# как раз из-за их врождённой дополнительной косвенности.

_>>Вот есть у тебя некое красивое, но не идеально оптимизированное C++ приложение (встречаются копирования объектов и т.п.). Ты добавил в него поддержку семантики перемещения и получил ускорение его работы на сколько то там процентов при сохранение внешнего вида кода. Это как считается, "нужна" или нет? )
lpd>Если нужно ускорение работы на несколько процентов, то я бы использовал ассемблер.

Но код тогда явно изменится и не в лучшую сторону.

_>>Или вот скажем у тебя есть хорошо оптимизированное приложение написанное на чистых указателях, где ты страдаешь с ручным отслеживанием всего этого дела. Ты переписал это всё на современном C++, сохранив старую производительность и при этом полностью забыл про все ужасы ручных указателей. Это считается "нужна" или нет? )
lpd>Ручные указатели ужасом мне не представляются, в отличие от всего свода правил по rvalue-ссылкам.

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

lpd>В принципе, если кто-то действительно может быстрый и понятный(хотя бы ему) код с move-семантикаой, то это само по себе не плохо. Кому-то вот, например нравится ассемблер, и он будет писать код, который ему нравится со вставками на ассемблере. Другой добавит туда perl6, который ему нравится.
lpd>Я к тому, что главное не использовать move-семантику только потому, что она в новом стандарте, а значит, типа, must-have.

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

lpd>Я еще редактировал предыдущий пост недавно, и добавлял:
lpd>На мой взгляд — обычный C++ это баланс производительностью, удобством и простотой, с возможностью ручного ассемблера. А с move-семантикой теряется простота. Кроме того, вот я когда то достаточно написал программ на ассемблере, и мне с моим опытом не очевидно, как move-семантика реализована. Компилятор резервирует место на стеке, выходит из функции, а когда стек возвращается к передвинутой локальной переменной, пропускает этот кусок памяти? или как?

Это ты сейчас описал что-то похожее на RVO. Единственный способ (без указателей) решать ту проблему с return до C++11. Но есть принципиальная разница. Во-первых в отличие от семантики перемещения это просто оптимизация, так что оно не всегда работает (зависит от компиляторов, может отключаться опциями оптимизации и т.п.). Во-вторых оно подходит только для узкой категории случаев (например в моём первом примере RVO не сработает из-за первого if'a), в то время как семантика перемещения гораздо универсальнее.

Что касается работы семантики перемещения, то она тривиальная по своим принципам. И в тоже время может быть сколько угодно сложной, т.к. полностью определяется программистом в том самом конструкторе перемещения. В самом банальном случае это может выглядеть так:

struct A{
    int8_t* data;
    A(int size): data(new int8_t[size]) {}
    A(A&& a) {data=a.data; a.data=nullptr;} //вот тут вся наша "магия"
    ~A() {delete data;}
};

Специально написал этот пример с явным указателем, для простоты понимания. Естественно в нормальном случае стоило бы использовать вместо него unique_ptr<int8_t> — тогда можно было бы не выписать руками деструктор. Да, кстати, а unique_ptr тоже сам по себе работает через семантику перемещения. )))

Здравствуйте, alex_public, Вы писали:

_>Здравствуйте, lpd, Вы писали:

lpd>>Модель акторов это очень хорошо. Однако она не всегда применяется, а передача объекта в другой поток встречается на каждом шагу, и тут указатели удобны.

_>А что у тебя за механизм передачи данных между потоками? ) Есть конечно специфические варианты прокидывания данных через систему (типа использования PostMessage в винде или что-то подобное), которые позволяют передать указатель и не позволяют объект. Но это как бы далеко не лучший способ организации межпоточного взаимодействия. Если же у тебя всё организовано по нормальному, внутри приложения, то непонятно откуда возьмётся разница в передаче между указателем и самим объектом.

PostMessage он не только в винде — это распространенный механизм, и очень полезный, т.к. упрощает синхронизацию и исключает большинство deadlockов при обмене данными между потоками. Но в данном случае достаточно просто передать в конструктор std::thread указатель, и после этого поиспользовать и затем забыть про него в основном потоке, как-то синхронизируясь, а с локальными объектами этого сделать нельзя.

Вообщем, можно спорить относительно полезности семантики. Очевидно, что это большое нововведение, меняющее язык, и я уже встречал вакансии где менеджеры(или тех лиды) пишут требованием C++14. На мой взгляд, это все равно что требовать от C++ программиста знания perl, lisp, erlang, rust или еще какого-то редкого языка, который, без сомнения, может чем-то улучшить программу. И это делается массово. Я, например, не увлекаюсь языками программирования — C++ это для меня только инструмент, а специализации у меня другие. И _необходимости_ использовать C++11-14 в программе нет. Это всего лишь дополнение к языку, к которому у разных людей разное отношение.

Здравствуйте, lpd, Вы писали:

lpd>и я уже встречал вакансии где менеджеры(или тех лиды) пишут требованием C++14.
Жжош напалмом

Здравствуйте, itslave, Вы писали:

I>Здравствуйте, lpd, Вы писали:

lpd>>и я уже встречал вакансии где менеджеры(или тех лиды) пишут требованием C++14.
I>Жжош напалмом

Не понял, что тебя удивляет. Как раз менеджеру или HR в первую очередь и представляется критическим преимуществом знание технологии именно последней версии, при этом он понятия не имеет что это и насколько реально необходимо в проекте. "Но это же СТАНДАРТ"

Здравствуйте, Воронков Василий, Вы писали:

ВВ>Соответственно, и ответа на то, чего не хватает интеграции C# в плане фич не будет. Для справки — поддержка C# устанавливается "целым пакетом" — OmniSharp for VSCode — и все работает.

Я например уже несколько раз говорил про создание проекта. Установили VS Code, установили расширение на базе OmniSharp "ивсеработает" — как C# проект создать?

Здравствуйте, lpd, Вы писали:

lpd>Не понял, что тебя удивляет. Как раз менеджеру или HR в первую очередь и представляется критическим преимуществом знание технологии именно последней версии, при этом он понятия не имеет что это и насколько реально необходимо в проекте. "Но это же СТАНДАРТ"

Я прочитал как "манагеры пишут на С++14". Был неправ, недочитал.

Здравствуйте, lpd, Вы писали:

_>>И именно такой подход существенно убивает производительность, т.к. добавляет лишний уровень косвенности.
lpd>Ты что, всерьез заботишься о времени разыменования указателя? оно ничтожно, а в тех очень редких случаях, где играет роль, пишут просто вставки на ассемблере. Или как такой подход убивает производительность?

Вообще-то лишние косвенности по памяти это один из главных источников тормозов в управляемых языках. Если в C++ ты будешь использовать аналогичные структуры данных с кучей индерекций, то и получаешь скорость намного более близкую к управляемым тормозам

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, lpd, Вы писали:

_>>>И именно такой подход существенно убивает производительность, т.к. добавляет лишний уровень косвенности.
lpd>>Ты что, всерьез заботишься о времени разыменования указателя? оно ничтожно, а в тех очень редких случаях, где играет роль, пишут просто вставки на ассемблере. Или как такой подход убивает производительность?

EP>Вообще-то лишние косвенности по памяти это один из главных источников тормозов в управляемых языках. Если в C++ ты будешь использовать аналогичные структуры данных с кучей индерекций, то и получаешь скорость намного более близкую к управляемым тормозам

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

Здравствуйте, lpd, Вы писали:

EP>>Вообще-то лишние косвенности по памяти это один из главных источников тормозов в управляемых языках. Если в C++ ты будешь использовать аналогичные структуры данных с кучей индерекций, то и получаешь скорость намного более близкую к управляемым тормозам
lpd>Основной источник тормозов — это байткод.

Он по-твоему интерпретируется что ли?

lpd>Разыменование указателя это одна процессорная инструкция, т.е. несколько тактов процессора.

Ты думаешь раз одна процессорная инструкция, то должна выполнятся быстро? Даже если данные приедут например из файла подкачки?

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, lpd, Вы писали:

EP>>>Вообще-то лишние косвенности по памяти это один из главных источников тормозов в управляемых языках. Если в C++ ты будешь использовать аналогичные структуры данных с кучей индерекций, то и получаешь скорость намного более близкую к управляемым тормозам
lpd>>Основной источник тормозов — это байткод.

EP>Он по-твоему интерпретируется что ли?

Незнаком с деталями последних раработок Java и C#, однако все еще он исполняется в 2-4 раза медленне, чем процессорные коды.

lpd>>Разыменование указателя это одна процессорная инструкция, т.е. несколько тактов процессора.

EP>Ты думаешь раз одна процессорная инструкция, то должна выполнятся быстро? Даже если данные приедут например из файла подкачки?

Если система начнет свопиться, в подкачке данные окажутся, где бы они не находились. Оптимизация уровня экономии на разыменовании указателя может встречаться только в обработчиках срочных прерываний real-time embedded систем, и то очень редко. Если ты о кэше, то он сам далеко не даст той раницы в скорости, которая есть между Java/C# и C++.

Здравствуйте, lpd, Вы писали:

lpd>>>Основной источник тормозов — это байткод.
EP>>Он по-твоему интерпретируется что ли?
lpd>Незнаком с деталями последних раработок Java и C#, однако все еще он исполняется в 2-4 раза медленне, чем процессорные коды.

Гугли JIT — just-in-time compilation.

lpd>>>Разыменование указателя это одна процессорная инструкция, т.е. несколько тактов процессора.

EP>>Ты думаешь раз одна процессорная инструкция, то должна выполнятся быстро? Даже если данные приедут например из файла подкачки?
lpd>Если система начнет свопиться, в подкачке данные окажутся, где бы они не находились.

Это я тебе показываю что твоя мера скорости количеством инструкций абсурдна, причём на много порядков.

lpd>Оптимизация уровня экономии на разыменовании указателя может встречаться только в обработчиках срочных прерываний real-time embedded систем

Сделай простой тест, заполни массив десятью миллионами случайных int'ов, отсортируй, и просуммируй, замерь время суммирования.
В одном случае возьми vector<int>, а в другом vector<int*>.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, lpd, Вы писали:

lpd>>>>Основной источник тормозов — это байткод.
EP>>>Он по-твоему интерпретируется что ли?
lpd>>Незнаком с деталями последних раработок Java и C#, однако все еще он исполняется в 2-4 раза медленне, чем процессорные коды.

EP>Гугли JIT — just-in-time compilation.

Я знаю что такое JIT, однако она недостаточно оптимизирует код по понятным причинам.
lpd>>Оптимизация уровня экономии на разыменовании указателя может встречаться только в обработчиках срочных прерываний real-time embedded систем

EP>Сделай простой тест, заполни массив десятью миллионами случайных int'ов, отсортируй, и просуммируй, замерь время суммирования.
EP>В одном случае возьми vector<int>, а в другом vector<int*>.

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

Здравствуйте, lpd, Вы писали:

EP>>Гугли JIT — just-in-time compilation.

lpd>Я знаю что такое JIT, однако она недостаточно оптимизирует код по понятным причинам.

Как раз таки оптимизирует код оно прекрасно, но проблема не в этом, а в типичном вопросе на собеседовании: "В чем разница между кучей и стеком".

Здравствуйте, itslave, Вы писали:

_>>Ну т.к. стандартной GUI библиотек у C++ нет, то всё зависит от того, какую ты выбрал. Если это скажем Qt (в последнее время претендует на звание лидера в данной области) и базовых контролов не хватает (что довольно редко, т.к. в самой Qt всё крайне кастомизируемо)
I>Если взять https://www.devexpress.com/products/net/controls/winforms/grid/ и сравнить со стандартным qt гридом, то сколько % фичеров покроет грид qt из коробки? А предлагает ли https://inqlude.org/index.html что нить сравнимое?

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

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

Что касается сторонних решений, то я сделал поиск по странице inqlude на "grid" и "table" и ничего не нашёл. Собственно больше я тут ничего сказать не могу. Может нет таких готовых решений, а может и есть, но я про них ничего не знаю — мне никогда не требовались такие контролы.

_>Но ты вместо этого продолжаешь оправдываться, да ещё и пытаешься какие-то переходы на личности делать...

Напомню, что вся ветка началась с твоего перехода на мою личность.

_>Раз так, то давай разберёмся окончательно с этим вопросом. И так вот твоя точная цитата

Прекрасно, с этого и надо было начать — с точной цитаты того, что ты не понял.

Q>«В C++ это не так: выбираешь ли ты «Go To Declaration Ctrl+F12», или «Go To Definition F12» — он может выдать список.»

Здесь под «в C++» подразумевалось «в случае C++».

Q>«Потому что компилятор на «этапе чтения мной кода» (евпочя) не имеет достаточной информации»

_>Соответственно или ты тут нечаянно обозвал анализатор кода IDE компилятором

Да нет, вполне осознанно; не предвидя, конечно, что это у кого-то вызовет недоумение.

_>у тебя тут наблюдается банальное незнание самых базовых вещей (что компилятор C++ не имеет никакого отношения к навигации по коду в VS).

Боюсь, незнание базовых вещей набюлдается у тебя. Точнее, просто отстутсвие определённого бэкграунда в разработке компиляторов не позволяет тебе понимать неформальный жаргон. Твоё понимание ограничивается представлением, что компилятор — это такой исполняемый файл по типу `cl.exe` или `g++.exe` (это не компиляторы, скажешь ты, а консольные интерфейсы к компилятору и компоновщику). Я же трактую понятие несколько шире.

_>Каких-либо ещё вариантов интерпретации этой твоей цитаты быть не может.

Объясняю, как работает компиляция. Исходный код подвергается лексическому и синтаксическому анализу, строится некая его модель, даже несколько по желанию, например: AST, конкретное синтаксическое дерево, семантическое дерево, таблица символов, etc. Это условный фронт-энд. Дальше модель подвергается всяким преобразованиям, меняет ряд представлений, проходит через какие-то оптимизации, SSA-формы и тому подобное; например, втискивается в модель LLVM, etc.

Так вот, для полноценного анализа кода нужно фактически пропустить исходник через фронт-энд. Это не обязательно тот же фронт-энд, что в фактическом «компиляторе». Но его создание — описание грамматики (подмножества) языка, реализация парсинга в соответствии с этой грамматикой, организация символов, контекстно-зависимое разрешение еоднозначностей — это существенная часть компилятора. Люди, которые этим занимаются называют себя компиляторщиками — даже если они подсвечивают IDE, а не генерируют исполняемый код. Очевидно желание столь значительную часть переиспользовать, поэтму Майкрософт перешёл от C#-компилятора, написанного на C++, к компилятору, который использует общую платформу Roslyn, и шарит её с командой, разрабатывающей IDE. Чтоб не приходилось поддерживать ещё один параллельный независимый компилятор для целей IDE.

_>И оба данных варианта тебя совсем не красят.

Тебя не красит пустопорожнее до**ывание к формулировкам.

_>Вот сразу видно хорошо аргументированное утверждение.

Вместо тысячи слов — одна картинка э... из тысячи слов.


_>Вообще то я не советовал ему именно C++. Перечитай моё сообщение повнимательнее.

Ты так написал, что C++ чуть ли не вариант по-умолчанию, так как «универсальность». Вместо того, чтоб написать, что это last resort — если нет никакой возможности избежать, только тогда берите C++.

_>(всё же макросы заметно проще шаблонов). Навигация в таких случаях работает корректно в любом случае, т.к. она контекстная. Подсветка (неактивная ветка ifdef обычно подсвечивается серым фоном)

Откуда контексту взяться? Я читаю исходный файл библиотеки, внутри него перехожу к определению функции, навигация переводит меня в «не серую» ветку. Но в дальнейшем, когда я буду вызывать это в своём коде — кто знает, после каких дефайнов заинклудится мне файл библиотеки? Даже в разных единицах трансляции по разному может быть.

Здравствуйте, lpd, Вы писали:

lpd>PostMessage он не только в винде — это распространенный механизм, и очень полезный, т.к. упрощает синхронизацию и исключает большинство deadlockов при обмене данными между потоками.

Если ты подразумеваешь под PostMessage самую идею, а не реализацию, то это по сути и есть некая разновидность модели акторов. ))) А вот реализации могут быть очень разные. Можно попробовать использовать в этой роли системную очередь сообщений винды, но это далеко не самый стабильный и эффективный путь. А вот если взять что-то вроде такого http://actor-framework.org решение, то всё будет гораздо веселее. )

lpd>Но в данном случае достаточно просто передать в конструктор std::thread указатель, и после этого поиспользовать и затем забыть про него в основном потоке, как-то синхронизируясь, а с локальными объектами этого сделать нельзя.

Эээ что? ) Вот такой простейший пример кода:

struct Test{
    string data;
    Test(const string& s): data(s) {cout<<this_thread::get_id()<<" constructor: "<<data<<endl;}
    Test(const Test& t) {data=t.data; cout<<this_thread::get_id()<<" copy constructor: "<<data<<endl;}
    Test(Test&& t) {data=move(t.data); cout<<this_thread::get_id()<<" move constructor: "<<data<<endl;}
    ~Test() {cout<<this_thread::get_id()<<" destructor: "<<data<<endl;}
    void print() {cout<<this_thread::get_id()<<" print: "<<data<<endl;}
};
int main()
{
    thread second, third;
    second=thread([&]{
        Test test("hello world");
        test.print();
        third=thread([&](Test&& t){
            second.join();//ждём завершения родительского потока, чтобы всё было по честному (было ясно, что данные берутся не из его стека)
            t.print();
        }, move(test));
    });
    second.join();
    third.join();
}

Выдаёт такой результат:

2 constructor: hello world
2 print: hello world
2 move constructor: hello world
2 move constructor: hello world
2 destructor:
2 destructor:
3 print: hello world
3 destructor: hello world

lpd>Вообщем, можно спорить относительно полезности семантики. Очевидно, что это большое нововведение, меняющее язык, и я уже встречал вакансии где менеджеры(или тех лиды) пишут требованием C++14. На мой взгляд, это все равно что требовать от C++ программиста знания perl, lisp, erlang, rust или еще какого-то редкого языка, который, без сомнения, может чем-то улучшить программу. И это делается массово. Я, например, не увлекаюсь языками программирования — C++ это для меня только инструмент, а специализации у меня другие. И _необходимости_ использовать C++11-14 в программе нет. Это всего лишь дополнение к языку, к которому у разных людей разное отношение.

Конечно. C++ в общем то тем и хорош, что позволяет работать в любом стиле. Хоть в стиле чистого древнего C пиши и всё будет отлично работать. Но я бы всё же посоветовал изучить и применять современный C++, потому как он позволяет переложить значительную часть работы на плечи компилятора.

Здравствуйте, lpd, Вы писали:

lpd>>>>>Основной источник тормозов — это байткод.
EP>>>>Он по-твоему интерпретируется что ли?
lpd>>>Незнаком с деталями последних раработок Java и C#, однако все еще он исполняется в 2-4 раза медленне, чем процессорные коды.
EP>>Гугли JIT — just-in-time compilation.
lpd>Я знаю что такое JIT, однако она недостаточно оптимизирует код по понятным причинам.

Он плохо оптимизирует в том числе потому что управляемый код труднее оптимизировать. Например замыкания на C++ порождают обычные вызовы, а на C# косвенные.
Собственно C++ код быстрее

Автор: Evgeny.Panasyuk
Дата: 07.06.15

даже после JIT'а (в веб-браузере, Карл!).

lpd>>>Оптимизация уровня экономии на разыменовании указателя может встречаться только в обработчиках срочных прерываний real-time embedded систем

EP>>Сделай простой тест, заполни массив десятью миллионами случайных int'ов, отсортируй, и просуммируй, замерь время суммирования.
EP>>В одном случае возьми vector<int>, а в другом vector<int*>.
lpd>Суммирование это одна инструкция. С загрузкой из памяти инструкций окажется две, что даст разницу.

Ты опять меряешь количество инструкций я могу в вариант vector<int> добавить хоть десять xor eax,eax — и он всё равно окажется быстрее.

lpd>С загрузкой из памяти инструкций окажется две, что даст разницу.

Разница (причём на порядок) будет из-за дополнительной загрузки из памяти по случайному адресу, что портит prefetcher, cache-hit и КПД использования bandwidth.

lpd>В реальных программах исключение разменования указателя и даже кэш миссы дадут крохи производительности почти всегда.

А в реальных управляемых программах будет не одна индерекция, а целое дерево

lpd>Там, где это даст разницу, оптимизируют обычно на ассемблере.

Ты понятия не имеешь о чём говоришь.

Здравствуйте, Klikujiskaaan, Вы писали:

lpd>>Я знаю что такое JIT, однако она недостаточно оптимизирует код по понятным причинам.
K>Как раз таки оптимизирует код оно прекрасно, но проблема не в этом,

Проблема в том числе и в этом. У JIT'а нет столько времени на оптимизацию, плюс сам управляемый код труднее оптимизировать.

K>а в типичном вопросе на собеседовании: "В чем разница между кучей и стеком".

В приведённом примере vector<int> vs vector<int*> — и то и другое находится в куче.

Здравствуйте, Evgeny.Panasyuk, Вы писали:

EP>Здравствуйте, lpd, Вы писали:


EP>Разница (причём на порядок) будет из-за дополнительной загрузки из памяти по случайному адресу, что портит prefetcher, cache-hit и КПД использования bandwidth.
Если мы говорим о хранении больших объектов в векторе, то возникает проблема переаллокации и фрагментации.
А в listе никакой локальности данных не будет.

lpd>>В реальных программах исключение разменования указателя и даже кэш миссы дадут крохи производительности почти всегда.

EP>А в реальных управляемых программах будет не одна индерекция, а целое дерево

lpd>>Там, где это даст разницу, оптимизируют обычно на ассемблере.

EP>Ты понятия не имеешь о чём говоришь.
Я тебе поясню, если ты начитался статей про оптимизацию JIT-компиляции:
Оптимизировать попадания в кэш и индирекцию нужно при проектировании в самую последнюю очередь, и только в редких случаях. А если необходима максимальная производительность, то архитектура, move-семантика и простота кода все вместе уходят на второй план. В общем случае о локальности данных имеет смысл заботится только разработчикам процессоров и компиляторов, которые выжимают каждый процент и которым необходимо сразу учесть все варианты использования.