Keresés

Aktív témák

  • cucka

    addikt

    válasz pmonitor #78 üzenetére

    Amit írtam, az nem egy megvitatandó gondolatmenet, hanem egy axioma.
    Ha OOP nyelvben fejlesztesz, akkor amit írtam, az egy tény. Ez van.
    Elfogadhatod és magadévá teheted ezt a gondolatmenetet, és akkor OOP-ben jobb fejlesztő leszel mint előtte. Már ha akarod, persze, senki se kényszerít.

    A másik topikban panaszkodtál, hogy itt senki se segít semmiben, hát tessék, az már rajtad áll, hogy mit kezdesz vele.

  • cucka

    addikt

    válasz pmonitor #76 üzenetére

    De amit tényleg próbálj felfogni, az a következő:

    Valami vagy garantálja az elemek sorrendjét, vagy nem garantálja.

    És ha nem garantálja, akkor nem írsz olyan kódot, ami csak akkor működik jól, ha ez a garancia teljesül.

    Szerintem nem túl bonyolult. Szóval mielőtt lemennél ASM-be, azért próbáld megérteni ezeket az egyszerű logikai összefüggéseket.

  • cucka

    addikt

    válasz pmonitor #74 üzenetére

    Leírtam az esetet, amikor nem működik.

    Amikor te az [A,B,C] hashset-et listává alakítod, akkor az általában az [A,B,C] listát fogja eredményezni. Tehát az indexelésed általában működni fog.

    Kivéve amikor nem. Mert jön a gc és átrendezi a memóriádat. Vagy valaki egy másik CLR-en futtatja a kódodat. Vagy beraksz egy D elemet a set-be, és az nem a lista végén fog megjelenni.

    Ha az elemek sorrendje nincs garantálva, az azt jelenti, hogy nem írsz olyan logikát, ami azt feltételezi, hogy a sorrend garantálva van. Akkor se, ha általában a sorrend nem szokott változni.

    Ez egy egzakt eldönthető kérdés. Vagy sorrendben vannak az elemek, vagy nincsenek sorrendben.
    Ha többé-kevésbé az esetek nagy részében általában sorrendben vannak, és kipróbálod, és a sorrend nem változik, és a te gépeden jónak tűnik, na az nem jelent lófaszt se.

    [link] itt fel van sorolva az összes interfész, amit a HashSet implementál. Mindegyik garantál valamilyen viselkedést.
    Amelyik viselkedést itt látod, azon dependálhatsz.
    Amelyiket nem látod, azon nem dependálsz.
    Nem olyan bonyolult.

  • cucka

    addikt

    válasz pmonitor #70 üzenetére

    Mondom jókedvemben vagyok, szóval vegyük végig.
    Ott van a metódusod, amivel indexelni tudod a hashset-edet. Amikor azt mondom, hogy hashset[i], akkor
    1. a hashset-ből csinálsz egy listát - ugye ez az aminek nem determinált a sorrendje
    2. visszatérsz a lista[i]-vel

    Namost legyen egy hashsetem, A, B, C értékekkel. Jön a for ciklus, ami végigmegy az elemein

    i=0 eset
    megcsinálod a listát, az lesz benne, hogy [A,B,C]. visszatérünk a lista[0]-val, ami az A érték.

    i=1 eset
    megcsinálod a listát, az lesz benne, hogy [B,A,C], visszatérünk a lista[1]-el, ami az A érték

    i=2 eset
    megcsinálod a lsitát, az lesz benne, hogy [C,B,A], visszatérünk a lista[2]-vel, ami ismét az A érték

    végigértünk a for cikluson, az [A,B,C] hashset-ből feldolgoztuk az A értéket 3szor, és a többi értéket nem dolgoztuk fel.

    Ezt jelenti az, hogy a egy Set elelein nincs sorrend meghatározva. Erre mondtad hogy érted, de láthatóan nem érted, remélhetőleg így már menni fog.

    Szóval innen adódik a köv. feladat, hogy vajon hogy lehet mégis olyan indexelést csinálni egy hashset-re, ami garantáltan működik?

    mod: a példa kódodra. Itt a fenti esetben is az lesz, hogy általában a listád az lesz, hogy [A,B,C] és általában működni fog.
    Kivéve, amikor nem fog működni, mert jön a háttérben a gc és átrendezi a memóriádat. És akkor majd más lesz a sorrend.

  • cucka

    addikt

    válasz pmonitor #70 üzenetére

    A foreach-al végig tudsz iterálni egy collection-ön. Pontosabban bármin, ami implementálja az IEnumerable interfészt.

    Az egyetlen dolog, amit egy IEnumerable garantál, hogy írhatsz rá egy foreach-et, ami a collection-öd mindegyik elemét fel fogja dolgozni.

    Amivel az IEnumerable nem foglalkozik, és nem is szükséges tudni egy foreachhez, az hogy :
    - melyik elem micsoda
    - két elem közül melyik a nagyobb
    - melyik elem hányadik a sorban

    Te valamiért mindenképp Array-ként akarod használni. Az Array egy szűkebb értelmezése a collection-nek, mert mindenképp garantálja, hogy minden elemnek van egy nemnegatív indexe, és az indexekben nincsenek lyukak.

    Nyilván az Array az egy Enumerable. De fordítva ez nem igaz.

  • cucka

    addikt

    válasz cucka #68 üzenetére

    Most jó hangulatban vagyok, szóval itt egy feladat, amiből tanulhatsz valamit.

    Adott pár hsz előtt az indexelő megoldásod. És adott ez a for ciklus amit írtál.

    Gondold végig, hogy vajon ez a for ciklus mindig garantáltan fel fogja-e dolgozni a hashSet-et összes elemét?

    A választ erre már megírtam itt, csak össze kell raknod fejben.

  • cucka

    addikt

    válasz pmonitor #67 üzenetére

    Egyébként ez a kód mit csinál?
    Milyen osztály adattag ellenőrzés?
    Milyen negatív indexek?

    Ne haragudj, de ezek a szavak külön-külön értelmesek, de nem formálódnak koherens gondolattá.
    Csakúgy mint ez a pár soros kód. Értem, hogy mit csinál, csak azt nem, hogy miért. Mi értelme ennek, mit jelent az az i érték amit kiírsz a végén?
    (Mert ugye a hashset-edben nincs sorrend definiálva. Tehát az i érték a végén az bármi lehet. Egy szám, jelentés nélkül.)

  • cucka

    addikt

    válasz pmonitor #65 üzenetére

    Ha tudnád, akkor nem írtad volna meg ezt a kódot így.
    Amikor a set-ből listát csinálsz abban a getterben, ott szintén nincs garantálva az elemek sorrendje.
    Tehát nincs semmilyen garancia arra, hogy ez a kód jól fog működni. Az esetek többségében jó lesz, de ez csak a véletlen műve.

  • cucka

    addikt

    válasz pmonitor #63 üzenetére

    Azért nem lehet indexelni, mert a Set nem garantál semmilyen sorrendet. Ez egy halmaz. Egy halmaznak nincs "első eleme" meg "második eleme".

    Ha szükséged van sorrendre, akkor létezik SortedSet.

  • cucka

    addikt

    válasz cucka #50 üzenetére

    Még egy nem annyira apróság, ami kimaradt.
    Amit írtam, az ott érvényes, ahol a string mutable.
    Java-ban (meg talán c#-ban is) a string immutable.
    Immutable esetben értelmét veszti a copy on write technika, mert ugye nincs write.
    A stringjeidet immutable értékként kezeled oszt jónapot.

  • cucka

    addikt

    válasz hiperFizikus #44 üzenetére

    Itt azért keveredik a szezon a f*zommal.

    Egy magas szintű nyelvben a string az egy karakterlánc, valamilyen jól meghatározott kódolással. Az, hogy hol van a memóriában, hány byte-ot kell neki foglalni, mikor kell felszabadítani, mikor kell lemásolni, ezt mind a fordító fogja neked kitalálni és nem kell vele foglalkozz.

    C-ben a string az egy char*, ami egy mutató, ami egy darab memória legelső byte-jára mutat.
    A char típus egy byte-ot jelent, nem egy karaktert.
    A stringed vége a legközelebbi 0x00 byte lesz.
    Szóval van egy halom byte-od. C-ben ez a string. Azt csinálsz vele, amit akarsz, rád van bízva, hogy milyen karakterkódolás szerint értelmezed, vagy egyáltalán ember által olvasható karakterként értelmezed-e.
    Ha beolvasol egy jpeg képet a memóriába, akkor az is egy byte halmaz lesz, az is char* típus lesz, a te dolgod, hogy tudd, hogy mit kezdj vele.

  • cucka

    addikt

    válasz pmonitor #43 üzenetére

    Az eltén nem tanítanak blődségeket, a copy on write fogalmával érdemes barátkozni.
    Az egész bonyolítás azért lett kitalálva, mert ha a string nem value típus, akkor szívás vele dolgozni és nagyon könnyű hibázni. Ha value típus és mindenhol másolatot készítesz belőle, az meg brutál lassú és memóriaigényes lesz.

    Ezért a fordító eljátssza azt neked, hogy a string value típus, mint ha minden egyes stringed egy másolat lenne, de valójában csak akkor másol, amikor muszáj.
    Sőt olyan is van, hogy csak egy részét másolja le.

    Szval amikor te az unsafe kódban ott turkálod a memóriát, és azt hiszed, hogy okosságra jöttél rá, akkor hidd el, akik a fordítót írták, azok okosabbak nálad meg nálam összeadva kétszer.

    A referencia pedig gyakorlatilag nem egy mutató. A mutató a mutató.
    Ha ugyanazt jelentenék, akkor nem létezne két külön fogalom rá.

Aktív témák