W dniu 2017-06-05 o 10:13, AK pisze:
> Użytkownik "slawek" <f...@f...com> napisał:
>
>> On Fri, 2 Jun 2017 21:07:38 +0200, "AK" <n...@n...net> wrote:
>>> Probowals to robic ? Da sie uzyc/zlinkowac dll-ke majaca w swym API
>>> uzycie standardowego kontenera STL ?
>>
>> Da się. Rzutowaniem i warperem.
>
> Owszem. Tylko, ze ten wrapper to nie banal i wcale nie daje
> gwarancji "na przyszlosc".

A co daje ci jakiekolwiek gwarancje "na przyszłość"?
--
http://kaczus.ppa.pl

do góry

Użytkownik "Tomasz Kaczanowski" <k...@p...onet.pl> napisał w wiadomości
news:oh36jr$418$1@node2.news.atman.pl...
>W dniu 2017-06-05 o 09:18, AK pisze:
>> Użytkownik "Tomasz Kaczanowski" <k...@p...onet.pl> napisał:
>>
>>> Trochę bez sensu. Czemu C++ miałoby mieć jakieś konkretne wytyczne do tworzenia
dll-ek, skoro
>>> one sa związane z jednym konkretnym systemem. Systemów operacyjnych jest więcej
na świecie i one
>>> mogą w różny sposób definiować dostęp do bibliotek współdzielonych.
>>
>> Dokladnie po to, aby ta "dowolnosc" ustandaryzowac i tym samym
>> uczynic kod przenosnym i nie majacym bzdurnych ograniczen
>> (zabronione uzycie standardowego jakby nie bylo STLa w APIs
>> bibliotek dzielonych).
>
> Ale jakie zabronienie. Mylisz 2 pojęcia. DLL to część systemu, tak jak .library,
czy .so Jak to
> ustandaryzować, nakazać twórcom systemów korzystanie z takich a nie innych rzeczy?
Przecież to bez
> sensu.

Nieprawda. dll/so ma w sobie wiecej z kompilatora niz z systemu (os-a)
OS go jedynie laduje/wykonuje i zapewnia ABI (ustandaryzowane wolanie itp).
Za dostep do "bebechow" dll-ki w duzym stopniu odpowiada kompilator i to
_da sie ustandaryzowac_ (bo tak naprawde glownie chodzi o mangling i o
ustandaryzowanie generacji tempatow coby musialy spelniac reguly ABI dll/so).

> Robienie z C++ coś na modłę javy, dla mnie też bez sensu, wszelkie zalety c++ idą
się paść,

Wlasnie tak dzis powinien wygladac nowoczesny wysokopoziomowy jezyk
programowania. Powinien byc przenosny zarowno na poziomie zrodel
jak i binariow. C++ ma wciaz duze problemy juz z tym pierwszym, ze
o drugim nie wspomne.

> już idą często ze względu na pewną nieprzewidywalność w stosunku do C.

Nieprzewidywalnosc C++ w duzej mierze tyczy tego co idiotycznie przejelo po C.

AK

do góry

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

>> Owszem. Tylko, ze ten wrapper to nie banal i wcale nie daje
>> gwarancji "na przyszlosc".
>
> A co daje ci jakiekolwiek gwarancje "na przyszłość"?

Zgodnosc ze standardem.
Wtedy to tworcy kompilatorow sa zmuszeni do dbania o
backward compatibility, a nie programista.

AK

do góry

W dniu 2017-06-05 o 11:19, AK pisze:
>
> Użytkownik "Tomasz Kaczanowski" <k...@p...onet.pl> napisał w
> wiadomości news:oh36jr$418$1@node2.news.atman.pl...
>> W dniu 2017-06-05 o 09:18, AK pisze:
>>> Użytkownik "Tomasz Kaczanowski" <k...@p...onet.pl> napisał:
>>>
>>>> Trochę bez sensu. Czemu C++ miałoby mieć jakieś konkretne wytyczne
>>>> do tworzenia dll-ek, skoro one sa związane z jednym konkretnym
>>>> systemem. Systemów operacyjnych jest więcej na świecie i one mogą w
>>>> różny sposób definiować dostęp do bibliotek współdzielonych.
>>>
>>> Dokladnie po to, aby ta "dowolnosc" ustandaryzowac i tym samym
>>> uczynic kod przenosnym i nie majacym bzdurnych ograniczen
>>> (zabronione uzycie standardowego jakby nie bylo STLa w APIs
>>> bibliotek dzielonych).
>>
>> Ale jakie zabronienie. Mylisz 2 pojęcia. DLL to część systemu, tak jak
>> .library, czy .so Jak to ustandaryzować, nakazać twórcom systemów
>> korzystanie z takich a nie innych rzeczy? Przecież to bez sensu.
>
> Nieprawda. dll/so ma w sobie wiecej z kompilatora niz z systemu (os-a)
> OS go jedynie laduje/wykonuje i zapewnia ABI (ustandaryzowane wolanie itp).
> Za dostep do "bebechow" dll-ki w duzym stopniu odpowiada kompilator i to
> _da sie ustandaryzowac_ (bo tak naprawde glownie chodzi o mangling i o
> ustandaryzowanie generacji tempatow coby musialy spelniac reguly ABI
> dll/so).

no patrz ale tak jest zawsze, ze kompilator musi wygenerować odpowiedni
kod.Jesli chodzi o "da się ustandaryzować" - to tak, ale dla DLL-ki, ale
jak napisałem, takiej dll-ki bez emulatora na innym systemie nie
uruchomisz. dll to jest sprawa systemu, a nie języka.


--
http://kaczus.ppa.pl

do góry

W dniu 2017-06-05 o 11:35, AK pisze:
> Użytkownik "Tomasz Kaczanowski" <k...@p...onet.pl> napisał:
>
>>> Owszem. Tylko, ze ten wrapper to nie banal i wcale nie daje
>>> gwarancji "na przyszlosc".
>>
>> A co daje ci jakiekolwiek gwarancje "na przyszłość"?
>
> Zgodnosc ze standardem.
> Wtedy to tworcy kompilatorow sa zmuszeni do dbania o
> backward compatibility, a nie programista.

tia.... widać to w wielu językach, jak właśnie czegos podobnego brakuje.
W zasadzie wbrew pozorom, to najwięcej zgodności jest właśnie w C i C++,
a to pewnie dzięki temu, że starają cię mieć pewne normy. Języki
zmieniają się wolniej, bo normy muszą być wypracowane ect, ale są.

--
http://kaczus.ppa.pl

do góry

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

> no patrz ale tak jest zawsze, ze kompilator musi wygenerować odpowiedni kod.Jesli
chodzi o "da się
> ustandaryzować" - to tak, ale dla DLL-ki, ale jak napisałem, takiej dll-ki bez
emulatora na innym
> systemie nie uruchomisz. dll to jest sprawa systemu, a nie języka.

Nic nie rozumiesz i tyla.
Nie chodzi o innny system. Chodzi o ten sam system, ale rozne kompilatory
(czy nawet ich wersje) oraz o wymuszenie w standardzie C++ wsparcia/ustandaryzowanie
C++owych bytow waznych szczegolnie w dllkach. Np.mangling nazw, wymog wspierania
przez kompilator atrybutow so/dll-owych (publish).

AK

do góry

W dniu 2017-06-05 o 12:29, AK pisze:
> Użytkownik "Tomasz Kaczanowski" <k...@p...onet.pl> napisał:
>
>> no patrz ale tak jest zawsze, ze kompilator musi wygenerować
>> odpowiedni kod.Jesli chodzi o "da się ustandaryzować" - to tak, ale
>> dla DLL-ki, ale jak napisałem, takiej dll-ki bez emulatora na innym
>> systemie nie uruchomisz. dll to jest sprawa systemu, a nie języka.
>
> Nic nie rozumiesz i tyla.
> Nie chodzi o innny system. Chodzi o ten sam system, ale rozne kompilatory
> (czy nawet ich wersje) oraz o wymuszenie w standardzie C++
> wsparcia/ustandaryzowanie
> C++owych bytow waznych szczegolnie w dllkach. Np.mangling nazw, wymog
> wspierania
> przez kompilator atrybutow so/dll-owych (publish).

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.

--
http://kaczus.republika.pl

do góry

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

>> Zgodnosc ze standardem.
>> Wtedy to tworcy kompilatorow sa zmuszeni do dbania o
>> backward compatibility, a nie programista.
>
> tia.... widać to w wielu językach, jak właśnie czegos podobnego brakuje.

Widac, raz mniej raz wiecej.
np. w Javie super - kopiuje jary i chodzi
np. w Pythonie nienajgorzej (choc gorzej niz w Javie), jednak pelne ABI wciaz w
marzeniach.
np. W .NET super. Kopiuje z Win->*nix exe-ki i dll-ki (oczywiscie w srodku bytecode)
i chodzi/dziala
W "zwyklym C++" pomarzyc. A przeciez mozna by....
Takie MS VC z 90tych lat mialo opcje "bytecode generate", a tak wygenerowany
zwykly exe-k byl zaledwie ~15% wolniejszy od "processor code".
A przeciez mozna by to dzis jeszcze ulepszyc (jit-y czy techniki rodem z JS v8).

> W zasadzie wbrew pozorom, to najwięcej zgodności jest właśnie w C i C++,

Wbrew pozorom to piszac to dajesz przyklad, ze C/C++ znasz tylko z ksiazek i
Internetu.

C/C++ jest wciaz dzis jednym z najbardziej uciazliwych jezykow w sensie portability.
(Jestem skrajnym wieloplatformowcem :) - od 1992 roku wlasciwie kazdy system w ktorym
bralem udzial byl full porable na : Win, Linux, Solaris, HP-UX .
Dobrze radze nie "wyzywac mnie na pojedynek" w tym temacie bo mozna byc
"zjedzonym na sniadanie" ;)

AK

do góry

W dniu 2017-06-05 o 12:45, AK pisze:
> Użytkownik "Tomasz Kaczanowski" <k...@p...onet.pl> napisał:
>
>>> Zgodnosc ze standardem.
>>> Wtedy to tworcy kompilatorow sa zmuszeni do dbania o
>>> backward compatibility, a nie programista.
>>
>> tia.... widać to w wielu językach, jak właśnie czegos podobnego brakuje.
>
> Widac, raz mniej raz wiecej.
> np. w Javie super - kopiuje jary i chodzi
> np. w Pythonie nienajgorzej (choc gorzej niz w Javie), jednak pelne ABI
> wciaz w marzeniach.
> np. W .NET super. Kopiuje z Win->*nix exe-ki i dll-ki (oczywiscie w
> srodku bytecode)

Dawno nie próbowałem, ale na platformach z innym endianem nie działało....


> i chodzi/dziala
> W "zwyklym C++" pomarzyc. A przeciez mozna by....
> Takie MS VC z 90tych lat mialo opcje "bytecode generate", a tak
> wygenerowany
> zwykly exe-k byl zaledwie ~15% wolniejszy od "processor code".
> A przeciez mozna by to dzis jeszcze ulepszyc (jit-y czy techniki rodem z
> JS v8).

tia i pochłania kilka razy tyle pamięci.


>> W zasadzie wbrew pozorom, to najwięcej zgodności jest właśnie w C i C++,
>
> Wbrew pozorom to piszac to dajesz przyklad, ze C/C++ znasz tylko z
> ksiazek i Internetu.
>
> C/C++ jest wciaz dzis jednym z najbardziej uciazliwych jezykow w sensie
> portability.
> (Jestem skrajnym wieloplatformowcem :) - od 1992 roku wlasciwie kazdy
> system w ktorym
> bralem udzial byl full porable na : Win, Linux, Solaris, HP-UX .
> Dobrze radze nie "wyzywac mnie na pojedynek" w tym temacie bo mozna byc
> "zjedzonym na sniadanie" ;)


też jestem wieloplatformowcem, i często przenoszę kod na bardziej dziwne
platformy niż windows np: uclinux, rtos, morphos... jakoś aplikacje js 8
na tym nie chca działać, dodatkowo często różna endianowość też nie
ułatwia, nawet na linuksie z procesorem z innym endianem juz jest
inaczej (nie pisze tu o javie jeśli chodzi o endianowość, żeby nie
było). Ale pewnie to wiesz, skoroś tak wyedukowany

--
http://kaczus.ppa.pl

do góry

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.

https://stackoverflow.com/questions/5661738/how-can-
i-use-standard-library-stl-classes-in-my-dll-interfa
ce-or-abi/
https://stackoverflow.com/questions/2110151/using-te
mplated-classes-and-functions-in-a-shared-object-dll
?noredirect=1&lq=1

"It's well documented on MSDN that you should not export STL maps from your DLLs."
https://social.msdn.microsoft.com/Forums/en-US/8b53e
d27-f7df-4aac-913a-0118cb4952da/stl-map-in-dll?forum
=vclanguage

Jesli sie komus chce czytac opery mydlane to zaledwie zajawki tu:
https://www.codeproject.com/articles/28969/howto-exp
ort-c-classes-from-a-dll
https://stackoverflow.com/questions/22797418/how-do-
i-safely-pass-objects-especially-stl-objects-to-and-
from-a-dll

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

AK

do góry