On 29/06/2012 13:27, Michoo wrote:
> #include "stdafx.h"
> #include <cassert>
> float ff(float a,float b,float c){
> return a+(b+c);
> }
> float fff(float a,float b,float c){
> return a+b+c;
> }
> int _tmain(int argc, _TCHAR* argv[])
> {
> float b = 1e32f;
> float c = -1e32f;
> float a = 1.0f;
> assert(ff(a,b,c)==1);
> assert(fff(a,b,c)==1);
> }
>
>
>> A precyzyjniej (jak od poczatku twierdzilem): moze byc, bo C/C++ nie
>> determinuje nie tylko kolejnosci
>> evaluowania podwyrazen "at all", ale takze kolejnosci ewaluowania
>> wynikow czesciowych w przypadku
>> operatorow o tym samym priorytecie i nie robia tego rowniez nawiasy.
> Ciągle bredzisz.
>
> Grupowania wyznacza semantykę. Kompilator może robić cokolwiek tak długo
> jak długo zachowanie będzie zgodne z tym co wynika z grupowania.
>
> To teraz prostymi, żołnierskimi słowami, żeby dotarło do ograniczonej
> głowy mistrzunia:
> - może mieć w dupie kolejność dodawania uintów ze względu na własności
> arytmetyki modulo
> - może mieć w dupie kolejność dodawania intów o ile ma je w arytmetyce
> modulo i nie ma trap'a na przepełnieniu
> - _nie_ może mieć w dupie dodawania floatów


lepiej (i ładniej!) nie potrafiłbym tego wytłumaczyć, oprawię sobie ramkę :)


B.