C++ luokka / olio ongelma.

Joo-o, mutta noinhan se on.
Muuten muomasin virheen

//RYHMÄB
std::vector< std::vector < CGroupItem> > g_group;
Eli siinä oli se vectori, mistä mainitsit.
Mutta kun noilla ryhmäB:n ryhmän jäsenet voi olla monessa ryhmässä sekä niitä pitää saada etsiä parilla eri nimellä, mikä vain sekottaa pakkaa entisestään.
Tästähän tulee monen suhde moneen. Tietokanta virityksessä se purettaisiin aputaululla jollain taas saatais yhden suhde moneen. Mutta yritän tehdä tätä ilman SQL:ää.

Sanot tosta yksilöivästä ID:stä mikä siis pitää kirjaa mikä ID kuuluu mihin ;)
Koska jos noihin vectoreihin sijoittaa paljon kamaa, niin kopiointi alkaa käymään tuskaseksi samoin haut sieltä. Raapinu kohta kalloni halki.

_hukassa_ kirjoitti:

Joo-o, mutta noinhan se on.
Muuten muomasin virheen

//RYHMÄB
std::vector< std::vector < CGroupItem> > g_group;
Eli siinä oli se vectori, mistä mainitsit.
Mutta kun noilla ryhmäB:n ryhmän jäsenet voi olla monessa ryhmässä sekä niitä pitää saada etsiä parilla eri nimellä, mikä vain sekottaa pakkaa entisestään.
Tästähän tulee monen suhde moneen. Tietokanta virityksessä se purettaisiin aputaululla jollain taas saatais yhden suhde moneen. Mutta yritän tehdä tätä ilman SQL:ää.

Sanot tosta yksilöivästä ID:stä mikä siis pitää kirjaa mikä ID kuuluu mihin ;)
Koska jos noihin vectoreihin sijoittaa paljon kamaa, niin kopiointi alkaa käymään tuskaseksi samoin haut sieltä. Raapinu kohta kalloni halki.

Lue lisää

Kannattaa käyttä linkitettyjä listoja

_hukassa_ kirjoitti:

Joo-o, mutta noinhan se on.
Muuten muomasin virheen

//RYHMÄB
std::vector< std::vector < CGroupItem> > g_group;
Eli siinä oli se vectori, mistä mainitsit.
Mutta kun noilla ryhmäB:n ryhmän jäsenet voi olla monessa ryhmässä sekä niitä pitää saada etsiä parilla eri nimellä, mikä vain sekottaa pakkaa entisestään.
Tästähän tulee monen suhde moneen. Tietokanta virityksessä se purettaisiin aputaululla jollain taas saatais yhden suhde moneen. Mutta yritän tehdä tätä ilman SQL:ää.

Sanot tosta yksilöivästä ID:stä mikä siis pitää kirjaa mikä ID kuuluu mihin ;)
Koska jos noihin vectoreihin sijoittaa paljon kamaa, niin kopiointi alkaa käymään tuskaseksi samoin haut sieltä. Raapinu kohta kalloni halki.

Lue lisää

Nojoo, en ole jaksanut / kerennyt kunnolla perehtymään, mitä haet, mutta:

Tietorakenteita on muutamaa perustyyppiä, kullakin omat kompromissinsa:

tasapainotetut binääripuut ( std::set, std::map ). Löytyy muunkinlaisia puita erityistarkoituksiin
- Ympäripyöreä kompromissi. Lähes kaikki on kohtalaisen nopeata, mutta ykkönen ei ole oikeen missään osa-alueella ( ellei puhuta jostain omasta erityis viriviripuusta ).

Linkitetyt listat( std::deque yms ). Ylläpito nopeata, täsmähaut todella hitaita.

vektorit / taulukot ( std::vector, Group grp[ x ] ) - lajitelutuna nopeat haut, kun n:s alkio saadaan heti esiin. Ylläpito voi olla tosi hidasta
Hajautustaulut. Tämä vaatii enempi suunnittelua, mutta jos napsahtaa kohdalleen niin todella nopea.

Pointterit on nopea, joskin vaarallinen tapa ylläpitää noita ryhmien välisiä relaatioita, esimerkiksi kahteen suuntaan, että mitkä ryhmät kuuluvat A:han ja sitten puolella B, että mitkä A:t sisältävät kyseisen B:n. Jos rymiä pitää luoda / tuhota dymaamisesti, menee homma tietty bugiherkäksi, kun pitää ensiksi ottaa ryhmä pois kaikista listoista ja sitten vasta saa sanoa sille et näkemiin. Mutta näyttää siltä, että niin pitää tehdä jokatapauksessa. Lisäksi ryhmien osoitteet tietty silloin pitää säilyä samana... Tapauskohtainen juttu, minkälaista viritystä on hyvä käyttää.

Tietorakenteita kun suunnittelee, niin kompromissin muodostamiseksi voisi miettiä seuraavaa:
1) Mitä muutetaan ja kuinka usein
2) Kuinka paljon mitäkin on
3) Mitä haetaan ja kuinka usein, kuinka kovat lukunopeusvaatimukset. Täytyykö kaiken läpikäynti olla tosinopeaa? Tehdäänkö täsmähakuja vai tarvitaanko esim. tuki tyyliin ryhmäNimi1 = "?Rämä*", jolloin hakutuloksina vaikkapa CRämä, ARämä1 ja BRämäHohoo. Ovatko nimet uniikkeja vai ei?
4) Konvertoitavuus, eli halutaanko dataa helposti esimerkiksi SQL tai LDAP muodossa pihalle.
5) ym ym, kussakin tapauksessa omat erityisvaatimuksensa.

Tässä sitten painii vastakkain ylläpidettävyys, bugiherkkyys ja performanssi. Mikäli noita on miljoonia, ja hakuja tehdään ziljoniia sekunnissa, niin silloin pitää panostaa tehokkuuteen. Jos muutoksiakin tulee paljon sekunnissa, menee homma vaativaksi. Etenkin jos ryhmiä luodaan / tuhotaan ja rakennetta muokataan jatkuvalla syötöllä. Nimen vaihdoissa täytyy tiettty päivittää indeksit, päivitysnopeus riippuu minkätyyppistä tietorakennetta käyttää indeksoimiseen.

Tietorakenteista:
Vektori -- Vie vähän muistia / alkio. insert / erase O(n) eli hidas, mitä lähempänä alkua, sitä hitaampi. Ainoastaan push_back / pop / erase peräpäästä nopeata. Haut nopeita, mikäli voi käyttää puolitushakua, eli että alkiot ovat valmiiksi lajiteltu ( std::sort / std::lower_bound ). Sortatun vektorin ylläpitäminen voi olla tosihidasta ( O(n)log(n) ). Lineeariset haut sekä läpikäynti nopeinta.

Linkitetty lista ( std::deque yms ): Vie vähän enempi muistia, kun prev / next pointtereita pitää ylläpitää. Lineaarinen haku nopeata, puolitushaku ei onnistu ollenkaan, täsmähaku hidasta O(N). Alkioiden lisääminen / poistaminen on erittäin nopeata:

Hajautustaulu: Hyvin suuniteltuna vähän tilaa vievä, ylläpito nopeata ja täsmähaut todella nopeita, ihanteellisesti O(1). Hankalampi toteuttaa, ylläpidettävyys huonompi. Lineaarinen haku käytännössä yhtä nopeaa kuin vektori tai linkitetty lista, voi olla hidas jos taulussa on paljon tyhjää. Tietokannoissakin hash indeksit tuppavat olemaan tykimpiä, jos tehdään paljon täsmähakuja.

std::set / map: Lisääminen / poistaminen, sekä haut nopeahkoa O ( lg(N) ). Vie usein stl toteutuksesta riippuen muistia enempi kuin noi ylläolevat, ihanteellisesti samaa luokkaa kuin linkitetyssä listassa. Puolitushaku vektorista tyypillisesti nopeampi ja hyvästä hajautustaulusta paljon nopeampi. Lineaarinen haku hidasta ( O(Nlg(N) ) ). Nämä ovat kohtalaisen selkeitä käyttää ja kompromissit ovat yleensä vähäisiä.

Ihan helppoa kirjoitti:

Kannattaa käyttä linkitettyjä listoja

Linkitetys listas oliot pannaan jonoon siten, että olion attribuuteista seuraava osoittaa seuraavaan ja edellinen osoittaa edelliseen olioon. Noitten attribuuttien ei tartte olla justiinsa ton nimisii: riittää, että itte hiffaa, mitä ne nimestä huolimatta tarkoittaa.