[DimaG 0]

Бред какой ...

Только что проделал такое с VC 6. Результирующий exe-файл в обоих случаях идентичный (проверено тотал коммандером).

 

Потому, что умный компилятор соптимизировал. Но не слишком надейтесь на то, что так будет всегда. Попробуйте проверить с объектом класса с определенным оператором пост и прединкремента

[GetSmart 0]

...Но не слишком надейтесь на то, что так будет всегда...

В 2012-ом все компиляторы дружно разучатся оптимизировать

[DimaG 0]

В 2012-ом все компиляторы дружно разучатся оптимизировать

 

Имелось в виду - при смене компилятора / платформы / типа данных :laughing:

[zltigo 0]

Потому, что умный компилятор соптимизировал.

А дураки среди компиляторов вымирают, посему пересказывать байки начала 90x не надо. Поздно.

Попробуйте проверить с объектом класса с определенным оператором пост и прединкремента

"определенным" это то, что люди называют перегруженным оператором? Это во-первых C++, а во-вторых еще проще для оптимизатора, ибо по стандарту перегрузка оператора заменяется на вызов функции - и никаких фантазий для неправильной оптимизации вообще нет. Нут тебe и железнейшая sequence points еще до кучи.

[DimaG 0]

А дураки среди компиляторов вымирают, посему пересказывать байки начала 90x не надо. Поздно.

 

"определенным" это то, что люди называют перегруженным оператором? Это во-первых C++, а во-вторых еще проще для оптимизатора, ибо по стандарту перегрузка оператора заменяется на вызов функции - и никаких фантазий для неправильной оптимизации вообще нет. Нут тебe и железнейшая sequence points еще до кучи.

 

Да, перегруженным.

Вот пример класса. В нем перегружены операторы инкремента

 

#include <stdio.h>
#include <time.h>
#include <sys/time.h>

typedef struct timeval TTime;

/////////////////////////////////////////////////
class ClTest
{
 public:
int aiBuf_m[1024];

ClTest()
{
  aiBuf_m[0] = 0;
}

//Prefix form of increment
ClTest& operator ++()	
{
  ++aiBuf_m[0];
  return *this;
}

//Postfix form of increment
ClTest operator ++(int)
{
  ClTest clRetValue_ = *this;
  ++aiBuf_m[0];
  return clRetValue_;
}
};

/////////////////////////////////////////////////
unsigned int GetInterval(TTime* psBegin_, TTime* psEnd_)
{
 return (psEnd_->tv_usec - psBegin_->tv_usec) + (psEnd_->tv_sec - psBegin_->tv_sec)*1000000;
}

/////////////////////////////////////////////////
int main()
{
 TTime sBeginTime_, sEndTime_;
 static const unsigned int ITTERATIONS_CNT = 100000;

 { 
ClTest clTest_;

gettimeofday(&sBeginTime_, NULL);

for (;clTest_.aiBuf_m[0] != ITTERATIONS_CNT; ++clTest_)
  continue;

gettimeofday(&sEndTime_, NULL);

printf("Prefix form: time = %u\n", GetInterval(&sBeginTime_, &sEndTime_));
 }

 { 
ClTest clTest_;  

gettimeofday(&sBeginTime_, NULL);

for (;clTest_.aiBuf_m[0] != ITTERATIONS_CNT; clTest_++)
  continue;

gettimeofday(&sEndTime_, NULL);

printf("Postfix form: time = %u\n", GetInterval(&sBeginTime_, &sEndTime_));
 }

 return 0;
}

 

Вот результат его работы (GCC 4.1.2, оптимизация выключена):

Prefix form: time = 520

Postfix form: time = 116160

 

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

Слышал, что люди, хорошо владеющие STL и тп вещами, аккуратнее относятся к пост и пред инкременту.

 

 

Собственно, немного изменил пример, и GCC на оптимизации O3 сдулся

 

Prefix form: time = 68

Postfix form: time = 89358

 

{ 
ClTest clTest_;
volatile int i;

gettimeofday(&sBeginTime_, NULL);

for (;clTest_.aiBuf_m[0] != ITTERATIONS_CNT; )
  i = (++clTest_).aiBuf_m[0];

gettimeofday(&sEndTime_, NULL);

printf("Prefix form: time = %u\n", GetInterval(&sBeginTime_, &sEndTime_));
 }

 { 
ClTest clTest_;
volatile int i;  

gettimeofday(&sBeginTime_, NULL);

for (;clTest_.aiBuf_m[0] != ITTERATIONS_CNT; )
  i = (clTest_++).aiBuf_m[0];

gettimeofday(&sEndTime_, NULL);

printf("Postfix form: time = %u\n", GetInterval(&sBeginTime_, &sEndTime_));
 }

[GetSmart 0]

Кстати, во FreeRTOS встречаются оба варианта инкремента (без доп. действий) одинакого часто. Автор мечется в сомнении ?!

[Flexz 0]

FreeRTOS просто, видимо, разные люди пишут :)

У Страуструпа, кстати, там где int - постинкремент, а там где итератор - прединкремент

[HARMHARM 0]

FreeRTOS просто, видимо, разные люди пишут :)

Нет, там один человек. Впрочем, по коду, который долгое время эволюционирует, можно проследить как эволюционирует сам программист :)

[DimaG 0]

У Страуструпа, кстати, там где int - постинкремент, а там где итератор - прединкремент

Со встроенными типами практически всегда это без разницы - компилятор соптимизирует :) (хотя, вдруг выйдет новая интересная платформа + сырой комиплятор :rolleyes: )

 

Но лично мне не нравится такой зоопрак из ++i и i++ в программе :(

Поэтому пишу единообразно, используя ++i

[_Pasha 0]

Но лично мне не нравится такой зоопрак из ++i и i++ в программе :(

Поэтому пишу единообразно, используя ++i

Ладно-ладно. А volatile-переменные тоже по-умному "додумываются" ? Или все-таки есть разница? ;)

[DimaG 0]

Ладно-ладно. А volatile-переменные тоже по-умному "додумываются" ? Или все-таки есть разница? ;)

:rolleyes:

Чет не пойму, что Вы имеете в виду :laughing:

[defunct 0]

Короче говоря единственно правильный вариант:

twi_write_data(0,ptr, data[ptr]);
ptr++;

До единственно правильного далеко т.к. есть пара вопросов:

1. На кой в twi_write_data передавать "ptr"?

2. На кой индекс неверно обзывать поинтером?

 

Два единственно правильных варианта:

 

- twi_write_data( 0, *ptr++ )

- twi_write_data( 0, data[ i++ ] );

[_Pasha 0]

:rolleyes:

Чет не пойму, что Вы имеете в виду :laughing:

Коль скоро для volatile оптимизации запрещены, то разница между ++j и j++ (volatile j) должна наблюдаться на любых компиляторах.