Keresés

Új hozzászólás Aktív témák

  • caddie

    csendes tag

    válasz ktg3 #126 üzenetére

    Azt hiszem, hogy a problemak egy reszet mar leirtak, en meg javasolnek 1-2 dologt:

    - nagyon nem illik a headerekbe a using namespace std;-t beleirni
    - a standard konyvtar definial egy vector template osztalyt, majdnem azonos neven
    - a kiiro operator definialasakor te igazabol egy free (''globalis'') fuggvenyt definialsz, amely egyik parametere template osztaly. ebbol kifolyolag az altalad definialt kiiro operatornak is templatenek kell lennie (alatta ki is van kommentezve)
    - konstruktoroknal erdemes hasznalni az inicializalasi listat (ezzel kikerulheto a telejsen felesleges default konstrualas es az ezuatni ertekadas)
    - unsigned int-ek helyett, erdemes hasznalni az STL-hoz hasonloan a size_t tipust
    - ertekado operatorok tipikusan T& ternek vissza a lancbafuzes tamogatasa miatt, de persze lehet, neked pont az volt a celod, hogy ilyen dolgokat ne engedj meg
    - mivel letezik a vektor meretenek lekerdezesere kialakitott interface (size()), ezert velemenyem szerint felesleges a kiiro template operatort friendkent deklaralni
    - a NULL nem szabvanyos! nullat hasznalj helyette
    - a copy konstruktort biztos igy akartad csinalni?


    {
    Vector<int> a;
    // a-t feltoltod elemekkel

    Vector<int>b(a);
    }
    // megsemmisul a, felszabadul a.pData;
    // felszabadul(na) b.pData;
    // de mivel a.pData == b.pData ami mar megsemmisult,
    // ehelyett katasztrofa lesz


    // alternativ eset

    a.clear(); // felszabadul a.pData (b.pData is oda mutat)
    b[5];
    // szerencses esetben elcrachel a programod
    // peches esetben pedig fut tovabb csak hulyeseg irodik ki
    // megpechesebb esetben jo irodik ki
    // klasszikus undefined behaviour



    - copy konstruktor egyertelmuen hibas
    - assert.h helyett majd inkabb cassert-et hasznald
    - erase eseten, ha egy elemed volt akkor -1-re alitod az elemenNum-t
    - postfix increment / decrementalas helyett erdemes a prefixet hasznalni (ahol persze azonos a ketto funkcionalitasa)
    - erase eseteben a torlendo elem kihagyasa nem tul elengas, sott gyanus, hogy a for ciklusnal a ciklusfeltetel tulindexelest fog eredmenyezni
    - insert-nel erdemes lenne const T& -et atadni
    - ennek nem latom sok ertelmet:


    if(elementNum==UINT_MAX)
    {
    return false;
    }


    de ha mar ilyenekre figyelsz, akkor erdemes lenne inkabb a C++ std altal biztositott dolgokat hasznalni, tovabba inkabb a new sikeres memoriafoglalasat ''leellenorizni''* (bar egy beadando eseteben egyiknek sincs tul sok jelentosege)

    * erdemes eszrevenni, hogy alap esetben std::bad_alloc exceptiont dob, de nothrow-os valtozat hasznalataval ra lehet venni arra is, hogy nullpointert adjon vissza sikertelen foglalas eseten


    - insertnel megint az kell, hogy modnjam, hogy ez nem tul elegans modja az elem beszuarasanak
    - insertnel ha pos > mint az aktualis vektor merete, akkor ne egyenkent toltsd fel nullaval, hanem default konstruald nullaval inkabb
    - insertnel nem latom pontosan, hogy miert pos + 1 meretu tombot foglalsz
    - [] operator eseteben az az altalanos STLes megkozelites, hogy [] nem ellenoriz indexhatarokat, csak at teszi azt, igy az at fuggvenyt a [] segitsegevel valositjak meg.
    - eddig sem lattam sok ertelmet az asserteknek, az amlitett dolgok nem olyan hibak amiert le kene shutdownolni az egesz programot, de ertekado operator eseteben egyenesen a jozan esz ellen megy. Abban az esetben inkabb egy return *this; kellene, amennyiben onertekadasrol lenne szo



    Igy elso atfutasra en ezeket a furcsasagokat vettem eszre, nehany kozulok talan csak sznobizmus, de azert akadt kozottuk par tervezesi hiba es eletveszelyes undefined behaviour is.

    [Szerkesztve]

    ''C++ : Where friends have access to your private members.'' — Gavin Russell Baker.

  • caddie

    csendes tag

    válasz Zulfaim #140 üzenetére

    Hat a kod sok-sok sebbol verzik:

    - buff = ' 'zzz' ' ez mi ez?, miert nem hasznalsz inicializalasi listat?
    - kiiro operatornak nyugodtan lehet const buffer& -t atadni
    - += operatornt - minimalisan - igy modositanam:

    )
    buffer& buffer:: operator+=( const char* value)
    {
    char* temp=new char[size = strlen(buff)+ strlen(value) +1];
    strcpy(temp,buff);
    strcat( temp, value);
    delete[] buff;
    buff = temp;
    return *this;
    }


    teljesen feleslegesen masolgatsz es foglalsz memoriat. Jelen pillanatban nem ellenerozom, hogy az atadott pointer null pointer / van legalabb 1 karkater benne stb. Ezt belehekkelheted.

    - ertekado operatornal, bevallom nem ertem ezt:

    for(int i=0;i<size;i++)
    {
    buff=e.buff;
    }


    ez mi ez?

    talan

    for(int i=0;i<size;i++)
    {
    buff [ .i. ] =e.buff [ .i. ] ; // konvertalas miatt :(
    }


    ? De ez sem jo, mert a vegere nem masolja oda a '/0' -t. Sztem erdemesebb lenne hasznalni a strcpy-t

    - kiiro operator hasonloan beteg

    - nem latok racionalis okot, hogy meirt van a += es az egyik ertakado operator az osztalyon belul definialva, a tobbi meg kivul.

    - copy konstruktor is beteg, keves memoriat foglalsz es utana u.a. a hulyeseg van mint ertakado operatornal

    - sztem teljsen feleslegesen a postfix incerementalo operatorok

    [Szerkesztve]

    ''C++ : Where friends have access to your private members.'' — Gavin Russell Baker.

  • caddie

    csendes tag

    1, Osztalyon kivul definicio:
    - letisztult marad az osztaly interface ( kod olvashatosag )
    - tipikusan kulon header / forras fileokba rendezzuk az osztaly deklaraciot es definiciot, hogy az osztaly implementaciojanak megvaltoztatasakor ne kelljen ujraforditani mindne olyan forrasfilet, amely csak az interface-tol fugg (erre vannak meg szofisztikaltabb modellek is pl: pimpl idiom)
    - C++ -ban az a szokas, hogy az inline fuggvenyeket definialjuk osztalyon belul, amelyek 1-2 sorosak, a tobbit pdig osztalyon kivul definialjuk


    2, using namespace std;

    - ezt alapbol nem ajanlott hasznalni, mert az std nevterben levo osszes elerheto nevet beemeli, helyette specifikusan a hasznalt neveket szokas / vagy meginkabb minositeni szokas a hasznalt dolgokat
    - ha header file-ba irod be, akkor az osszes forrasfile amely felhasznalja a headert keretlenul is megkapja az osszes std nevterben levo elerheto nevet
    - nevtereket pont azert talaltak ki, hogy particionalva legyenek (felosztva) a nevek. using namspace std beemelesevel pont ezt iktatjuk ki, hiszen minden beemelunk a ''globalis'' nevterbe


    3, inicializalasi lista:

    - amikor a konstruktor torzsebe adod meg, hogy adott member valtozonak milyen kezdoerteket szeretnel megadni, akkor eloszor letrejon az objektum, lefut a default konstruktora, majd egy kulon fuggvenyhivas kereteben masolodik at a kezdoertek. inicializalasi listaval az adott valtozo konstrualasakor mar kezdoertekkel latod el azt (tehat hatekonyabb es igy az elegans, erre talaltak ki az inicializalasi listat).


    4, size_t: STL az egy peldas kod, erdemes annak a filozofiaja szerint dolgozni, annak eszkozeit hasznalni es amennyire ertelmes idomulni hozza.

    5. NULL nincs benne a C++ szabvanyban, teljesen forditofuggo, hogy van-e benne, mi van mogotte (makro) es hogy a fordito kov. verziojaban is benne lesz-e. amugya 0 -nak implicit konverzioja van pointerekre.

    6. a postfix novelo operatorok definicio szerint egy temporalis objektumba mentik a valtozo eredeti erteket, majd megnovelik a valtozo erteket, a regi erteket pedig visszadjak. a prefix novelo operator cask novel es visszaad, ergo a postfix min 2x annyi muveletet vegez (szamszeruleg, valoszinuleg a fordito ugyanis kioptimalizalja). A lenyeg, hogy prefix kell mindenhova kiveve ahova postfix kell :)


    Roviden ennyi, remelem nem hagytam ki semmit

    ''C++ : Where friends have access to your private members.'' — Gavin Russell Baker.

  • caddie

    csendes tag

    válasz norbiphu #159 üzenetére

    A kodot nem neztem, de a copy konstruktor azert hivodik, mert az operator*() egy temporalis objektumot 'hoz letre' es ez adodik ertekul a b-nek.


    # 1 b = b * 2
    # 2 b = [ c ]
    # 3 b = c



    Ez lenne a normalis megvalositasa egy opeartor*() -nak, amely 'free' esetleg friend fuggvenykent van megvalositva.

    [Szerkesztve]

    ''C++ : Where friends have access to your private members.'' — Gavin Russell Baker.

  • caddie

    csendes tag

    válasz FehérHolló #161 üzenetére

    En megmondom oszinten nem ertem mi a kerdes. Kiprobalod aztan majd kiderul.

    ''C++ : Where friends have access to your private members.'' — Gavin Russell Baker.

  • caddie

    csendes tag

    válasz Zulfaim #168 üzenetére

    Erre annyit lehet mondani, hogy:

    1. szakirodalom
    2. a) net: [link]
    2. b) google: c++ iterator tutorial

    ''C++ : Where friends have access to your private members.'' — Gavin Russell Baker.

  • caddie

    csendes tag

    válasz FehérHolló #175 üzenetére

    Nyilvanvaloan ciklus kesesben van az EOF ellenorzes, mert te a kovetkezot csinalod:


    file: < megnyit
    adat < ellenoriz majd olvas
    adat < ellenoriz majd olvas
    EOF < ellenoriz (adatot olvasott elozoleg) majd olvas(EOFot meg minden mast ami mar nincs is)
    ... < ellenoriz (EOF volt!) es kilep


    Mas:

    tmpstr.restore(f);


    A restore fuggvenyen belul mi ez a masik restore hivas. Valami rekurziv fuggvenyhivas?

    [Szerkesztve]

    ''C++ : Where friends have access to your private members.'' — Gavin Russell Baker.

  • caddie

    csendes tag

    válasz FehérHolló #177 üzenetére

    Ha megnezted volna amit irtam, akkor latszik, hogy en egy konkret eseten irtam le az algoritmus mukodeset, nem altalanossagban... :(

    Olvasol egy sor adatot (n db olvasas egy ciklusban), pont EOF elott er veget az olvasasi sorozat. Az ellenorzes ebben az esetben termesztesen azt mondja, hogy meg nincs EOF, igy elkezded a kovetkezo (n db) olvasast: Az elso adat olvasasakor EOF jon, de te sehol nem ellenorzod, hanem haladsz szepen tovabb es beolvasol n-1 db tovabbi 'adatot' es amikor megtetted csak akkor ellenorzol EOF-ot ujra.

    Tovabbra sem ertem ugyanakkor, hogy mi a terminalo feltetele a String::restore() rekurziv hivassorozatnak. A restore ismet es ismet meghivja onmagat...

    Azt sem ertem, hogy miert nevezted el a String osztalyodat Stringnek? A standard ugyanis definial egy std::string -et, rendkivul megteveszto!!

    ''C++ : Where friends have access to your private members.'' — Gavin Russell Baker.

  • caddie

    csendes tag

    válasz KMan #180 üzenetére

    void main :)

    ''C++ : Where friends have access to your private members.'' — Gavin Russell Baker.

  • caddie

    csendes tag

    válasz FehérHolló #189 üzenetére

    Sztem logikus, hogy az utobbi. Nem varhatjuk el C++-tol, hogy nekunk elore olvas (sott elvarjuk, hogy ne olvasgasson ossze vissza). A I/O flagek a stream aktualis allapotat tukrozik, amikor pedig a kov. elem az eof, akkor bizony az majd csak a kovetkezo olvasaskor fog kiderulni.

    ''C++ : Where friends have access to your private members.'' — Gavin Russell Baker.

  • caddie

    csendes tag

    válasz bpx #194 üzenetére

    Ha ilyet leirsz C++-ban akkor szegyeld magad, de nagyon.

    ''C++ : Where friends have access to your private members.'' — Gavin Russell Baker.

  • caddie

    csendes tag

    válasz KMan #230 üzenetére

    De most komolyan. Ettol egyertelmubb dolog nincs, hogy az ertekadas bal oldalan allo operandusnak adod ertekul az ertekadas jobb oldalan allo operandust. Mar a matematikaba is szinte mindig igy van a:={...}. Ez igazan nem a fordito hibaja.

    ''C++ : Where friends have access to your private members.'' — Gavin Russell Baker.

  • caddie

    csendes tag

    válasz nukeleo #228 üzenetére

    Nem lenne hatranyos, hogy ha
    - leszukidened a kodod a relevans reszekre, nehogy mar nekunk kelljen megfejteni, hogy pontosan mire gondolsz
    - egy paste-bin -be betenni es egy linket adni, mert teljesen olvashatatlan igy indentalas nelkuk

    Ha ezt megteszed szivesen segitek, addig bocs, de az alabbi behanyt kodra nem szivesen fut ra a tekintetem.

    ''C++ : Where friends have access to your private members.'' — Gavin Russell Baker.

Új hozzászólás Aktív témák