Użytkownik "Tomasz Kaczanowski" <k...@p...onet.pl> napisał:

>> Ty dalej nic nie rowumiesz.
>> Nie mowie o generowaniu dllki tylko o wymogu w standardzie C++
>> aby kazdy kompilator z nim zgodny zapewnial wsparcie dla uzycia
>> _standardowych_ rzeczy (glownie stl) w publicznym API dll/so/kazdego rodzaju
biblioteki
>> Tyle (na poczatek:)
>
> publiczne api: dll, so, library itp to rzeczy systemowe

Zle Wasc prawisz.
W tym publicznym API sa nazwy ktore nadaje sobie dowolnie kompilator.
Te nazwy sa nieustandaryzowane (brak usstandaryzowania mainglingu w C++) - to raz
ta nazwy tycza metod i "zmiennych" dostepnych poprzez to API.
Te metody i atrybuty sluza do "dobrania" sie do ich adresow po aladowaniu dll-ki
(innym sposobem - szybszym, ale mniej "flexible" - jest dobieranie sie przez ordinal
number).
W poruszanym problemie chodzi o to ze kompilator generuje _calkiem inne_ instancje
tempaltes dla przypadku.

class A
{
public:
std::list sequence;
};

niz dla:

class A
{
public:
declspec(export) std::list sequence;
};

i linkerowi brakuje implementacji w bibliotece kompilatora.
Standard C++ powinien nie tyle nawet zalecic, ale _wymusic_ na kompilatorze
dostarczenie implementacji stl/std:: _rowniez_ dla bibliotek dzielonych.

To o czym Wasc prawisz to ABI, ktore faktycznie jest tworem os/systemowym
(ale i tak dosc glekoko "zanurzonym" w czystym C, choc na Win jest to akurat
bardziej Pascalowaty twor:).

PS: Poza tym zwykle/statyczne libraries to niekoniecznie rzeczy systemowe,
ale jak najbardziej rowniez kompilatorowe.

AK