🚀 go-pugleaf

On 12/27/2017 11:38 AM, szykcech@gmail.com wrote:
> Czy bezpieczne jest usuwanie z programu (exe) danych alokowanych w bibliotece (dll)?

Tak. O ile allokator jest ten sam.

Użytkownik <szykcech@gmail.com> napisał:

> Czy bezpieczne jest usuwanie z programu (exe) danych alokowanych w bibliotece (dll)?

Co do zasady: Nie! Nie wiem jak w przyupadku QSharedPointer.
Generalnie (bez wzgledu na rodzaj biblioteki) musi  byc zachowana zasada
identycznosci kompilatora (i jego podstawowych ustawien) dla exe i dll-ki.

PS: W interface dll-lek nie wolno (bez naprawde glebszej znajomosci rzeczy) uzywac
      niczego  z STL-la, a co dopiero jakies niestandardowe biblioteki.

AK

Najbezpieczniej jest stworzyć interfejs zgodny z językiem ANSI C, wtedy kompatybilność jest gwarantowana (nawet pomiędzy różnymi językami).

Swego czasu robiłem różne eksperymenty m.in z kontenerami STL i to mi działało. Musisz tylko pamiętać, że zestaw narzędzi użyty do zbudowania EXE oraz DLL musi być ten sam (Visual C++ tu i tu) w takich samych wersjach, ponieważ pomiędzy poszczególnymi wersjami niekoniecznie będzie zachowana kompatybilność binarna.

Jeśli chodzi o Qt, to również jest to możliwe.
https://wiki.qt.io/How_to_create_a_library_with_Qt_and_use_it_in_an_application

Jednak zalecam ostrożność.

Użytkownik <dawid.bautsch@gmail.com> napisał:

> Najbezpieczniej jest stworzyć interfejs zgodny z językiem ANSI C,
> wtedy kompatybilność jest gwarantowana (nawet pomiędzy różnymi językami).

To za malo.
Musi byc _dokladnie_ ten sam alokator (co implikuje ten sam kompilator ale to warunek zalwedwie 
konieczmy).
W dodatku winny byc zgode podstawowe opcje kompilatora.

> Swego czasu robiłem różne eksperymenty m.in z kontenerami STL i to mi działało.

W VC++ tylo niektore podstawowe kontenery da sie tak uzywac i to przy wykonaniu "owijek"
No i wiadomo, ze nie ma 100%towej pewnosci, ze w ktorejs tam przyszlej wersji kompilatora nie 
przestanie dzialac.

> Musisz tylko pamiętać, że zestaw narzędzi użyty do zbudowania EXE oraz DLL musi być ten sam 
> (Visual C++ tu i tu)
> w takich samych wersjach, ponieważ pomiędzy poszczególnymi wersjami niekoniecznie będzie zachowana 
> kompatybilność binarna.

Ta, ale to wciaz za malo (patrz wyzej).

> Jednak zalecam ostrożność.

O taaak ;)
IMHO lepiej przyjac jednak zasade, iz zasob zwalnia sie _scisle tam_ gdzie zostal 
przydzielony/utworzony.

AK

> IMHO lepiej przyjac jednak zasade, iz zasob zwalnia sie _scisle tam_ gdzie zostal 
> przydzielony/utworzony. 

Nie napisałem tego w poprzednim poście, jednak zgadzam się z tym co napisałeś. W dawnych czasach pisałem mniej lub bardziej eleganckie programy, które zawierały m.in funkcję void * Malloc(unsigned) oraz Release(void*) która była eksportowana przez EXE. Dzięki temu miałem pewność, że zostanie użyty manadżer pamięci który zaalokował dany zasób.

W przypadku QSharedPointer najlepiej przekazywać QWeakPointer i sprawdzać czy pointer jest poprawny.

W dniu czwartek, 28 grudnia 2017 13:49:29 UTC+1 użytkownik dawid....@gmail.com napisał:
> > IMHO lepiej przyjac jednak zasade, iz zasob zwalnia sie _scisle tam_ gdzie zostal 
> > przydzielony/utworzony. 
> 
> Nie napisałem tego w poprzednim poście, jednak zgadzam się z tym co napisałeś. W dawnych czasach pisałem mniej lub bardziej eleganckie programy, które zawierały m.in funkcję void * Malloc(unsigned) oraz Release(void*) która była eksportowana przez EXE.

Co to znaczy "eksportwana przez EXE"?!? Exe udostępnia coś bibliotekom dll?!? Jak to zakodować w C++?!?
 
> W przypadku QSharedPointer najlepiej przekazywać QWeakPointer i sprawdzać czy pointer jest poprawny.

Dlaczego najlepiej?!? Jak to sprawdzić czy "pointer jest poprawny"?!?

Można eksportować.

Zapoznaj się z publikacją -> https://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL

Użytkownik <dawid.bautsch@gmail.com> napisał:

>Można eksportować.

Napisales czesko-omylkowo: "Release(void*) która była eksportowana przez EXE" zamiast 
"...Release(void*) która była eksportowana przez DLL"
i tego czepil sie przedpisca.

AK 

Użytkownik <szykcech@gmail.com> napisał:
>> W przypadku QSharedPointer najlepiej przekazywać QWeakPointer i sprawdzać czy pointer jest 
>> poprawny.

> Jak to sprawdzić czy "pointer jest poprawny"?!?

Normalnie. Jak wiekszosc weak pointerow.

if ( weak_ptr )
{
     // poprawny => obiekt dostepny
}

AK 

On Friday, December 29, 2017 at 9:36:19 AM UTC+1, AK wrote:
> Użytkownik <szykcech@gmail.com> napisał:
> >> W przypadku QSharedPointer najlepiej przekazywać QWeakPointer i sprawdzać czy pointer jest 
> >> poprawny.
> 
> > Jak to sprawdzić czy "pointer jest poprawny"?!?
> 
> Normalnie. Jak wiekszosc weak pointerow.
> 
> if ( weak_ptr )
> {
>      // poprawny => obiekt dostepny
> }

I co zrobisz z samym weak, skoro nie można na nim zrobić dereferencji;>
A jeśli takiego masz, to w trzeciej linijce ostatni shared_ptr zniknie
i zniknie nasz obiekt. Bum;)

Trzeba wyciągnać z weak shared (i ta operacja mówi, czy się powiodła)
i operować sobie na nowy wspoldzeiolonym, który nam zapewnia istnienie 
obiektu na czas naszej operacji. 
W std coś w rodzaju 

if (auto observe = weak.lock()) {
   //observe jest shared_ptr, istnieje aż po zamykającą klamerkę.
  ....
} 


BTW, nie bardzo rozumiem radę, by przekazywać weak_ptr.
Czy przekazywać weak_ptr czy shared_ptr zależy od tego,
co cheć z tym zrobić. 
Jeśli daje jakiś zasób z biblioteki, to najcześceij chcę
przekazać własność, czyli daje shared (a w 90% przypadków
jeszcze prościej - unique_ptr). Jaki jest sens dawania weak_ptr,
wtedy biblioteka musi mieć trzymać shared_ptr. Kiedy go zwolni?
Jak wywołam moja_biblikteka::free_badziew()?
Wtedy cała zabawa ze sprytnimi wskaźnikami traci sens, 
a za pol roku ktoś zapomni o free_badziew i będzie wyciek;-)


Piszę o bibliotece, bo to uniwersalne. Jak wpakujemy to w dll,
to dochodzą do tego wszystkie opisane wcześniej problemy;-)

pzdr
bartekltg

Użytkownik "bartekltg" <bartekltg@gmail.com> napisał:

On Friday, December 29, 2017 at 9:36:19 AM UTC+1, AK wrote:
> Użytkownik <szykcech@gmail.com> napisał:
> >> W przypadku QSharedPointer najlepiej przekazywać QWeakPointer i sprawdzać czy pointer jest
> >> poprawny.
>
> > Jak to sprawdzić czy "pointer jest poprawny"?!?
>
> Normalnie. Jak wiekszosc weak pointerow.
>
> if ( weak_ptr )
> {
>      // poprawny => obiekt dostepny
> }

> I co zrobisz z samym weak, skoro nie można na nim zrobić dereferencji;>

Napisalem jak _sie sprawdza_ istnienie weak-nietego obiektu a nie jak sie z niego korzysta.
Uzycie weak to czesto jednak przydatna technika/informacja - czasami nawet lepsza niz "twardy"
shared (gdy sie chce uniknac np. cyklu czy niepotrzebnego "trzymania" obiektu "na zapas".)

> BTW, nie bardzo rozumiem radę, by przekazywać weak_ptr.
> Czy przekazywać weak_ptr czy shared_ptr zależy od tego,
> co cheć z tym zrobić.

1. Mowa byla o QTowym weak-u.
2. Nigdzie nie odnioslem sie ani slowem do rady przedpiscy.

AK 

On Fri, 29 Dec 2017 03:03:14 -0800 (PST), bartekltg 
<bartekltg@gmail.com> wrote:
> Piszę o bibliotece, bo to uniwersalne. Jak wpakujemy to w dll,
> to dochodzą do tego wszystkie opisane wcześniej problemy;-)


I dlatego C# lub Java są lepsze.  ;)

> I dlatego C# lub Java są lepsze.  ;)

Są zapewne w tym lepsze, że emulują procesor zamiast go po prostu używać... Tym samym na dzień dobry mamy zdławioną wydajność do emulacji jakiegoś NIEISTNIEJĄCEGO procesora wirtualnego...

On 12/30/2017 6:02 AM, szykcech@gmail.com wrote:
>> I dlatego C# lub Java są lepsze.  ;)
> Są zapewne w tym lepsze, że emulują procesor zamiast go po prostu używać...

Taki HotSpot od połowy lat 90tych wykonuje Jave natywnie.

> Tym samym na dzień dobry mamy zdławioną wydajność do emulacji jakiegoś NIEISTNIEJĄCEGO procesora wirtualnego...

Całe szczęscie to tylko bzdura w ujeciu ogólnym.

> Zapoznaj się z publikacją -> https://www.codeproject.com/Articles/28969/HowTo-Export-C-classes-from-a-DLL

Rzuciłem okiem. I od razu nasuwa się pytanie: Czy to jest przenośne?!? Bo ja nie mam zamiaru wiązać sobie kodu do Windos.

> >> I dlatego C# lub Java są lepsze.  ;)
> > Są zapewne w tym lepsze, że emulują procesor zamiast go po prostu używać...
> 
> Taki HotSpot od połowy lat 90tych wykonuje Jave natywnie.

Ta... Nowa wersja Java i nowy procesor?!? Zdrówka życzę...
 
> > Tym samym na dzień dobry mamy zdławioną wydajność do emulacji jakiegoś NIEISTNIEJĄCEGO procesora wirtualnego...
> 
> Całe szczęscie to tylko bzdura w ujeciu ogólnym.

Choćby wszyscy programiści Java się na raz zesrali nic tego nie zmieni że Java to emulacja czegoś co nie istnieje... Jit to próba obejścia tego faktu - łata. Wirtualne maszyny Java i C# to chore pomysły i żadna łata tego nie zmieni - co więcej z każdą kolejną łatą choroba postępuje.
To tak jakby powiedzieć, po co mi normalne oddychanie skoro mogę użyć respiratora?!? Po co Ci nerki skoro możesz użyć maszyny do dializy?!? Po co Ci własne serce skoro możesz mieć sztuczne?!?
Opamiętaj się człowieku i nie wciskaj młodym głupot. A jeśli chcesz żyć podłączony do tych wszystkich kabli - to twój (chory) wybór...

On 12/30/2017 9:32 PM, szykcech@gmail.com wrote:
>> Taki HotSpot od połowy lat 90tych wykonuje Jave natywnie.
> Ta... Nowa wersja Java i nowy procesor?!? Zdrówka życzę...

Zupełnie jak z kompilatorami dowolnych językow.

> Choćby wszyscy programiści Java się na raz zesrali nic tego nie zmieni że Java to emulacja czegoś co nie istnieje...

x86 tez "nie istnieje". Istnieje tylko mikrokod, reszta to emulacja.

> Jit to próba obejścia tego faktu - łata. Wirtualne maszyny Java i C# to chore pomysły i żadna łata tego nie zmieni - co więcej z każdą kolejną łatą choroba postępuje.

Nijak świat tak nie uważa. Pewno nie czytają usenet. Paaaanie, ile tu 
było już dobrych rad dla świata i dupa. Niekt nie słucha kolejnych 
kaznodziei.

> To tak jakby powiedzieć, po co mi normalne oddychanie skoro mogę użyć respiratora?!? Po co Ci nerki skoro możesz użyć maszyny do dializy?!? Po co Ci własne serce skoro możesz mieć sztuczne?!?

Z bardzo wielu przyczyn które tutaj pomijasz. Java i C# kompilują do 
kodu pośredniego nie dlatego że tworcy byli idiotami, tylko dlatego że 
mozna dzięki temu osiągnąc kilka celów których nie da się osiągnąc w 
językach natywnych, przynajmniej nie bez doatkowego wysiłku. Dodatkowo 
niektore wersje jitc potafiły optymalizwac kod w *runtime* co jest 
nieosiągalne dla tradycyjnej kompilacji.

> Opamiętaj się człowieku

Nie przyszło Ci do głowy że aby wypowiadać się w dowolnym temacie nalezy 
miec o nim pojęcie?

> A jeśli chcesz żyć podłączony do tych wszystkich kabli - to twój (chory) wybór...

Analogie tumanistyczne mają to do siebie że zazwyczaj się gówno warte.

On Fri, 29 Dec 2017 21:02:16 -0800 (PST), szykcech@gmail.com wrote:
> Są zapewne w tym lepsze, że emulują procesor

Niezupełnie. 

Na pewnym poziomie abstrakcji nie jest istotne czy JVM jest 
bezpośrednio zrobione na krzemie. I czy na krzemie czy na arsenku 
galu?  To są szczegóły, które niekoniecznie muszą interesować 
programistę.

Co ciekawe - nowe maszyny Javy kompilują w locie do natywnego - więc 
jest szybko.

Co jeszcze ciekawsze: przy wielu rdzeniach GC może hasać w odrębnym 
wątku.

W dniu sobota, 30 grudnia 2017 21:32:20 UTC+1 użytkownik szyk...@gmail.com napisał:
> > >> I dlatego C# lub Java są lepsze.  ;)
> > > Są zapewne w tym lepsze, że emulują procesor zamiast go po prostu używać...
> > 
> > Taki HotSpot od połowy lat 90tych wykonuje Jave natywnie.
> 
> Ta... Nowa wersja Java i nowy procesor?!? Zdrówka życzę...
>  
> > > Tym samym na dzień dobry mamy zdławioną wydajność do emulacji jakiegoś NIEISTNIEJĄCEGO procesora wirtualnego...
> > 
> > Całe szczęscie to tylko bzdura w ujeciu ogólnym.
> 
> Choćby wszyscy programiści Java się na raz zesrali nic tego nie zmieni że Java to emulacja czegoś co nie istnieje... Jit to próba obejścia tego faktu - łata. Wirtualne maszyny Java i C# to chore pomysły i żadna łata tego nie zmieni - co więcej z każdą kolejną łatą choroba postępuje.
> To tak jakby powiedzieć, po co mi normalne oddychanie skoro mogę użyć respiratora?!? Po co Ci nerki skoro możesz użyć maszyny do dializy?!? Po co Ci własne serce skoro możesz mieć sztuczne?!?
> Opamiętaj się człowieku i nie wciskaj młodym głupot. A jeśli chcesz żyć podłączony do tych wszystkich kabli - to twój (chory) wybór...

zgodzilbym sie z tym ponikad z tymz e mozna zauwazyc ze o tyle jawa (jako 'wsad dla emulatorow') wydaje sie wlasnie idealna do swiata www (aplikacji webowych?) - gdzie taki bytekode dosyc wydajny, odpalalny na roznych archotekturach wydaje sie wlasnie idealny
w kilku niezwykle istatnych punktach cos bardzo podobnego wydaje sie idealne do takich celow (1)jest wlasnie emulowane, 2) jest szybkie (przynajmniej wydaje mi sie ze powinno byc szybkie w porownaniu do takiego js, zwlaszcza ze mozna jit-owac) 3) jest male (po byte-kodowej-kompilacji, przynajmniej chyba powino byc male) 4) jest co nieco obfuskowane (co tez raczej zaleta).. nawet garbage colector (ktory noralnie wydaje mi sie nie za dobrym pomyslem w swiecie www wydaje sie bardziej znosny... wada moze wydawac sie to ze jest 'malo skryptowy' ale nie jestem pewien na ile to powazna wada bo dla mniej powaznych rzeczy pewnie  liczy sie skryptowatosc ale dla tych bardziej powaznych chyab jednak bardzej efektywnosc.. niekwestionowana wada jest OOP ktorego ja bardzo nei lubie ale to mozna powiedziec istnieje troche na uboczu)

incydentalnie (bys skopiowac slowo z angielskiego) jawa na www chyba kompletnie zdechla - gdy moja wlasnie tu wyrazona wyzej logika wydaje sie mi mowic ze do www 
jawa wlasnie sie powinna najbardziej nadawac )

W dniu poniedziałek, 15 stycznia 2018 01:29:17 UTC+1 użytkownik (fir) napisał:
> W dniu sobota, 30 grudnia 2017 21:32:20 UTC+1 użytkownik szyk...@gmail.com napisał:
> > > >> I dlatego C# lub Java są lepsze.  ;)
> > > > Są zapewne w tym lepsze, że emulują procesor zamiast go po prostu używać...
> > > 
> > > Taki HotSpot od połowy lat 90tych wykonuje Jave natywnie.
> > 
> > Ta... Nowa wersja Java i nowy procesor?!? Zdrówka życzę...
> >  
> > > > Tym samym na dzień dobry mamy zdławioną wydajność do emulacji jakiegoś NIEISTNIEJĄCEGO procesora wirtualnego...
> > > 
> > > Całe szczęscie to tylko bzdura w ujeciu ogólnym.
> > 
> > Choćby wszyscy programiści Java się na raz zesrali nic tego nie zmieni że Java to emulacja czegoś co nie istnieje... Jit to próba obejścia tego faktu - łata. Wirtualne maszyny Java i C# to chore pomysły i żadna łata tego nie zmieni - co więcej z każdą kolejną łatą choroba postępuje.
> > To tak jakby powiedzieć, po co mi normalne oddychanie skoro mogę użyć respiratora?!? Po co Ci nerki skoro możesz użyć maszyny do dializy?!? Po co Ci własne serce skoro możesz mieć sztuczne?!?
> > Opamiętaj się człowieku i nie wciskaj młodym głupot. A jeśli chcesz żyć podłączony do tych wszystkich kabli - to twój (chory) wybór...
> 
> zgodzilbym sie z tym ponikad z tymz e mozna zauwazyc ze o tyle jawa (jako 'wsad dla emulatorow') wydaje sie wlasnie idealna do swiata www (aplikacji webowych?) - gdzie taki bytekode dosyc wydajny, odpalalny na roznych archotekturach wydaje sie wlasnie idealny
> w kilku niezwykle istatnych punktach cos bardzo podobnego wydaje sie idealne do takich celow (1)jest wlasnie emulowane, 2) jest szybkie (przynajmniej wydaje mi sie ze powinno byc szybkie w porownaniu do takiego js, zwlaszcza ze mozna jit-owac) 3) jest male (po byte-kodowej-kompilacji, przynajmniej chyba powino byc male) 4) jest co nieco obfuskowane (co tez raczej zaleta).. nawet garbage colector (ktory noralnie wydaje mi sie nie za dobrym pomyslem w swiecie www wydaje sie bardziej znosny... wada moze wydawac sie to ze jest 'malo skryptowy' ale nie jestem pewien na ile to powazna wada bo dla mniej powaznych rzeczy pewnie  liczy sie skryptowatosc ale dla tych bardziej powaznych chyab jednak bardzej efektywnosc.. niekwestionowana wada jest OOP ktorego ja bardzo nei lubie ale to mozna powiedziec istnieje troche na uboczu)
> 
> incydentalnie (bys skopiowac slowo z angielskiego) jawa na www chyba kompletnie zdechla - gdy moja wlasnie tu wyrazona wyzej logika wydaje sie mi mowic ze do www 
> jawa wlasnie sie powinna najbardziej nadawac )

moze przewazylo to ze te jawwskie wstawki nie sa/ nie byly tak bardzo dobrze sintegrowane z resztą strony w htmlu jak js? (nie wiem bo praktyczni enie znam tych apletow w jawie i bardzo slabo js i html..
ale wydaje sie ze ta integracja (kyora w 
wypadku js i html jest chyab bardzo dobra
w wypadku jawy i html niebardzo wystepowala) (teoretycznie mozna by ja zrobic ale pewnie raczej wtedy gdyby htmle tez byly kompilowane do bytekodu)