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

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

Architektura aplikacji - powody wyłączania dll z exe

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

Contents

  Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-14 21:10 -0800
    Re: Architektura aplikacji - powody wyłączania dll z exe Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-11-15 08:01 +0100
      Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-15 00:21 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-11-15 09:44 +0100
    Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-15 06:11 -0800
      Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-18 02:38 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-20 03:57 -0800
      Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-19 05:02 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-19 05:11 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-19 23:08 -0800
      Re: Architektura aplikacji - powody wyłączania dll z exe michal@kleczek.org - 2017-11-19 09:26 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe michal@kleczek.org - 2017-11-19 09:28 -0800
    Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-16 19:57 +0100
      Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-17 01:29 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-17 17:28 +0100
          Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-20 04:42 -0800
            Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-20 08:26 -0800
              Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-21 22:52 -0800
            Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-20 22:53 +0100
              Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-20 14:57 -0800
              Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-21 04:35 -0800
                Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-21 08:17 -0800
                Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-21 22:21 +0100
                  Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-21 17:02 -0800
                  Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-22 06:33 -0800
                    Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-22 18:20 +0100
                      Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-22 18:56 +0100
                      Re: Architektura aplikacji - powody wyłączania dll z exe Maciej Sobczak <see.my.homepage@gmail.com> - 2017-11-23 02:55 -0800
                        Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-23 04:18 -0800
                        Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-23 13:52 -0800
                        Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-23 22:52 +0100
                Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-21 23:05 -0800
                  Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-22 09:45 -0800
                    Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-23 13:35 -0800
                  Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-23 04:26 -0800
                    Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-23 13:57 -0800
                  Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-23 09:10 -0800
                    Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-23 14:04 -0800
                    Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-11-27 09:57 +0100
                      Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-27 04:20 -0800
                        Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-11-30 01:16 +0100
                          Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-30 08:27 -0800
                            Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-01 01:22 +0100
                              Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-12-01 04:21 -0800
                                Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-12-01 07:42 -0800
                                Re: Architektura aplikacji - powody wyłączania dll z exe Roman Tyczka <noemail@because.no> - 2017-12-01 20:14 +0100
                                  Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-12-01 15:11 -0800
                                    Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-12-01 17:02 -0800
                                      Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-02 09:24 +0100
                                        Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-12-02 03:15 -0800
                                          Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-12-02 03:43 -0800
                                            Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-02 16:15 +0100
                                              Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-12-02 07:26 -0800
                                          Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-02 16:12 +0100
                                    Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-02 09:15 +0100
                                  Re: Architektura aplikacji - powody wyłączania dll z exe "AK" <nobody@nowhere.net> - 2017-12-02 08:59 +0100
      Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-17 06:23 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-17 17:35 +0100
          Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2017-11-17 09:11 -0800
            Re: Architektura aplikacji - powody wyłączania dll z exe Sebastian Biały <heby@poczta.onet.pl> - 2017-11-17 18:29 +0100
    Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-19 04:21 -0800
      Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-20 08:31 -0800
        Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-21 22:56 -0800
          Re: Architektura aplikacji - powody wyłączania dll z exe Mateusz Bogusz <mabakay@o2.pl> - 2017-11-22 21:09 +0100
            Re: Architektura aplikacji - powody wyłączania dll z exe "M.M." <mmarszik@gmail.com> - 2017-11-23 13:44 -0800
              Re: Architektura aplikacji - powody wyłączania dll z exe Mateusz Bogusz <mabakay@o2.pl> - 2017-11-29 22:09 +0100
      Re: Architektura aplikacji - powody wyłączania dll z exe fir <profesor.fir@gmail.com> - 2017-11-22 12:09 -0800
    Re: Architektura aplikacji - powody wyłączania dll z exe szykcech@gmail.com - 2018-09-12 10:55 -0700

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

#30971

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

> Wszystko "zalezy". Widzalem statyczne linkowane exe-ki, ktore  mialy w sobie np.
> z pol biblioteki, mimo, ze w kodzie uzyta byla jedna funkcja (wolna od zaleznosci).
>
> AK

> Jaka to była biblioteka i kompilator?

Np. QT i MSC
Np. Borland i VermontViews
itp..
itd...

PS: Znasz strukture lib-a i intelowskiego obj-ta?

AK

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

#30979

On Thursday, November 30, 2017 at 1:16:36 AM UTC+1, AK wrote:
> Użytkownik "M.M." <mmarszik@gmail.com> napisał:
> 
> > Wszystko "zalezy". Widzalem statyczne linkowane exe-ki, ktore  mialy w sobie np.
> > z pol biblioteki, mimo, ze w kodzie uzyta byla jedna funkcja (wolna od zaleznosci).
> >
> > AK
> 
> > Jaka to była biblioteka i kompilator?
> 
> Np. QT i MSC
> Np. Borland i VermontViews
> itp..
> itd...
Ok.



> PS: Znasz strukture lib-a i intelowskiego obj-ta?
Kiedyś wczytywałem się... w forma exe także, trochę zaczynałem 
rozumieć, ale już mi uleciało. Nie mam motywacji aby pogłębiać
tego typu wiedzę. Pytasz dlatego, żeby wiedzieć, czy
mam podstawy aby ustalić czego kompilator (bez względu na użyty
algorytm) nie może (bez ryzyka) odrzucić? Nie mam takich podstaw.
Pozdrawiam

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

#30982

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

> Pytasz dlatego, żeby wiedzieć, czy mam podstawy aby ustalić czego kompilator
> (bez względu na użyty algorytm) nie może (bez ryzyka) odrzucić? Nie mam takich podstaw.

Ok. No to po krótce.
Nie kompilator ale linker (kiedys byl to osobny program) m atu glownie "do czynienia".
Akurat na DOS/Windows format *.lib-a to po prostu zbior *.obj-tow.
obj to kompilat powstajacy z np. (jednego lub wielu) *.c
Ten kompilat to po prostu bytecode, ale nie scalony - czyli skladajacy sie z segmentow kodu
i danych i slownika symboli dla linkera (zmanglowane nazwy funkcji, zmiennych itp)
W obj-cie nie ma podzialu na funkcje. sa tylko bloki kodu i danych. "Standardowo" linker w ogole nie 
wie
nic o funkcjach. On tylko laczy porzez symbole  bloki kodu i danych w gotowy *.com czy *.exe
To powoduje ze gdy ktos w takim *.c umiesci 80% funcji to nawet jesli uzyje w kodzie docelowym
tylko jednej z nich (i to bez zaleznosci) to dolinkowany zostanie i tak caly kod (segment CODE)
w ktorym znajduje sie ta funkcja. Dlatego dobrze jest (i tak sie robi) tworzyc wiele obj-tow
nawet jesli funkcje z jednego sa od siebie neizalezne.
Tak bylo drzewiej (na DOS i WIndows).
Dzis jest lepiej bo i obj juz dawno porzestal byc surowy/standardowy i mozna wiele informacji do 
niego
dowalic (chocby symbole dla debuggera, demangling itp) i linkowanie na poziomie funkcji dzis ni4 
jest nowina/
Ale i tak to bardzo compiler-specific i wciaz dobrze jest stosowac zasade wielu neizaleznych 
obj-tow.
Tyle ze kiedyc obj-ty mozna bylo linkowac teoretycznie dowlonym linkerem (dobze o tym wiedza 
Clipperowcy
gdy stosowalismy Borlandowskiego szybkiego i prostego tlinka zamiast Clipperowskiego plinka), ale 
dzisiaj
linkery staly sie juz wlasciwie czescia kompiltatora z w/w powodow.

AK


i
Pozdrawiam

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

#30986

On Friday, December 1, 2017 at 1:23:11 AM UTC+1, AK wrote:
> Użytkownik "M.M." <mmarszik@gmail.com> napisał:
> 
> > Pytasz dlatego, żeby wiedzieć, czy mam podstawy aby ustalić czego kompilator
> > (bez względu na użyty algorytm) nie może (bez ryzyka) odrzucić? Nie mam takich podstaw.
> 
> Ok. No to po krótce.
> Nie kompilator ale linker (kiedys byl to osobny program) m atu glownie "do czynienia".
> Akurat na DOS/Windows format *.lib-a to po prostu zbior *.obj-tow.
> obj to kompilat powstajacy z np. (jednego lub wielu) *.c
> Ten kompilat to po prostu bytecode, ale nie scalony - czyli skladajacy sie z segmentow kodu
> i danych i slownika symboli dla linkera (zmanglowane nazwy funkcji, zmiennych itp)
> W obj-cie nie ma podzialu na funkcje. sa tylko bloki kodu i danych. "Standardowo" linker w ogole nie 
> wie
> nic o funkcjach. On tylko laczy porzez symbole  bloki kodu i danych w gotowy *.com czy *.exe
> To powoduje ze gdy ktos w takim *.c umiesci 80% funcji to nawet jesli uzyje w kodzie docelowym
> tylko jednej z nich (i to bez zaleznosci) to dolinkowany zostanie i tak caly kod (segment CODE)
> w ktorym znajduje sie ta funkcja. Dlatego dobrze jest (i tak sie robi) tworzyc wiele obj-tow
> nawet jesli funkcje z jednego sa od siebie neizalezne.

Chodź szczegółów nie znam, to ogólnie tak to sobie wyobrażałem i 
coś podobnego dawno temu czytałem. 


> Tak bylo drzewiej (na DOS i WIndows).
Czyli teraz się pozmieniało.

> Dzis jest lepiej bo i obj juz dawno porzestal byc surowy/standardowy i mozna wiele informacji do 
> niego
> dowalic (chocby symbole dla debuggera, demangling itp) i linkowanie na poziomie funkcji dzis ni4 
> jest nowina/
> Ale i tak to bardzo compiler-specific i wciaz dobrze jest stosowac zasade wielu neizaleznych 
> obj-tow.
> Tyle ze kiedyc obj-ty mozna bylo linkowac teoretycznie dowlonym linkerem (dobze o tym wiedza 
> Clipperowcy
> gdy stosowalismy Borlandowskiego szybkiego i prostego tlinka zamiast Clipperowskiego plinka), ale 
> dzisiaj
> linkery staly sie juz wlasciwie czescia kompiltatora z w/w powodow.

Rozumiem. Teraz niekoniecznie jest tak źle jak kiedyś, ale standardy
poszły do kosza. Dziękuję za wyjaśnienia. 

Niepokoi mnie tylko jedno. W językach takich  jak C, C++ , Pascal i w 
kilku innych, można zrobić:

var = foo()     // trudna do oszacowana wartość
var();          // wywołanie funkcji

Wiem że taka praktyka programistyczna jest bardzo zła, ale formalnie
poprawna. Jak więc linkier / kompilator może ustalić, że pewne funkcje
z libów można pominąć?

Pozdrawiam

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

#30988

W dniu piątek, 1 grudnia 2017 13:21:13 UTC+1 użytkownik M.M. napisał:
> On Friday, December 1, 2017 at 1:23:11 AM UTC+1, AK wrote:
> > Użytkownik "M.M." <mmarszik@gmail.com> napisał:
> > 
> > > Pytasz dlatego, żeby wiedzieć, czy mam podstawy aby ustalić czego kompilator
> > > (bez względu na użyty algorytm) nie może (bez ryzyka) odrzucić? Nie mam takich podstaw.
> > 
> > Ok. No to po krótce.
> > Nie kompilator ale linker (kiedys byl to osobny program) m atu glownie "do czynienia".
> > Akurat na DOS/Windows format *.lib-a to po prostu zbior *.obj-tow.
> > obj to kompilat powstajacy z np. (jednego lub wielu) *.c
> > Ten kompilat to po prostu bytecode, ale nie scalony - czyli skladajacy sie z segmentow kodu
> > i danych i slownika symboli dla linkera (zmanglowane nazwy funkcji, zmiennych itp)
> > W obj-cie nie ma podzialu na funkcje. sa tylko bloki kodu i danych. "Standardowo" linker w ogole nie 
> > wie
> > nic o funkcjach. On tylko laczy porzez symbole  bloki kodu i danych w gotowy *.com czy *.exe
> > To powoduje ze gdy ktos w takim *.c umiesci 80% funcji to nawet jesli uzyje w kodzie docelowym
> > tylko jednej z nich (i to bez zaleznosci) to dolinkowany zostanie i tak caly kod (segment CODE)
> > w ktorym znajduje sie ta funkcja. Dlatego dobrze jest (i tak sie robi) tworzyc wiele obj-tow
> > nawet jesli funkcje z jednego sa od siebie neizalezne.
> 
> Chodź szczegółów nie znam, to ogólnie tak to sobie wyobrażałem i 
> coś podobnego dawno temu czytałem. 
> 
> 
> > Tak bylo drzewiej (na DOS i WIndows).
> Czyli teraz się pozmieniało.
> 
> > Dzis jest lepiej bo i obj juz dawno porzestal byc surowy/standardowy i mozna wiele informacji do 
> > niego
> > dowalic (chocby symbole dla debuggera, demangling itp) i linkowanie na poziomie funkcji dzis ni4 
> > jest nowina/
> > Ale i tak to bardzo compiler-specific i wciaz dobrze jest stosowac zasade wielu neizaleznych 
> > obj-tow.
> > Tyle ze kiedyc obj-ty mozna bylo linkowac teoretycznie dowlonym linkerem (dobze o tym wiedza 
> > Clipperowcy
> > gdy stosowalismy Borlandowskiego szybkiego i prostego tlinka zamiast Clipperowskiego plinka), ale 
> > dzisiaj
> > linkery staly sie juz wlasciwie czescia kompiltatora z w/w powodow.
> 
> Rozumiem. Teraz niekoniecznie jest tak źle jak kiedyś, ale standardy
> poszły do kosza. Dziękuję za wyjaśnienia. 
> 
> Niepokoi mnie tylko jedno. W językach takich  jak C, C++ , Pascal i w 
> kilku innych, można zrobić:
> 
> var = foo()     // trudna do oszacowana wartość
> var();          // wywołanie funkcji
> 
> Wiem że taka praktyka programistyczna jest bardzo zła, ale formalnie
> poprawna. Jak więc linkier / kompilator może ustalić, że pewne funkcje
> z libów można pominąć?
> 
> Pozdrawiam

o ile pamietam (bo nigdy jakos sam nie generowalem libow) lib to archiwum (zestaw) plikow o/obj 

kazdy taki plik o ma swoje importy i exporty w postaci dwu tabel wiec
linker wie ktorych potrzebuje (bo wie ktore symbole potrzebuje importowac) a ktore sa mu dio niczego nie potrzebne - tymsamym 
to nie funkcje sie odrzuca tylko 
odrzuca sie na poziomie tych wewnetrznych plikow obj

trzebby oczywioscie doczytac bo to dosyc wazne (ale jak to zwykle troche nie mam sily)

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

#30989

On Fri, 1 Dec 2017 04:21:11 -0800 (PST), M.M. wrote:

> Niepokoi mnie tylko jedno. W językach takich  jak C, C++ , Pascal i w 
> kilku innych, można zrobić:
> 
> var = foo()     // trudna do oszacowana wartość
> var();          // wywołanie funkcji
> 
> Wiem że taka praktyka programistyczna jest bardzo zła, ale formalnie
> poprawna. Jak więc linkier / kompilator może ustalić, że pewne funkcje
> z libów można pominąć?

Przecież robiąc to przypisanie dajesz znać, że tego używasz, zatem zostaje
nieusunięte, co tu niejasnego?

-- 
pozdrawiam
Roman Tyczka

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

#30990

On Friday, December 1, 2017 at 8:14:21 PM UTC+1, Roman Tyczka wrote:
> On Fri, 1 Dec 2017 04:21:11 -0800 (PST), M.M. wrote:
> 
> > Niepokoi mnie tylko jedno. W językach takich  jak C, C++ , Pascal i w 
> > kilku innych, można zrobić:
> > 
> > var = foo()     // trudna do oszacowana wartość
> > var();          // wywołanie funkcji
> > 
> > Wiem że taka praktyka programistyczna jest bardzo zła, ale formalnie
> > poprawna. Jak więc linkier / kompilator może ustalić, że pewne funkcje
> > z libów można pominąć?
> 
> Przecież robiąc to przypisanie dajesz znać, że tego używasz, zatem zostaje
> nieusunięte, co tu niejasnego?
> 

Ściślej, kompilator dostaje informacje o nieprzewidywalnych wywołaniach w
momencie gdy jakaś zmienna jest rzutowana na typ wskaźnika na funkcję.
Jak wtedy kompilator powinien się zachować? Czy powinien wcielić absolutnie
całego liba? 

Pozdrawiam

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

#30991

W dniu sobota, 2 grudnia 2017 00:11:12 UTC+1 użytkownik M.M. napisał:
> On Friday, December 1, 2017 at 8:14:21 PM UTC+1, Roman Tyczka wrote:
> > On Fri, 1 Dec 2017 04:21:11 -0800 (PST), M.M. wrote:
> > 
> > > Niepokoi mnie tylko jedno. W językach takich  jak C, C++ , Pascal i w 
> > > kilku innych, można zrobić:
> > > 
> > > var = foo()     // trudna do oszacowana wartość
> > > var();          // wywołanie funkcji
> > > 
> > > Wiem że taka praktyka programistyczna jest bardzo zła, ale formalnie
> > > poprawna. Jak więc linkier / kompilator może ustalić, że pewne funkcje
> > > z libów można pominąć?
> > 
> > Przecież robiąc to przypisanie dajesz znać, że tego używasz, zatem zostaje
> > nieusunięte, co tu niejasnego?
> > 
> 
> Ściślej, kompil000000ator dostaje informacje o nieprzewidywalnych wywołaniach w
> momencie gdy jakaś zmienna jest rzutowana na typ wskaźnika na funkcję.
> Jak wtedy kompilator powinien się zachować? Czy powinien wcielić absolutnie
> całego liba? 
> 

widze ze ciezka niekumacja tu sie odwala (co jest troche smutne)

to co robi kompilator to poprostu buduje sekcje importow (ktora z tego co wiem nie jest niczym innym co lista stringow) z symboli ktore 
w zrodle sa oznaczone jako symbole
do importu

(z tego z kolei co wiem w zrodle c 
jako symbole do importu sa oznaczane te symbole ktore nie sa
w nim zdefiniowane) (tj w przypadku dllek trzeba ztcw jawnie naisac __declspec(dllimport) ale w wypadku
linlkowanie ststycznego systarczy 
z tcw jedynie zadeklarowac symbol
bez definicji (nie pamietam czy trzeba dodawac slowo extern ale oip chyba raczej nie)

jesli var bedzie zadeklarowane jako taki symbol do importu np

void var(int);
 
to linker zrobi z tego symbol do importu, przypisanie nie ma tu ztcw nic do rzeczy, z tego co kojarze takie przypisanie chyba raczej powinno wyrzicic blad bo to var chyba nie jest tak do konca zmienną
(jest ew adresem funkcji w pamieci
wiec niby mozna tam cos wpisac, wiec moze i powinno byc dozwolone choc i tak wywola segfault)

powtarzajac linker (wlasciwie 
powinien to byc kompilator ale 
ze wzgledu na to ze jak sie buduje sekcje importu symbol trzeba podpiac pod konkretna nazwe dllki w ktorej ma byc on szukany i taki kompilator musi poszukac w jakiej
dllce ten symbol moze byc wiec robi nieststy jakby za linker) bedzie importowal jedynie to co jest zadeklarowane jako symbole do importu

(przy okazji jest to doba ilustracja dlaczego czy tez na jakiej zasadzie "asembler" czytez 
"niskopoziomowa orientacja" przydaje sie by zrozumiec jasno
pewne rzeczy)

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

#30995

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

> widze ze ciezka niekumacja tu sie odwala (co jest troche smutne)

Mowisz o sobie ? Zgoda w 100% ! :)

> ale w wypadku linlkowanie ststycznego systarczy z tcw jedynie zadeklarowac symbol
> bez definicji (nie pamietam czy trzeba dodawac slowo extern ale oip chyba raczej nie)

Bzdura do kwadratu.
NIE wystarczy zadeklarowac (bo taka deklaracja to pustoslow dla kompilatora, ot kawalek tekstu)
Trzeba tot UZYC !! Jakkolwiek (nawet "pusto") ale UZYC.
Dousz sie nieopierzony palancie zanim zaczniesz krytykowac innych.

PS: Nie twierdze ze niektore kompillatory C sama deklaracje moga potraktowac jako
      uzycie, ale to jest _wylacznie_ ich specyficzna cecha i wcale nie gwarantuje niczego.

PS1: Prawdziwy problem zaczyna sie dopiero wtedy gdy niektore optymalizatory C/C++ juz na poziomie
        kompilacji "wycinaja" takie puste odwolania do funkcji (ogolnie: linkeroiwych symboli 
zewnetrznych) :)

AK

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

#30996

W dniu sobota, 2 grudnia 2017 09:24:32 UTC+1 użytkownik AK napisał:
> Użytkownik "fir" <profesor.fir@gmail.com> napisał:
> 
> > widze ze ciezka niekumacja tu sie odwala (co jest troche smutne)
> 
> Mowisz o sobie ? Zgoda w 100% ! :)
> 
> > ale w wypadku linlkowanie ststycznego systarczy z tcw jedynie zadeklarowac symbol
> > bez definicji (nie pamietam czy trzeba dodawac slowo extern ale oip chyba raczej nie)
> 
> Bzdura do kwadratu.
> NIE wystarczy zadeklarowac (bo taka deklaracja to pustoslow dla kompilatora, ot kawalek tekstu)
> Trzeba tot UZYC !! Jakkolwiek (nawet "pusto") ale UZYC.
> Dousz sie nieopierzony palancie zanim zaczniesz krytykowac innych.
> 
> PS: Nie twierdze ze niektore kompillatory C sama deklaracje moga potraktowac jako
>       uzycie, ale to jest _wylacznie_ ich specyficzna cecha i wcale nie gwarantuje niczego.
> 
> PS1: Prawdziwy problem zaczyna sie dopiero wtedy gdy niektore optymalizatory C/C++ juz na poziomie
>         kompilacji "wycinaja" takie puste odwolania do funkcji (ogolnie: linkeroiwych symboli 
> zewnetrznych) :)
> 
w trzec punktach

1.

od kolegi to moglbym sie tylko nauczyc jak robic cos w rodzaju publicznych pokazów nielimitowanego oglupialego dziadostwa 

2.

nie bardzo mnie to interesuje wiec
za to gdybym byl w formie moglbym
ze tak powiem zaczac uczyc jak walczyc/ opierac sie takiemu dziadostwu (w uoglniony filozoficznie oczywiscie 
sposob, bo wyslac kolega samego 
na planete dziadostwa to zaden problem, mam na mysli walke z tego typu dziadostwem w ogóle) - 

3.

problem w tym ze ostatnio nie mam formy na takie rzeczy (co jest oczywiscie smutne, traktuje to troche tak jakbym stracil częśc
jakichs waznych zdolnosci ) (a praktycznie sprowadza sie to do tego ze wogole nie che mi sie tu byc i temu dziadostwu sie nawet przygladac gdy mam mase o wile 
inteligentnieszych ludzi z ktorymi
moge porozmawiac na o wiele wyzszym
poziomie)

jakie wnioski z tego kolega wyciagnie to nie wiem - zakladam ze żadne 

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

#30997

W dniu sobota, 2 grudnia 2017 12:15:44 UTC+1 użytkownik fir napisał:
>  walke z tego typu dziadostwem w ogóle) - 

troche niprecyzyjny zwrot (ale ostatnio w erze mentalnej plytkosci dużo takich) - chodzi wlasnie o 'zanegowanie' oodbicie sie od takich plytkich limatow dziadostwa w (kiedys dobrze mi znane) glebsze rejony mysli

(jak to sie robi? pewnym sposobem jest chyba przyjmowanie negatywnej postawy wobec twierdzen, (ale o tym ew kiedy indziej)

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

#30999

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

> w (kiedys dobrze mi znane) glebsze rejony mysli

Glebsze rejony to ty niewatpliwie masz, ale na pewno nie mysli...

PS: Do meritum sie odnies betonie programistyczny

AK

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

#31000

W dniu sobota, 2 grudnia 2017 16:15:35 UTC+1 użytkownik AK napisał:
> Użytkownik "fir" <profesor.fir@gmail.com> napisał:
> 
> > w (kiedys dobrze mi znane) glebsze rejony mysli
> 
> Glebsze rejony to ty niewatpliwie masz, ale na pewno nie mysli...
> 
> PS: Do meritum sie odnies betonie programistyczny
> 
> AK

nie musialbym sie odnosic panie zdziadzialy buraku gdybys rozumial ze moja wypowiedz byla o czyms zupelnie innym i o symbolach do importu mówie tam tylko na tyle 
na ile jest po potrzebne - uchodzi to jednak twojej wieprzowej narzucanej grupi tępocie i w sumie bardzo dobrze

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

#30998

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

> w trzec punktach

.. i jak zwykle zero co do meritum.
Slowem: nie wprowadzaj ludzi w blad nieopierzony palancie !

AK

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

#30994

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

> Ściślej, kompilator dostaje informacje o nieprzewidywalnych wywołaniach w
> momencie gdy jakaś zmienna jest rzutowana na typ wskaźnika na funkcję.
> Jak wtedy kompilator powinien się zachować? Czy powinien wcielić absolutnie
> całego liba?

Nie. Kompilator (a raczej linker) nic nie wie (on wie tylko to co jest wprost) o
docelowych funkcjach wiec sam ich nie dolaczy/dolinkuje.
Musisz sam o to zadbac (np tworzac w kodzie "puste" odwolania).
Kiedys wystarczylo takie nie wprost uzywane funkcje po prostu umiescic w obj-cie
(bo dolinkowywany byl caly obj) ale pewniejszym (dzis i wtedy/drzewiej:) jest tworzenie
"pustych odwolan" chocby typu:

int main()
{
funkcja1;
funkcja2;
..
}

Tak jak wspomnialem wczesniej podobny problem jest przy templatach C++ gdy
tworzymy biblioteke w ktorej nie ma uzycia konkretnego templata, ale w "user kodzie"
bedzie (no bo po to tworzymy biblioteke:).
Wtedy w lib-ie tworzymy sztucznie inicjatory takich templatow aby w ogole
kompilator stworzyl kod dla tego templata i linker docelowo mial co dolaczac.
(jak to sie "uczenie"nazwywa ? instancjonowanie szablonow czy jakos tak?
Ayatollachowie C++ sie wypowiedza?:)

PS:  Dlatego jestem "goracym" zwolennikiem modulow jak w Py czy jarow jak w Javie
czy "assembles" w .NET.
Lezy toto sobie na dysku, a brane jest _tylko wtedy_ gdy trzeba a nie "na zapas" jak
w statycznym linkowaniu.
Bo to sa o wiele bardziej prawdziwe moduly niz cala zabawa w C/C++ (dll-ki to tez nie ideał)

AK

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

#30993

Użytkownik "Roman Tyczka" <noemail@because.no> napisał:

> Przecież robiąc to przypisanie dajesz znać, że tego używasz, zatem zostaje
> nieusunięte, co tu niejasnego?

Nie ma tak prosto :).
I Ty masz racje, ale i M.M ma/moze miec racje.

PS: Podobny problem jest z szablonami w C++.
      Trzeba dosc czesto sztucznie wymusic utworzenie ich instancji by linker/librarian mial co 
dolaczac.

AK

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

#30845

> Aby nie ładować wszystkiego na raz do pamięci. Przeciętna poważna 
> aplikacja może mieć sumę zajmowanego kodu w dll w granicach kilku GB.

To raczej można między bajki włożyć... Nie wiem jak pod Windows, ale taki Linux ładuje do pamięci tylko to co aktualnie jest potrzebne. Dlatego monitory uruchomionych aplikacji podają 2 wartości zajętości pamięci (zadeklarowany i rzeczywisty). Tak więc Linux nie ładuje do pamięci całych exe ani so. Nie widzę też przeszkód by Windows nie zachowywał się podobnie...

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

#30847

On 11/17/2017 3:23 PM, szykcech@gmail.com wrote:
>> Aby nie ładować wszystkiego na raz do pamięci. Przeciętna poważna
>> aplikacja może mieć sumę zajmowanego kodu w dll w granicach kilku GB.
> To raczej można między bajki włożyć... Nie wiem jak pod Windows, ale taki Linux ładuje do pamięci tylko to co aktualnie jest potrzebne. Dlatego monitory uruchomionych aplikacji podają 2 wartości zajętości pamięci (zadeklarowany i rzeczywisty). Tak więc Linux nie ładuje do pamięci całych exe ani so. Nie widzę też przeszkód by Windows nie zachowywał się podobnie...

To co opisujesz nie ma żadnego związku z linkowaniem statycznym, te same 
efekty uzyskuje się na ładowaniu dynamicznym.

Pozwole sobie zacytować prosto z "Modern C programming" [1]:

"Dynamic linking is now the default on computers running System V 
release 4 UNIX, and it should always be used. Static linking is now 
functionally obsolete, and should be allowed to rest in peace"

Niestety ludzie piszacy pojedncze pliki exe i nie mający kontaktu z 
duzym software czesto zapominają że duże aplikacje zachowują sie 
podobnie jak systemy operacyjne. I te stare słowa te sa nie tylko ważne 
w OS ale i w app.

[1] Polecam przeczytać jako humorystyczna pozycje, wiele się można 
dowiedzieć o tym dlaczego współczesne programowanie i OSy wygladają jak 
wyglądają.

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

#30848

> Pozwole sobie zacytować prosto z "Modern C programming" [1]:

> [1] Polecam przeczytać jako humorystyczna pozycje, wiele się można 
> dowiedzieć o tym dlaczego współczesne programowanie i OSy wygladają jak 
> wyglądają.

Nie podałeś autora. 
Poza tym: Czy "Modern C programming" czy "Modern C++ programming"?!?

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

#30849

On 11/17/2017 6:11 PM, szykcech@gmail.com wrote:
>> [1] Polecam przeczytać jako humorystyczna pozycje, wiele się można
>> dowiedzieć o tym dlaczego współczesne programowanie i OSy wygladają jak
>> wyglądają.
> Nie podałeś autora.
> Poza tym: Czy "Modern C programming" czy "Modern C++ programming"?!?

Co gorsza przekrecilem tytuł.

"Expert C Programming - deep C secrets" - Peter Van Der Linden.

http://ptgmedia.pearsoncmg.com/images/9780131774292/samplepages/0131774298.pdf

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

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

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

csiph-web