Безопасен ли такой код QList<QPushButton*>?

[Пантер]

BRE, чтобы таких холиваров не раздувалось.

[Alex_cs_gsp]

ИМХО разработчиками не нужно было документировать как вообще происходит распределения  памяти.

Почему?

Не было бы таких вопросов. Ведь это реализация, а она не так уж важна.

[Sancho_s_rancho]

foreach - богомерзкий прием, богомерзкого С с шаблонами.

http://labs.trolltech.com/blogs/2009/01/23/iterating-efficiently/

[BRE]

Не было бы таких вопросов. Ведь это реализация, а она не так уж важна.

IMHO, чем больше ты будешь знать как "это" работает, тем более эффективно ты сможешь "это" использовать.

[BRE]

foreach - богомерзкий прием, богомерзкого С с шаблонами.

Ну, для использования итераторов не обязательно использовать foreach.

[Alex_cs_gsp]

Не давно осилил очередную книгу Рихтера по вынь-апи . Так вот в винде такое распределения памяти, что если юзать все возможности, то можно офигеть. Поэтому в большинстве случаев, если MFC, то используют new, а как оно там дальше мне по барабану, будет ли та память в страничный файл выгружена, какое там смещение или защита страницы. Вижу в этом аналогию.

[Sancho_s_rancho]

foreach - богомерзкий прием, богомерзкого С с шаблонами.

Ну, для использования итераторов не обязательно использовать foreach.

Да я не серьезно. Просто потроллить после рабочего дня захотелось.

[Alex_cs_gsp]

А вообще хорошо, чтобы этот механизм каким-то образом был в стандарт с++ запихнутым , тогда точно вопросов не будет.

[Igors]

for (QList <int>::iterator......
Чем тебе этот for не угодил?

Тем что строка длинная получается. и все это смахивает на "демонстрацию познаний" взамен содержательной работы  

Чем проще? А если индекс элемента не нужен вообще? Для чего инкрементировать/декрименторовать не нужную переменную, да еще постоянно вычислять по ней смещение до нужного элемента? А как быть с индексом при работе со связанным списком (его конечно можно приспособить, только нужно ли?).

Разговор о контейнерах с прямым доступом, для остальных (хочешь - не хочешь) итератор использовать придется. "Смещение до нужного элемента" по существу та же адресная арифметика, плюс небольшие накладные расходы. Утверждение что ++ итератора якобы "ощутимо быстрее" взятия по индексу лишено оснований. Это обойдется в 2-3 машинных команды даже для классического vector, что пренебрежимо мало по сравнению с тем что делается в теле цикла.  Для остальных контейнеров вообще дело темное кто там быстрее. Так что дело вкуса что использовать - итератор или индекс.

Если речь идет о скорости - с удовольствием приму участие в обсуждении. Только по-честному. А то Вы спокойно относитесь к тому что контейнер перераспределяет память (что стоит сотен/тысяч команд), входит в EnterCriticalSection при добавлении нового элемента (напр std::set) и.т.п. В этом контексте говорить о "выжимании микронов" неуместно  

[Пантер]

Индексный - сишный подход. В с++ принято итераторами пользоваться.

[BRE]

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

Если это обращение ко мне, то мне не понятно почему я спокойно к этому отношусь? 
А точнее мне не понятно какое перераспределение памяти имеется ввиду.

[Alex_cs_gsp]

Отнюдь не всегда перераспределение памяти стоит сотни тысяч команд. Например в винде, выделить блок памяти менее размера одной страницы попросту нельзя, а это 2 или 4 кб, тем не менее, каким то чудом new может вернуть память в один байт.  Поэтому все зависит от диспетчеризации. Никто вам не мешает зарезервировать нужное количество памяти.

[Igors]

Индексный - сишный подход. В с++ принято итераторами пользоваться.

Ну так С++ всего лишь (небольшая) надстройка над базовым С. Так, флигелек в котором живет "наша малышь"  

Если это обращение ко мне, то мне не понятно почему я спокойно к этому отношусь?  
А точнее мне не понятно какое перераспределение памяти имеется ввиду.

Никаких "персональных выпадов" (по крайней мере с моей стороны   ). Просто если речь об эффективности контейнеров, надо говорить/обсуждать применяемые ими "стратегии" (мерзкое слово) распределения памяти/ресурсов, т.к. 95% эффективности определяется этим. Остальные 5% останутся пятью, как бы мы ни старались   Любой контейнер есть "растущий массив" и все зависит от того как он растет.

[Пантер]

Ну так С++ всего лишь (небольшая) надстройка над базовым С. Так, флигелек в котором живет "наша малышь" 

"А мужики-то не знают..."

[BRE]

Ну так С++ всего лишь (небольшая) надстройка над базовым С. Так, флигелек в котором живет "наша малышь" 

Это совершенно не так.
C - это процедурный язык, C++ - объектно-ориентированный.
Между двумя этими подходами огромная разница, начиная от проектировании и заканчивая реализацией задачи. Там все по другому, и кто только не пытался это донести до пользователей, начиная с автора языка. 
А то что синтаксис их похож... ну так исторически сложилось, Страуструп выбрал его.

Просто если речь об эффективности контейнеров, надо говорить/обсуждать применяемые ими "стратегии" (мерзкое слово) распределения памяти/ресурсов, т.к. 95% эффективности определяется этим. Остальные 5% останутся пятью, как бы мы ни старались  Любой контейнер есть "растущий массив" и все зависит от того как он растет.

А какое отношение имеет стратегия распределения памяти к методам доступа. Начали с индексов/итераторов, закончили стратегией распределения. 
В принципе можно обсудить и распределение памяти.