Eli nyt tulee varmasti vaikea selkoista tekstiä.
Ongelma on, että pitäisi saada tehtyä seuraavanlainen määrittely.
On paljon ryhmiäA, missä on paljon ryhmäB kokonaisuuksia. RymilläA on kaksi nimeä kuvaamaan niitä sekä niiden nimet voi muuttua ohjelman suorituksen aikana kuitenkaan hävittämättä sitä alkuperäistä ryhmääA tai ryhmä kokonaisuuksiaB.
Nämä ryhmät A-B on täysin dynaamiset, joten niihin ei voi luoda mitään kovakoodattua indeksointia.
Miten tuolta löydän haluamani tietoa, miten toi homma kannattais järjestää? Ideksoinnin puuttuessa olen turvautunut liittämään tietoa yhteen string==string.
g_groupID, g_tID on vaan indeksejä toisissa luokissa. NIISTÄ ei tarvii välittää.
Tässä on nyt koko yö tota jo kirjoteltu/pohdittu ja aloitettu alusta :)
Ite oon menny ihan solmuun tän asian kanssa. Kyseessä ei ole minkään koulun harjoitus, vaan ihan oma pikku kyhäelmä. Toivon mukaan joku tajus mitä tuuppaan takaa.
Tässä nyt mitä olen kyhännyt... ehkä se avaa enemmän. En laita muuta kun muuttujien esittelyt.
// RYHMÄB
class CGroupItem{
protected:
int g_GroupID; // ÄLÄ TÄSTÄ VÄLITÄ
int g_tID; // ÄLÄ TÄSTÄ VÄLITÄ
std::string g_groupName; // TÄLLÄ HETKELLÄ LIITTÄÄ TÄMÄN JOHONKI RYHMÄKOKONAISUUTEEN
};
class CGroup{
protected:
//RYHMÄB
std::vector< std::vector > g_group;
std::vector< std::string > g_groupNamesShort;
std::vector< std::string > g_groupNamesLong;
}
C++ luokka / olio ongelma.
5
658
Vastaukset
- keksa1
niin eikö toteutus voi myös olla ihan millinane haluaa.
Jos ryhmät voivat dynaamisia ja ties mitä, niin eikö indeksointia ja järjestämistä voisi tehdä ulkopuolisessa komponentissa joka soveltuu siihen paremmin esim. tietokanta.
Oliota luodessa sille annetaan vaan täysin yksilöivä ID ja muuten olion tila ja arvot voi muuttua miten tahansa.
Indeksointi, ruhmät yms on tehty tietokannassa ja siellä tuo olion yksilöivä ID on pääaivan. muut sarakkeet vois olla ryhmäid tms.
Oliot vois siis olla yhdessä vectorissa kaikki ja ryhmät saa selville kannan kautta- _hukassa_
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. - Ihan helppoa
_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.Kannattaa käyttä linkitettyjä listoja
- hmmhohumm
_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.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ä. - Listaa vaan
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.
Ketjusta on poistettu 0 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Mitä yhteistä on sulla ja kaivatulla?
Onko teillä samantyyppinen olemus tai luonne? Vai muistuttaako vartalonne toisiaan? Tai kasvot? Entä pukeutuminen? Onko991516- 2231136
Kerran oltiin mekin kahdestaan
Saanko sanoa, että minua kyllä vähän huvitti jälkeenpäin? Olit kuin vapiseva jänis ketun vieressä valmis loikkimaan paik131136Oikeasti, voitais mennä kahville
ja jutella niin kuin normi-ihmiset. Kyllä toivon sitä. En pelkää kohdata enkä istua sun kanssa samassa pöydässä. Miten o81949Persut yritti estää somalinaista väittelemästä lääketieteen tohtoriksi
Yrittivät saada hänet lähihoitajakouluun, vaikka pärjäsi hyvin koulussa. Nyt hän on yliopistossa väitellyt lääketieteen240941- 141920
Jos nainen harrastaa seksiä
Useiden kanssa, miten se eroaa miesten mielestä siitä, jos miehellä on ollut useita s kumppaneita? Oletan että kaikki mi179903Pihlaja-puulle
Illat on mulle pahimpia. En tiiä miks se olis vaan parasta yöstä toiseen nukkua sun kanssa ja herätä sun kasvoihin. Jos15819- 71757
Yritin keväällä unohtaa sinut nainen
mutta siinä kävi niin, että ikävä tuli korkoineen takaisin. Niin että mikä taikavoima sinulla on minuun, sitä joutuu mie31713