eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programmingJakie typowanie jest najlepsze i dlaczego statyczne?Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
  • Data: 2013-02-15 12:29:02
    Temat: Re: Jakie typowanie jest najlepsze i dlaczego statyczne?
    Od: Andrzej Jarzabek <a...@g...com> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    On Feb 15, 9:37 am, Maciej Sobczak <s...@g...com> wrote:
    > W dniu czwartek, 14 lutego 2013 23:57:25 UTC+1 użytkownik Andrzej Jarzabek napisał:
    >
    > > DLL-ki to tylko trick, który ułatwia życie. Częścią definicji języka
    > > (jego modelu kompilacji) są object files.
    >
    > Nie są. Np. C++ coś tam wspomina, że translation units mogą być translowane osobno
    > i potem zlinkowane, ale kompletnie niczego nie określa. Można sobie wyobrazić
    > implementację, która używa w tym celu bazy danych.

    Nadal będziesz miał ten sam problem - jeśli twoja baza danych
    przechowuje skompilowane jednostki (instantiation units w terminologii
    standardu) pochodzące z różnych translacji z różnymi źródłowymi
    definicjami typów danych, to nie ma żadnej gwarancji zadziałania.

    Poza tym w rzeczywistości decydując o wyborze języka do tworzenia
    oprogramowania sensownie kierować się implementacjami istniejącymi, a
    nie tymi, które można sobie wyobrazić. Chyba że działanie programu,
    który tworzysz, też masz zamiar sobie tylko wyobrażać.

    > > Rozwiązanie, w którym ja
    > > dostarczam program korzystający z funkcji w postaci zestawu object
    > > files, a kto inny dostarcza tych funkcji w postaci object files, a
    > > klient sobie to wszystko linkuje statycznie linkerem przed uruchomieniem
    > > ma dokładnie ten sam problem,
    >
    > Nie musi mieć i np. w Adzie nie ma. To, że ma w C++ wynika z badziewności
    > typowego zestawu narzędzi, ale nie z języka.

    Badziewnośc realnie dostępnych narzędzi to bardzo dobry powód, żeby w
    praktyce wybrać inny język, który ma mniej badziewne narzędzia. Na
    Adzie się nie znam, ale czy nie jest przypadkiem tak, że do wielu
    aplikacji biznesowych byłaby słabym wyborem ze względu na brak
    bibliotek i narzędzi właśnie?

    > DLL już całkowicie jest poza językiem. Jak Ci nie działa, to naprawiaj to tam,
    > gdzie jest zepsute, czyli nie w języku.

    Ale jeśli przez to, że wybiorę inny język może nie być zepsute, to po
    co w ogóle mam naprawiać?

    > > Problem jest taki, że coupling między skompilowanymi object files jest
    > > tight - muszą być skompilowanymi z tymi samymi definicjami typów, bo
    > > inaczej nie ma żadnych gwarancji na to, że będzie działało.
    >
    > I bardzo dobrze. To jest zaleta statycznego systemu.

    Że się program wywali? Faktycznie, rewelacyjna zaleta.

    > > No więc sam masz przykład na to, że w pewnych realnych sytuacjach
    > > spotykanych w dużych systemach taki np. C++ po prostu nie działa dobrze,
    > > bo musisz "wychodzić poza język" i "używać dynamicznych tricków".
    >
    > Jeżeli dynamiczne techniki nie działają a statyczne działają, to jaki z tego
    > wniosek w kontekście tytułu tego wątku?

    Skoro programy komputerowe często nie działają, to może zamiast
    komputerów lepiej używać znacznie bardziej niezawodnych pięściaków?

    > > Niby dlaczego? Biorąc pod uwagę całą historię języków statycznie
    > > typowanych,
    >
    > OK, w takim razie nie dogadaliśmy się. Ty piszesz o tym, że nawet
    > języki statyczne dają narzędzia do strzelania sobie w stopę i to wiadomo.
    > Ja piszę o tym, że przynajmniej wiadomo, jaki jest zakres użycia tych
    [...]

    Akurat rozmawiamy o tym, czy Java jest językiem statycznie czy
    dynamicznie typowanym. Umówmy sie może w takim razie, że konstrukcja
    pozwalająca na niebezpieczne rzutowania nie dyskwalifikuje języka z
    bycia statycznie typowanym.

    > > No to proszę bardzo, przykład w C++:
    > >      B& b = dynamic_cast<B&> a;
    > > Skompiluje się?
    >
    > Tak. Jeżeli dynamiczne ficzery prowadzą do programów, które nie działają,
    > to est to argument przeciwko dynamicznym ficzerom.

    Każdy język, który jest Turing-complete ma dynamiczne ficzery, które
    nie działają.

    > > Jeśli uważasz, że dynamic_cast jest dynamicznym trickiem
    > > i dlatego działa źle, to zamień sobie na static_cast i zastanów się, czy
    > > na pewno będzie lepiej.
    >
    > UB. Język wyraźnie mówi, że nie wolno tego static cast zrobić.
    > Kompilator nie nadąża, więc może język jest za mało statyczny?

    Jak napisałem, chodziło o sytuację, kiedy B dziedziczy po A. To jest
    trywialny przypadek, więc może jakiś model checker by to wyłapał, ale
    w ogólnym przypadku kompilator nie ma podstawy do stwierdzenia, czy za
    referencją na A kryje się obiekt typu B, więc możnaby temu zapobiec
    jedynie zabraniając downcastów w ogóle.

    Zarówno Java, jak i C++, jak i wiele innych języków powszechnie
    uważanych za statycznie typowane i obiektowe (czy powiedzmy
    wspierające obiektowość) mają taką instytucję jak niebezpieczny
    downcast.

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: