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
629
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
Aivosyöpää sairastava Olga Temonen TV:ssä - Viimeinen Perjantai-keskusteluohjelma ulos
Näyttelijä-yrittäjä Olga Temonen sairastaa neljännen asteen glioomaa eli aivosyöpää, jota ei ole mahdollista leikata. Hä912900Pelotelkaa niin paljon kuin sielu sietää.
Mutta ei mene perille asti. Miksi Venäjä hyökkäisi Suomeen? No, tottahan se tietenkin on jos Suomi joka ei ole edes soda2991686Mikä saa ihmisen tekemään tällaista?
Onko se huomatuksi tulemisen tarve tosiaan niin iso tarve, että nuoruuttaan ja tietämättömyyttään pilataan loppuelämä?2461557- 871391
IL - VARUSMIEHIÄ lähetetään jatkossa NATO-tehtäviin ulkomaille!
Suomen puolustuksen uudet linjaukset: Varusmiehiä suunnitellaan Nato-tehtäviin Puolustusministeri Antti Häkkänen esittel4021374Nyt kun Pride on ohi 3.0
Edelliset kaksi ketjua tuli täyteen. Pidetään siis edelleen tämä asia esillä. Raamattu opettaa johdonmukaisesti, että3981292Kiitos nainen
Kuitenkin. Olet sitten ajanmerkkinä. Tuskin enää sinua näen ja huomasitko, että olit siinä viimeisen kerran samassa paik21079Esko Eerikäinen tatuoi kasvoihinsa rakkaan nimen - Kärkäs kommentti "Ritvasta" lävähti somessa
Ohhoh! Esko Eerikäinen on ottanut uuden tatuoinnin. Kyseessä ei ole mikä tahansa kuva minne tahansa, vaan Eerikäisen tat381037Hyväksytkö sinä sen että päättäjämme ei rakenna rauhaa Venäjän kanssa?
Vielä kun sota ehkäpä voitaisiin välttää rauhanponnisteluilla niin millä verukkeella voidaan sanoa että on hyvä asia kun329874Miksi Purra-graffiti ei nyt olekkaan naisvihaa?
"Pohtikaapa reaktiota, jos vastaava graffiti olisi tehty Sanna Marinista", kysyy Tere Sammallahti. Helsingin Suvilahden257855