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

• #3599 jattila48 aktív tag dobragab #3597

  Új Válasz 2016-09-08 13:45:25 #3599

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

  Hát akkor marad a típus vizsgálat, static_cast. Nem tudok jobbat. A típusvizsgálatot virtuális fv. használatakor sem lehet elkerülni, hiszen a konkrét típus ismeretében tudom csak eldönteni, hogy meghívjam-e egyáltalán a virtuális fv.-t (ami ráadásul a többi osztályban esetleg nincs is implementálva). Ez után a static_cast már csak a fordítót terheli, a futást nem, szemben a virtuális fv. hívással.
  A különböző típusok külön táblázatban való tárolása nem opció, mert nagyon megnehezíti a szimbólum hozzáadást, -keresést, scope kezelést, ráadásul ezeket a fv.-eket át kell írni, ha új típusú szimbólumot vezetnék be. Ez egy olyan példa, hogy noha a tárolandó osztályoknak látszólag nem sok közük van egymáshoz, mégis más okból (scope-ban nem lehetnek azonos nevű szimbólumok) célszerű őket együtt tárolni. Szóval szerintem nem tervezési hiba. A külön táblázatok viszont az lenne.

• #3598 jattila48 aktív tag dobragab #3597

  Új Válasz 2016-09-08 12:57:25 #3598

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

  Ez most egy kicsit bonyolult, de pl. változó esetén a stack-en elfoglalt helyét, az érték típusát, és a statikus level-t tartalmazza. Függvény esetében a fv.-tábla-beli pozíciót, paraméterek számát, típusát, stb. Osztály definíció esetén ...elég bonyolult. A lényeg, hogy teljesen mások a szimbólumok, viszont a scope kezelés miatt egy vektorban (igazából stack-ben) kell őket tárolni.

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