eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingArchitektura aplikacji - powody wyłączania dll z exeRe: Architektura aplikacji - powody wyłączania dll z exe
  • X-Received: by 10.31.94.198 with SMTP id s189mr396637vkb.9.1512142925025; Fri, 01 Dec
    2017 07:42:05 -0800 (PST)
    X-Received: by 10.31.94.198 with SMTP id s189mr396637vkb.9.1512142925025; Fri, 01 Dec
    2017 07:42:05 -0800 (PST)
    Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.nask.pl!news.nask.org.pl!news.unit
    0.net!peer03.am4!peer.am4.highwinds-media.com!peer03.iad!feed-me.highwinds-medi
    a.com!news.highwinds-media.com!m31no46628qtf.0!news-out.google.com!t48ni159qtc.
    1!nntp.google.com!m31no46624qtf.0!postnews.google.com!glegroupsg2000goo.googleg
    roups.com!not-for-mail
    Newsgroups: pl.comp.programming
    Date: Fri, 1 Dec 2017 07:42:04 -0800 (PST)
    In-Reply-To: <c...@g...com>
    Complaints-To: g...@g...com
    Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=5.172.255.251;
    posting-account=Sb6m8goAAABbWsBL7gouk3bfLsuxwMgN
    NNTP-Posting-Host: 5.172.255.251
    References: <0...@g...com>
    <oukn36$l7m$1@node2.news.atman.pl>
    <4...@g...com>
    <oun2nc$r4t$1@node2.news.atman.pl>
    <8...@g...com>
    <ouviso$22u$1@node1.news.atman.pl>
    <9...@g...com>
    <1...@g...com>
    <e...@g...com>
    <ovgk2k$kc2$1@gioia.aioe.org>
    <5...@g...com>
    <ovnil0$ubp$1@gioia.aioe.org>
    <4...@g...com>
    <ovq7de$f0m$1@node2.news.atman.pl>
    <c...@g...com>
    User-Agent: G2/1.0
    MIME-Version: 1.0
    Message-ID: <a...@g...com>
    Subject: Re: Architektura aplikacji - powody wyłączania dll z exe
    From: fir <p...@g...com>
    Injection-Date: Fri, 01 Dec 2017 15:42:05 +0000
    Content-Type: text/plain; charset="UTF-8"
    Content-Transfer-Encoding: quoted-printable
    X-Received-Bytes: 5470
    X-Received-Body-CRC: 2113388064
    Xref: news-archive.icm.edu.pl pl.comp.programming:211812
    [ ukryj nagłówki ]

    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)

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: