Кто со мной?

[Son Of Pain]

Сообщение от _Bers

Если компилятор её сам за тело цикла не выставит - да. Будит дергаться.

Даже если не говорить об оптимизации - компилятору банально нет смысла это делать. Менять esp в конце итерации, чтобы вернуть его на место вначале - абсолютно бессмысленное действие. Это будет выглядеть примерно так -

L1:
  sub esp, 4
  //тело цикла
  add esp, 4
  jmp L1

[Пепел Феникса]

Даже если не говорить об оптимизации - компилятору банально нет смысла это делать. Менять esp в конце итерации, чтобы вернуть его на место вначале - абсолютно бессмысленное действие. Это будет выглядеть примерно так -

если бы оптимизации не было вообще, то было бы так между прочим, ибо конец блока
а вот даже базовая оптимизация делает примерно так:

{
    char c;
    int i;
    //etc
    for(i=0;i<H;i++)
    {
        //тело
    }
}

[_Bers]

Сообщение от Пепел Феникса

подпрограммы

Всегда думал, что стек выделяется потоку в единственном экземпляре один раз при создании, а дальше идут только прыжки по стеку.
Вход в тело функции - прыжок.
выход - прыжок.

Сама память уже не выделяется и не удаляется

Сообщение от Пепел Феникса

компиляторы имеют довольно хороший оптимизатор.
если хотите можно проверить на gcc(MinGW) и студии.

да и команда sub esp,1 ;//(если без выравнивания)
довольна быстра. потому даже без оптимизации скорость не упадет в общем то.

А если "не в общем то", а конкретно вообще не упадёт?

Программист на с++ не должен:
1. Уповать на компилятор.
2. Думать в терминах другого языка программирования.

Он должен решать задачи максимально эффективным способом на своём уровне, при помощи своего языка.

Вынеси переменную за тело цикла - и ни с кем не имей никаких проблем.

Оставь её в теле цикла - и беги учить ассемблер, что бы теперь следить за каждым компилятором, оптимизировал ли он? Не было ли нерационального падения производительности?

Что проще?

[Пепел Феникса]

Всегда думал, что стек выделяется потоку в единственном экземпляре один раз при создании, а дальше идут только прыжки по стеку.
Вход в тело функции - прыжок.
выход - прыжок.

ну то что вы имели в виду под прыжками, мы сейчас назвали резервированием стека(оно же создание кадра стека).
оно же выделение памяти в стеке.

А если "не в общем то", а конкретно вообще не упадёт?

не значительно.
но такие оптимизации проводят все компиляторы современные.

Что проще?

{
    char c;
    int i;
    //etc
    for(i=0;i<H;i++)
    {
        //тело
    }
}

ок пишите так

Сама память уже не выделяется и не удаляется

кстати, если копнуть глубже то выделение памяти возможно(но не освобождение).

[netrino]

Сообщение от _Bers

Всегда думал, что стек выделяется потоку в единственном экземпляре один раз при создании, а дальше идут только прыжки по стеку.
Вход в тело функции - прыжок.
выход - прыжок.

Сама память уже не выделяется и не удаляется

Прыжков по стеку не происходит, а меняется указатель на вершину стека. Я не говорил, что при входе в подпрограмму выделяется из кучи новый стек, я говорил о том, что при входе в подпрограмму, в стеке сразу выделяется кусок памяти под её переменные. Путём изменения указателя не вершину стека - sp (stack pointer).

А если "не в общем то", а конкретно вообще не упадёт?

вообще не упадёт, потому что выделения (изменения sp) памяти происходит только при входе в подпрограмму, при создании стекового фрейма (во всяком случае во всех тех компиляторах, которые я использовал, даже с отключёнными оптимизациями).

Программист на с++ не должен:
1. Уповать на компилятор.
2. Думать в терминах другого языка программирования.

Он должен решать задачи максимально эффективным способом на своём уровне, при помощи своего языка.

Вынеси переменную за тело цикла - и ни с кем не имей никаких проблем.

Оставь её в теле цикла - и беги учить ассемблер, что бы теперь следить за каждым компилятором, оптимизировал ли он? Не было ли нерационального падения производительности?

программист на C++ должен уже знать ассемблер, перед тем как садиться писать высокопроизводительные программы, должен знать свой компилятор и как наиболее эффективно написать код для него.

[Son Of Pain]

Сообщение от Пепел Феникса

если бы оптимизации не было вообще, то было бы так между прочим, ибо конец блока

Вряд ли ) логичнее все же выглядело бы

sub esp, 4
L1:
   //тело цикла
   jmp L1
add esp,4

Хотя, конечно, такое поведение тоже можно обозвать оптимизацией. Вечная проблема нечетких определений )

[_Bers]

Сообщение от netrino

программист на C++ должен уже знать ассемблер, перед тем как садиться писать высокопроизводительные программы, должен знать свой компилятор и как наиболее эффективно написать код для него.

А ну да, привязываться и запиливаться под конкретный камень/ось/компилятор. Ну-ну.

И там, где проще тупо создать переменную за циклом, и не париться - проявлять чудеса академических знаний и по части компилятора, и по части ассмы, и по части камня, да? Это у вас такой подход к программированию на с++

[netrino]

Сообщение от _Bers

А ну да, привязываться и запиливаться под конкретный камень/ось/компилятор. Ну-ну.

И там, где проще тупо создать переменную за циклом, и не париться - проявлять чудеса академических знаний и по части компилятора, и по части ассмы, и по части камня, да? Это у вас такой подход к программированию на с++

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

[Son Of Pain]

Сообщение от _Bers

Программист на с++ не должен:
1. Уповать на компилятор.
2. Думать в терминах другого языка программирования.

В первую очередь программист на C++ (да и на любом другом языке) должен писать код так, чтобы его было приятно читать. Ты же не будешь спорить с тем, что если переменная объявлена рядом с местом ее использования - это выглядит логичнее, чем pascal-style куча переменных в одном месте?

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

[Пепел Феникса]

логичнее все же выглядело бы

я тоже самое написал, но на плюсах.

И там, где проще тупо создать переменную за циклом, и не париться

а как же минимальная область видимости переменной?
любой компилятор переработает этот цикл.
вообще если хотите, можете вынести в for-init секцию.