i++ против ++i, спор однако Опции

[Red Devil]

Я согласен с автором в том, что опен соурс программисты слишком непрофиссионально относятся к работе. В большенстве своем пишут на Си, те кто пишут на С++ используют его неправильно.
Стоит хотя бы исходные коды посмотреть, ужас, ужас. Естественно все будет тормозить, когда циклы не оптимизируется, пишется i++, вместо ++i, функция вызыова размерности вызывается каждый при проходе цикла, вместо того чтобы ее сохранить при начале проходе и сравнивать значение. Лишние переменные с неопределенными сроком жизни, отсуствие применения паттернов проектирования - это я его могу продолжать еще долго. Привычка пихать все в классы, ничего не разделяя. На первый взгляд кажется что типа это дело автора опен соурс, но это напрямую влияет на архитуктуру проекта и того кто будет в дальшнейшем его развивать. Большенство проектов умирают, потому что никто не хочет поддерживать тот убогий код, который был заложен автором при разработке, в том числе и сам автор.
Статью читал где-то месяц назад, про программистов во всем согласен, что там написано.

Сообщение отредактировал Red Devil - 20.7.2008, 11:29

[Tonal]

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

struct A {
  A() : m_val(0) {}
  A(int val) : m_val(val) {}
  A & operator ++ () {
    ++m_val;
    return *this;
  }
  
  A operator ++(int) {
    A temp(*this);
    ++*this;
    return temp;
  }
  bool operator ==(const A& x) {
    return m_val == x.m_val;
  }
  bool operator !=(const A& x) {
    return m_val != x.m_val;
  }

  private:  
    int m_val;
};

int f1(A cur, const A& end) {
  int r = 0;
  for (; cur != end; ++cur)
    ++r;
  return r;
}

int f2(A cur, const A& end) {
  int r = 0;
  for (; cur != end; cur++)
    ++r;
  return r;
}

g++ (GCC) 3.4.5 (mingw-vista special r3)
>g++ -S -O1 iter.cpp

    .file    "iter.cpp"
    .text
    .align 2
.globl __Z2f11ARKS_
    .def    __Z2f11ARKS_;    .scl    2;    .type    32;    .endef
__Z2f11ARKS_:
    pushl    %ebp
    movl    %esp, %ebp
    pushl    %ebx
    movl    12(%ebp), %ebx
    movl    $0, %ecx
    movl    8(%ebp), %eax
    movl    %eax, %edx
    cmpl    (%ebx), %eax
    je    L9
L7:
    incl    %ecx
    leal    1(%edx), %eax
    movl    %eax, %edx
    cmpl    (%ebx), %eax
    jne    L7
    movl    %eax, 8(%ebp)
L9:
    movl    %ecx, %eax
    popl    %ebx
    popl    %ebp
    ret
    .align 2
.globl __Z2f21ARKS_
    .def    __Z2f21ARKS_;    .scl    2;    .type    32;    .endef
__Z2f21ARKS_:
    pushl    %ebp
    movl    %esp, %ebp
    pushl    %ebx
    movl    12(%ebp), %ebx
    movl    $0, %ecx
    movl    8(%ebp), %eax
    movl    %eax, %edx
    cmpl    (%ebx), %eax
    je    L20
L18:
    incl    %ecx
    leal    1(%edx), %eax
    movl    %eax, %edx
    cmpl    (%ebx), %eax
    jne    L18
    movl    %eax, 8(%ebp)
L20:
    movl    %ecx, %eax
    popl    %ebx
    popl    %ebp
    ret

Как можно убедиться, код обоих функций одинаков.
Для других уровней оптимизации и последующих версий gcc это тоже верно.

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

Сообщение отредактировал Tonal - 22.7.2008, 21:29