C++ luokka / olio ongelma.

_hukassa_

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;

}

5

656

    Vastaukset

    Anonyymi (Kirjaudu / Rekisteröidy)
    5000
    • 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

    1. Suureksi onneksesi on myönnettävä

      Että olen nyt sitten mennyt rakastumaan sinuun. Ei tässä mitään, olen kärsivällinen ❤️
      Ikävä
      65
      1453
    2. Perusmuotoiset TV-lähetykset loppu

      Nyt sanoo useiden HD-muotoistenkin kanavien kohdalla äly-TV, ettei kanava ole käytössä, haluatko poistaa sen? Kanavia
      Apua aloittelijalle
      110
      900
    3. No ei sun asunto eikä mikään

      muukaan sussa ole erikoista. 🤣 köyhä 🤣
      Ikävä
      58
      751
    4. YLE Äänekosken kaupunginjohtaja saa ankaraa arvostelua

      Kaupungin johtaja saa ankaraa kritiikkiä äkkiväärästä henkilöstöjohtamisestaan. Uusin häirintäilmoitus päivätty 15 kesä
      Äänekoski
      47
      734
    5. Mitä mietit Honey?

      Kulta nainen ❤️❤️
      Ikävä
      57
      720
    6. Missä kaikessa olet erilainen

      Kuin kaivattusi? Voin itse aloittaa: en ole vegaani kuten hän. Enkä harrasta tietokonepelejä lainkaan.
      Ikävä
      39
      697
    7. Hyvin. Ikävää nainen,

      Että vainoat ja stalkkaat miestäni.onko tarkoituksesi ehkä saada meidät eroamaan?no,siinä et tule onnistumaan
      Ikävä
      71
      671
    8. Linnasuolla poliisi operaatio

      Kamalaa menoa taas meidän ihanassa kaupungissa. https://www.uutisvuoksi.fi/paikalliset/8646060
      Imatra
      26
      669
    9. Katsoin mies itseäni rehellisesti peiliin

      Ja pakko on myöntää, että rupsahtanut olen 😆. Niin se ikä saavuttaa meidät kaikki.
      Ikävä
      41
      657
    10. Uskomaton tekninen vaaliliitto poimii rusinoita pullasta

      Korni näytösesitelmä menossa kaupunginvaltuustossa. Juhlia ei ole kokouksista tiedossa muilla, kuin monipuolue paikalli
      Pyhäjärvi
      67
      650
    Aihe