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

• #4071 jattila48 aktív tag choco01 #4070

  Új Válasz 2018-04-22 23:13:49 #4071

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  jattila48

  aktív tag

  válasz choco01 #4070 üzenetére

  Ez így van! Másképp tényleg nem lenne értelme. Az előző válaszom hosszabb lett volna, csak közben lejárt a szerkesztési idő.

• #4065 jattila48 aktív tag choco01 #4060

  Új Válasz 2018-04-22 21:12:16 #4065

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  jattila48

  aktív tag

  válasz choco01 #4060 üzenetére

  Ahogy b.kov leírta, k a kölcsönzéseket tároló tömb, ami kolcsonzes * típusú (vagyis kolcsonzes tipusu strukturara mutató pointer). Ez azért pointer, (és nem tömb, de tömbként lesz használva), mert előre nem tudod, hogy hány darab kölcsönzést fog tartalmazni (ezt is fájlból olvasod be a db változóba), tömböt deklarálni pedig csak konstans mérettel lehet. Ha megvan hogy hány darab kölcsönzést tartalmaz a fájl, akkor ekkora méretű tömböt fogsz dinamikusan (new-val) lefoglalni, ami kolcsonzes * típusú pointert ad vissza. Talán az okozza a zavart, hogy nem érted miért kell pointer, ha egyszer tömbbe olvasol be. A C-ben (és C++-ban) pointereket lehet tömbszerű szintaxissal használni (ki lehet indexelni mint a tömb elemet), illetve a tömb neve (indexelés nélkül) a tömb kezdőcímét jelenti. A tömb indexelés tulajdonképpen nem más, mint a kezdőcímhez képest indexszel eltolt pointerre való dereferencia. Tehát tomb ugyanaz, mintha *(tomb+i) -t írnál (ez pedig ugyanaz mint *(i+tomb), ami ugyanaz mint i[tomb]; egy kis nyalánkság a C szintaxisból). Ahogy fent írtam, csak a dinamikus helyfoglalás miatt kell pointer, és nem tömb. Ha azt gondolnád, hogy ilyen módon a pointer és a tömb tulajdonképpen ugyanaz, akkor nem lenne egészen igazad, ugyanis a tömb név (mint a tömb kezdő címe) konstans pointer (fordítás idejű konstans), ezért nem lehet neki értéket adni, és nem lehet a címét képezni, ellentétben a pointer típusú változóval. Elég baj, hogy a C-ben a tömb és pointer fogalma így összemosható, ebből szoktak félreértések (és hibák) adódni. Ennyit a tömbökről.
  Hogy miért private ez a tömb (pointer), az pedig azért, mert nem feltétlenül kellene a kölcsönzéseket tömbben tárolni (lehetne pl. lista), ezért az osztályod felhasználója nem kell (nem szabad) hogy tudjon az implementációról, számára elég a publikusan biztosított tagfüggvények ismerete, ami az implementációtól függetlenül mindíg ugyanúgy hívható (ez OOP alapelv).
  "De most akkor azt is lehetne írni a feltöltéskor hogy kolcsonzes[i].datum;"
  Ebben a sorban nem csináltál semmit, egyszerűen a stackre helyezted a kolcsonzes[i].datum értékét.
  "hogyan tehetem a private tagokat elérhetővé más számára?"
  Leginkább public tagfüggvények által, magát a private adatszerkezetet nem szokás (hiszen ezért private). Ha feltétlenül elérhetővé akarod tenni, akkor legyen public. Előfordulhat azonban, hogy bizonyos külső (free vagyis nem tfv.-ek) függények számára meg akarod engedni a private/protected adattagok elérését, akkor az osztályod ezeket a fv.-eket friend-ként deklarálja (komplett osztályt is lehet friend-ként deklarálni). A friend deklaráció nem esik a public, private, protected láthatóság hatálya alá, mindegy hová írod. Mindíg az az osztály fogadhat barátjának egy fv.-t (vagy másik osztályt), amelyik ezek számára meg akarja engedni a private tagjainak elérését. Nem fordítva, tehát egy külső fv. nem jelentkezhet be, hogy szeretné az adott osztály private tagjait elérni.
  A struktúra és az osztály között összesen az a különbség, hogy a struktúra tagjai default public elérésűek, míg az osztályé default private. Vagyis ha nem írsz ki láthatóságot, akkor ez vonatkozik a tagokra. Más különbség nincs, ettől eltekintve teljesen ugyanúgy használhatók. Szokás szerint, ha csak adattagok vannak, akkor struktúrát használnak, ha tfv.-ek is vannak, akkor osztályt, de ez csak konvenció.

  u.i.: közben míg írtam a választ dabadab megelőzött, kb. ugyanazt válaszolta.

• #4062 dabadab titán choco01 #4057

  Új Válasz 2018-04-22 20:33:04 #4062

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dabadab

  titán

  válasz choco01 #4057 üzenetére

  "ovábbá ezt sem értem hogy miért nevezzük ezt a konstruktornak: kolcsonzo(char fnev[]); mert hát más is néz ki ehhez hasonlan.. pl.: int GetMagellan();"

  Két fontos különbség van a kolcsonzo() meg a GetMagellan() között:
  1. a konstruktort pontosan úgyanúgy hívják mint az osztályt
  2. nincs visszatérési értéke (még void se)

  "mivan ha nem csinálok konstruktort hanem csak int kolcsonzo(char fnev[]);-et írok?"

  Reklamálni fog a fordító, hogy konstruktornak nem adhatsz meg visszatérési értéket (az meg, hogy konstruktor, onnan jön, hogy pont úgy hívják, mint az osztályt)

• #4061 dabadab titán choco01 #4060

  Új Válasz 2018-04-22 20:19:09 #4061

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  dabadab

  titán

  válasz choco01 #4060 üzenetére

  C++-ban a struct meg a class ugyanaz a dolog, két különböző névvel. Az egyetlen különbség a default láthatóság, vagyis ha nem írod ki, hogy public: meg private: (de úgyis kiírod), akkor classnál defaultból minden private, structnál meg minden public. Szóval gyakorlatilag az classt meg a structot lehetne egymás helyett használni (de ne csinálj ilyet, mert csak összezavarsz vele másokat (meg a jövőbeli magadat )

  "meg hogyan tehetem a private tagokat elérhetővé más számára?"

  A private pont azért private, hogy ne legyen elérhető más számára Ha ezt akarod, akkor legyen public, de alapvetően adattagotkat nem jó ötlet publicra rakni, mert akkor mindenki úgy rondít bele, ahogy nem szégyell - inkább legyenek a más osztályok számára érdekes adatok tagfüggvényeken keresztül, mert így egyrészt tudod ellenőrizni az értékadásokat, hogy nem hülyeséget akar-e a másik beleírni, illetve át tudod faragni a belső adatstruktúrát anélkül, hogy emiatt át kellene írni a többi osztályt is.

  (A kivétel az, ha tisztán adatokat (függvényeket viszont nem) tartalmazó osztályt kell létrehozni, ott publicra érdemes rakni a tagokat és ezeknél érdemes a struct kulcsszót használni, hogy mindenki elsőre lássa, hogy miről van szó)

• #4059 cattus addikt choco01 #4057

  Új Válasz 2018-04-22 19:23:13 #4059

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  cattus

  addikt

  válasz choco01 #4057 üzenetére

  Ezt olvasd el, szerintem nagyon jól le vannak írva az OOP alapvető elvei.

• #4058 b.kov senior tag choco01 #4056

  Új Válasz 2018-04-22 19:17:56 #4058

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  b.kov

  senior tag

  válasz choco01 #4056 üzenetére

  Ennek a pointernek a segítségével hozod létre az egyes kölcsönzőkhöz tartozó tömböket, amiknek az eleme "kolcsonzes" típusúak. Tehát ha pontosabbak akarunk lenni, akkor azt is lehet mondani, hogy a k pointered ennek a tömbnek a fejelemére mutat. A k[i] pedig a fejelemtől i. távolságra lévő elemre.

  Ennek a pointernek pontosan azért kell privátnak lennie, mivel minden egyes "kolcsonzo" példány létrehozásával egy file-ból olvasod be a kölcsönzéseket. Ezek ugye statikus adatok, amiken később nem szeretnél vátloztatni. Tehát ne lehessen azt mondani, h pl. "mintaKolcsonzo" objektumon keresztül, a 3. kolcsonzés idejét megváltoztatod. Tehát:

  kolcsonzo mintaKolcsonzo("inputFile_1");

  Ekkor beolvasod ugye a fájlból a statikus adatokat. Nem lenne jó, ha ezután tudnál ilyet csinálni:
  mintaKolcsonzo.k[2]->datum = "Buddha szobor";

  Persze létezik igény fájlból beolvasott adatok utólagos módosítására (sőt), viszont ez akkor sem szép megoldás. Arra külön setter függvényeket szokás írni, csakúgy mint a mostani getter függvények.

  Tehát az előző példában ha megengednénk a dátum módosítását, akkor így lenne mondjuk szép:

  mintaKolcsonzo.modifyDate(2, "2018.02.03");
  Ahol ez első paraméter a kölcsönzés száma, a második pedig az új kölcsönzési dátum.

• #4057 choco01 addikt choco01 #4056

  Új Válasz 2018-04-22 19:09:01 #4057

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  choco01

  addikt

  válasz choco01 #4056 üzenetére

  Továbbá ezt sem értem hogy miért nevezzük ezt a konstruktornak: kolcsonzo(char fnev[]); mert hát más is néz ki ehhez hasonlan.. pl.: int GetMagellan(); és akkor ehhez is lehetne egy ~GetMagellan();-t destruktornak írni..? mivan ha nem csinálok konstruktort hanem csak int kolcsonzo(char fnev[]);-et írok?

  bocs a dupláért..

• #4055 b.kov senior tag choco01 #4054

  Új Válasz 2018-04-22 18:19:59 #4055

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  b.kov

  senior tag

  válasz choco01 #4054 üzenetére

  Ha van valami konkrét kérdésed, akkor írd nyugodtan, de egyébként jól látod szerintem a dolgokat.
  Ha nincs öröklődés, akkor a protectedet felejtsd el egy kicsit, és csak a public-private részre koncentrálj.

  Nagyon egyszerűen tényleg csak annyi a dolog, hogy a privát adattagokhoz/függvényekhez kintről (az osztály példányain keresztül) nem lehet közvetlenül hozzáférni. Ez ugye az enkapszuláció lényege, előttem jól meg lett fogalmazva.

• #4053 b.kov senior tag choco01 #4052

  Új Válasz 2018-04-22 18:02:15 #4053

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  b.kov

  senior tag

  válasz choco01 #4052 üzenetére

  Nem rosszabb semmivel, azonban ekkor a stack-en jön létre az objektum, ahogy írták is korábban.

  Amíg nem indokolt pointerek használata, addig egyébként is érdemes kerülni őket. Majd ha belemerülsz jobban a témába, és szembe jön veled a dinamikus kötés, referencia szerinti paraméterátadás, öröklődés, stb... akkor érdemes foglalkozni jobban a pointerekkel is. Addig tanulgatni teljesen jó ez a módszer is, ahogyan most csinálod.

• #4051 jattila48 aktív tag choco01 #4050

  Új Válasz 2018-04-22 14:18:49 #4051

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  jattila48

  aktív tag

  válasz choco01 #4050 üzenetére

  tanulo.nev = "Tamas"; helyett
  tanulo->nev = "Tamas"; sorral próbálkozzál. Úgy jónak kell lenni. Mivel new-val hoztad létre az objektumot, egy erre mutató pointert kaptál vissza (mint ahogy helyesen így is deklaráltad a tanulo változót), aminek a tartalma (*tanulo) maga az objektum, és ennek van nev nevű adattagja. Ezért így is írhattad volna:
  (*tanulo).nev = "Tamas";
  De mivel annyira gyakori konstrukcióról van szó, a rövidség kedvéért err bevezették a -> operátort.

• #4049 PandaMonium őstag choco01 #4048

  Új Válasz 2018-04-22 11:47:39 #4049

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  PandaMonium

  őstag

  válasz choco01 #4048 üzenetére

  Az objektum-orientált programozás egyik alapelve az enkapszuláció, ami magyarul annyit tesz, hogy mindig csak annyit akarsz láthatóvá tenni egy-egy objektumodból amennyit nagyon muszáj. Alapból minden adattag és függvény legyen privát, akkor legyen bármi is publikus, ha kívülről el akarod érni az adott dolgot.

  Konstruktor jelen esetben a kolcsonzo(char fnev[]);, ez mondja meg milyen paraméterekkel tudsz létrehozni egy példányt (= objektumot) az osztályodból. Itt egy char[] -t vár paraméterként a konstruktor, ami egy karaktertömb/karakterlánc. Emiatt így tudsz pl. létrehozni egy példányt a kolcsonzo-ből: kolcsonzo peldany("karakterlanc");.

  A destruktor ez a sor: ~kolcsonzo();.
  Ez akkor fog lefutni mikor a példány megszűnik létezni. Ez már kicsit haladóbb téma, de röviden annyit, hogy tudsz objektumokat létrehozni a stack-en és a heap-en is. Minden amit new nélkül példányosítasz az a stacken jön létre, amit new-al az pedig a heap-en.

  A stacken létrejövő dolgok automatikusan megszűnnek létezni mikor a stack megszűnik (végetér a { } zárójel), ezzel szemben a heap-en létrehozott dolgok ott maradnak egészen addig amíg meg nem hívod a memóriacímükre a delete-et. Bármelyik eset is álljon fenn, ilyenkor lefut a objektum destruktora.

  Ezek nagyon gyakori kérdések, ne jegyzetből tanuld meg őket, csak keress rá, hogy objektum-orientált programozás (object-oriented programming vagy OOP) és kismillió tutorialt fogsz találni.

• #3979 m.zmrzlina senior tag choco01 #3977

  Új Válasz 2018-01-10 08:07:02 #3979

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  m.zmrzlina

  senior tag

  válasz choco01 #3977 üzenetére

  Pár link, egy darabig elleszel velük

  Geekforgeeks

  Ez itt (néha kicsit buta) megoldásokkal együtt.

  http://www.includehelp.com/cpp-programming-examples-solved-cpp-programs.aspx

  A címe alapján a Strostrup könyv melléklete lehet.

• #3978 b.kov senior tag choco01 #3977

  Új Válasz 2018-01-10 08:00:52 #3978

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  b.kov

  senior tag

  válasz choco01 #3977 üzenetére

  Üdv!
  Fentebb linkeltem, részletes, jól összeszedett jegyzet: ELTE C++

• #3886 leviske veterán choco01 #3885

  Új Válasz 2017-10-31 22:56:26 #3886

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  leviske

  veterán

  válasz choco01 #3885 üzenetére

  A Deitel-féle C++ könyv az elég szájbarágós és jól alapoz SZERINTEM. És úgy látom, nem csak angol verzió létezik. Kitér tipikus programozási hibákra, teljesítmény tippkere, stb.

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