Użytkownik "Maciej Sobczak" <s...@g...com> napisał:

> Od dłuższego czasu unikasz wywiązania się z obietnicy udowodnienia, że (a + b) + c
i a + (b + c)
> to jest to samo.

Hm.. Bo jest ! :)
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.
A jesli "moze byc" to nalezy przyjac ze "jest" i nie wymuszac kolejnosci obliczen
nawiasami
(bo nie one w C/C++ do tego sluza) bo to moze (jak udowodnilem) nic nie dac i _bedzie
katastrofa_.

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

> Przez moment zrobiłeś wybieg twierdząc, że programy kompiluje się kompilatorem a
nie standardem -
> to świetny wybieg,
> bo pozwala schować pod dywan nieznajomość standardu.

Alez to najprawdziwsza prawda :) Row sie kopie "fizyczna" lopata, a nie jej rysunkiem
technicznym.

> Problem w tym, że o kompilatorach też nie masz pojęcia.

Jakies tam pojecie mam, bo.. je wlasnie piszę ;).
No dobrze :) Nie kompilatory, ale parsery.
Mam na "rozkladzie" gramatyke: C, C++, Java, C#, IDL (Corbowy) i pewien OQL
( + na razie puste podkatalogi Ada, VB, SIM).

PS: Do reszty sie nie odniose, bo to bajania nawiedzonego teoretyka ktoremy sie
wydaje,
ze "wie" bo se standard pod poduszke wlozyl.

AK

do góry

On 29.06.2012 10:47, AK wrote:
> Użytkownik "Maciej Sobczak" <s...@g...com> napisał:
>
>> Od dłuższego czasu unikasz wywiązania się z obietnicy udowodnienia, że
>> (a + b) + c i a + (b + c) to jest to samo.
>
> Hm.. Bo jest ! :)
Nie jest.

#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

ergo (wiem, trudne słowo dla fachowca Twojego pokroju) w ogólnym
przypadku NIE może zmieniać kolejności i MUSI się trzymać tego co
napisał programista.


> A jesli "moze byc" to nalezy przyjac ze "jest" i nie wymuszac kolejnosci
> obliczen nawiasami
> (bo nie one w C/C++ do tego sluza) bo to moze (jak udowodnilem) nic nie
> dac i _bedzie katastrofa_.
Jeżeli będzie katastrofa to znaczy, że masz totalnie zwalone narzędzie.

> Alez to najprawdziwsza prawda :) Row sie kopie "fizyczna" lopata, a nie
> jej rysunkiem technicznym.
Więc nie tylko nie znasz języka C, ale i nie znasz kompilatora, który
używasz (przykład wyżej). No fachowiec z ciebie jest genialny.

>
>> Problem w tym, że o kompilatorach też nie masz pojęcia.
>
> Jakies tam pojecie mam, bo.. je wlasnie piszę ;).
> No dobrze :) Nie kompilatory, ale parsery.
> Mam na "rozkladzie" gramatyke: C, C++, Java, C#, IDL (Corbowy) i pewien OQL
> ( + na razie puste podkatalogi Ada, VB, SIM).
Współczuję tym co będą tego używać.


--
Pozdrawiam
Michoo

do góry

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.

do góry

Użytkownik "Bronek Kozicki" <b...@s...net> napisał:

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

To tez sobie opraw :).

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 2012-06-29, AK <n...@n...com> wrote:
> Użytkownik "Bronek Kozicki" <b...@s...net> napisał:
>
>> lepiej (i ładniej!) nie potrafiłbym tego wytłumaczyć, oprawię sobie ramkę :)
>
> To tez sobie opraw :).
>
> 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

Chłopcze, kiedy zaczniesz dowodzić ogólną własność zamiast pokazywać
specyficzny przypadek, kiedy własność jest spełniona? Bo na razie
prowadzisz dowód przez przykład, że jeden konkretny kompilator w przy
jednym konkretnym kodzie daje taki wynik, jakiego się spodziewasz.


--
Secunia non olet.
Stanislaw Klekot

do góry

Użytkownik "Stachu 'Dozzie' K." <d...@g...eat.some.screws.spammer.invalid> napisał:

w wiadomości news:slrnjusdcn.96u.dozzie@jarowit.net...
> On 2012-06-29, AK <n...@n...com> wrote:
>> Użytkownik "Bronek Kozicki" <b...@s...net> napisał:
>>
>>> lepiej (i ładniej!) nie potrafiłbym tego wytłumaczyć, oprawię sobie ramkę :)
>>
>> To tez sobie opraw :).
>>
>> 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
>
> Chłopcze, kiedy zaczniesz dowodzić ogólną własność zamiast pokazywać
> specyficzny przypadek, kiedy własność jest spełniona?

O ! Widze ze TWA C++owych Ayatollahow mieknie nieco :)
Czyli jednak nie jest zawsze jest tak dobrze/bezpiecznie
z tymi nawiasami/wyrazeniami jak piszecie.

Jeden ? A gdzie ja napisalem, ze zachodzi "zawsze" ?
Gdzie napisalem ze tyczy to np. przeciazonych operatorow ?
Przyczepilem sie _wylacznie_ do tych intow (i innych typow calkowitych)
_swiadomie_ (na uzytek tej prowokacji/flejma).

Ale "jeden" przypadek jednak _zachodzi_ wiec lepiej przyjac ogolne
_praktyczne_ zasady (np zmienne tymczasowe) "zabezpieczajace" niz przyjac,
ze "zawsze" jest dobrze, a potem sie dziwic niepomiernie, ze wystapil _jeden_
tylko wylot /no.. potem jeszcze drugi. Z pracy.../ :).

> Bo na razie prowadzisz dowód przez przykład, że jeden konkretny kompilator w przy
> jednym konkretnym kodzie daje taki wynik, jakiego się spodziewasz.

Apropos jednego przypadku ?
Czy aby napewno jeden ? :)
A moze w przypadku typow prostych C jest tak pol na pol ? Hę ?
Ze jeden kompilator ? A skad wiesz ze jeden ?
A jesli nawet jeden kompilator C/C++ to "raczej" znaczacy (zdecydowanie
najczesciej uzywany na swiecie). Prawda ?
A moze ten "jeden" tez raz tak a raz tak (w zaleznosci od opcji) ?

AK

do góry

A tu przyklad kliniczny tego, czym sie roznia Ayatollay C++ ode mnie czy innych
"Dinozaurow" :)

Nie tak dawno na pl.comp.lang.c (Eh.. po co tam znow polazlem ? :) Poprawie sie od
jutra..):
Napisalem, jako przyklad antyprogramowania ("koszmarek"):

"
Użytkownik "Kicer" <...@...c> napisał:

> czasem można sobie poradzić za pomocą "?:"

Tu jest to wzglednie proste:

const volatile double x = (warunek) ? (zrob1(), zrob2(), zrob3()) : (zrob4(),
zrob5());

Tyle ze znow robi sie koszmarek, mimo ze poprawny niby w pelni.

PS: zaraz bedzie sciana ze niby wystarczy za cale C && || i ,

AK
"

A dzis jeden (nieglupi zreszta, a nawet wiecej) Ayatollah C++
podaje ten/podobny koszmerek calkiem pozwanie jako alternatywe:

"
>> final double x;
>> if (warunek) {
>> zrob1();
>> zrob2();
>> x = zrob3();
>> } else {
>> zrob4();
>> x = zrob5();
>> }
> Można zrobić coś takiego(choć nie jest idealne):
> const double x=[&]{
> if(w1){
> {
> zrob1();
> zrob2();
> return zrob3();
> }else{
> zrob4();
> return zrob5();
> }
> }();

const double x = w1 ? (zrob1(), zrob2(), zrob3())
: (zrob4(), zrob5());

jak ktoś nie lubi tak zwięźle, to może sobie dodać nowe linie i tabulację.

B.
"

No rece opadaja :)

AK

do góry

In the darkest hour on Sat, 30 Jun 2012 09:58:14 +0200,
AK <n...@n...com> screamed:
>> Chłopcze, kiedy zaczniesz dowodzić ogólną własność zamiast pokazywać
>> specyficzny przypadek, kiedy własność jest spełniona?
>
> O ! Widze ze TWA C++owych Ayatollahow mieknie nieco :)
> Czyli jednak nie jest zawsze jest tak dobrze/bezpiecznie
> z tymi nawiasami/wyrazeniami jak piszecie.
>
> Jeden ? A gdzie ja napisalem, ze zachodzi "zawsze" ?
> Gdzie napisalem ze tyczy to np. przeciazonych operatorow ?
> Przyczepilem sie _wylacznie_ do tych intow (i innych typow calkowitych)
> _swiadomie_ (na uzytek tej prowokacji/flejma).
>

Jako wyłączny obserwator wątku chciałbym zaznaczyć, że jeśli coś nie
zachodzi zawsze to nie jest to własność spełniona.
Powyższe posty natomiast to charakterystyczny przykład odwracania kota
ogonem po wytknięciu błędów.

--
[ Artur M. Piwko : Pipen : AMP29-RIPE : RLU:100918 : From == Trap! : SIG:230B ]
[ 09:46:06 user up 13217 days, 21:41, 1 user, load average: 0.09, 0.61, 0.45 ]

Immature poets imitate; mature poets steal. -- T. S. Eliot

do góry

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",
(a raczej ~na pol), a wiec wlasnosc ta (uzywanie wylacznie nawiasow
do wymuszania tejze kolejnosci) nie jest spelniona.
Lepiej wiec (dla bezpieczenstwa) przyjac, ze nie determinuja w ogole.

W takich jezykach jak np. Algol czy Fortran nawiasy _zawsze_
determinuja kolejnosc "podobliczen".
W tych jezykach rowniez kolejnosc obliczania podwyrazen
jest jednooznacznie zdeterminowana (od lewej do prawej).
W C/C++ nie.

AK

do góry

Dnia 02-07-2012 o 10:36:00 AK <n...@n...com> napisał(a):
(...)

Możesz podeprzeć się odpowiednim punktem standardu?

Pozdrawiam -- Spook.

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

do góry