Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #29702 > unrolled thread

Oszczędności

Back to article view | Back to pl.comp.programming

Contents

  Oszczędności Sebastian Biały <heby@poczta.onet.pl> - 2017-05-30 22:04 +0200
    Re: Oszczędności niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-05-31 17:57 +0200
      Re: Oszczędności szykcech@gmail.com - 2017-05-31 21:05 -0700
        Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-01 09:17 +0200
        Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-01 09:21 +0200
          Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-01 10:55 +0200
          Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-01 16:03 +0200
            Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-01 19:15 +0200
              Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-01 23:54 +0200
                Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 09:14 +0200
                  Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-02 11:31 +0200
                    Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 12:01 +0200
                      Re: Oszczędności "M.M." <mmarszik@gmail.com> - 2017-06-02 04:05 -0700
                        Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-02 15:54 +0200
                          Re: Oszczędności "M.M." <mmarszik@gmail.com> - 2017-06-02 08:27 -0700
                      Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-02 15:43 +0200
                        Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 20:41 +0200
                          Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-03 11:06 +0200
                            Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 10:14 +0200
                      Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-02 15:44 +0200
                      Re: Oszczędności bartekltg <bartekltg@gmail.com> - 2017-06-02 08:29 -0700
                        Re: Oszczędności "M.M." <mmarszik@gmail.com> - 2017-06-02 08:41 -0700
                          Re: Oszczędności nikt mnie k_rwa nie lubi 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-06-02 18:10 +0200
                          Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 18:51 +0200
                            Re: Oszczędności "M.M." <mmarszik@gmail.com> - 2017-06-02 11:53 -0700
                              Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 21:07 +0200
                                Re: Oszczędności "M.M." <mmarszik@gmail.com> - 2017-06-02 12:36 -0700
                                  Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 23:07 +0200
                                    Re: Oszczędności "M.M." <mmarszik@gmail.com> - 2017-06-03 00:38 -0700
                                      Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 09:55 +0200
                                        Re: Oszczędności "M.M." <mmarszik@gmail.com> - 2017-06-07 00:03 -0700
                                    Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 08:32 +0200
                                      Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 09:18 +0200
                                        Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 11:00 +0200
                                          Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 11:19 +0200
                                            Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 11:38 +0200
                                              Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 12:29 +0200
                                                Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 12:32 +0200
                                                  Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 13:47 +0200
                                                    Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 13:51 +0200
                                                      Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 14:08 +0200
                                                        Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 14:28 +0200
                                                          Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 15:34 +0200
                                Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-03 10:55 +0200
                                  Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 10:13 +0200
                                    Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 11:03 +0200
                                      Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 11:35 +0200
                                        Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 11:42 +0200
                                          Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 12:45 +0200
                                            Re: Oszczędności Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-06-05 12:57 +0200
                        Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 18:44 +0200
                          Re: Oszczędności bartekltg <bartekltg@gmail.com> - 2017-06-03 03:26 -0700
                            Re: Oszczędności "M.M." <mmarszik@gmail.com> - 2017-06-03 14:36 -0700
                              Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-05 10:11 +0200
                        Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-03 10:52 +0200
              Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-01 23:55 +0200
                Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 09:18 +0200
          Re: Oszczędności slawek <fake@fakeemail.com> - 2017-06-01 16:17 +0200
            Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-01 19:12 +0200
    Re: Oszczędności Wojciech Muła <wojtek.mula@gmail.com> - 2017-06-01 00:24 -0700
    Re: Oszczędności Zenon Oktawiec <zenon@samm.com.pl> - 2017-06-02 08:53 +0200
      Re: Oszczędności "AK" <nobody@nowhere.net> - 2017-06-02 09:24 +0200
      Re: Oszczędności Sebastian Biały <heby@poczta.onet.pl> - 2017-06-03 21:14 +0200
      Re: Oszczędności Budzik <budzik61@poczta.o.n.e.t.pl.nie.spam.oj> - 2017-06-04 11:55 +0000
        Re: Oszczędności w systemie siła 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-06-04 14:12 +0200

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#29727

On Friday, June 2, 2017 at 12:01:15 PM UTC+2, AK wrote:
> Użytkownik "slawek" <fake@fakeemail.com> napisał:

> Niskopoziomowo nalezy pisac dopiero wtedy gdy wszytsko inne zawiedzie, gdyz po prostu i zwyczajnie
> jezyki niskopoziomowe (tak tak, w tym C i C++) sa wielokrotnie bardziej 

Co jest niskopoziomowego w c++? 
C++ daje dostęp do bebechów i przez to daje się tam pisać jak
w przenośnym assemblerze zwanym C (za co powinni bić linijką po rękach)
ale sam w sobie jest zdecydowanie językiem wysokiego poziomu. 

pzdr
bartekltg

[toc] | [prev] | [next] | [standalone]

#29728

On Friday, June 2, 2017 at 5:29:31 PM UTC+2, bartekltg wrote:
> On Friday, June 2, 2017 at 12:01:15 PM UTC+2, AK wrote:
> > Użytkownik "slawek" <fake@fakeemail.com> napisał:
> 
> > Niskopoziomowo nalezy pisac dopiero wtedy gdy wszytsko inne zawiedzie, gdyz po prostu i zwyczajnie
> > jezyki niskopoziomowe (tak tak, w tym C i C++) sa wielokrotnie bardziej 
> 
> Co jest niskopoziomowego w c++? 

Może autor miał na myśli "proceduralny C++", bez klas, szablonów, 
wyjątków, ale z międleniem nazw i przeładowaniem? Hmmm trudno
tak programować, bo biblioteki używają klas, szablonów i wyjątków
także, choć rzadziej.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#29729

> Może autor miał na myśli "proceduralny C++", bez klas, szablonów,
> wyjątków, ale z międleniem nazw i przeładowaniem? Hmmm trudno

nie drażnij lwa

[toc] | [prev] | [next] | [standalone]

#29731

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

> Hmmm trudno tak programować, bo biblioteki używają klas, szablonów
> i wyjątków także, choć rzadziej.

Tak?. To napisz C++sowy dll,  ktory w interface/API ma cus (np pole, parametr metody) ze 
standardowego STL-a...

AK

[toc] | [prev] | [next] | [standalone]

#29737

On Friday, June 2, 2017 at 6:51:17 PM UTC+2, AK wrote:
> Użytkownik "M.M." <mmarszik@gmail.com> napisał:
> 
> > Hmmm trudno tak programować, bo biblioteki używają klas, szablonów
> > i wyjątków także, choć rzadziej.
> 
> Tak?. To napisz C++sowy dll,  ktory w interface/API ma cus (np pole, parametr metody) ze 
> standardowego STL-a...
> 
> AK

Biblioteki to nie tylko dll, są biblioteki nagłówków - o czym dobrze 
wiesz. Gdy potrzeba funkcjonalności szablonów na poziomie biblioteki, to
nie ma innego wyjścia, jak wygenerować kod szablonu, wywołać kompilator i
skompilować szablon do biblioteki, a potem dynamicznie załadować - o 
czym też dobrze wiesz ;-)

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#29738

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

> Gdy potrzeba funkcjonalności szablonów na poziomie biblioteki, to
> nie ma innego wyjścia, jak wygenerować kod szablonu, wywołać kompilator i
> skompilować szablon do biblioteki, a potem dynamicznie załadować - o
> czym też dobrze wiesz ;-)

Probowals to robic ? Da sie uzyc/zlinkowac dll-ke majaca w swym API
uzycie standardowego kontenera STL ?
C++/SzacownyKomitetANSIC++ to przewidzial/zezwala ?

AK

[toc] | [prev] | [next] | [standalone]

#29741

On Friday, June 2, 2017 at 9:07:46 PM UTC+2, AK wrote:
> Użytkownik "M.M." <mmarszik@gmail.com> napisał:
> 
> > Gdy potrzeba funkcjonalności szablonów na poziomie biblioteki, to
> > nie ma innego wyjścia, jak wygenerować kod szablonu, wywołać kompilator i
> > skompilować szablon do biblioteki, a potem dynamicznie załadować - o
> > czym też dobrze wiesz ;-)
> 
> Probowals to robic ? 
> Da sie uzyc/zlinkowac dll-ke majaca w swym API
> uzycie standardowego kontenera STL ?
> C++/SzacownyKomitetANSIC++ to przewidzial/zezwala ?

Nie wiem w czym widzisz problem. We wszystkich wariantach nie próbowałem.
Po prawdzie, częściej :

1) generowałem cały program, kompilowałem i uruchamiałem przez jakieś 
   exec;

2) program umiał sam wygenerować fragment swojego kodu, potem trzeba 
   było ręcznie ten fragment podmienić i skompilować.

Zawsze działało. Dlaczego to nie miałoby działać z biblioteką?
Oczywiście jeśli generujemy tylko bibliotekę, a nie cały program,
to w programie magicznie nie dopasują się interfejsy. Wywołanie
musi być przy pomocy wcześniej przewidzianej metody, ale wewnątrz
biblioteki, np. w celu optymalizacji, można używać szablonów.
Wszystko co napisałem wiesz i Ty wiesz, że ja wiem, więc nie 
wiem w czym widzisz problem? Chyba nie w tym dopatrujesz się
problemu (bo po co?), że to się dzieje na poziomie bibliotek/systemu, a 
nie w ramach standardu C++?


Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#29743

Użytkownik "M.M." <mmarszik@gmail.com> napisał:
On Friday, June 2, 2017 at 9:07:46 PM UTC+2, AK wrote:
> Użytkownik "M.M." <mmarszik@gmail.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

[toc] | [prev] | [next] | [standalone]

#29744

On Friday, June 2, 2017 at 11:07:14 PM UTC+2, AK wrote:
> Użytkownik "M.M." <mmarszik@gmail.com> napisał:
> On Friday, June 2, 2017 at 9:07:46 PM UTC+2, AK wrote:
> > Użytkownik "M.M." <mmarszik@gmail.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

Ok, przyznaję że opisujesz obszar z którym miałem zbyt małą styczność
żeby wyrobić sobie zdanie. Warunek konieczny: szablon musi być 
identycznie skompilowany w bibliotece i w programie korzystającym z
biblioteki, aby nie było problemów przy linkowaniu statycznym bądź
dynamicznym. Musi też być standardowo wystawiony na zewnątrz. Czy są z 
tym aż takie problemy? Skoro piszesz że są, to wierzę na słowo.

Pozdrawiam

[toc] | [prev] | [next] | [standalone]

#29755

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

> Czy są z tym aż takie problemy? Skoro piszesz że są, to wierzę na słowo.

Sa sa.  Uzywajac VC++.
Ale to nie jest wina MSa. VC++ nie lamie standardu C++.
To wina "niedostrzegania" przez lata tego problemu/nieustandaryzowania
sprawy przez szacowny komitet do spraw "rozwoju" C++.

PS: Opisze Ci/podam przyklad i obejscie. Moze Ci/komus sie przyda
(oby nie musial:).

PS1: Dla tych co zaraz napisza, ze problem jest blachy, wydumany,
niepraktyczny itd. itp, a C++ wspanialy bo tak !:).

Istnieje sobie lata/a moze i dziesiatki lat wysoce ustandaryzowane
(i uzywane w setkach miejsc) API podstawowego lib-a systemu
w ktorym nagminnie i nowoczesnie korzysta sie z STL miast
chorych wskaznikow char *str itp (i bardzo dobrze).
W pewnym momencie  z roznych wzgledow konieczne jest zmiana
statycznego liba (*.lib) na dzielony (*.dll).
Warunek podstawowy wydaje sie oczywisty:
jakakolwiek zmiana dotychczasowego API/naglowkow (*.h*)
jest niedopuszczalna.
Generalnie sprawa wydaje sie prosta i bezproblemowa, a tu...
W najnowoczesniejszym z mozliwych SCRUMie wszyscy
wyciagneli w gore karty: 2 dni, 4 dni, ktos dal tydzien, i tylko
jakis chory stary grzyb wyciagnal karte z napisem 60 dni .
Oczywiscie zostalo to wykpione, wspomniano nawet o dr Alzheimerze
itp (ot Mlodzi Wyksztalceni z Duzych Miast:).
Ostatecznie Temida (Pani Rzeczywistosc) po jakims czasie (napewno
dluzszym niz wspomnany tydzien:) oddala jednak problem w rece tego
grzyba i fakt ze zajelo mu to ok tygodnia, ale podstawowe zalozenie
zostalo zachowane (oczywiscie przy zlamaniu zasady ze w publicznym
API dll-ki nie moze byc uzyty zaden kontener C++owego STLa).
Nie musze dodawac, ze musiala byc zachowana scisle
backward compatibility nie tylko APIs, ale i background-u
(nie mozna bylo zmienic kompilatorow i innych bibliotek na nowsze
wersje itd itp. W ogole prawie niczego nie wolno bylo "ruszyc").
Nie obylo sie takze bez pewnych restrykcji w tym publicznym API
(np. bylo konieczne wymuszenie i uzywania w nim std::vector zamiast
std::list). Na szczescie w tym konkretnym przypadku zmiany byly
na tyle male, ze mozliwe do wykrycia uzycia/przeprowadzenia w tych
setkach miejsc kompilacji.

AK

[toc] | [prev] | [next] | [standalone]

#29776

On Monday, June 5, 2017 at 9:55:42 AM UTC+2, AK wrote:
> Użytkownik "M.M." <mmarszik@gmail.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

[toc] | [prev] | [next] | [standalone]

#29753

W dniu 2017-06-02 o 23:07, AK pisze:
> Użytkownik "M.M." <mmarszik@gmail.com> napisał:
> On Friday, June 2, 2017 at 9:07:46 PM UTC+2, AK wrote:
>> Użytkownik "M.M." <mmarszik@gmail.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++.


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. Więc takie porównanie 
jest bez sensu... .Net natomiast podobnie jak java mają swoje środowisko 
uruchomieniowe niezależne od systemu, co czasami pomaga, a czasami 
denerwuje. W zalezności od zastosowania.

-- 
http://kaczus.ppa.pl

[toc] | [prev] | [next] | [standalone]

#29754

Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.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).

> Więc takie porównanie jest bez sensu...

Otoz nie. Ma _gleboki_ praktyczny sens.
Ominiecie tego problemu w "wysokopoziomowym" C++
wymaga (ze tak to nazwe specjalistycznej "wiedzy" - cudzuslow
zamierzony bo to kolejny  syf/smiec w pamieci niz prawdziwa wiedza)
i zejscia na maksynalnie niski poziom - nawet linkera (czyli
"wysokopoziomowosc" C++ idzie sie zwyczajnie pasc.

AK

[toc] | [prev] | [next] | [standalone]

#29759

W dniu 2017-06-05 o 09:18, AK pisze:
> Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.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. 
Robienie z C++ coś na modłę javy, dla mnie też bez sensu, wszelkie 
zalety c++ idą się paść, już idą często ze względu na pewną 
nieprzewidywalność w stosunku do C.


>> Więc takie porównanie jest bez sensu...
> 
> Otoz nie. Ma _gleboki_ praktyczny sens.
> Ominiecie tego problemu w "wysokopoziomowym" C++
> wymaga (ze tak to nazwe specjalistycznej "wiedzy" - cudzuslow
> zamierzony bo to kolejny  syf/smiec w pamieci niz prawdziwa wiedza)
> i zejscia na maksynalnie niski poziom - nawet linkera (czyli
> "wysokopoziomowosc" C++ idzie sie zwyczajnie pasc.

Ale mi nie zależy na tym by C++ było lub nie wysoko czy niskopoziomowym 
językiem. natomiast porównanie było bez sensu, gdyż C++ ma byc przenośny 
na poziomie źródeł, a nie binariów.

-- 
http://kaczus.ppa.pl
http://kaczanowska.info

[toc] | [prev] | [next] | [standalone]

#29761

Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.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" <kaczus@poczta.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

[toc] | [prev] | [next] | [standalone]

#29763

W dniu 2017-06-05 o 11:19, AK pisze:
> 
> Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.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" <kaczus@poczta.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

[toc] | [prev] | [next] | [standalone]

#29765

Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.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

[toc] | [prev] | [next] | [standalone]

#29766

W dniu 2017-06-05 o 12:29, AK pisze:
> Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.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

[toc] | [prev] | [next] | [standalone]

#29769

Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.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-interface-or-abi/
https://stackoverflow.com/questions/2110151/using-templated-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/8b53ed27-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-export-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 

[toc] | [prev] | [next] | [standalone]

#29770

W dniu 2017-06-05 o 13:47, AK pisze:
> Użytkownik "Tomasz Kaczanowski" <kaczus@poczta.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

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | pl.comp.programming

csiph-web