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
674
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
Persujen mukaan rasismi on huumoria
Vaan kun koomikko kutsui Halla-ahoa fasistiksi, niin piti haastaa oikeuteen. Mihin se huumorinitaju yhtäkkiä hävisi? ⠀2806729Rasismia kaikkialla näkevät ovat Suomen tyhmimpiä ihmisiä
ja monillahan kuluu myös mielialalääkkeitä, eli päässä on ongelmia. Mutta he eivät tajua kuinka paljon ja ihan todellis2426290Ei kahta sanaa etteikö Petteri Orpo hyväksy rasismia
Koska jatkaa hallituksessa rasistisen perussuomalaisiksi itseään kutsuvan puolueen kanssa. Se on Petteri Orpon arvomaai425672Mitkäs nuorisoporukat ovat toisia nuoria ryöstelleet (selvää rassismia)
No poliisi kertoo, että maahanmuuttajataustaisia ovat, ja isot porukat sillä yhden suomalaisen uhrin kimpussa on ollut j1585005Pitkän linjan yritysjohtaja: Suomen tapahtumat eivät ole Aasian kärkiuutinen
Viimeaikaista kohua on käytetty sisäpoliittisena lyömäaseena, Thomas Zilliacus sanoo. – Koska asiaa kuitenkin kommentoi373830Hallitus on kaadettava ja Orpon on erottava
Mikään muu hallitus ei ole oman elämäni aikana tuhonnut näin paljon tämän maan taloutta ja työllisyyttä sekä suomen main1953739Lasse Lehtonen vaatii persuja pyytämään anteeksi aasialaisilta
Persut ova romahduttaneet Suomen maakuvan parissa päivässä negatiiviseksi rasismillaan ja se alkaa vaikuttamaan jo Suome1323467HS 12/25 kysely: persut romahti, demarit raketoi
Kyyti on kylmää persuleirissä, saattaa vetää siellä silmätkin viirulleen. Sen sijaan SDP:n puoluetoimistolla voidaan pok453169Demarit ovat oikeasti törppöjä eli heikkoälyisiä
ja todistavat sitä päivittäin täällä lapsellisilla jutuillaan. Kauheasti on hehkuttaneet kuinka demarien kannatus vaan53155Rasismi rapauttaa Suomen mainetta ja hallituksen hiljaisuus pahentaa vahinkoa
Finnairin viesti Japanista on pysäyttävä: suomalaisen politiikan rasismikohut heijastuvat suoraan matkustuspäätöksiin ja3372830