Użytkownik "Wojciech "Spook" Sura" <s...@o...pl> napisał:

Podpieram sie (po raz n-ty) rzeczywistoscia:

bar.cpp
=====
int bar(int a, int b, int c)
{
return (a + b) + c;
}

foo.cpp
=====
int foo(int a, int b, int c)
{
return a + (b + c);
}

D:\>diff bar.asm foo.asm
3c3
< ; Listing generated by Microsoft (R) Optimizing Compiler Version 15.00.30729.01
<
< TITLE D:\bar.cpp
---
> ; Listing generated by Microsoft (R) Optimizing Compiler Version 15.00.30729.01
>
> TITLE D:\foo.cpp
12c12
< PUBLIC ?bar@@YAHHHH@Z ; bar
---
> PUBLIC ?foo@@YAHHHH@Z ; foo
14c14
< ; COMDAT ?bar@@YAHHHH@Z
---
> ; COMDAT ?foo@@YAHHHH@Z
19,20c19,20
< ?bar@@YAHHHH@Z PROC ; bar, COMDAT
< ; File d:\bar.cpp
---
> ?foo@@YAHHHH@Z PROC ; foo, COMDAT
> ; File d:\foo.cpp
28c28
< ?bar@@YAHHHH@Z ENDP ; bar
---
> ?foo@@YAHHHH@Z ENDP ; foo

AK

do góry

On Monday, July 2, 2012 10:56:40 AM UTC+1, AK wrote:
> Użytkownik "Wojciech "Spook" Sura" <s...@o...pl> napisał:
>
> Podpieram sie (po raz n-ty) rzeczywistoscia:
>
> bar.cpp
> =====
> int bar(int a, int b, int c)
> {
> return (a + b) + c;
> }
>
> foo.cpp
> =====
> int foo(int a, int b, int c)
> {
> return a + (b + c);
> }

Zmien "int" na "double" i powtorz ten test.

RW

do góry

Dnia 02-07-2012 o 11:56:40 AK <n...@n...com> napisał(a):
(...)

Ale ja mam w głębokim poważaniu rzeczywistość. Interesuje mnie, w którym
miejscu standard C++ mówi, jak powinien się zachowywać kompilator podczas
rozwiązywania nawiasów. Jest na przykład całkiem możliwe, że w *tym
konkretnym przypadku* optymalizator zauważył, że kolejność nie ma
znaczenia. Albo że kompilator nie jest zgodny ze standardem w tej kwestii.

Pozdrawiam -- Spook.

--
Używam klienta poczty Opera Mail: http://www.opera.com/mail/

do góry

Użytkownik "Wojciech "Spook" Sura" <s...@o...pl> napisał:

'> Ale ja mam w głębokim poważaniu rzeczywistość.

Jeśli tak, to już jest wyłącznie zwykłe palanciarstwo zawodowe (częste
wśród "niedzielnych programistow").
Zmien opcję, pókiś młody :)

PS: Nie tak znow calkiem dawno dane mi bylo pracowac z kodem
"wielopratformowym": Win, Solaris, Linux, i HP-UX.
Niby niec specjalnego, tyle ze ten compilel C++ HP byl "bez -AA" czyli
w wersji.. ARM C++. Tam to sobie standard (nawet ten stary) C++
czesto mozna bylo sobie wlozyc ..., ale sprobowalbys "wytlumaczyc"
swa niemoc ("no bo to niezgodne ze standardem C++ plose Pani,
a jak mam w glebokim powazniu taka rzeczywistosc") .
Ciekawe, ja by wygladalo zrozumienie Twej "zawodowej" postawy
przez druga strone wyplaty ;).

AK

do góry

On 02.07.2012 10:36, AK wrote:
> Użytkownik "Artur M. Piwko" <m...@b...pl> napisał:
>
>> Jako wyłączny obserwator wątku chciałbym zaznaczyć, że jeśli coś nie
>> zachodzi zawsze to nie jest to własność spełniona.
>
> Racja. Dokladnie o to chodzi.
> Nawiasy w C/C++ nie zawsze determinuja kolejnosc "podobliczen",
Zgadza się, determinują wynik. Nie determinują kolejności obliczeń w
przypadku gdy nie ma to znaczenia dla wyniku[1], co zresztą napisałem w
wiadomości będącej początkiem Twojego rantu na mnie [4]

> (a raczej ~na pol), a wiec wlasnosc ta (uzywanie wylacznie nawiasow
> do wymuszania tejze kolejnosci) nie jest spelniona.
Nieprawda. Kompilator zapewnia, że jeżeli wykona optymalizację to nie
zmieni ona wyniku na inny niż opisany za pomocą wyrażenia. Czyli nawet
jeżeli liczy inaczej niż to wynika z zapisu to uzyskany wynik jest taki
jaki został wymuszony nawiasami.[3]

Np:
(a+b)+(a+b) zostanie prawdopodobnie policzone na uintach jako (a+b)*2,
ale już na float nie. W obu przypadkach wynik będzie dokładnie taki jak
to zapisano nawiasami.

> W tych jezykach rowniez kolejnosc obliczania podwyrazen
> jest jednooznacznie zdeterminowana (od lewej do prawej).
> W C/C++ nie.
W C++ jest zdefiniowane grupowanie, czyli kolejność obliczeń.
"Niezdefiniowana kolejność obliczania podwyrażneń" oznacza tylko tyle,
że standard nie narzuca w jakiej kolejności liczyć niezależne składowe.
(Np. lewa i prawa strona przypisania.)

[1] Ściśle mówiąc zapewnienie jest szersze, dotyczy zarówno
obserwowalnego zachowania jak i efektów ubocznych.
[3] Standard opisuje "abstrakcyjną maszynę" i na niej definiuje
operacje. W tym tworze tożsamości znane z matematyki jak np. a/b==1/b*a
nie są w ogólności prawdziwe, za to prawdziwe są inne np. dla typu char
w arytmetyce modulo bez trap na przepełnieniu (char)255==-1.
[4] nntp://jn386g$qrf$...@m...internetia.pl

--
Pozdrawiam
Michoo

do góry

> (a+b)+(a+b) zostanie prawdopodobnie policzone na uintach jako (a+b)*2

Od 10 lat przestało mnie to fascynować, ale chyba nic się nie zmieniło,
że mnożenie jest be. IMHO będzie (a+b)<<1

artur

do góry

On 04.07.2012 16:06, Artur Muszyński wrote:
>> (a+b)+(a+b) zostanie prawdopodobnie policzone na uintach jako (a+b)*2
>
> Od 10 lat przestało mnie to fascynować, ale chyba nic się nie zmieniło,
> że mnożenie jest be. IMHO będzie (a+b)<<1
assemblerowo na x86 będzie pewnie add a,b; add a,a, albo sztuczka z
lea, ale tu chodziło o idę przekształcenia.

--
Pozdrawiam
Michoo

do góry