- KpeHDeJIb
- Постоялец
Кукурузо!
> Deft в данном случае не автор, а переводчик... мопэд не его, он просто разместил объяву :))
это не оправдание, переводить надо что-нибудь интересное, а не богом забытый блог какого то васи
KpeHDeJIb
> Что это значит?
Меня это тоже смутило. :)
Наверное там должно быть *arg == 0, но при этом в функции тогда ещё должно быть int * arg.
Может косяки при переводе?
> - Не объявляйте объекты тогда, когда они возможно не будут использованы;
Обычно таки в C++ все так и поступают, объявляют переменные как раз перед их использованием, обратной проблемой страдал Си где нельзя было так делать, но там и "тяжелых" объектов не было.
> - Используйте списки инициализации в конструкторах, вместо operator= для инициализации членов класса;
Правда для POD типов бессмысленно, а с массивами так вообще такое появилось только в C++0x
> - Используйте операцию пре-инкремента (++i) вместо операции пост-инкремента (i++), чтобы избежать создания временных объектов;
> - Избегайте операторов, возвращающих результат по значению (например, operator=);
RVO таки есть везде, главное самому понимать что это значит.
> - Не помещайте в конструкторы большой код и избегайте инициализации членов класса внутри конструкторов (лучше сделать замену этим возможностям, путем создания дополнительных методов, типа setName());
В чем собственно проблема? Иногда конструктор полезен как раз чтобы задать дефолтные значения параметров. И я не говорю про объекты которые вообще бы не должны иметь конструктора по-умолчанию, типа vec2,3,4
> - Используйте кэш в непрерывном блоке памяти для хранения и использования объектов;
Очень, очень сильно зависит от ситуации.
> - При разработке игры, если необходимо, переопределите операции new & delete, а еще лучше – напишите собственный менеджер памяти;
Странное правило "если необходимо", тут к любому правилу надо написать тогда "если необходимо", что за фигня.
> - При выделении памяти часто оказывается проще выделить сразу n * count байт, чем выделить count байт n раз;
Капитан не дремлет? Или с чем связан этот совет?
> - Избегайте использования виртуальных функций;
"если необходимо"
> - Отключайте директивы отладчика при создании исполняемого файла;
"если необходимо"
> - Избегайте использования большого количества исключений;
"если необходимо"
> - Настройте компоновщик так, чтобы он удалял неиспользуемые функции и классы;
"если необходимо"
> - При создании исполняемых файлов включайте наивысший уровень оптимизации;
"если необходимо"
> - Не делайте встраиваемыми большие функции;
"если необходимо"
> - Будьте осторожны с использованием контейнеров из библиотеки STL. Предпочтительнее для хранения элементов лучше использовать вектора, а вместо std::string использовать C-строки;
"если необходимо"
> - Современные компиляторы хорошо оптимизируют код шаблонов классов, поэтому использование шаблонов может повысить производительность за счет удаления похожего кода.
"если необходимо"
Итог: статья скорее хорошая чем плохая, но толковых вещей в ней не так уж и много, слишком много мест где можно вставить "если необходимо" и есть целый веер исключений, нельзя научиться писать эффективный код на С++ используя статьи, необходимо много писать на С++, по другому никак. Ну и картинку вам, в догонку:
KpeHDeJIb
а как же 1.21 гигаватт ? :)
Ох :)
Executor
>> Можно пример, где пре-инкремент будет быстрее, чем пост-инкремент?
В статье написано, что это имеет смысл при использовании этих операций над user-defined типами. Мне лично это показалось естественным, если при пост-инкременте будет создаваться нетривиальный временный объект.
Yuko
Спасибо, поправил.
ashujon
>>я думаю автор начал прогать не более года назад и по совместительству начинающий кэп
Если это про меня - то нет, программированием занимаюсь не один год, если про автора этой статьи (я ее переводил, внизу указана ссылка, перевод достаточно точный, я не пытался что-то выдумывать), то вряд ли он занимается кодингом менее 1 года :)
Executor Участник
Кукурузо!
Ну вот пусть автор подкрепит эти заявления примером кода. Я вот реально никогда не сталкивался с такой проблемой и мне интересно, что нужно сделать, чтобы была тут разница.
Ммм.. ну, скажем, абстрактный (наверное, очень абстрактный :) ) пример - массив векторов 3х100 или более. Не думаю, что создание копии такого объекта будет незаметно, особенно, если это происходит часто.
это не оправдание, переводить надо что-нибудь интересное, а не богом забытый блог какого то васи
Это перевод не из богом забытого блога.. В конце статьи копирайты :)
KpeHDeJIb & Executor
Меня это тоже смутило. :)
Наверное там должно быть *arg == 0, но при этом в функции тогда ещё должно быть int * arg.
Может косяки при переводе?
Нет, сверил с оригиналом - все верно. Автор имеет ввиду умножение целого числа на ноль. Видимо, он пытался таким образом подчеркнуть то, что код очень часто не проходит дальше, после примера это написано:
Если arg принимает значение нуль очень часто
Я это не придумал, честно :)
В чем собственно проблема? Иногда конструктор полезен как раз чтобы задать дефолтные значения параметров. И я не говорю про объекты которые вообще бы не должны иметь конструктора по-умолчанию, типа vec2,3,4
>
Встраивание зачастую является причиной необычайно громоздких функций. Компиляторы с легкостью могут проигнорировать ваши директивы inline, не сказав об этом ни слова. Более того, компилятор самостоятельно может сделать некоторые функции встраиваемыми. Это еще одна причина, по которой не стоит нагружать конструкторы большим количеством кода
> - При выделении памяти часто оказывается проще выделить сразу n * count байт, чем выделить count байт n раз;
Капитан не дремлет? Или с чем связан этот совет?
Имелось ввиду, что быстрее будет выделить большой блок памяти один раз, чем много раз выполнять операцию по выделению памяти для нескольких более мелких блоков.
2KpeHDeJIb
За картнику спасибо, очень саркастично :)
Мне кажется, что копирайты в конце статьи я чисто для себя поставил, чтобы знать? Я не писал эту статью, это перевод, причем перевод дословный (конечно, не через Google Translate).
Единственное, что там не от автора - раздел "Итоги", остальное - подлинник.
P.S.
И я не читаю книги "C++ за 21 день/час". Да, я начинающий гейм-девелопер, и мои знания в этой области на данный момент стремятся к нулю. Но я не начинающий программист.
Спасибо за комменты :) Статья действительно не новая, написана автором давно, в следующий раз постараюсь найти что-нибудь поинтереснее, если позволите ^^
innuendo
> а как же 1.21 гигаватт ? :)
В оригинале 1.21 джигаватт было :D
Deft
переведи плз это http://www.spuify.co.uk/?p=454
для новичков будет полезно...
Автор, если ты пишешь статью по оптимизации, то голословные советы никого не интересуют, особенно в случаях, когда вовсе не очевидно, что твоим советом вместо меня не сможет воспользоваться мой оптимизирующий компилятор. Уж удосужься, сделай ссылки на примеры кода, использованный компилятор, его опции и время выполнения до/после.
KpeHDeJIb
> > а как же 1.21 гигаватт ? :)
> В оригинале 1.21 джигаватт было :D
это они типа не расслышали
// Offtop
2Pushkoff
Да no problems ;)
Правда, вторая статья о виртуальных функциях вызывает сомнения, т.к. в комментах один из участников написал, что тесты не совсем подходящие..
Deft
> Видимо, он пытался таким образом подчеркнуть то, что код очень часто не проходит дальше
Автор то вроде крутой мужик, а код какой-то странный :)
Executor
> Хотел бы я посмотреть на игру, в которой был бы ботлнек в виртуальных функциях.
> :)
С миру по ниточке - нищему рубаха ;) А вообще, стоимость вызова вирт. ф-ции это +2 инструкции.
З.Ы. Есть замечательный документ от ISO - Technical Report on C++ Performance. Там все хорошо расписано, что по чем и почему.
StiX
> Есть замечательный документ от ISO - Technical Report on C++ Performance. Там
> все хорошо расписано, что по чем и почему.
После которого надо взять и прочитать мануал процессора, вот тогда станет ясно сколько они стоят.
На PC они дешевъе, на конзолях/телефонах - нет.
Тема в архиве.