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-14 23:57:25
    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 13/02/2013 09:29, Maciej Sobczak wrote:
    > W dniu środa, 13 lutego 2013 06:31:15 UTC+1 użytkownik Andrzej Jarzabek napisał:
    >
    >> Większe problemy masz
    >> takie:
    >>
    >> * używasz dwóch konstrukcji językowych (struct/class lub hashtable) do
    >> tego samego celu
    >
    > To nie jest ten sam cel - obiekty istniejące na granicy modułów (podobnie na
    > granicy z DB) to inne cele i w tych miejscach jestem gotowy na inne konwencje.

    To, że cośtam jest na granicy to jest szczegół implementacyjny. W
    funkcji liczącej bezwistność flafulca obchodzi cię czym jest flafulec,
    jakie ma właściwości potrzebne do wyliczenia jego bezwistności i jak się
    z tych właściwości bezwistność wylicza, a nie czy obiekt reprezentujący
    flafulca przyszedł z przeglądarki, bazy danych, czy został wygenerowany
    przez kod C++ zlinkowany z funkcją liczącą bezwistność.

    >>>> Nie jest. Prosty przykład - w C++ nawet niewielka zmiana definicji
    >>>> typu danych między biblioteką a programem z niej korzystającym
    >>>> może spowodować spektakularne wylecenie wszystkiego w powietrze.
    >>
    >>> Na moim komputerze kompilator pokaże, gdzie nastąpiła niezgodność.
    >>
    >> Naprawdę? Jak nowa wersja execa spróbuje załadować starą DLL-kę?
    >
    > Nie wierzę, że sobie takiego gola strzelasz.
    > DLL-ki nie są częścią C++ a ich wsparcie to trick ze strony systemu
    > operacyjnego. Jeżeli wychodzisz poza język po to, żeby nie korzystać
    > z jego zalet, to nie miej pretensji, że coś nie działa.

    DLL-ki to tylko trick, który ułatwia życie. Częścią definicji języka
    (jego modelu kompilacji) są object files. 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, tylko że dodatkowo jest mniej wygodne.

    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.

    > DLL-ki to właśnie metoda na dynamiczność w programie. Czy sugerujesz,
    > że języki statyczne są do dupy, bo jak się je omija i używa dynamicznych
    > tricków, to nie działają dobrze?
    > No, nie działają.

    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".

    >> W języku statycznie typowanym możesz mieć nawet:
    >> TreeSet s = new TreeSet();
    >> s.add(new CannotCompare());
    >> [...]
    >
    > To nie jest język statycznie typowany, nawet jeśli tak ma napisane na pudełku.

    Niby dlaczego? Biorąc pod uwagę całą historię języków statycznie
    typowanych, i w szczególności języków statycznie typowanych ze wsparciem
    OO w popularnym rozumieniu (czyli wywodzący się z Simuli - klasy,
    dziedziczenie), to jest to możliwe chyba w każdym z nich - z całą
    pewnością zarówno w C++ jak i w Object Pascalu - pomijając nawet typ
    void* i jego odpowiednik w Pascalu, to wystarczy zdefiniować klasę
    bazową Object czy inne Comparable i już masz dokładnie ten sam problem.

    >>> W tym przykładzie Java zachowuje się dokładnie jak skryptowy język
    >>> dynamiczny.
    >>
    >> int i=3;
    >> i=5;
    >>
    >> W tym momencie C++ zachowuje się dokładnie jak skryptowy język
    >> dynamiczny. Zatem jest językiem dynamicznym.
    >
    > Nie. Nie mógłbyś zrobić i="x"; Zatem słaby argument.

    Tak samo dobry jak twój, przecież w twoim programie też nie można zrobić
    TreeSet<CannotCompare> s = "x";

    >> Dodatkowo od dynamicznego języka wymagałbym
    >
    > Ale ja nie twierdzę, że Java ma wszystkie cechy takich języków.
    > Natomiast od języka statycznego wymagam, żeby kod, który nie może się
    > poprawnie wykonać ze względu na *nieistnienie jakiejś funkcji*, która
    > na pewno będzie zawołana, się nie kompilował. Java tego wymagania nie spełnia.

    No to proszę bardzo, przykład w C++:

    struct A
    {
    };

    struct B
    {
    void foo();
    };

    bar(A& b)
    {
    B& b = dynamic_cast<B&> a;
    b.foo();
    }

    int main()
    {
    A a;
    bar(a);
    }

    Skompiluje się? 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.

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: