Mul on moniulotteinen muuttuja(taulukko) joka pitäs saaha tyhjennettyä mites onnistuu?
Vai kannattaakos muuttujia tyhjätä jos niiden sisältöä ei enään tartte kyseisessä muuttujassa kuitenkin aika runsaasti tietoja?
Onkos tämä sama asia
ofstream myfile ("example.bin", ios::out | ios::app | ios::binary);
kuin
ofstream myfile;
myfile.open ("example.bin", ios::out | ios::app | ios::binary);
Vai kannattaakos muuttujia tyhjätä jos niiden sisältöä ei enään tartte kyseisessä muuttujassa kuitenkin aika runsaasti tietoja?
Onkos tämä sama asia
ofstream myfile ("example.bin", ios::out | ios::app | ios::binary);
kuin
ofstream myfile;
myfile.open ("example.bin", ios::out | ios::app | ios::binary);
Vastaukset 5
Vanhimmat
"Mul on moniulotteinen muuttuja(taulukko) joka pitäs saaha tyhjennettyä mites onnistuu? "
Mitä tarkoitat "tyhjentämällä"? Vapauttaa muistia vai asentaa sisältöä nollaksi?
int taulukko[100][100]; //staattinen taulukko
Vie tietyn määrän muistia, jos tyhjennät yhden tai kaikkien elementtien sisältöä se ei vaikuta kokonaismuistimäärään:
taulukko[23][45]= NULL; //turhaa, ei vapauta muistia.
Jos taulukkosi on luotu dynaamisesti (eli olet käyttänyt esim new tai malloc() sen rakenteen luomiseen voit mys vapauttaa taulukon viemä tilaa delete tai free() (pointerimuuttuja taulukkoon jää, mutta sen sisältö on nolla).
Tuohon toiseen kysymykseen koskien ofstream en muista varmuudella, mutta veikkaisin että toimivat samalla tavalla. Sehän on helposti testattavissa, jos tuo ensimmäinen tapaus antaa herjan kun siihen yrittää I/O:ta se ei ole auki ja on avattava erikseen. Toinen tapaus pitäisi toimia.
*Mitä tarkoitat "tyhjentämällä"? Vapauttaa muistia vai asentaa sisältöä nollaksi? *
Vapauttaa muistia. Aikasempa ohjelmointi kokemus scriptaus kielistä joissa tuota muuttujien tyhjentämistä kannatti tehdä muistin säästämiseksi.
Jotenkin tuntuu, että ajattelen kaik asiat liian PHP mäisesti, kai sitä pikkuhiljaa oppii ymmärtämään C ajattelumailmankin.
Kiitoksia joten empäs turhaan yrittele tyhjentää noita staattisia taulukoita.
*Sehän on helposti testattavissa, jos tuo ensimmäinen tapaus antaa herjan kun siihen yrittää I/O:ta se ei ole auki ja on avattava erikseen.*
Tuo ensinmäinenkin toimii ja toimii myös functioiden sisällä. Mutta tuo open jutun sisältävä herjaa jos tietoa functiossa yritän tallentaa.
Mutta avaako tuo ofstream myfile ...... tiedoston kun sitä ensinmäisen kerran tietoa kirjoitetaan ja sulkee heti, vai suljetaanko tiedosto vasta sitten kun ohjelmakin suoritus loppuu?
Tietoa kun tallennan aikasta paljon ja monta kertaa, joten turhaa sitä tiedostoa on avata ja sulkea, kun voisi olla auki kokoaja.
Vielä muutama kysymys lisää.
Onkos staattinen dynaamista taulukkoa nopeampi käyttää?
Vai miten/mihin se tieto kannattaisi tallentaa jos nopeus on tärkeitä?
tunnen ofstream melko pinnallisesti (en käytä sitä). Uskoisin kuitenkin että väylä pysyy auki kunnes suljet tiedoston tai ohjelma lopettaa toimintaansa. Jos ilmenee ongelmia, flush-tominta saattaa olla ratkaisu (ei jää tavaraa puskuriin).
Tuota toista kysymystä mietin vähän aikaa, ja rehellisyyden nimessä minun täytyy myötää että en varmuudella tiedä mistä taulukkoelementit löytyvät nopeammin, staattisesta tai dynaamisesta taulukosta. Vahva käsitykseni on että staattisesta, täysin varma en kuitenkaan ole. Mutta mitään suurempia nopeusparannuksia et tästä kyllä saavuta.
Se mikä kuitenkin on >100% varmaa on että dynaamisen taulukon tilan varaaminen vie paljon, paljon enemmän aikaa kun staattisen taulukon taulukon luonti.
Jos haluat (muuta kuin tuhlatakseen aikani) perustelut vastaukseni, ehkä lähetän ne.
Vastaus tuohon viimeiseen kysymykseen, "miten data kannattaa tallentaa jos nopeus on tärkeää?", on yksinkertainen: Se riippuu kokonaan mitä aiot tehdä datalle!
Taulukko (ns flat table) on melko harvoin oikea tapa tallentaa data. Jos ajattelet esim taulukkolaskentaohjelman ulkonäköä, tyypillinen taulukko mutta suurin osa taulukkoelementeistä ovat tyhjiä! Kukaan ei ole kiinnostunut tyhjistä soluista, ainoastaan niistä jotka sisätävät jotain tietoa. Tämän takia käytetään harvan matriisin menetelmää (Sparse matrix) jossa jokaisen täytetyn elementin kohdalla on viite seuraavaan täytettyyn elementtiin.
Toinen esimerkki voisi olla käyttöjärjestelmän tiedostoallokointijärjestelmä (esim FAT-table). Vaikka kyseessä ei ole muuta kuin taulukko jossa periaatteessa on kaksi saraketta, tiedostonimi ja sen sijainti levyllä, haku pitäisi olla nopea. Ei ole mitään järkeä kelata kaikko taulukon tiedistonimet läpi kunnes löydetään oikeaa! Siksi käytetään tieto(huom.ei tiedosto) rakennetta nimeltä "binary tree": Jos tiedostonimen ensimmäinen kirjain on pienempi kuin "k", siirry vasemmalle. Jos ensimmäinen kirjain on suurempi kuin "g" siirry oikealle. Tällaisella rakenteella alennat exponentiaallisesti hakuajat, esim morse-aakkoset voi löytää 6:ssa hakuvaiheessa, suora haku edellyttäisi 37 hakuvaihetta.
Toiset mielenkiintoidia tietorakenteet voisivat olla linked-list, double-linked-list, hash-table jne. Ammattiohjelmoija hyvin harvoin käyttää taulukoita, niiden hitauuden takia.
#include
#include
#include
#pragma hdrstop
//---------------------------------------------------------------------------
#pragma argsused
using namespace std;
int main(int argc, char* argv[])
{
//Luodaan streami tiedosto example.txt
ofstream myfile ("example.txt", ios_base::out | ios_base::app | ios_base::binary);
//Kirjoita tiedostoon jotakin
myfile.close();//Tallennetaan tiedosto
getch();
//Nyt voidaan hyödyntää olemassaolevaa streamiä esim:
//myfile.open ("example.txt", ios_base::out | ios_base::trunc | ios_base::binary);
//Ylläoleva tyhjentää tiedoston
//myfile.close();
//Luotu streami siis säilyy tiedoston sulkemisesta huolimatta ja voidaan
//asettaa uusia ios-lippuja.Nuo kaksi lauseketta eivät siis ole sama asia,
//kysymykseesi viitaten.myfile.open-lausekkeella tiedosto voidaan siis avata
//eri käyttötarkoituksia varten,kunhan streami on ensin olemassa.
return EXIT_SUCCESS;
}
//---------------------------------------------------------------------------
Niin,olihan se sama asia.En vain huomannut,että
sinulla oli streami avattuna myös siinä toisessa
lausekkeessa.