Problem Z C++

[@Sorror]

Typy real, float, double zawsze otrzymują tyle samo pamięci (choć pewnie znajdą się jakieś wyjątki, ale na pewno nieliczne).

Racja jeśli chodzi o float. Double oraz long double to już wolna amerykanka (stąd tak duża popularność klas rzutujących).

[@perl]

Ależ skąd System priorytetów operatorów jest cechą danego języka i sprzęt nie ma tu nic do rzeczy

 

W Cepepe inkrementacje/dekrementacje mają jeden z najwyższych priorytetów, mianowicie piętnasty w 17-sto stopniowej skali.

priorytety operatorow to zupelnie inna bajka, mi chodzilo o kolejnosc wykonania operacji operatorowej ktora zalezy (poza programista) TYLKO od kompilatora (a kod generowany przez kompilator zalezy ŚCIŚLE od architektury sprzetowej)

 

bo nie wiem czy wiecie ale oprocz architektury x86 istnieja jeszcze inne (posiadajace zupelnie inny zbior instrukcji procesora, wielkosc rejestrow, sposob kolejkowania rozkazow, inny bity najbardziej znaczacy itp.) - najprosciej mowiac kompilator przeksztalaca program na najbardziej dopasowany do sprzetu zbior instrukcji, wiec architektura tutaj ma sporo do powiedzenia

 

program powinien byc tak napisany aby chodzil tak samo, niezaleznie na jakiej architekturze zostal skompilowany,

 

natomiast kawalek kodu ktory podalem, nie spelnia tego wymogu (bo jest niepoprawny)

 

widze ze nikomu nie chialo sie zajrzec do ksiazki tylko od razu napisaliscie wlasne niepoprawne przemyslenia

 

podam wiec przyklad:

a[i]=i++;

 

i teraz odpowiedzcie czy inkrementacja i nastapi przed przypisaniem wartosci do elementu wektora czy moze nastapi po tym przypisaniu ??

[Sanczo]

perl Oczywiście nastąpi po.

 

Co do tamtej linijki którą zaprezentował Zygmunt, rzeczywiście kod nie jest napisany w sposób jednoznaczny (patrz błędny) mimo iż sam kompilator tego nie stwierdza.

 

Jeśli chodzi o ten skromny kawałek kodu, to nie ma sie tutaj co rozwodzić nad przenośnością, bo w tak banalnym przypadku ten problem nie występuje.

 

(a kod generowany przez kompilator zależy ŚCIŚLE od architektury sprzętowej)

 

oraz od kompilatora.

[@perl]

perl Oczywiście nastąpi po.

wlasnie chodzi o to ze niekoniecznie wszystko zalezy od uzytego kompilatora

 

a dlaczego kompilatory roznie potrafia rozpatrywac ten sam kod to juz odsylam do lektury (bo nie czas na wywody)

 

Jeśli chodzi o ten skromny kawałek kodu, to nie ma sie tutaj co rozwodzić nad przenośnością, bo w tak banalnym przypadku ten problem nie występuje.

ten banalny program daje inne wyniki na platformie Sun SPARC oraz x86_64, na ktorych to kompilowalem a powodem nie jest bledne dzialanie kompilatora czy tez sprzetu, ale wlasnie zle napisany program

 

tak wiec poprawne nawyki w pisaniu trzeba sobie wpoic, zeby potem nie zastanawiac sie po kilka tygodni dlaczego nasz program daje zle wyniki ( <-- autentyczna sytuacja)

[Byku]

Nie wiem z jakiej książki uczysz się programować

Programuje ja już od 4 lat, nie tylko w c++, ale nigdy jakos sie nie zaglebialem dokladnie w ta tematyke (skad sie biora takie "dziwne" wyniki"). Ale coraz bardziej uswiadamiam sobie, ze chyba jednak czas na chwilke wrocic do podstaw i sobie pare spraw wyjasnic

[Sanczo]

perl

ten banalny program daje inne wyniki na platformie Sun SPARC oraz x86_64, na których to kompilowalem lamo.gif a powodem nie jest błędne działanie kompilatora czy tez sprzętu, ale właśnie źle napisany program dry.gif

 

Miałem na myśli przenośność prawidłowo napisanego tamtego kodu, nie jego wersje z błędem

 

CYTAT (Sanczo @ 26.12.2005 - 20:14)

perl Oczywiście nastąpi po.

 

właśnie chodzi o to ze niekoniecznie cool.gif wszystko zależy od użytego kompilatora

 

Osobiście nie spotkałem się z różną interpretacją wyrażeń typi a=i++ przez kompiltory.

A pisałem już min na: Borland 6.1(?) C++, DevC++, gcc, MS Visual Studio i na żadnym nie miałem odstępstw od tego wyniku działania który podałem.

Ale żadnym razie nie próbuje podważać twoich słów po porostu sam z tym sie jeszcze nie zetknąłem...

 

pozdrawiam

[@Sorror]

perl Oczywiście nastąpi po.

wlasnie chodzi o to ze niekoniecznie wszystko zalezy od uzytego kompilatora

 

a dlaczego kompilatory roznie potrafia rozpatrywac ten sam kod to juz odsylam do lektury (bo nie czas na wywody)

Na jakim kompilatorze inkrementacja następuje u Ciebie 'przed'?

[@perl]

@sorror: z takimi sytuacjami spotkalem sie kilkukrotnie, kompilatory dolaczone z SunOSem (UltraSPARC), oraz z RH 7.3 (Pentium MMX)

 

w obu przypadkach kompilacja (w formie bibliotek numerycznych) byla silnie optymalizowana pod sprzet, czesci kodu operujace na duzych wektorach i macierzach zawieraly petle (to moim zdaniem bylo powodem takiego dzialania)

 

chodzilo o to ze podczas wykonywania kompilacji moglo zajsc zjawisko kiedy komorka pamieci do ktorej miala zostac przypisana wartosc zostala znajdowana pozniej niz przeprowadzenie proces inkrementacji

 

tutaj jest przykladowe wyjasnienie kilku sytuacji: http://www.eskimo.com/~scs/cclass/notes/sx7c.html

 

ostrzezenia przed takim stosowaniem operatorow sa w wielu miejscach: http://www.stata.com/help.cgi?m2_op_increment

 

 

[@Sorror]

tutaj jest przykladowe wyjasnienie kilku sytuacji: http://www.eskimo.com/~scs/cclass/notes/sx7c.html

Ah już wiem o czym mówisz. To problem poruszony nawet przez Bjerne w referencji Cpp, ale nie dotyczy konkretnych kompilatorów (co innego architekrura), jest to kwestia nieprzewidywalności (teoretycznie, ponieważ gcc zachowuje się [zwykle] w sposób stały, przeprowadzaliśmy testy w zeszłym roku na Dniach Programowania we Wrocławiu) w zakresie każdego z nich.

 

O architekturze się nie wypowiadam, piszę tylko pod x86

[Zygmunt]

Dzieki za posty!!!

Ja dopiero zaczołem programować....

Chciałem napisać program na silnie przez rekurencje, i mnie zastanowilo dlaczego tak jest.

Wiec napisałem na forum...

Narq

[@perl]

ale nie dotyczy konkretnych kompilatorów (co innego architekrura)

ja pisze programy obliczeniowe dla roznych architektor sprzetowych, oraz na roznych platformach systemowych,

 

tak jak napisalem wczesniej kompilatory z ktorymi sie spotkalem scisle zalezaly od sprzetu (architektury), uzywalem wielu kompilatorow (na roznych platformach systemowych), a moj opis nie dotyczyl tylko kompilatora GNU

 

jednak przede wszystkim chodzi mi o to, ze stosowanie zapisu (dekremantacji), ktory zaprezentowal Zygmunt jest zle i trzeba sie tego wystrzegac,

 

w ogolnosci trzeba sie wystrzegac (dla bezpieczenstwa) stosowania operacji operatorowych na indeksach uzywanych rowniez jednoczesnie w operacji przypisania

 

takie operacje moga przez kompilator zostac potraktowane przy optymalizacji w sposob przez nas niechciany,

 

wazne jest aby pisac programy poprawnie i tylko dlatego jestem taki upierdliwy

[Zygmunt]

Hej Perl....

Wkońcu chyba o to chodzi, aby komus cos wytłumaczyć, to trzeba trzymac sie upierdliwosci;-)

[wlochaty]

Chcialem tylko dodac, moze troche nie na temat ale skoro Zygmunt uczy sie programowac to poprawmy i to.

Moja rada nigdy przenigdy nie uzywaj cout<< bez zakonczenia go <<endl; lub <flush;. Widzialem juz programy w ktorych nieczyszczony bufor powodowal sytuacje gdzie dopisanie definicji np. int i; zmienialo stale wyniki generowane przez program.

A wiec:

cout << "Podaj liczbe do obliczenia silnii z niej: "<<flush;

i zycze powodzenia na nowej drodze zycia .

 

 

#include <iostream>

using namespace std;

double long silnia(int n)

{

double long wynik;

if (n==0 || n==1)

return 1;

wynik = n * silnia (--n);

return wynik;

}

int main()

{

int a;

cout << "Podaj liczbe do obliczenia silnii z niej: ";

cin >> a;

cout << a << "! = " << silnia(a) << endl;

}

[@Sorror]

Moja rada nigdy przenigdy nie uzywaj cout<< bez zakonczenia go <<endl; lub <flush;. Widzialem juz programy w ktorych nieczyszczony bufor powodowal sytuacje gdzie dopisanie definicji np. int i; zmienialo stale wyniki generowane przez program.

O czym Ty w ogóle mówisz?

[Sanczo]

wlochaty

Widzialem juz programy w ktorych nieczyszczony bufor powodowal sytuacje gdzie dopisanie definicji np. int i; zmienialo stale wyniki generowane przez program

 

O czym Ty do mnie rozmawiasz

 

chyba miałeś na myśli coś w deseń cout.flush(), ale to i tak nie tlumaczy dalszej części zdania