C ++ õpetus ujukite ja intide käsitsemiseks

Int on täisarv, näiteks 47 ilma komata. Teil ei tohi olla 4,5 beebit ega silmus 32,9 korda. Ujuki kasutamisel võib teil olla 25,76 dollarit. Seega peate oma programmi loomisel otsustama, millist tüüpi kasutada.

Seda teevad mõned skriptikeeled? Kuna ujukid on ebaefektiivsed, võtavad ujukid rohkem mälu ja on üldiselt aeglasemad kui ints. Samuti ei saa te hõlpsalt võrrelda kahte ujukit, et näha, kas need on võrdsed, nagu saate intide korral.

Numbritega manipuleerimiseks peate need mällu salvestama. Kuna väärtust saab hõlpsalt muuta, nimetatakse seda muutujaks.

koostaja mis loeb teie programmi ja teisendab selle masinkoodiks, peab teadma, mis tüüpi see on, st kas see on int või ujuk, nii et enne kui teie programm kasutab muutujat, peate kuulutama seda.

Võite märgata, et muutuja Loendur on seatud 0-le. See on valikuline lähtestamine. Muutujate lähtestamine on väga hea tava. Kui te ei lähtesta ja kasutate neid siis koodis ilma algväärtust määramata, algab muutuja juhusliku väärtusega, mis võib teie koodi „murda”. Väärtus on mis tahes, mis oli programmi laadimisel mälus.

instagram viewer

Mis on suurim arv, mida int saab salvestada?. Noh, see sõltub tüüpi Protsessor kuid üldiselt aktsepteeritakse seda 32 bitina. Kuna see mahutab peaaegu sama palju negatiivseid väärtusi kui positiivseid, on väärtuste vahemik +/- 2-32 kuni 2-ni32 või -2,147,483,648 kuni +2,147,483,647.

See on mõeldud allkirjastatud int jaoks, kuid on ka allkirjastamata int, mis hoiab nulli või positiivset. Selle vahemik on vahemikus 0 kuni 4 294 967 295. Lihtsalt mäleta - allkirjastamata sisendid ei vaja nende ees silti (nagu + või -1), kuna need on alati positiivsed või 0.

On olemas lühem int tüüp, mida juhuslikult nimetatakse lühikeseks int, mis kasutab 16 bitti (2 baiti). See hoiab numbreid vahemikus -32768 kuni +32767. Kui kasutate suurt arvu sisendeid, saate mälu salvestada lühikeste intide abil. See ei ole kiirem, vaatamata sellele, et see on poole väiksem. 32-bitised CPU-d tõmbavad väärtused mälust korraga 4 baiti plokkides. St. 32 bitti (seega nimi - 32-bitine CPU!). Nii et 16 bitti toomine nõuab ikkagi 32-bitist toomist.

Seal on pikem 64-bitine nn pikk pikk C-s Mõned C ++ kompilaatorid ei toeta seda tüüpi otse, kuid kasutavad alternatiivset nime, nt kasutavad nii Borland kui ka Microsoft _int64. Selle vahemik on -9223372036854775807 kuni 9223372036854775807 (allkirjastatud) ja 0 kuni 18446744073709551615 (allkirjastamata).

Kui te ei tee teaduslikku programmeerimist väga suurte või väikeste numbritega, kasutate suurema täpsuse saavutamiseks ainult kaheinimeseid. Ujukid on 6-kohalise täpsusega, kuid kahekordsed pakuvad 15-kohalisi.

Mõelge numbrile 567.8976523. See on kehtiv ujuki väärtus. Kuid kui prindime selle välja selle koodi abil allpool, näete, et ilmneb ebatäpsus. Numbril on 10 numbrit, kuid seda hoitakse ainult kuue numbri täpsusega ujukõikumises.

Vaata Sisendi ja väljundi kohta üksikasju kuidas cout töötab ja kuidas täpsust kasutada. See näide seab väljundi täpsuseks 8 numbrit. Kahjuks mahub ujukitesse ainult 6 ja mõned kompilaatorid annavad hoiatuse topeltväärtuse ujukiks teisendamise kohta. Kui see töötab, prinditakse see välja 567.89764

Kui muudate täpsuse 15-le, prinditakse see numbrina 567.897644042969. Üsna erinev! Liigutage nüüd komakohta vasakule, nii et väärtus on 5.678976523, ja käivitage programm uuesti. Seekord on selle väljund 5.67897653579712. See on täpsem, kuid siiski erinev.

Kui muudate väärtuse tüübi kahekordseks ja täpsuse 10, prindib väärtus täpselt määratletud. Üldiselt on hõljukid käepärased väikeste täisarvude korral, kuid enama kui 6-kohalise numbri korral peate kasutama kahekohalist numbrit.

Arvutitarkvara kirjutamisest poleks palju kasu, kui ei saaks teha liitmist, lahutamist jne. Siin on näide 2.

Lisaks liitmisele saate teha ka lahutamist, korrutamist ja jagamist. Lihtsalt kasutage +, - lahutamiseks, * korrutamiseks ja / jagamiseks.

Ujukite korral ei saa te kontrollida, mitu komakohta kuvatakse, kui te pole täpsust seadnud nagu varem näidatud.

Nüüd saab laiust, joondust, komakohtade arvu ja märke seada nupuga cout objekt ja iomanip sisaldavad failifunktsioone.

Tuhandete eraldajad on pisut keerukamad. Need seatakse arvuti lokaadi järgi. Locale sisaldab teie riigi jaoks olulist teavet, näiteks valuutasümbolid ja koma ning tuhandeid eraldajaid. Suurbritannias ja USA-s kasutatakse arv 100,98 koma. koma, kui mõnes Euroopa riigis on see koma, tähendab 5,70 eurot hinda 5 eurot ja 70 senti.

loob objekti mpunkt mis on viide a rahapunkt malli klass. Sellel on teave määratletud lokaadi - meie puhul - tuhat_sep () meetod tagastab tuhandete eraldaja jaoks kasutatud märgi.

Märge Tundub, et erinevate koostajate vahel on lahknevusi selles osas, kuidas cout.imbue käitub. Visual C ++ 2005 Express Editioni versioon hõlmas eraldajaid. Kuid sama kood Microsoft Visual C ++ 6.0-ga ei teinud!

Kui kasutate ühte neist kahest vormindamisrežiimist läbi cout.setf siis täpsus() seab kümnendkohtade arvu pärast koma (mitte numbrite üldarvu), kuid te kaotate tuhandete vormingute. Ka nulljooned (nagu võimaldas ios_base:: showpoint ) lubatakse automaatselt ilma vajaduseta showpoint.

Võite oodata midagi väärtust 11.0909090909. Tegelikult on väärtus 11. Miks on see? sest väljendus paremal (tuntud kui rvalue) on täisarv / täisarv. Seega kasutab see täisarvu aritmeetikat, mis viskab murdosa ära ja määrab 11-ga f. Selle muutmine

C-s pole sellist tüüpi nagu a loll. C-s avaldised põhinesid selles, et null on vale või null mitte, kui tõsi. C ++ tüüpi loll oskab väärtusi võtta tõsi või vale. Need väärtused on endiselt võrdsed 0 ja 1-ga. Kuskil kompilaatoris on see

Või vähemalt toimib see nii! Kaks allpool olevat rida kehtivad ilma ülekandmata, nii et kulisside taga teisendatakse lollid kaudselt intideks ja neid saab isegi suurendada või vähendada, ehkki see on väga halb tava.

If teeb ikkagi if-i, kuna halb muutuja pole null, kuid see on halb kood ja seda tuleks vältida. Hea tava on kasutada neid nii, nagu need on ette nähtud. kui (! v) on kehtiv C ++, kuid eelistan selgemat kui (v! = 0). See on aga maitse küsimus, mitte a peab tegema direktiiv.

parem on kompilaatoril vigu püüda kompileerimise ajal kui kasutajal jooksuajal

instagram story viewer