Hirdetés
- Nagyon nem szokványos módon ment tönkre egy ASML gép Kínában...
- Fájlformátumok a gyakorlatban: ProRes, H.265, AV1
- "3D-s" hővezető csövekkel jön a Cooler Master legfrissebb CPU-hűtője
- Olcsóbb fajtájúnak ígérkező Team Group SSD a PCI Express 5.0-s halmazban
- Több memóriát kapott az RTX PRO 5000 új kiadása
Új hozzászólás Aktív témák
-
jattila48
aktív tag
válasz
jattila48 #3184 üzenetére
A "fölösleges" kód akkor keletkezik, ha handle_class.h-ban a BodyClass incomplete type-ként forward deklarálva van. Ha beinkludolom a teljes body_class.h-t, akkor "szép" kódot generál. Ekkor persze nincs értelme a pimpl-nek. Úgy tűnik, hogy a forward deklarációval nincs elég információja a BodyClass osztályról, hogy a pimpl és az mfp alapján meghatározza a BodyClass f tfv.-ének valódi címét. Mintha a pimpl-et akarná különböző információk alapján igazítani, ahogy a this-t szokta igazítani a thunk kód többszörösen örökölt osztályok esetén. Jó lenne, ha a forward deklarációban meg lehetne mondani, hogy a BodyClass teljesen közönséges osztály, nem örökölt senkitől (főleg nem többektől) és nincs virtuális tfv.-e (még emiatt is lehet ez az igazítás). Akkor talán nem generálná ezt az ilyen osztályokra amúgy tényleg fölösleges igazító kódot. Ilyet sajnos tudtommal nem lehet a C++-ban. Egyébként a kódban valószínűleg csak cím hibás, mégpedig a
004116D6 cmp dword ptr ds:[4168B4h],0
sorban a 4168B4. Amikor rosszul fut, akkor ez a cím unicode sztringekre mutat, vagyis nyilvánvalóan rossz. Amikor jól fut, akkor különböző globális konstansok lehetnek itt és környékén (ha jól fut, akkor 0). Mégsem a const deklarációtól függ, hogy jó-e vagy nem, mert újra buildeléskor const-tal is elromlott. Talán a linker lesz a hibás. Egyébként az LLVM erre a kódra assertion failed-del elszáll, és kéri, hogy a hibajelentést küldjem be. Csak a gcc tudta minden gond nélkül buildelni. -
MageRG
addikt
válasz
jattila48 #3184 üzenetére
Nem értek annyira a C++ programozáshoz, de nekem fura hogy egy static memberbe akarsz belepakolni egy másképp példányosodó valamit.
A HandleClass::mfp közös az összes HC-ben, ugyanazt a BodyClass példány memberét hívja.
De a HandleClass::f meg egy-egy külön BodyClass példány membert hív, ami a konstruktorban jön létre.
Vagyis a két hívás *vára nem ugyanazt csinálja.
Akkor lenne ugyanaz, ha a *pimpl member is statikus lenne.De ez csak az én "két centem".
Új hozzászólás Aktív témák
● ha kódot szúrsz be, használd a PROGRAMKÓD formázási funkciót!
- Audioquest kábelek RCA, LAN, Optikai
- új iPhone Air 256GB space black asztrofekete független Apple 1 év garancia
- újszerű MacBook Pro M1 256GB SSD Apple magyar space gray
- szinte új iPhone 16 Pro 128GB black titanium fekete titán független Apple 1 év garancia
- újszerű Apple Watch Series 10 GPS 46mm kozmoszfekete alumíniumtok fekete Apple 2 év garancia
- HIBÁTLAN iPhone 12 Pro Max 128GB Blue -1 ÉV GARANCIA - Kártyafüggetlen, MS3109
- Intel Processzorok sok db : Xeon E5-1620V3, Pentium G4400T, i3 6100, i3-4130, i3-2140T
- Apple iPhone 11 64GB, Kártyafüggetlen, 1 Év Garanciával
- HIBÁTLAN iPhone SE 2020 64GB White -1 ÉV GARANCIA - Kártyafüggetlen, MS2025, 100% akkumulátor
- Apple iPhone 13 mini Red Kompakt méret, nagy teljesítmény 256 GB Használt,szép állapot, 100%
Állásajánlatok
Cég: NetGo.hu Kft.
Város: Gödöllő
Cég: Promenade Publishing House Kft.
Város: Budapest