Hirdetés

  2. Fórumok
  3. Szoftverfejlesztés
  4. C++ programozás
Keresés

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

  • #4470 jattila48 aktív tag jattila48 #4467
    Új Válasz #4470
    Ú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 jattila48 #4467 üzenetére

    Azt hiszem, sikerült kisilabizálni a választ. Függvény nevek esetén a név dekoráció (vagy manglálás) azért kell, hogy a linker meg tudja különböztetni az overload-olt fv. neveket. Ez világos (és eddig is az volt). Függvény pointer nevek azonban nem overload-olhatók, ezért ott nincs szükség név dekorációra, így az extern "C" deklarációnak (ami elnyomja a C++ név dekorációt) sincs értelme. Gondoltam én. Csakhogy fv. pointer nevek esetén a dekorációt nem az overload-olás miatt használják, hanem a hívási konvenció miatt. A különböző TU-kban deklarált és definiált ugyanolyan nevű fv. pointereknek meg kell egyezni a hívási konvencióban. Eddig azt gondoltam, hogy nincs külön C és C++ hívási konvenció (mint ahogy MS fordítóknál nincs is), de elképzelhető, hogy más fordítóknál ez másképp van. Legalábbis a lehetőségét fenntartják.

    érdekes olvasmány: [link]

    Idézet a cppreference.com -ról:

    "Since language linkage is part of every function type, pointers to functions maintain language linkage as well. Language linkage of function types (which represents calling convention) and language linkage of function names (which represents name mangling) are independent of each other"

    Tehát a fv. típus és fv. név language linkage-e (mint pl. az extern "C") két különböző, és független dolog. Eszerint fv. pointer esetén a language linkage a pointer által mutatott fv. típusára utal (hívási konvenció), nem pedig a fv. pointer névre.

    Elnézést a hosszú hozzászólásért, remélem azért érthető volt min problémáztam.

  • #4469 coco2 őstag jattila48 #4467
    Új Válasz #4469
    Ú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

    coco2

    őstag

    válasz jattila48 #4467 üzenetére

    A lentiek akkor tudnak neked magyarázatul szolgálni, ha legacy problémákba ütköztél bele.

    A C és a C++ linkelések eltérőek. A legacy környezetekkel kompatibilis linkelés kötelezően támogatott mindegyik fordító által, de külön jelezned kell, ha azt kívánod használni.

    A C++ linkelés néhány verziónként eltér, és nem lehet azok között átugrálni. Egy nagyon régi projekthez előrefordított C++ dll-t nem tudsz új projektekben betölteni. Próbáld ki, és meglátod. Forráskódot kell újrafordítani jelenkori verzió alatt. Ha azt meg tudod tenni, akkor értelmetlen a vacakolás - ahogy írtad. De ha csak bináris formában van rádhagyva egy régi C++ dll, és nincsen lehetőséged újrafordításra, akkor bizony workaround kell. Egyik lehetőségként visszatérhetsz régebbi C++ fordítóra, és használhatod a teljes projekthez. Feltéve, hogy a toolchain-ed nem kényszerít rád újabb verziót. Ha abba ütköztél bele, akkor rámicsodáltál. Egy régebbi C++ dll binárisa lehetségesen kuka. Egy C dll örökéletű. A C idejében még nem volt verziók közötti kompatibilitási gond, és a mai napig nincsen.

    Ami probléma egy előrefordított C dll-el lenni tud, az a target cpu. Legacy C dll-ek várhatóan x86. De azóta már előfordul armv7 és x64 is. Eltérő platformokon nem tudsz keresztül linkelni.

  • #4468 cog777 őstag jattila48 #4467
    Új Válasz #4468
    Ú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

    cog777

    őstag

    válasz jattila48 #4467 üzenetére

    Azt hittem azt kerdezed hogy csak a declaraciora vonatkozik az extern "c" vagy az implementaciora is.
    A fenti peldaban mindkettot ajanljak, ha tobbfele forditot hasznalsz.

    Ha a valtozora kerdezel ra, akkor igen lehet hasznalni arra is, ugyanabbol a celbol.
    Language linkage - cppreference.com

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