В том-то и фишка, что в С++ многие вещи даются "даром" (ну или почти), чего не скажешь о многих других языках. В этом и заключается его сила. По-сути, целью создания языка С++ было создание высокоуровневого ОО-языка, не уступающего в производительности языку Си. Именно С++ впервые показал, что ООП не обязательно должно быть дорогим удовольствием.

Код программы тоже в памяти находится, если вы забыли.
inline функция - это функция, непосредственно встраиваемая в код программы. Этим самым уменьшается время на передачу параметров, но увеличивается размер программы и занимаемая ей ПАМЯТЬ

Daevaorn имел в виду, что в данном случае нет дополнительного расхода памяти по-сравнению с обычным массивом. Кстати, это хорошо видно из ассемблерного листинга.

Это сообщение отредактировал(а) likehood - 22.4.2007, 19:28

Угу. Только оператор [] вектора транслируется в 1-2 машинные команды — куда меньше, чем запихивание параметров в стек, вызов, выполнение операции и возврат.

Все возможные причины, по которым вектор может быть медленнее, уже перечислили. operator [] к ним не относится.

Таак, теперь подумай, если тот код который скрывается за vector::operator[] встроить в место вызова(нет ни передачи параметров, нет вызова функции, нет создания фрейма стека, нет передачи результата), то что получится? Правильно, сокращения расхода "памяти" и соответсвенно увеличение скорости. Вот так вот. Посмотри, кстати, asm листинг и прозрей

А если вызовов 20?
Мы же сравниваем не просто однострочную iniline функцию с вызовом через стек и вызовом inline?

Мы сравниваем конкретную функцию inline с командой непосредственно взятия данных из массива. Эта inline функция практически это и делает! Посмотрите на ее код - я же ее привел. И сравните с кодом a = b[i].

Добавьте туда код остальных методов вектора (даже если ими не пользоваться (кстати, а зачем тогда вектор, правда?) - они что, в воздухе висят? Теперь добавим, что у нас есть вектор int и вектор float - 2 совершенно разных класса скомпилятся. Со всем своим функционалом (которым можно не пользоваться).

Полноте - чудес на свете не бывает, еще раз повторю. Просто к памяти сейчас отношение такое - типа ее много. И получаем операционки, которые на ядро 512 требуют - зато все удобно. Раз схалявил - два схалявил и получаем экзешники по 10 метров с функционалом, "которым необязательно пользоваться".

likehood,  Daevaorn,

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

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

За удобства надо платить. И это закон жизни, а не только программирования. Отсюда правда вытекает еще один лозунг: надо постараться не платить за неудобства - это уже ближе к программированию.

прошу показать где происходит перерасход ресурсов на примере.
vimdiff запущенный на исходники даёт такую картину



По мне так эти асмовые исходники примерно эквивалентны. Основной цикл так вообще один к одному.

Это сообщение отредактировал(а) Mayk - 22.4.2007, 21:07

а какая разница сколько, с каждого inline'a экономим.

мы сравниваем доступ к элементу

ну и где тогда по твоему проигрывает вектор?

а ты знаешь сколько кода генерирует компилятор, допустим, для создания массива не из элементов POD типа? Для вызова деструкторов и т.д. Так что на этом фоне при POD типе в векторе, теряем минимум. А при не POD типе, ещё больший минимум

Неа. Компилятор осуществляет merge'инг. Ну например метода vector::size(). И многих других

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

Мы говорим про доступ к элементам. Ты же всячески уходишь от темы в "общую" болтовню

Mayk, у вектора на три машинных инструкции больше  

  
Vyacheslav(извини если исковеркал), что призван показать твой пример, что для использования вектора в этом контексте надо заюзать еще одну строку кода, так это ему не в плюс..

??? Вот те раз. Посмотрите мои посты. Я как раз и написал в первый раз - общее свое мнение о шабонных классах. 
И то что на моем компиляторе вектор по скорости слегка отстал - это факт, я его просто зафиксировал и написал об этом.

Последние посты - были как раз общие - теоретизировали на тему рессурсов:







Mayk, посмотрите заодно размеры получившихся файлов, если использовать массив и вектор. А по поводу практической идентичности листингов - про это я уже сказал, чем вы хотите меня удивить? вектор ведь тоже на СИ++ написан:



А поповоду незначительноя разницы уже было:





Много пены - мало толку.   

разница сосавляет 371 байт. После strip'а она уменьшается до 296 байтов.


371 байт и 3 машинные инструкции (не входящие в основной цикл процедуры) являются величинами на несколько порядков меньшими чем заявленные



что свидетельствует о преувеличении тормознутости и гигантности stl. 


Это сообщение отредактировал(а) Mayk - 22.4.2007, 21:55

Про какие величины я, простите, упоминал? Про "незначительные"? Или про "несколько десятков тактов (не команд)" процессора? А как я их должен еще охарактеризовать? А про 20% выигрыш в скорости на моем тесте - что имею, то и имею. Можно говорить, что Билдер плохо оптимизирует работу STL, столько же на сколько другой компилятор плохо оптимизирует работу массивов. Это все вода. Поймите главное: STL написана на том же языке! используя те же команды. Это не другой компилятор, не некая сторонняя библиотека - это шаблоны! И компилируются они одновременно с вашим кодом. И если утверждать на 100% - что STL работает быстрее, это то же самое, что говорить - никто не напишет лучше, чем разработчики STL. А ее писали такие же программисты (и может быть пользовались теми же форумами). Именно поэтому STL может быть медленнее стандартных средств, такая же по скорости, но никак не быстрее (если брать уровень программиста одинаковый). Потому, что одни и те же механизмы языка используются. 

А на счет экзешников по 10 метров - это мое обобщенное отношение к современным подходам. Почем линуксоиды не любят форточников? Одна из причин именно - за это. Линукс при том же функционале работает на полном барахле. Там код вылизывают и лишнего не вешают.

На счет килобайтов исходного кода STL.
Да, тут я погорячился. Посмотрел исходники. Их не килобайты. Их Мегабайты. Ну тут уж извиняйте.


Покажите хоть один мой пост, где я назвал STL тормознутой и гигантской? Максимум, что я говорил - это о некоторой потери рессурсов. И это чистая правда, хоть что тут сделай. За исключением разве что результатов теста - там я оговорил четкие цифры, которые выдала конкретно моя машина с конкретно моим компилятором.

Можно, конечно еще поспорить на эту тему - например, посчитать такты процессора для каждой команды и т.п.
Использовать не тепличный бессмысленный тест, а более рабочую программу. все равно результат будет такой-же. Программист всегда будет выбирать: написать быстрее, но готовыми средствами, или изобрести свой велосипед. В некоторых случаях последнее дает ощутимые результаты, а в некоторых нет. Все зависит от задачи и от головы. Можно использовать вектор как в приведенном последнем тесте или "не используя его функционал" - непонятно зачем тогда. А если пользоваться всей мощью вектора - тогда платить придется точно. А так спор близок к теме: кто больше бензина жрет мопед или мерседес. Если их отправить накатом с горки - поверьте одинаково. Но в реальной жизни речь идет не о бензине. Если надо ехать из Питера в Москву - то уж естественно на мерседесе. А если через пробки смотаться в магазин за два квартала - то мопед. ИМХО.

БАЯН. Давайте его заканчивать!   

Темка, однако, полезная... закрепить бы ее на будущее

Всем отписавшимся респект!   

Кэширование оперативной памяти в кэш процессора, я имел в виду.

   Тема тут, конечно, успела еще 2 страницы постов нагрести 

жесть, сколько настрочили... всё не асилил...

ничего не происходит... сколько раз уже это повторить?

International Standard (Programming languages - C++, ISO-IEC, IS-14882, Second edition, 2003-10-15)
слово принуждает в Ожегове посмотри, плз ;)


"дополнительной" памяти нужно ровным счётом столько же, сколько понадобится, если написать то же самое, только в самом коде... короче говоря, дополнительного там ничего нет!



которое работает только с STL-контейнерами?  


Это сообщение отредактировал(а) archimed7592 - 23.4.2007, 19:10