Code blocks programiranje

Molio bi pomoć oko ovog zadatka? 

Ispricavam se, c++ je programski jezik, trazim neke stranice za kreiranje polja, al nisam bas nesto korisno pronasao..bilo kakva pomoc je dobro dosla. Hvala

#include <iostream>
#include <fstream>
#include <string>

using namespace std;

int main()

{

ifstream niz("niz.txt");
if (niz.is_open())
{
int broj;
while (niz >> broj)

{
cout << broj << endl;
}
}
else
{

}
{
{
int brojevi[1000];
int dobroja=1000-1;
bool zamijena=true;
while (zamijena==true)
{
zamijena=false;
for (int i = 0; i < dobroja; i++)
{
if (brojevi[i+1]<brojevi[i])
{
swap(brojevi[i],brojevi[i+1]);
zamijena=true;
}
}
dobroja--;
}
for (int i = 0; i < 1000; i++)
{
cout<<brojevi[i]<<endl;
}
}
}
return 0;
}

probao sam ovako, al neznam kako da povežem buble sort sa ovom niz.txt datotekom, jer ovako baca random brojeve. Mi smo na 4. godini faxa, prvi put se susrećemo sa ovim programiranjem, niko nema 1/3 osnovnog znanja za ovako nesto isprogramirat :// 

Ako je tek počeo sa programiranjem, a čini mi se da je, bilo bi dobro pisat dijagram toka

Znam da je nevjerojatno al tako je, niko nije ništa objasnio šta se ovoga tiče. Nikakve petlje, funkcije nista. Asistent da zadatak i ode ca prakticki....Hvala bogu pa mi je nešto prijatelj sa fera objasnio neke osnove
Naime zanima me u ovom kodu, Zašto u sortiranoj listi ne prikazuje decimalne brojeve..znam da trebam nekako deklarirat double-om al neznam di tocno. Isto tako ne ispisuje decimalne ni u datoteci. 
Ovo je zadatak: Napišite program koji korisniku omogućuje unos 10 decimalnih brojeva u polje. Sortirajte polje silazno koristeći algoritam sortiranja umetanjem te sortirano polje ispišite na ekran i u datoteku ime_prezime.txt. Algoritam sortiranja realizirajte pomoću funkcije

ovo je kod:

#include <iostream>
#include <fstream>
#include <iomanip>
#include <cstdlib>

using namespace std;

void insertion (double p[], int n);
void ispisimiovo(double p[], int n);

int main()
{
ofstream izlaz;
izlaz.open("NovaDatoteka.txt");

double znakovi[10];

for (int i=0; i<10; i++)
{
cout<< "upisi neki broj: "<<endl;
cin>>znakovi[i];
}
cout << "nije sortirano: " <<endl;
ispisimiovo(znakovi, 10);
insertion (znakovi,10);
cout<< "sortirani znakovi: "<<endl;
ispisimiovo(znakovi,10);

for(int i=0; i<10; i++)
{
izlaz<<znakovi[i]<<endl;
}

izlaz.close();

return 0;

}

void insertion (double p[], int n)
{
for(int i=1; i<n; i++)
{
int setac=i;
int tmp=p[i];
while(setac>0 && tmp>p[setac-1])
{
p[setac]=p[setac-1];
setac--;
}
p[setac]=tmp;
}
return;
}
void ispisimiovo(double p[], int n)
{
for(int i=0; i<n; i++)
{
cout<<p[i]<<setw(5);
}
cout<<endl;
return;
}

Mr.Devil ti je rekao šta je tvoj problem i zašto dolazi do greške u debuggeru...

Trebao bih da pročitas sve ovo, ali prvi dio je uglavnom vezan za tvoj problem, ostatak je više-manje ono općenito :)

EDIT: Ovo je sve čisto da bih shvatio, jer na stacku svako peti se umijesa i vecinom 80% komentara ne bude tačno

 float a(327653225), b(327653213); std::cout << a - b;       // Neispravan ispis!
 
Ova sekvenca ispisuje kao rezultat nulu, iako bi rezultat trebao da bude broj “1 ”. Brojevi smješteni u promjenljive tipa “float” su jednostavno imali “previše cifara” za taj tip, tako da je kompajler nakon njihovog pretvaranja u binarni sistem izvršio zaokruživanje, čime su one postale jednake. Da se uvjerimo u to, možemo napisati sljedeću naredbu:
 
std::cout << a << " " << b;     // Pokušaj zavaravanja...
 
Na ekranu će se, kod većine današnjih kompajlera, na ekranu pojaviti sljedeći ispis:
 
 3.27653e+008 3.27653e+008
 
Vidimo da nam je kompajler pokušao “zamazati oči” tako što je vrijednosti promjenljivih “a” i “b” prikazao u eksponencijalnoj notaciji (prikazani rezultati zapravo predstavljaju vrijednost 3.27653 ∙ 10 ). Eksponencijalnu notaciju možemo izbjeći na razne načine, na primjer eksplicitnim navođenjem preciznosti ispisa. Recimo, ako napišemo naredbu poput  
 
std::cout << std::setprecision(30) << a << " " << b;   // Vidi sad...
 
na ekranu ćemo dobiti sljedeći ispis:
 
 327653216 327653216
 
Eksponencijalna notacija je izbjegnuta. Međutim, interesantnije je primijetiti da zapamćene vrijednosti nisu tačne (tačne vrijednosti su trebale biti 3 7653  5 i 3 7653 13). Promjenljive tipa “float” nisu u stanju zapamtiti dovoljno tačnih cifara. Relativne greške pamćenja su sasvim male (apsolutne greške iznose 9 i 3 respektivno, što relativno posmatrano u odnosu na same vrijednosti iznosi svega 0.00000275 % odnosno 0.000000916 %). U inžinjerskoj praksi ovaj gubitak tačnosti obično nije veliki problem (ko uostalom može ijednu fizikalnu veličinu izmjeriti sa tačnošću boljom od recimo 0.00001 %), ali za one koji očekuju savršenu tačnost ovo može biti frustrirajuće. Frustracije mogu biti tim veće što mnogi očekuju da bi makar cijeli brojevi morali biti tačno zapamćeni, ali vidimo da ovo ne mora vrijediti ukoliko se njihovo pamćenje vrši u promjenljivim realnog tipa (u suštini, najveći cijeli broj koji se može bez greške smjestiti u promjenljivu tipa “float” prema IEEE 754 standardu iznosi    − 1 = 16777215).
 
Generalizacijom prethodnog primjera može se zaključiti da mogu nastati ozbiljni problemi kad god se oduzimaju dva velika, a međusobno bliska broja. Rezultat je tada ili pogrešan, ili sadrži znatno manji broj tačnih cifara u odnosu na brojeve koji se oduzimaju. Sličan problem se javlja ako pokušamo da saberemo veoma veliki i veoma mali broj. Na primjer:
 
float a(327653225); float b(a + 1);   // Da li je stvarno b sada različito od a?

 
Nakon ove sekvence naredbi, varijable “a” i “b” će biti iste, iako ne bi trebale da budu. Tip “float” ne može da zapamti dovoljno cifara da bi razlika od jedne jedinice mogla da bude registrirana u broju koji ima devet cifara. Svi dosada demonstrirani problemi biće riješeni ako umjesto tipa “float” koristimo tip “double”, ali ni on nije svemoguć: sa brojevima koji imaju više od 15 tačnih cifara ne možemo očekivati tačan račun (konkretnije, prema IEEE 754 standardu, najveći cijeli broj koji se može bez greške smjestiti u promjenljive tipa “double” iznosi    − 1 = 9007199254740991). Posebni problemi mogu nastati pri korištenju izraza u kojima se pojedini operandi drastično razlikuju po veličini. Razmotrimo, recimo, sljedeći primjer:
 
double a(1e20), b(1), c(–1e20);  std::cout << a + b + c << " " << a + c + b << std::endl;  // Čudno... 
 
Tačna vrijednost zbira “a + b + c” iznosi 1. Međutim, pokušaj računanja ovog izraza daje netačan rezultat 0, dok se prividno ekvivalentni izraz “a + c + b” tačno računa (i daje tačan rezultat 1). Problem je u tome što se sabiranje izvodi slijeva nadesno, a brojevi smješteni u promjenljive “a” i “b” se toliko razlikuju po veličini da se vrijednost zbira “a + b” praktično ne razlikuje od vrijednosti promjenljive “a”. Ovaj primjer pokazuje da, kompjuterska “približna” aritmetika, strogo uzevši, ne zadovoljava ni uobičajene zakone komutativnosti i asocijativnosti poznate iz matematike. Međutim, ovaj primjer je uzet pomalo vještački. Primjeri poput ovog ne javljaju se tako često u praksi, tako da se može uzeti da tip “double” uglavnom pokriva područje praktičnih primjena (mada su uvijek moguća iznenađenja). Zbog toga, ako memorijski zahtjevi nisu veoma strogi, tip “float” treba izbjegavati i umjesto njega koristiti tip “double”.
 
Neko bi mogao postaviti pitanje zbog čega uopće postoji tip “float” ukoliko je on tako netačan u odnosu na tip “double”. Razlozi su uglavnom istorijske prirode. U danima kada je programski jezik C nastajao, procesori uglavnom nisu znali hardverski raditi sa realnim brojevima, tako da su se sve operacije sa realnim brojevima simulirali softverski. Pri tome je vrijeme izvršavanja pojedinih operacija sa realnim brojevima najčešće bilo proporcionalno kvadratu broja cifara operanada, što je za posljedicu imalo da su se operacije sa promjenljivim tipa “double” (koje pamte otprilike dvostruko više cifara od promjenljivih tipa “float”) izvršavale oko četiri puta sporije od operacija sa promjenljivim tipa “float”. Danas kada se operacije sa realnim brojevima izvode čisto hardverski, praktično nema nikakve razlike u brzini izvršavanja računskih operacija sa promjenljivim tipa “float” i “double”, tako da danas korištenje promjenljivih tipa “float” neće ništa ubrzati program u odnosu na slučaj kada se koriste promjenljive tipa “double”. Ostaje još činjenica da promjenljive tipa “double” zauzimaju dvostruko više memorije od promjenljivih tipa “float”. U današnjim okolnostima kada količina memorije gotovo nikada nije tako tijesna, o ovome se ne treba previše brinuti. Ipak, ukoliko treba rezervirati niz od 10000000 realnih brojeva, činjenica je da će se zaista mnogo memorije uštediti ukoliko se uzme da su elementi niza tipa “float” a ne tipa “double”. Ipak, takvi slučajevi se ne susreću često u praksi.
 
Ni korištenje tipa “double” ne rješava nas svih problema, čak ni pri radu sa brojevima “razumne” veličine. Problem leži u tome što se mantisa broja pamti sa konačnim brojem bita (binarnih cifara), a nerijetko se dešava da mantisa ima beskonačno mnogo cifara. Prvo ćemo ilustrirati ovaj problem na jednom relativno jasnom primjeru koji lijepo ilustrira problem gubljenja tačnosti, a pravi “hladan tuš” doći će uskoro nakon toga. Razmotrimo prvo sljedeći programski isječak:
 
double a(123.0), b(321.0);  std::cout << a * b / b - a / b * b;  // Zar ovo ne treba biti 0? 
 
Matematika kaže da bi ovaj primjer trebao ispisati nulu, ali to se neće desiti. U čemu je problem? Izrazi “a * b / b” i “a / b * b” nakon uvrštavanja konkretnih vrijednosti “a” i “b” svode se na brojčane izraze “123.0 * 321.0 / 321.0” i “123.0 / 321.0 * 321.0”. U prvom slučaju, računa se produkt “123.0 * 321.0” koji daje rezultat “39483.0”, a koji se zatim dijeli sa “321.0”, što na kraju daje tačan rezultat “123.0”. Međutim, u drugom slučaju, prvo se računa količnik “123.0 / 321.0” koji ima beskonačno mnogo decimala (0.38317757009…). Ovaj rezultat će svakako morati biti zaokružen na određen broj decimala. Nakon množenja zaokruženog rezultata sa “321.0”, neće se dobiti tačno “123.0” kao rezultat, što na kraju dovodi do greške u konačnom rezultatu.
 
Treba naglasiti da, ukoliko se koristi neki kompajler koji podržava agresivnu optimizaciju (a takva je većina današnjih kompajlera), postoji mogućnost da će prethodni primjer ipak ispisati nulu ukoliko je optimizacija uključena (optimizacija se uvijek može opcionalno uključiti ili isključiti, što se recimo u CodeBlocks razvojnom okruženju postiže aktiviranjem odgovaraućih opcija na kartici Compiler u meniju Settings). Naime, ukoliko je optimizacija uključena, kompajler ima pravo da izvrši reorganizaciju programa sa ciljem da dobije ekvivalentni program koji se efikasnije izvršava. Međutim isto tako, kompajler tada ima pravo da sve izraze koji se mogu izračunati još za vrijeme kompajliranja programa izračuna tada, da se ne gubi vrijeme na njihovo izračunavanje kada se program počne izvršavati. Tako kompajler može zaključiti da kako su vrijednosti promjenljivih “a” i “b” poznate još u toku kompajliranja programa (ne ovise recimo od nečega što bi korisnik mogao unijeti sa tastature kad program započne sa radom), vrijednost izraza “a * b / b - a / b * b” moguće je izražunati odmah u toku kompajliranja. Zvrčka je u tome što se izračunavanja u fazi kompajliranja često izračunavaju u znatno većoj tačnosti nego izračunavanja u fazi izvršavanja programa (tj. znatno većom nego što predviđa IEEE 754 standard), jer u fazi kompajliranja trajanje samog izračunavanja i nije toliko bitno (izračunavanja u većoj tačnosti su naravno sporija). Desi li se da kompajler primijeni povećanu tačnost tokom izračunavanja za vrijeme kompajliranja (a to će se često desiti), moguće je da zaključi da taj izraz ima vrijednost 0 i da ga prosto zamijeni nulom. U tom slučaju ćemo zaista dobiti nulu kao rezultat. Stoga, da bi primjeri koji slijede zaista demonstrirali ono što želimo reći, pretpostavićemo da kompajler radi sa isključenom optimizacijom (što je obično podrazumijevani režim rada ukoliko niste sami aktivirali optimizaciju). Alternativno, moguće je i deklarirati promjenljive uz ključnu riječ “volatile” (tj. pisati “volatile double” umjesto samo “double”). Ova ključna riječ ima više značenja, a jedno od njih je da ona efektivno sprečava vršenje optimizacije pri upotrebi tako deklariranih promjenljivih. Tako će isječak programa

 
 volatile double a(123.0), b(321.0);  std::cout << a * b / b - a / b * b;  // Neće biti 0...
 
ispisati nekorektnu vrijednost različitu od nule, čak i ukoliko je uključena optimiztacija.
 
Sada je vrijeme i za najavljeni “hladan tuš”. Poseban problem stvara činjenica što neki brojevi koji u dekadnom brojnom sistemu imaju konačno mnogo decimala, dobijaju beskonačno mnogo decimala nakon pretvaranja u binarni brojni sistem. Na primjer, vrijedi
 
0.2 = (0.001100110011…) 
 
Međutim, pokušamo li ovaj broj zapamtiti u promjenljivoj tipa “double”, prema IEEE 754 standardu biće zapamćena samo 5  bita mantise (ne računajući vodeće nule, koje se “namještaju” izborom eksponenta), odnosno biće zapamćen broj zaokružen na 5  bita mantise, koji glasi
 
 (0.001100110011001100110011001100110011001100110011001101) 
 
Prevedeno u dekadni zapis, ovaj broj glasi
 
 0.200000000000000011102230246251565404236316680908203125
 
Mada je ovaj broj veoma blizak broju 0.  (apsolutna greška manja je od 10   ), ostaje činjenica da on nije 0. . Drugim riječima, računar ne može u promjenljivim realnog tipa tačno da zapamti niti tako jednostavan broj kao što je 0.  (bar ne koristeći IEEE 754 standard zapisa realnih brojeva). Iluziju o tačnom pamćenju stvara činjenica da će sljedeći programski isječak
 
 double a(0.2);  std::cout << a;       // Izgleda tačno... 
 
ispisati na ekran tačnu vrijednost “0. ”. Međutim, naredbe za ispis realnih brojeva programirane su tako da “zamazuju oči” korisniku time što se pri ispisu rezultat uvijek zaokružuje na određeni broj tačnih cifara (prema standardu 6, ako se ne kaže drugačije). Malo bolji (mada ne i potpuni) uvid u surovu stvarnost pruža sljedeći programski isječak:
 
 double a(0.2);  std::cout << std::setprecision(30) << a;  // Je li ovo baš 0.2? 
 
Ovaj programski isječak ispisuje na ekran “0.20000000000000001”, odakle se barem vidi da zapamćena vrijednost zapravo i nije tačno 0. . Moglo bi se postaviti pitanje ako je već tako, zbog čega onda nije ispisano još decimala, iako smo tražili ispis sa preciznošću od 30 cifara. Odgovor leži u činjenici da manipulator “setprecision” u većini implementacija ne dozvoljava da se traži veća preciznost ispisa od one koja se maksimalno može postići u radu sa promjenljivim tipa “double” (tj. 15 − 16 cifara)

Ovim ćU završiti priču o frustracijama vezanim za realne tipove podataka (ima ih još mnogo, ali gore opisane su vjerovatno najbolnije, a ima ih jos par). Kao pouku treba izvući zaključak da se promjenljive realnog tipa ne trebaju koristiti olako, nego samo onda kada su zaista neophodne (pogotovo ih ne treba koristiti za rješavanje problema koji bi se lijepo mogli riješiti upotrebom isključivo cjelobrojnih promjenljivih). Još je bitno napomenuti da opisane nezgode nisu same po sebi svojstvo jezika C i C++, nego su posljedica zapisa realnih brojeva u pokretnom zarezu prema IEEE 754 standardu, koji je prihvatila većina kompajlera za većinu programskih jezika. Dakle, većinu opisanih problema možete očekivati i u Javi, C#-u, Pascal-u, Visual BASIC-u, itd