Użytkownik "M.M." <m...@g...com> napisał:
On Friday, June 2, 2017 at 9:07:46 PM UTC+2, AK wrote:
> Użytkownik "M.M." <m...@g...com> napisał:

> Chyba nie w tym dopatrujesz się
> problemu (bo po co?), że to się dzieje na poziomie bibliotek/systemu, a
> nie w ramach standardu C++?

Kurde... Nawet ostatni standard tego "wysokopoziomowego" C++
nie "przewidzial:" czegos takiego jak biblioteki dynamiczne/dzielone
(mimo ze istnieja juz >30 lat).
Skutek jest taki, ze nigdzie nie znajdziesz nie tylko unormowanego
manglingu nazw, ale tez zapewnienia "przrezroczystosci" m.in. kontenerow
standardowych (czyki STL). Bezpiecznie moga byc przekazywane
tylko typy proste i surowe pointery (lub pochodne tychze typow, czyli wlasciwie typu
rodem z C). Skutek jest taki ,ze kazdy kompilator dziala z STLem w tym obszarze po
swojemu
a czasem/czesto nie dopuszcza/daje bledy linkera itp skutek zlego (bez modyfikatora
dll-export ) generowania templates.
Skutek finalny jest taki, ze po prostu _NIE WOLNO_ uzywac typow stl-owych w API
dll-ki
i to, ze jedne kompilatory to dopuszczaja (gcc) nie stanowi żadnej gwarancji
poprawnosci/portability (bo liczy sie raport jezyka a nie "probkowanie"
kompilatorow).
Po prostu templates z atrybutem dll-export sa _inne_ niz bez niego i linker glupieje.
Czyli mamy standard (STL), ale... nie mozemy go uzyc w jakze "rzadkiej" sytuacji
(API dll-ek:).
To wciaz tyczy tego samego kompilatora dla dllki i programu glownego.
Jesli kompilatory sa rozne (a to przeciez czesta/normalna sytuacja) to juz zaczyna
sie prawdziwa dzungla (nawet dla dinozaurow nie do przebycia).

Dlatego wole .NET czy Jave gdzie sa normalne moduly gwarantujace normalne
API a nie "wysokopoziompowy" w tym wzgledzie C++.

Pozdrawiam

AK