W dniu 23.11.2017 o 22:44, M.M. pisze:
>> i albo napisał
>> sztywny most albo ma się mini aplikację wewnątrz
>> docelowej, a nie komponent.
>
> Jakie są różnice pomiędzy mini aplikacją a komponentem?

Np. takie że mini aplikacja ma swoje własne źródło konfiguracji (np.
osobny plik) zamiast za pomocą DI zapytać o własną sekcję.

Albo implementuje własny sposób logowania i logi z całej aplikacji lecą
w jedno miejsce, a tych z pseudo komponentu gdzieś indziej.

--
Pozdrawiam,
Mateusz Bogusz

do góry

Użytkownik "M.M." <m...@g...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

do góry

On Thursday, November 30, 2017 at 1:16:36 AM UTC+1, AK wrote:
> Użytkownik "M.M." <m...@g...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

do góry

Użytkownik "M.M." <m...@g...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

do góry

On Friday, December 1, 2017 at 1:23:11 AM UTC+1, AK wrote:
> Użytkownik "M.M." <m...@g...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

do góry

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." <m...@g...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)

do góry

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

do góry

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

do góry

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)

do góry

Użytkownik "Roman Tyczka" <n...@b...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

do góry