| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > C/C++: Общие вопросы > array, vector или new...[] |
| Автор: boriska 20.4.2007, 23:45 | ||
задание в Lippman'e
Путаюсь в догадках Помогити, аргументируя please. |
| Автор: boriska 21.4.2007, 00:20 |
| предположения конечно имеются : а) массив 1. потому что знаем размер 2. с набором будем работать локально б) vector не известно кол-во счетов и можно использовать vector::push_back() в) динамический массив 1. знаем размер 2. удобно передать указатель но не уверен ... |
| Автор: Daevaorn 21.4.2007, 00:32 |
| boriska, ты получаешь приз за правильный ответ |
| Автор: archimed7592 21.4.2007, 16:10 |
| а я бы вектор использовал... его не нужно уничтожать вызывающей ф-ции (в отличие от дин. массива)... |
| Автор: vinter 21.4.2007, 17:18 | ||
зато работает медленнее, и возможно неэффективно использует память. |
| Автор: archimed7592 21.4.2007, 17:22 | ||
почему? std::vector<myType> v (elem_size)... да и vector::reserve никто не отменял |
| Автор: vinter 21.4.2007, 17:30 | ||
| помещение в вектор ф-ия значит уже медленнее, а также вся манипуляция идет через высокоуровненвые механизмы это опять же временные затраты. да и если бы вектор был действительно лучшим по всем параметром, он бы давно стал заменой new\delete а этого не происходит..
дополнительные усилия |
| Автор: apook 21.4.2007, 17:38 |
| vector классный массив он лучше чем array В языке высокого уровня Python массивы имеют примерно такую же природу что vector Вернее строка там есть список, и типов нет или есть, скорость конечно это аргуметнт , но что уж при нынешних скоростях этот параноидальный скоростной погоня за скорост |
| Автор: archimed7592 21.4.2007, 17:54 | ||||
скажем так: чем по (трудо-, время-)затратам отличаются записи v[i] и a[i], если v - vector, a - массив, созданный при помощи new.
конечно... когда используют new, размер массива не указывают - он сам догадывается... ну и в итоге... vector и ещё раз vector! |
| Автор: vinter 21.4.2007, 18:07 | ||||
неа, но мы получаем что vминус new только в операции удаления, а это уже не смертельно
я не знаю как реализован этот оператор, поэтому про него ниче не скажу, а вот push будет раьотать полюбому медленнее. |
| Автор: archimed7592 21.4.2007, 18:13 | ||||
а кто заставляет использовать push, если в нём нет нужды (объём массива заранее известен)?
точнее, ты сейчас сказал, что для вектора усилий нужно меньше (не нужно напрягаться об удалении) |
| Автор: vinter 21.4.2007, 18:37 | ||
результат new\delete - 1572 результат вектора - 26432, думая дальнейший спор не уместен, а преимущество более чем в 10 раз, само за себя говорит. компилилось в VS2003, дебаг |
| Автор: nickless 21.4.2007, 18:59 |
| Хм, а у меня (gcc 4.1.2) результаты: вектор: 3750 без оптимизации, 630 с -O2 new/delete: 1000 без оптимизации, 450 с -О2 Получается верктор только в 1,4 раза медленее, имхо если не нужно выжимать последние миллисекунды - самое то. |
| Автор: vinter 21.4.2007, 19:03 |
| если release то 1400 и 700, но все равно разница ощутима. и это хороший аргумент в пользу new |
| Автор: boriska 21.4.2007, 19:09 | ||||
разница получается из-за того что при
время тратиться на создание временного объекта, инициализацию этим объектом, а потом удаление его. Даже при
у меня натикало 11968, а вариант с динамическим выделением - всего 890 |
| Автор: archimed7592 21.4.2007, 19:20 | ||
g++-3.4.2+stlport-5.1.3 в релизе(про дебаг отдельно) даёт 234 против 343 (vector и new соответственно)... насчёт дебага: прелесть контейнеров в том, что, в дебаг-режиме они проверяют всё на логические ошибки... к примеру, если после изменения контейнера использовать итератор, полученный до этого изменения, то он(итератор) кинет исключение(smart-iterator), в релизе же даже не пикнет(fast-iterator)... насчёт менеджера памяти: изначальный вариант я не поленился запустить 25 раз (только new, vector даже пробовать не стал)... каждый раз результат был всё меньше и меньше, причём, разрыв между первым запуском и последним был чуть ли не в 10 раз... короче говоря результат сильно зависит и от менеджера памяти и от операционной системы и от объёма оперативной памяти... |
| Автор: nickless 21.4.2007, 19:26 | ||||
Ничего там не тратится, это же не конструктор копирования.
Оптимизацию включи Скорость нужно проверять на релизной сборке, потому что именно она будет потом использоваться. |
| Автор: Mayk 21.4.2007, 19:30 | ||
НЕ ВЕРНО. Запись vector<int> (50000) создает вектор из 50000 ПРОИНИЦИАЛИЗИРОВАННЫХ элементов.
|
| Автор: archimed7592 21.4.2007, 19:33 |
| кстати, ещё одна "мелочь": вектор имеет инициализированные значения (0)... отсюда и разница такая... а вот как объяснить, что в цикле записи вектор работает быстрее чем дин-массив я затрудняюсь... но говорит это только в его пользу Добавлено через 40 секунд Mayk, опередил |
| Автор: boriska 21.4.2007, 19:36 | ||
| nickless - за второе замечание спасибо а по поводу
готов спорить.... to Mayk - |
| Автор: nickless 21.4.2007, 19:54 |
Я вообще имел ввиду и Какой именно временный объект там создаётся? int? То что вектор инициализирует память, с этим я не спорю. |
| Автор: vinter 21.4.2007, 22:36 | ||
то что он инициализируется "это его проблемы", тесты закончились у всех поразному, у меня new дало двойной прирост памяти. так что я остаюсь при своем мнениии. |
| Автор: JackYF 21.4.2007, 23:35 | ||
Vector нужен, когда количество элементов заранее не известно. Точка. Увеличение скорости даже на 10% иногда очень важно. А уж в данному случае, когда прирост 50-100%... В обертках, кроме того, могут использоваться дополнительные переменные для удобства реализации остальных функций.
вот... иногда инициализация такая не нужна. Ну а тут и ты не прав... Кто же в дебаге скорость проверяет? Инлайнинг функций-то в дебаге не производится... как минимум. А, уже сказали до меня по этому поводу... А вообще по ходу поддерживаю. Если размер заранее известен, то даже 50% прирост скорости весьма существенен. Векторное - векторному. В данном случае использовать вектор ради всего лишь автоматического удаления... имхо, не то. |
| Автор: Lomir 21.4.2007, 23:35 | ||
| 50000000 Это слишком большое число для масивов, т.к. время работы зависит от свободной памяти, распределение страниц, виртуальной памяти и т.д. У меня на VS 2005 1 раз вектор работал 2сек, 2 раз около 1,5 все последущие 0,7 сек. Масив 0,5 сек. Привиду свой тест:
Вектор: 1,7сек Масив: 1,5сек Вектор немного отстает, но если им правильно пользоваться то отставание не большое - максимум процентов 20-35. ИМХО во всех программах особо не чуствительных к скорости лучши пользоваться вектором. Кроме того вектор непожирает лишнюю память, и не инициализирует обьекты пока они не нужны. Например зачем нам иметь масив из 100000 обьектов (причем все будут инициализированы), если мы пользуем в 80% тока 100. |
| Автор: JackYF 21.4.2007, 23:44 | ||||
Офигеть... ты посты выше читал? Цитату об определение вектора и инициализации? Вектор память лишнюю не пожирает? Да чтобы сделать операцию добавления элемента квазиконстантной по времени, он всегда резервирует какой-то процент от текущей запрошенной памяти... Намного быстрее объявить 1000000 элементов сразу без инициализация, чем потом 20 раз перераспределять и/или выделять поблоково эти данные. Массив динамический вообще не инициализирует память...
Вообще говоря, это немало. Кроме того - это если действительно умело пользоваться. Если не очень умело, то цифра может заметно возрасти. Кроме того, как уже писали выше, поведение вектора более дерганое при выделении, и тут еще менеджер памяти может чего-то фигачить... |
| Автор: archimed7592 21.4.2007, 23:53 | ||||
| Lomir, ты не понял... push_back мы не используем... мы ставим и вектор и new в равные условия - заранее сообщаем длину массива и используем оператор [] для доступа к эдементам... ммм... про прирост памяти ты умолчал... насчёт "его проблемы" - если я не ошибаюсь, то эта "проблема" решается путём смены аллокатора (второй шаблонный параметр вектора...) угу, а то, что при доступе к объектам скорость +30% (хотя, я это объяснить не могу) тебя не смущает...
а, что, если от неё можно избавится? ;) ну и в заключении: кто-нибудь может объяснить то, что доступ к элементам для вектора быстрее, чем для массива созданного с помощью new? |
| Автор: Anikmar 22.4.2007, 00:49 |
| Достаточно прикольный спор получился. Мне кажется что-то не так - ведь вектор изнутри организован стандартными функциями. Я уже в свое время проводил тест: какой доступ быстрее через указатель или через скобки. Скобки оказались ощутимо быстрее. Но этот результат получился только при приближении задачи к реальной - вставке дополнительных команд в цикл. Ведь в реальности нет задач просто прогнать цикл по массиву без каких-либо действий. Мне кажется, что в векторе очень хорошо используются регистровые переменные для настройки оптимизатора. Так как тест проводился в голом виде - просто индексация, то вектор и показал с оптимизатором себя быстрее. На самом деле время доступа у массива и вектора не должно отличаться - так как они используют одинаковые механизмы. В живой задаче, где между изменениями индекса будут находиться другие команды, которые не позволят оптимизатору сохранить регистры вектор должен быть медленнее априоре - так как у него обязательно будут дополнительные механизмы обслуживания сервиса. ИМХО: Для большинства задач вектор подходит идеально, но как любая универсальная штуковина она просто ОБЯЗАНА съедать больше ресурсов - за удобство надо платить. В задачах, где рессурсы критичны, собственное хранилище данных несомненно будет более экономичное. Любой мастер своего дела (в любой специальности) имеет как наборы стандартных инструментов, так и собственные приспособления, с помощью которых он достигает лучшего результата. Так и в программировании. Так что правы все стороны. |
| Автор: JackYF 22.4.2007, 01:10 | ||||||
да как в принципе такое может быть? что может быть быстрее доступа (прямого) по памяти? (на user-уровне). Не верю. Разве что кэширование какое-нибудь, блин... причем хитро, очень хитро работающее...
Геморрой, имхо. В массиве ничего дополнительно делать не надо.
Какими? Автоматическое удаление? В данном случае - выделки не стоит.
выложи полный код еще раз (если он изменился), на котором ты получил +30%. А я у себя проверю... что получится. |
| Автор: vinter 22.4.2007, 08:58 |
тьфу..описался я |
| Автор: likehood 22.4.2007, 11:48 |
| Согласен с Lomir'ом на счет размера массива: он должен быть не слишком большим, чтобы не сказывалось обращение к свопу. Только в его варианте нужно вместо push_back обращаться к элементам по индексам. Тогда скорость работы вектора и массива будут совершенно одинаковыми (с учетом статистических погрешностей) - проверено на VS 2003. |
| Автор: Vyacheslav 22.4.2007, 17:15 | ||
И в конце концов, если мы гонимся за эффективностью и не хотим отказываться от удобств, предоставляемых вектором, кто мешает обращаться с ним, как с массивом?
|
| Автор: archimed7592 22.4.2007, 17:36 | ||||||
точнее они есть, но если их не использовать (работать так же как и с массивом)
вектор - тоже геморрой... но он уже готовый... точно также как и готовые в boost пулы... также, как и этот аллокатор, который можно сделать один раз и не парится универсальность хотя бы... ну это каждому по вкусу...
http://forum.vingrad.ru/index.php?showtopic=147290&view=findpost&p=1107431 |
| Автор: Anikmar 22.4.2007, 17:51 | ||
А что, в векторе нет контроля выхода за пределы индекса? |
| Автор: Daevaorn 22.4.2007, 17:54 |
только в методе at(size_t) |
| Автор: nickless 22.4.2007, 17:56 |
есть, но не во всех методах, например в operator[] нет, а в at() есть. |
| Автор: Mayk 22.4.2007, 18:08 | ||||
Она не обязана быть в []. Но МОЖЕТ присутствовать в отладочных версиях.
|
| Автор: Anikmar 22.4.2007, 18:24 | ||
| Вектор является ведь шаблонным классом. И когда идет вызов переменной типа Vector - то передается как минимум 2 адреса: самого объекта и функции, которую необходимо вызвать. Соответственно - вот дополнительный сервис. И вообще спор этот с моей точки зрения абсолютно бессмысленен. Вектор ОБЯЗАН быть медленнее - только потому, что это высокоуровневый объект (класс). Со всеми вытекающими отсюда накладными расходами - код дополнительных методов и т.п. Отсюда же следует, что вектор ОБЯЗАН быть удобнее - на то это и есть высокоуровневый объект. Мне стало интересно - я слегка модернизировал приведенный тест - так, чтобы он всетак ближе был к реальности. Я избрал такой вариант:
Специально сделал массив небольшим, помешал оптимизатору вовсю использовать регистровые переменные, режим включил релизный. Если отбросить отклонения из-за сторонних процессов (специально сделал несколько проходов), то вектор однозначно отстает от массива. Я и так был в этом уверен на 99% (чудес на свете не бывает), но тут в обсуждении все по-разному говорили, вот я и решил сам посмотреть. В среднем массив быстрее вектора примерно на 20% и это абсолютно нормально. |
| Автор: Mayk 22.4.2007, 18:33 | ||||
Не стоит обобщать свой опыт на все компиляторы и все оптимизаторы.
Как мы видим, всё совсем не так однозначно. |
| Автор: Daevaorn 22.4.2007, 18:37 | ||||
Абсолютная неправда. Добавлено через 1 минуту и 1 секунду
а inline? |
| Автор: archimed7592 22.4.2007, 18:41 |
| я уже говорил выше, что IS принуждает компилятор ф-ции, определённые внутри класса далеть inline... соответственно ничего никуда не передаётся и нету нигде накладных расходов... |
| Автор: Anikmar 22.4.2007, 18:44 |
| А что такие цифры огромные? На самом деле я не обобщаю на все компиляторы, я взываю к здравому смыслу. Вектор написан на Си и использует абсолютно такую же технологию как и голый массив - это же шаблон! И где-то там внутри сидит оператор доступа к массиву - его можно посмотреть под отладчиком: const_reference operator[](size_type __n) const { return *(begin() + __n); } Только чтобы получить значение по этому адресу - как минимум происходит вызов функции ( вонкретном случае оператора []) И нельзя заставить вектор быть быстрее голого массива - он ведь призван сделать массив удобнее - так как является надстройкой над стандартным массивом. Конкретные тесты на скорость на самом деле достаточно условны: разница между командами - несколько десятков тактов процессора, и на таких небольших величинах заемтна особо не будет. Как у меня: В режиме отладки вектор медленее массива в 2 раза В режиме без оптимизации - медленнее примерно на 2% В режиме с оптимизацией - примерно 20% Можно для интереса запустить на всю ночь, но совершенно нет никакого интереса этим заниматься. Просто бессмысленный спор - вот и все. Я на форуме обратил внимание, что многие очень болезнено реагируют на любые попытки критики STL (на себе в свое время изучил) Я не критикую STL - а просто объяаляю факт: вектор слегка медленнее, но удобнее. И спорить с этим просто бессмысленно - так как даже в некоторых описаниях STL это прямо говориться. |
| Автор: Daevaorn 22.4.2007, 18:47 | ||
что такое "IS"? И как оно "принуждает"? |
| Автор: Anikmar 22.4.2007, 18:49 | ||
В любом учебнике по Си сказано, что inline функция увеличивает скорость, но в качестве накладных расходов - использует дополнительную память. Поверьте, даром ничего не бывает - если где-то прибавилось (в данном случае удобства) - значит где-то убавится (в данном случае скорости и памяти). Не понимаю, зачем так болезненно это воспринимать? На этом, я пожалуй раскланяюсь - спор ни о чем. Пустое. |
| Автор: Daevaorn 22.4.2007, 18:52 | ||
В этой фразе явно видно непонимание сути inline. Что такое "дополнительная память"? Как раз случай с вектором, это прямое доказательство ложности данного высказывания. |
| Автор: likehood 22.4.2007, 19:01 |
В том-то и фишка, что в С++ многие вещи даются "даром" (ну или почти), чего не скажешь о многих других языках. В этом и заключается его сила. По-сути, целью создания языка С++ было создание высокоуровневого ОО-языка, не уступающего в производительности языку Си. Именно С++ впервые показал, что ООП не обязательно должно быть дорогим удовольствием. |
| Автор: Anikmar 22.4.2007, 19:13 | ||
Код программы тоже в памяти находится, если вы забыли. inline функция - это функция, непосредственно встраиваемая в код программы. Этим самым уменьшается время на передачу параметров, но увеличивается размер программы и занимаемая ей ПАМЯТЬ |
| Автор: likehood 22.4.2007, 19:26 |
| Daevaorn имел в виду, что в данном случае нет дополнительного расхода памяти по-сравнению с обычным массивом. Кстати, это хорошо видно из ассемблерного листинга. |
| Автор: Void 22.4.2007, 19:40 | ||
Угу. Только оператор [] вектора транслируется в 1-2 машинные команды — куда меньше, чем запихивание параметров в стек, вызов, выполнение операции и возврат. Все возможные причины, по которым вектор может быть медленнее, уже перечислили. operator [] к ним не относится. |
| Автор: Daevaorn 22.4.2007, 19:42 | ||
Таак, теперь подумай, если тот код который скрывается за vector::operator[] встроить в место вызова(нет ни передачи параметров, нет вызова функции, нет создания фрейма стека, нет передачи результата), то что получится? Правильно, сокращения расхода "памяти" и соответсвенно увеличение скорости. Вот так вот. Посмотри, кстати, asm листинг и прозрей |
| Автор: Anikmar 22.4.2007, 20:35 | ||
А если вызовов 20? Мы же сравниваем не просто однострочную iniline функцию с вызовом через стек и вызовом inline? Мы сравниваем конкретную функцию inline с командой непосредственно взятия данных из массива. Эта inline функция практически это и делает! Посмотрите на ее код - я же ее привел. И сравните с кодом a = b[i]. Добавьте туда код остальных методов вектора (даже если ими не пользоваться (кстати, а зачем тогда вектор, правда?) - они что, в воздухе висят? Теперь добавим, что у нас есть вектор int и вектор float - 2 совершенно разных класса скомпилятся. Со всем своим функционалом (которым можно не пользоваться). Полноте - чудес на свете не бывает, еще раз повторю. Просто к памяти сейчас отношение такое - типа ее много. И получаем операционки, которые на ядро 512 требуют - зато все удобно. Раз схалявил - два схалявил и получаем экзешники по 10 метров с функционалом, "которым необязательно пользоваться". likehood, Daevaorn, Я немного не понимаю суть спора: неужели вы серьезно считаете, что функционал STL не потребляет дополнительных ресурсов? С чем вы спорите? Мое мнение: STL удобна, но расплачиваться приходится некоторым перерасходом ресурсов (памяти, скорости или того и другого). Ваше мнение: Ни фига - этот функционал ничего не пожирает, он достается даром. Т.е. все килобайты исходного кода STL - это все ерунда и ни памяти ни времени процессора она не отнимает. Продолжать дискуссию я просто не вижу смысла. За удобства надо платить. И это закон жизни, а не только программирования. Отсюда правда вытекает еще один лозунг: надо постараться не платить за неудобства - это уже ближе к программированию. |
| Автор: Mayk 22.4.2007, 21:01 | ||||||
прошу показать где происходит перерасход ресурсов на примере. vimdiff запущенный на исходники даёт такую картину
По мне так эти асмовые исходники примерно эквивалентны. Основной цикл так вообще один к одному. |
| Автор: Daevaorn 22.4.2007, 21:08 | ||||||||||||
а какая разница сколько, с каждого inline'a экономим.
мы сравниваем доступ к элементу
ну и где тогда по твоему проигрывает вектор?
а ты знаешь сколько кода генерирует компилятор, допустим, для создания массива не из элементов POD типа? Для вызова деструкторов и т.д. Так что на этом фоне при POD типе в векторе, теряем минимум. А при не POD типе, ещё больший минимум
Неа. Компилятор осуществляет merge'инг. Ну например метода vector::size(). И многих других
Программы делают люди и для людей, поэтому критерий "удобно" в этом случае приоритетный.
Мы говорим про доступ к элементам. Ты же всячески уходишь от темы в "общую" болтовню |
| Автор: vinter 22.4.2007, 21:14 | ||
Mayk, у вектора на три машинных инструкции больше
Vyacheslav(извини если исковеркал), что призван показать твой пример, что для использования вектора в этом контексте надо заюзать еще одну строку кода, так это ему не в плюс.. |
| Автор: Anikmar 22.4.2007, 21:34 | ||||||||||
??? Вот те раз. Посмотрите мои посты. Я как раз и написал в первый раз - общее свое мнение о шабонных классах. И то что на моем компиляторе вектор по скорости слегка отстал - это факт, я его просто зафиксировал и написал об этом. Последние посты - были как раз общие - теоретизировали на тему рессурсов:
Mayk, посмотрите заодно размеры получившихся файлов, если использовать массив и вектор. А по поводу практической идентичности листингов - про это я уже сказал, чем вы хотите меня удивить? вектор ведь тоже на СИ++ написан: А поповоду незначительноя разницы уже было:
Много пены - мало толку. |
| Автор: Mayk 22.4.2007, 21:50 | ||||||||
разница сосавляет 371 байт. После strip'а она уменьшается до 296 байтов.
371 байт и 3 машинные инструкции (не входящие в основной цикл процедуры) являются величинами на несколько порядков меньшими чем заявленные что свидетельствует о преувеличении тормознутости и гигантности stl. |
| Автор: Anikmar 22.4.2007, 22:59 | ||||
Про какие величины я, простите, упоминал? Про "незначительные"? Или про "несколько десятков тактов (не команд)" процессора? А как я их должен еще охарактеризовать? А про 20% выигрыш в скорости на моем тесте - что имею, то и имею. Можно говорить, что Билдер плохо оптимизирует работу STL, столько же на сколько другой компилятор плохо оптимизирует работу массивов. Это все вода. Поймите главное: STL написана на том же языке! используя те же команды. Это не другой компилятор, не некая сторонняя библиотека - это шаблоны! И компилируются они одновременно с вашим кодом. И если утверждать на 100% - что STL работает быстрее, это то же самое, что говорить - никто не напишет лучше, чем разработчики STL. А ее писали такие же программисты (и может быть пользовались теми же форумами). Именно поэтому STL может быть медленнее стандартных средств, такая же по скорости, но никак не быстрее (если брать уровень программиста одинаковый). Потому, что одни и те же механизмы языка используются. А на счет экзешников по 10 метров - это мое обобщенное отношение к современным подходам. Почем линуксоиды не любят форточников? Одна из причин именно - за это. Линукс при том же функционале работает на полном барахле. Там код вылизывают и лишнего не вешают. На счет килобайтов исходного кода STL. Да, тут я погорячился. Посмотрел исходники. Их не килобайты. Их Мегабайты. Ну тут уж извиняйте.
Покажите хоть один мой пост, где я назвал STL тормознутой и гигантской? Максимум, что я говорил - это о некоторой потери рессурсов. И это чистая правда, хоть что тут сделай. За исключением разве что результатов теста - там я оговорил четкие цифры, которые выдала конкретно моя машина с конкретно моим компилятором. Можно, конечно еще поспорить на эту тему - например, посчитать такты процессора для каждой команды и т.п. Использовать не тепличный бессмысленный тест, а более рабочую программу. все равно результат будет такой-же. Программист всегда будет выбирать: написать быстрее, но готовыми средствами, или изобрести свой велосипед. В некоторых случаях последнее дает ощутимые результаты, а в некоторых нет. Все зависит от задачи и от головы. Можно использовать вектор как в приведенном последнем тесте или "не используя его функционал" - непонятно зачем тогда. А если пользоваться всей мощью вектора - тогда платить придется точно. А так спор близок к теме: кто больше бензина жрет мопед или мерседес. Если их отправить накатом с горки - поверьте одинаково. Но в реальной жизни речь идет не о бензине. Если надо ехать из Питера в Москву - то уж естественно на мерседесе. А если через пробки смотаться в магазин за два квартала - то мопед. ИМХО. БАЯН. Давайте его заканчивать! |
| Автор: console 23.4.2007, 00:36 |
| Темка, однако, полезная... закрепить бы ее на будущее Всем отписавшимся респект! |
| Автор: JackYF 23.4.2007, 16:50 |
Кэширование оперативной памяти в кэш процессора, я имел в виду. |
| Автор: archimed7592 23.4.2007, 19:09 | ||||||
жесть, сколько настрочили... всё не асилил...
International Standard (Programming languages - C++, ISO-IEC, IS-14882, Second edition, 2003-10-15) слово принуждает в Ожегове посмотри, плз ;)
которое работает только с STL-контейнерами? |
| Автор: Daevaorn 23.4.2007, 19:24 | ||
Я не про слово спрашивал, а про его суть в том конкретном контексте в котором оно было написано. По этому самому стандарту, который ты привел, "принудить" компилятор не может даже слово inline. Так что уход от ответа, это не очень хороший стиль разговора;) |
| Автор: archimed7592 23.4.2007, 19:28 |
| ааа... ты об этом ну если компилятор соответствует Стандарту и ф-ция может быть заинлайнена, то это произойдёт... я это имел ввиду... |
| Автор: JackYF 23.4.2007, 19:35 | ||
А если серьезно, то у нынешних процессоров кэши обоих уровней и конвейера настолько не поддаются систематиации, то вполне могло быть и такое. Да! В твоих тестах - чей тест первым запускался - вектора или массива? Добавлено через 2 минуты
кажись, все-таки нет. inline - в стандарте, как уже говорили - всего лишь рекомендация. Формально компилятор имеет полное право этого не делать. Кажись, по стандарту. |
| Автор: archimed7592 23.4.2007, 19:42 | ||
ну дык... рекурсию хоть укакайся не заинлайниш... потому и в рекомендательном виде (хотя, совр. компиляторы оч хорошо рекурсию разворачивают)...
|
| Автор: JackYF 23.4.2007, 19:54 |
не, это понятно. В плане, компилятор, всего лишь Вот хороший компилятор, поддерживающий стандарт, конечно, из ресурсов системы выбьется, но сделает все, что сможет |
| Автор: Earnest 24.4.2007, 08:03 |
| Да ладно вам. Inline, конечно, рекомендательный характер носит, но это не значит, что компилятор будет на него плевать, если хочет (при соответствующих опциях, конечно). Просто это зависит от контекста. Например, куча вложенных вызовов и все хотят быть inline. Так что у бедного компилятора регистры из ушей вылезают... Поэтому ему и разрешено самому определять, что тут инлайнить, а что нет. И угадать это сложно. А в тривиальных случаях - можно не сомневаться, сделает. Если мы говорим не наколенном компиляторе от Вася Пупкин и Со. Поэтому лучшие друзья программиста - профайлер с отладчиком. |
| Автор: JackYF 24.4.2007, 16:28 |
| |