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