W dniu 2017-06-05 o 13:47, AK pisze:
> Użytkownik "Tomasz Kaczanowski" <k...@p...onet.pl> napisał:
>
>> Ale to chyba Ty nie rozumiesz, takie standardy musi wypracować twórca
>> systemu, a kompilatory muszą się do tego dostosować. Dll to kwestia
>> jednego systemu. Jeśli dll będzie wymagał danej struktury, to
>> kompilator taką wygeneruje, niezależnie czy będzie to kompilator
>> języka c/c++/pascala/asemblera/innego języka kompilowalnego.
>
> Nie. Nie wygeneruje. Bo nie musi . Bo standard C++ go nie zmusza.

a co ma zmuszanie standardu, do tego, że wygeneruje? Standard nie
zmuszał, by generował jakikolwiek kompilator biblioteki typu .library, a
patrz, są takie, które to robią.

> PS: ...i to ,ma byc nowoczesny jezyk programowania wysokiego poziomu? ;))

nie wiem, czy ma być, czy nie, bo mnie to rybka, jak go nazwiesz. Ale
jeśli generowanie dll-i obiektowych ma byc wyznacznikiem, to powiedz mi
jak java sobie z tym radzi i co standard na to. Napisz mi jak te dll-e
działają pod linuksem bez emulatora.


--
http://kaczus.cba.pl

do góry

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

>W dniu 2017-06-05 o 13:47, AK pisze:
>> Użytkownik "Tomasz Kaczanowski" <k...@p...onet.pl> napisał:
>>
>>> Ale to chyba Ty nie rozumiesz, takie standardy musi wypracować twórca systemu, a
kompilatory
>>> muszą się do tego dostosować. Dll to kwestia jednego systemu. Jeśli dll będzie
wymagał danej
>>> struktury, to kompilator taką wygeneruje, niezależnie czy będzie to kompilator
języka
>>> c/c++/pascala/asemblera/innego języka kompilowalnego.
>>
>> Nie. Nie wygeneruje. Bo nie musi . Bo standard C++ go nie zmusza.
>
> a co ma zmuszanie standardu, do tego, że wygeneruje? Standard nie zmuszał, by
generował
> jakikolwiek kompilator biblioteki typu .library, a patrz, są takie, które to robią.

A to ma, ze wtedy _jestes pewien_ ze kompillator wygeneruje.
Co do zwyklych bibliotek to byl/jesy ten sam syf.
Kilka formatow (.lib, .a), rozne formaty obj-tow itp
Kiedys linkowanie bylo scislej oddzielone od kompilacji
i to wymuszalo trzymanie sie pewnych zaszlosci/zgodnosc
(np. MS mial jeden linker do wszuytskich jezyow: Pascala, C/C++ i Fortranu,
a Borlandowskiegotlinka uzywalo sie powszechnie do linkowania.. Clippera
bo byl kikanascie razy szybszy od natywnego plinkera,
niktiire porzadne srodowiska mialy wspolne - zwykle Cowe - core bibliotek
np MicroWay NDP (Fortran, Pascal, C/C++) i idealne wzajemne
miedzujezykowe bridges (i to 20 lat przez .NETem).
Potem C++ _olal_ mangling i biblioteki dzielone i poszla dowolnosc juz pelna.
Skutkiem i wszem "rozwoj" nawet w skrajnej forwie net-services/"serwerow
aplikacyjnych:)"
konwertujacych C++ sowy string na javowy i abarot:)
PS: Cale szczescie ze powstal COM/ActiveX a pozneij .NET

>> PS: ...i to ,ma byc nowoczesny jezyk programowania wysokiego poziomu? ;))
>
> nie wiem, czy ma być, czy nie, bo mnie to rybka, jak go nazwiesz. Ale jeśli
generowanie dll-i
> obiektowych ma byc wyznacznikiem,

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:)

AK

do góry

W dniu 2017-06-05 o 14:08, AK pisze:
>
> Użytkownik "Tomasz Kaczanowski" <k...@p...onet.pl> napisał:
>
>> W dniu 2017-06-05 o 13:47, AK pisze:
>>> Użytkownik "Tomasz Kaczanowski" <k...@p...onet.pl> napisał:
>>>
>>>> Ale to chyba Ty nie rozumiesz, takie standardy musi wypracować
>>>> twórca systemu, a kompilatory muszą się do tego dostosować. Dll to
>>>> kwestia jednego systemu. Jeśli dll będzie wymagał danej struktury,
>>>> to kompilator taką wygeneruje, niezależnie czy będzie to kompilator
>>>> języka c/c++/pascala/asemblera/innego języka kompilowalnego.
>>>
>>> Nie. Nie wygeneruje. Bo nie musi . Bo standard C++ go nie zmusza.
>>
>> a co ma zmuszanie standardu, do tego, że wygeneruje? Standard nie
>> zmuszał, by generował jakikolwiek kompilator biblioteki typu .library,
>> a patrz, są takie, które to robią.
>
> A to ma, ze wtedy _jestes pewien_ ze kompillator wygeneruje.
> Co do zwyklych bibliotek to byl/jesy ten sam syf.
> Kilka formatow (.lib, .a), rozne formaty obj-tow itp
> Kiedys linkowanie bylo scislej oddzielone od kompilacji
> i to wymuszalo trzymanie sie pewnych zaszlosci/zgodnosc
> (np. MS mial jeden linker do wszuytskich jezyow: Pascala, C/C++ i Fortranu,
> a Borlandowskiegotlinka uzywalo sie powszechnie do linkowania.. Clippera
> bo byl kikanascie razy szybszy od natywnego plinkera,
> niktiire porzadne srodowiska mialy wspolne - zwykle Cowe - core bibliotek
> np MicroWay NDP (Fortran, Pascal, C/C++) i idealne wzajemne
> miedzujezykowe bridges (i to 20 lat przez .NETem).
> Potem C++ _olal_ mangling i biblioteki dzielone i poszla dowolnosc juz
> pelna.

No patrz, biblioteki kompilowane kompilatorem sasc nie koniecznie
chciały współdziałać z tymi kompilowanymi kompilatorem maxona... To, że
na jednej platformie działało (choć wiem, z doświadczenia, że nie
działało do końca pomiędzy niektórymi kompilatorami, no, ale przeciez Ty
wiesz lepiej, bo Tobie się kilka razy to udało), to zupełnie inny przypadek.



>>> PS: ...i to ,ma byc nowoczesny jezyk programowania wysokiego
>>> poziomu? ;))
>>
>> nie wiem, czy ma być, czy nie, bo mnie to rybka, jak go nazwiesz. Ale
>> jeśli generowanie dll-i obiektowych ma byc wyznacznikiem,
>
> 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 i to twórcy
systemu muszą o to zadbać,jeśli tak będzie, będą generowane odpowiednie
kody przez kompilatory. podchodzenie od tyłka strony spowoduje, że taka
bibliotekę będziesz mógł użyć tylko w jednym języku, bo twórcy systemu
zleją takie rzeczy, jeśli nie będą im dawały żadnych bonusów.

--
http://kaczus.ppa.pl

do góry

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

do góry

On Monday, June 5, 2017 at 9:55:42 AM UTC+2, AK wrote:
> Użytkownik "M.M." <m...@g...com> napisał:
>
> > Czy są z tym aż takie problemy? Skoro piszesz że są, to wierzę na słowo.
>
> Sa sa. Uzywajac VC++.
> [...]
> Na szczescie w tym konkretnym przypadku zmiany byly
> na tyle male, ze mozliwe do wykrycia uzycia/przeprowadzenia w tych
> setkach miejsc kompilacji.

Ok, rozumiem. Właściwie od początku ogólnie bylo jasne, że program
korzystający z biblioteki musi, generalnie pisząc, wiedzieć jak
zdekodować zawartość biblioteki. Zarzucasz brak (jedynego)
standardu w narzędziach do C++, bo przecież nie można tego zarzucić
językowi C++. Zgadzam się z Tobą, że to gówno a nie narzędzia
wysokopoziomowe, jeśli trzeba się martwić takim detalami jak sposób
skompilowania kodu w celu zachowania zgodności z bibliotekami/modułami.
Tu masz rację. Natomiast, po pierwsze, teraz nie przypominam sobie abym z
tym miał jakieś większe problemy, może zapomniałem o tych problemach bo
były rzadko i dawno temu, a może głównie korzystałem ze zbyt dobrze
pomyślanych bibliotek, takich jak OWL, MFC, VCL, QT? Po drugie, nasza
rozmowa zaczęła się od tego, że, gdy wydajność jest ważna, to program w
C++ może: wygenerować do pliku kawałek kodu, uruchomić kompilator, wygenerowany kod
skompilować do biblioteki, w końcu tę bibliotekę załadować. Gdy napływają
do programu dane wygodne dla kaczych języków, program napisany w C++
może wygenerować kod ze strukturą analogicznie jak to robią kacze języki i
ten kod może skompilować. No chyba że za "każdym razem" napływają dane o
innej strukturze, wtedy uruchamianie kompilatora i ładowanie biblioteki nie
będzie się opłacało. W C++ jednak można użyć drzewa, w którym węzeł ma
metody wirtualne, używa typu Variant, a potomki są w hash-table. Wiadomo, w
kaczych językach składnia jest ładniejsza i bardziej zwarta, ale w C++,
gdzie można przeładować operatory, implementacja powyższego nie jest
szczególnie straszna, no i są gotowce w postaci bibliotek.

Pozdrawiam

do góry