Ranged for vs Indexed for

Читабельность и лаконичность так блещет.

А ведь ещё немногим раньше вы сказали вот это :-)

Заберите обратно этот код.

Зря :-) Во-первых, моя реализация вашего весьма странного алгоритма гораздо понятнее :-) Во-вторых, она не вызывает взрыва мозга у читателя, потому что размер массива остаётся в теле цикла неизменным :-) Во-третьих, она эффективнее, потому что не дрюкается pop_back() в каждой итерации :-)

Читабельность и лаконичность так блещет.

А ведь ещё немногим раньше вы сказали вот это :-)

И как это противоречит моему высказыванию?

Во-первых, моя реализация вашего весьма странного алгоритма гораздо понятнее :-)

Вы просто подтверждаете, что «ваш правильный стиль» всего лишь вкусовщина.

Во-третьих, она эффективнее, потому что не дрюкается pop_back() в каждой итерации :-)

В моей реализации от pop_back() можно легко избавиться, сохранив читабельность и лаконичность. Но в этом нет особого смысла, т.к. накладные расходы pop_back() минимальны.

И как это противоречит моему высказыванию?

Противоречие заключается в том, что вы желаете уволить из профессии тех, кто не осилил разобрать ваш «лаконичный» код, но сами жалуетесь на читабельность объективно улучшенного варианта вашей тарабарщины :-)

Вы просто подтверждаете, что «ваш правильный стиль» всего лишь вкусовщина.

Не без этого :-) Но ведь были приведены объективные критерии почему мой вариант лучше :-)

В моей реализации от pop_back() можно легко избавиться, сохранив читабельность и лаконичность.

Но вы же не избавились, когда вам говорили, что так писать не надо :-) Избавился я :-) Покажите, как вы это сделаете :-)

Но в этом нет особого смысла, т.к. накладные расходы pop_back() минимальны.

Это говорит тот, кто 2 дня меряет foreach vs indexed for :-) Лол :-)

Нихрена тут нафлудили. По теме: коль скоро результаты профилирования в xcode не внушают доверия, стоит провести замеры другими способами(другой профайлер может есть, свои тесты _раличными_ средствами). Судя по этому:

Мои синтетические замеры дают приблизительно одинаковые результаты
[под xcode] получается иногда сильно быстрее

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

For me its much clearer to read.

Lets say that we give code in your example a bit more meaningful name is some context.

struct DataPackage
{
   uint32_t packageID;
   time_t   lastModified;
   size_t   dataSize;
   uint8_t  data;
};

Now lets say that somewhere in code i will see following.

const DataPackage & package = m_dataContainer[idx];

In most cases from my experience I already knew what the DataPackage is. So it would be much easier for me to understand what is stored in the container immediately just by looking at the line.

But if i would see a line like this

const auto & v = m_dataContainer[idx];

This is why I prefer to use explicit type declaration instead of auto. Its just makes hard for me to read my own code after 1 year of working in different parts of the project, not to mention somebody else need to dig in in order to change/add something.

const auto & v = m_dataContainer[idx];

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

For me its not enough, but anyway, it doesn't really matters, after all its just code :) Everyone can write in the way he prefers or in the convention accepted in his company.