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

• #3325 jattila48 aktív tag dobragab #3322

  Új Válasz 2016-03-21 10:27:11 #3325

  Ú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 dobragab #3322 üzenetére

  Jó összefoglaló, csak egy kis kiegészítést engedj meg:
  "- default ctor: végighívja az ősosztályok és adattagok copy ctor-át, sorrendben."
  Itt fontos megjegyezni, hogy az ősosztályok ctorát az öröklési sorrendben, az adattagokét pedig deklarációjuk sorrendjében hívja. Vagyis nem feltétlenül a taginicializáló listában írt sorrendben (néhány fordító warning-ot generál, ha a taginicializáló lista sorrendje eltér a deklaráció sorrendjétől). Ezek után hajtódik végre a szóban forgó objektum ctorának törzse. A destruktorok hívása éppen fordított sorrendben történik: Először az adott dtor törzse fut le, ami végül a ctor-ok hívásának fordított sorrendjében meghívja az adattagok és ősosztályok dtorait.

  A move operációt illetően: a szabvány bizonyos feltételek mellett (kb. amit leírtál) előírja implicit move operáció generálását, azonban erősen kétséges, hogy ez valóban jó ötlet-e. Bizonyos fordítók (talán a VS2010 is) ezt nem teszik. Ha egyáltalán generálható implicit move operáció, akkor az kb. ugyanaz mint a copy operáció, ezért fölösleges a move. A move-nak akkor van igazán értelme, amikor implicite nem generálható, pl. user defined dtor esetén. A move-val legfőbb probléma az, hogy milyen állapotban maradjon a moved-from objektum, vagyis az operáció forrás objektuma. Legyen default konstruált? Mi van, ha nincs default ctor-a? Az "elmove-olt" erőforrást a dtor-nak már nem szabad felszabadítania. A moved-from objektum egyfajta "zombivá" válik, hasonlóan a kétfázisú inicializálással létrehozott objektum esetén, amikor a ctor már lefutott, de az inicializálás még nem történt meg teljes egészében (ez mint tudjuk, kerülendő). A moved-from objektum ezután már csak copy vagy move assignment cél operandusaként használható, vagy megsemmisítendő, de minden esetre ügyelni kell rá, hogy ne használjuk újra (mint ahogy a félig inizializált objektumokat sem).

• #3324 EQMontoya veterán dobragab #3322

  Új Válasz 2016-03-21 09:19:21 #3324

  Ú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

  

  EQMontoya

  veterán

  válasz dobragab #3322 üzenetére

  C++-ban a compiler biztosan becsukja a fájlt a blokk végén (fstream).

  Ezért szoktak olyan loggereket írni, ami soronként nyit és zár filet. Én meg a hajamat tépem.

• #3323 ToMmY_hun senior tag dobragab #3322

  Új Válasz 2016-03-21 08:23:31 #3323

  Ú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

  

  ToMmY_hun

  senior tag

  válasz dobragab #3322 üzenetére

  Nagyon szépen köszönöm a részletes leírást! Nekem sok újat mondtál és gyors összefoglalónak kiváló - legalábbis így kezdőként könnyen fel tudtam fogni. A biztonság kedvéért a mester könyvében lévő konstruálással foglalkozó fejezetet tervezem átnyálazni, bár sok információt a cppreference.com-on is leírnak.

  Java-hoz képest jóval bonyolultabb a konstruálás (is), de nagyon szimpatikus az a precizitás, amit a nyelv megkövetel. Kivéve amikor ilyen apróság miatt megy el pár óra.

  EQMontoya: "Elég fontos dolog, ha mélyebben belemész a c++-ba." Teljesen jogos, meg is van a programom estére.

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