eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingArchitektura aplikacji - powody wyłączania dll z exeRe: Architektura aplikacji - powody wyłączania dll z exe
  • Data: 2017-12-01 13:21:11
    Temat: Re: Architektura aplikacji - powody wyłączania dll z exe
    Od: "M.M." <m...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    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

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: