> 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"?!?

do góry

On 11/17/2017 6:11 PM, s...@g...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

do góry

On Wednesday, November 15, 2017 at 3:11:20 PM UTC+1, Maciej Sobczak wrote:
> Zamieszam trochę: od dłuższego czasu jestem zwolennikiem linkowania
> statycznego wszystkiego co nie jest base-systemem. Życie mi się uprościło.

Kilka pytań:

Jaki rozmiar mają Twoje pliki wynikowe?

Ile czasu czekasz na kompilacje/zlinkowanie po zmianie jednej
linijki w pliku cpp/h ? Czy linkiery potrafią wykorzystać wiele rdzeni albo
GPU? Mnie ten problem na tyle bolał, że napisałem swój generator
plików make.


Z jakich bibliotek korzystasz? Czy masz łatwo dostępne prekompilowane
wersje do wkompilowywania statycznego? Jeśli nie masz, ile czasu
prekompilowałeś sam?


Jak rozwiązujesz problem dopasowania kodu do systemu? Bo w przypadku
dll po prostu ładuje się inną bibliotekę.


Czy w pracy zespołowej przydzielenie osobnym programistom/pod-zespołom
wykonanie osobnych plików dll/pluginów nie przyspieszałoby i nie
upraszczałoby realizacji całego projektu?


Pozdrawiam

do góry

W dniu środa, 15 listopada 2017 06:10:23 UTC+1 użytkownik s...@g...com napisał:
> Witam
> W wielu "dużych", "profesjonalnych" i "popularnych" programach obserwuję zjawisko
wyłączania z exe całego kodu aplikacji.
> Moje pytanie brzmi: Dlaczego wyłącza się dll z exe?
>
> Moje domniemania:
> 1. Żeby używać w innych aplikacjach. Tylko tu pojawia się takie pytanie: Czemu cały
exe jest przerzucany do dll?
> 2. Żeby używać w innych aplikacjach jako obiektu COM.
> 3. Żeby łatwiej testować (pisać programy exe testujące dll-kę zamiast mieszać kod
roboczy z testowym).
>
> A może są inne powody? Proszę potwierdzić moje domniemania lub je zweryfikować.
>
> z góry dzięki
> Szyk Cech

1)

z dll mozna wyexportowac funkcje, (z exe albo nie mozna albo tez mozna ale niktorzy i
tak tego nie chcą robic (w tej chwili nie pamietam czy sie da))
- co prawda nie jestem pewien czy takie exportowanie z exe to dobry pomysl ale byc
moze niektprzy chcą
lub muszą to robic (?)
(ogolnie architektura wydaje sie prostsza i latwiejsza gdy miedzy dllakami importy
ida tylko w jedną strone ale nie ejestem w stanie powiedziec czy czasem nie ejst
zrobic w dwie, tj czy robienie w dwie strony jest zawsze bledem)

2)
dllki mozna dzilic miedzy programami, na przyklad jesli dane fonta wrzuci sie do
dllki a jest on uzywany przez 117 programow to w pamieci bedzie on obecny tylko raz,
gdyby zas kazdy z tych programow czytal go z jakiegos pliku .bin
klasyczna metodą to por obiloby sie 117 oddzielnych kopii (co prawda
to daloby sie obejsc chyba przez m-mapowanie plikow itd (mozna by sie zastanowic
ktory z tych sposobow
dll czy mmap bylby lepszy /ogolniejszy)

(podbnie jak wyzej nie jestem jednak pewien czy exekow tez nie mozna dzilic miedzy
procesami (instancjami) oraz czy o to moze tu chodzic)

jeslibym jednak mial cos podejrzewac o powod to te dwa punkty (ciut bardziej pierwszy
niz drugi ale drugi tez byc moze moze byc prawdopodobny jesli ktos pisze na chacie
nie jeden a kilka programow robiacych podobne rzeczy)

3) trzeci powod tez jest prawdopodobny, komus moze nie bardzo zalezec czy kompilowac
jako exe czy dll i robi dll nawet wtedy gdy moglby robic exe

do góry

W dniu środa, 15 listopada 2017 15:11:20 UTC+1 użytkownik Maciej Sobczak napisał:
> > W wielu "dużych", "profesjonalnych" i "popularnych" programach obserwuję zjawisko
wyłączania z exe całego kodu aplikacji.
> > Moje pytanie brzmi: Dlaczego wyłącza się dll z exe?
>
> Zamieszam trochę: od dłuższego czasu jestem zwolennikiem linkowania statycznego
wszystkiego co nie jest base-systemem. Życie mi się uprościło.
>
> Dopuszczam DLL-ki tam, gdzie elementy programu mogą być pozyskiwane niezależnie od
głównego programu i ten ficzer jest istotną częścią filozofii używania danego
programu (np. pluginy).
>

ja odwrotnie, kompilowanie ststyczne to dla mnie za duzo roboty

bo o ile pamietam (nie jestem pewien czy dobrze pamietam ale chyba tak) aby statyczny
linker dzialal 'wybiórczo' nie wystarczy zlinkowac duzego pojedynczego pliku.o
(powiedzmy 5 MB) - jesli uzywamy tylko jednej prostej funkcji z tego obiektu i tak
statyczny linker zlinkuje 5 MB -
aby dzialal wybiórczo tworca tej
liby musialby kompilowac ja do wielu skladowych .o i potem pakowac ja w jedną
zbiorczą libe .lib
(tak mi sie przynajmniej wydaje bo co ciekawe nigdy o tym wiecej nie czytalem i nigdy
jakos specjalnie tego nie uzywalem itd) tak ze to jest ok (dodatkowo np pozwala
kompilowac rozne podkawalki z roznymi opcjami kompilacji) ale wymaga zauwazalnej
ilosci dodatkowej roboty a dla mnie dodatkowa robota jest zwykle denerwujaca (ta
robota moglaby byc
byc moze mniejsza gdyby toole robily troche wiecej z automatu itp, tak naprawde mozna
tez zauwazyc ze dynamiczne linkowanie
tez mogloby byc zrobione tak by dzialac wybiórczo acz to by co nieco skomplikowalo
sprawy)

dla mnie linkowanie dllek jest ok
tyle ze nalezy moze jedynie pamietac by te dllki mialy rozsądne
rozmiary (rozsądna jak na dzis to dla mnie chyba do 10 MB na jedną)
oraz by dependencje miedzy nimi byly jak najmniejsze (tj by nie bylo ich duzo i jak
juz sa by mialy w swoim secie jak najmniej dependencji (te dependencje miedzy dllkami
mozna zliczajac zliczajac kreseczki importow na grafie miedzy dllkami, (mowie o
importach calej dllki nie pszczegolnych symboli)
np jak ktos mialby 10 dllek z ktorych kazda importowalaby kazda inną to w sumie zdaje
sie tych dependencji byloby 90 - za duzo,
u mnie w moich projektach mam na
przyklad zaleznosc/import do green.fire.dll ktora z kolei ma importy do 7 systemowych
dllek (kernel32.dll gdi32.dll msvcrt.dll psapi.dll user32.dll winmm.dll ws2_32.dll)
sam exe moze tez siegac do niektorych bezposrednio (akurat moj klient irca siega
bezposrednio do kernel32 (i do msvcrt.dll choc to jest zrozumiela) na 12 funkcji
(dotyczacych critcal section, tls, exit process, get masage adress itp, i tego ciagle
do konca troche nie lapie szczerze mowiac, czy to gcc wkompilowuje te 12 funkci jako
normalne calle w startupie mojego kodu czy tez moze tworzy sobie takie importy tak
troszke jakby na wyrost?) (wiem przynajmniej jedno, jak sam zasembluje sobie swoim
asemblerem swoj plik exe to moge miec eleganckie zero importow mimo ze program dziala
(i pisze na konsole przez msvcrt.printf - hmm - w takim razie to tez jest dziwne,
moze moj exe oszukuje plugin do total commandera bo importy dzialają ale sie nie
pokazują)

do góry

W dniu niedziela, 19 listopada 2017 14:02:54 UTC+1 użytkownik fir napisał:
> W dniu środa, 15 listopada 2017 15:11:20 UTC+1 użytkownik Maciej Sobczak napisał:
> > > W wielu "dużych", "profesjonalnych" i "popularnych" programach obserwuję
zjawisko wyłączania z exe całego kodu aplikacji.
> > > Moje pytanie brzmi: Dlaczego wyłącza się dll z exe?
> >
> > Zamieszam trochę: od dłuższego czasu jestem zwolennikiem linkowania statycznego
wszystkiego co nie jest base-systemem. Życie mi się uprościło.
> >
> > Dopuszczam DLL-ki tam, gdzie elementy programu mogą być pozyskiwane niezależnie
od głównego programu i ten ficzer jest istotną częścią filozofii używania danego
programu (np. pluginy).
> >
>
> ja odwrotnie, kompilowanie ststyczne to dla mnie za duzo roboty
>
> bo o ile pamietam (nie jestem pewien czy dobrze pamietam ale chyba tak) aby
statyczny linker dzialal 'wybiórczo' nie wystarczy zlinkowac duzego pojedynczego
pliku.o (powiedzmy 5 MB) - jesli uzywamy tylko jednej prostej funkcji z tego obiektu
i tak statyczny linker zlinkuje 5 MB -
> aby dzialal wybiórczo tworca tej
> liby musialby kompilowac ja do wielu skladowych .o i potem pakowac ja w jedną
zbiorczą libe .lib
> (tak mi sie przynajmniej wydaje bo co ciekawe nigdy o tym wiecej nie czytalem i
nigdy jakos specjalnie tego nie uzywalem itd) tak ze to jest ok (dodatkowo np pozwala
kompilowac rozne podkawalki z roznymi opcjami kompilacji) ale wymaga zauwazalnej
ilosci dodatkowej roboty a dla mnie dodatkowa robota jest zwykle denerwujaca (ta
robota moglaby byc
> byc moze mniejsza gdyby toole robily troche wiecej z automatu itp, tak naprawde
mozna tez zauwazyc ze dynamiczne linkowanie
> tez mogloby byc zrobione tak by dzialac wybiórczo acz to by co nieco skomplikowalo
sprawy)
>
> dla mnie linkowanie dllek jest ok
> tyle ze nalezy moze jedynie pamietac by te dllki mialy rozsądne
> rozmiary (rozsądna jak na dzis to dla mnie chyba do 10 MB na jedną)
> oraz by dependencje miedzy nimi byly jak najmniejsze (tj by nie bylo ich duzo i jak
juz sa by mialy w swoim secie jak najmniej dependencji (te dependencje miedzy dllkami
mozna zliczajac zliczajac kreseczki importow na grafie miedzy dllkami, (mowie o
importach calej dllki nie pszczegolnych symboli)
> np jak ktos mialby 10 dllek z ktorych kazda importowalaby kazda inną to w sumie
zdaje sie tych dependencji byloby 90 - za duzo,
> u mnie w moich projektach mam na
> przyklad zaleznosc/import do green.fire.dll ktora z kolei ma importy do 7
systemowych dllek (kernel32.dll gdi32.dll msvcrt.dll psapi.dll user32.dll winmm.dll
ws2_32.dll) sam exe moze tez siegac do niektorych bezposrednio (akurat moj klient
irca siega bezposrednio do kernel32 (i do msvcrt.dll choc to jest zrozumiela) na 12
funkcji (dotyczacych critcal section, tls, exit process, get masage adress itp, i
tego ciagle do konca troche nie lapie szczerze mowiac, czy to gcc wkompilowuje te 12
funkci jako normalne calle w startupie mojego kodu czy tez moze tworzy sobie takie
importy tak troszke jakby na wyrost?) (wiem przynajmniej jedno, jak sam zasembluje
sobie swoim asemblerem swoj plik exe to moge miec eleganckie zero importow mimo ze
program dziala (i pisze na konsole przez msvcrt.printf - hmm - w takim razie to tez
jest dziwne, moze moj exe oszukuje plugin do total commandera bo importy dzialają ale
sie nie pokazują)

wiem tez z doswiadczenia (z moim wlasnym asemblerem ) ze odnoscnika do kernel32.dll
program tak naprawde nie potrzebuje: niektorzy wywolują exit process na koniec
programu ale zwykle ret (aloi nawet program zlozony wylacznie z ret (0xc3)) tez
dziala (i to komicznie bo taki program przy uruchomieniu tylko blinka czy tez ew
wywoluje jakby 'no reaction' ;c tak jak zreszta chyba powinno byc)

do góry

On Wednesday, November 15, 2017 at 3:11:20 PM UTC+1, Maciej Sobczak wrote:
> > W wielu "dużych", "profesjonalnych" i "popularnych" programach obserwuję zjawisko
wyłączania z exe całego kodu aplikacji.
> > Moje pytanie brzmi: Dlaczego wyłącza się dll z exe?
>
> Zamieszam trochę: od dłuższego czasu jestem zwolennikiem linkowania statycznego
wszystkiego co nie jest base-systemem. Życie mi się uprościło.
>

Eee tam. Staromodny jestes. Trzeba tworzyc obrazy Dockera!

--
Michal

do góry

On Sunday, November 19, 2017 at 6:26:06 PM UTC+1, m...@k...org wrote:
> On Wednesday, November 15, 2017 at 3:11:20 PM UTC+1, Maciej Sobczak wrote:
> > > W wielu "dużych", "profesjonalnych" i "popularnych" programach obserwuję
zjawisko wyłączania z exe całego kodu aplikacji.
> > > Moje pytanie brzmi: Dlaczego wyłącza się dll z exe?
> >
> > Zamieszam trochę: od dłuższego czasu jestem zwolennikiem linkowania statycznego
wszystkiego co nie jest base-systemem. Życie mi się uprościło.
> >
>
> Eee tam. Staromodny jestes. Trzeba tworzyc obrazy Dockera!
>

Aha - zapomnialem.
Dllki nalezy koniecznie przerobic na mikrousługi.

--
Michal

do góry

On Sunday, November 19, 2017 at 2:02:54 PM UTC+1, fir wrote:
> ja odwrotnie, kompilowanie ststyczne to dla mnie za duzo roboty

Wszystko zależy od okoliczności. Jeśli aplikacja korzysta z kilku
nie za dużych bibliotek 'poza systemowych', a poza tym z systemu, to
skompilowanie statyczne faktycznie wszystko upraszcza - jeden
plik copy-paste i działa. Gorzej, gdy trzeba zlinkować pól giga -
nie wiem czy to w ogóle jest możliwe w rozsądnym czasie.


> bo o ile pamietam (nie jestem pewien czy dobrze pamietam ale chyba tak) aby
> statyczny linker dzialal 'wybiórczo'

Kiedyś czytałem że to jest w ogóle niemożliwe w przypadku języków c/c++.
Uzasadnienia autor nie podawał - ja uwierzyłem.


> nie wystarczy zlinkowac duzego pojedynczego pliku.o (powiedzmy 5 MB) - jesli
uzywamy tylko jednej prostej funkcji z tego obiektu i tak statyczny linker zlinkuje 5
MB -
> aby dzialal wybiórczo tworca tej
> liby musialby kompilowac ja do wielu skladowych .o i potem pakowac ja w jedną
zbiorczą libe .lib
Tak, twórca musiałby dostosować liba do linkowania statycznego, ale to i
tak na nic, jeśli jedna funkcja wywołuje drugą, itd.


> (tak mi sie przynajmniej wydaje bo co ciekawe nigdy o tym wiecej nie czytalem i
nigdy jakos specjalnie tego nie uzywalem itd) tak ze to jest ok (dodatkowo np pozwala
kompilowac rozne podkawalki z roznymi opcjami kompilacji) ale wymaga zauwazalnej
ilosci dodatkowej roboty a dla mnie dodatkowa robota jest zwykle denerwujaca (ta
robota moglaby byc
> byc moze mniejsza gdyby toole robily troche wiecej z automatu

Pracowałem na kilku bibliotekach w visual studio i wszystko działo się z
automatu, tylko wybierałem czy statycznie czy dynamicznie.


> itp, tak naprawde mozna tez zauwazyc ze dynamiczne linkowanie
> tez mogloby byc zrobione tak by dzialac wybiórczo acz to by co nieco skomplikowalo
sprawy)

Musiałby być kod źródłowy i podpowiedzi kompilatora który element kodu
zależy od którego, bo po samym call nie wiem czy kompilator w ogóle
może wywnioskować.


> dla mnie linkowanie dllek jest ok
> tyle ze nalezy moze jedynie pamietac by te dllki mialy rozsądne
> rozmiary (rozsądna jak na dzis to dla mnie chyba do 10 MB na jedną)
> oraz by dependencje miedzy nimi byly jak najmniejsze (tj by nie bylo ich duzo i jak
juz sa by mialy w swoim secie jak najmniej dependencji (te dependencje miedzy dllkami
mozna zliczajac zliczajac kreseczki importow na grafie miedzy dllkami, (mowie o
importach calej dllki nie pszczegolnych symboli)
> np jak ktos mialby 10 dllek z ktorych kazda importowalaby kazda inną to w sumie
zdaje sie tych dependencji byloby 90 - za duzo,

A co ze statycznymi zmiennymi? Jeśli lib ma działać 'od zera' to przynajmniej
jego dane trzeba zaimportować. By trzeba dane statyczne podmieniać przed
wywoływaniem metody z innego dll... nie wiem jak to jest w praktyce, ale
coś mi się wydaje, że po protu ładuje się liby jak są potrzebne i nie
ma że za dużo.


> u mnie w moich projektach mam na
> przyklad zaleznosc/import do green.fire.dll ktora z kolei ma importy do 7
systemowych dllek (kernel32.dll gdi32.dll msvcrt.dll psapi.dll user32.dll winmm.dll
ws2_32.dll) sam exe moze tez siegac do niektorych bezposrednio (akurat moj klient
irca siega bezposrednio do kernel32 (i do msvcrt.dll choc to jest zrozumiela) na 12
funkcji (dotyczacych critcal section, tls, exit process, get masage adress itp, i
tego ciagle do konca troche nie lapie szczerze mowiac, czy to gcc wkompilowuje te 12
funkci jako normalne calle w startupie mojego kodu czy tez moze tworzy sobie takie
importy tak troszke jakby na wyrost?) (wiem przynajmniej jedno, jak sam zasembluje
sobie swoim asemblerem swoj plik exe to moge miec eleganckie zero importow mimo ze
program dziala (i pisze na konsole przez msvcrt.printf - hmm - w takim razie to tez
jest dziwne, moze moj exe oszukuje plugin do total commandera bo importy dzialają ale
sie nie pokazują)

Nie rozumiem, to już jakieś Twoje bardzo specyficzne (co nie znaczy że
złe) rozwiązanie.

Pozdrawiam

do góry

> Kilka pytań:
>
> Jaki rozmiar mają Twoje pliki wynikowe?

Relatywnie[*] nieduży, do kilku MB.

[*] Relatywnie, bo w relacji do danych, których mogę mieć dowolnie dużo.

> Ile czasu czekasz na kompilacje/zlinkowanie po zmianie jednej
> linijki w pliku cpp/h ?

Kilka(naście) sekund.

> Czy linkiery potrafią wykorzystać wiele rdzeni

Linker nie musi. Natomiat jest sens kompilować równolegle, służy do tego opcja -j w
make'u (i świetnie się sprawdza).

> Mnie ten problem na tyle bolał, że napisałem swój generator
> plików make.

Nie miałem takiej potrzeby.

> Z jakich bibliotek korzystasz?

Różnych!

> Czy masz łatwo dostępne prekompilowane
> wersje do wkompilowywania statycznego? Jeśli nie masz, ile czasu
> prekompilowałeś sam?

Skoro robię coś tylko raz, to nie mierzę, ile to trwa.

> Jak rozwiązujesz problem dopasowania kodu do systemu?

Co to znaczy?

> Bo w przypadku
> dll po prostu ładuje się inną bibliotekę.

A w przypadku linkowania statycznego po prostu linkuje się inną bibliotekę.

> Czy w pracy zespołowej przydzielenie osobnym programistom/pod-zespołom
> wykonanie osobnych plików dll/pluginów nie przyspieszałoby i nie
> upraszczałoby realizacji całego projektu?

A w czym to miałoby być prostsze? Efektem wykonania zadania jest nowy kod a nie plik
wykonywalny. Sposób linkowania jest zupełnie drugorzędny - i w chwili zlecania
takiego zadania może nawet nie być jeszcze znany (czyli: nie zdecydowałem jeszcze,
jak to będę linkował, ale napisz mi funkcję do liczenia czegośtam).
Zauważ, że gdybyśmy mówili o językach skryptowych (np. Python), to w ogóle ta kwestia
nie miałaby znaczenia przy zlecaniu zadania. W C++ też nie ma potrzeby tej kwesti na
takim etapie adresować. Dlatego sposób linkowania nie wpływa (tzn. nie widzę
potrzeby, żeby wpływał) na organizację pracy zespołowej.

--
Maciej Sobczak * http://www.inspirel.com

do góry