🚀 go-pugleaf

Dnia 24-11-2007, So o godzinie 23:18 +0100, Seweryn Habdank-Wojewódzki
pisze:

> >> Qrczak ale, tak konkretnie, jaki masz realny target, dla takiego ficzeru.
> > 
> > http://www.jython.org/docs/usejava.html
> 
> Ale to jest mniej więcej izomorficzne z IDE. Czym to się istotnie różni od
> tego, że masz jakiś header.

Nie rozumiem - jaki header?

Od możliwych rozwiązań w C++ różni się tym, że autor Jythona nie musiał
opisywać interfejsu każdej biblioteki Javy z osobna, a użytkownik
Jythona nie musi kompilować dodatkowego kodu, żeby używać dowolnej
biblioteki Javy z poziomu Jythona.

> Poza tym Jython jest napisany w Javie, więc nie widzę kłopotu, aby ładował
> sobie klasy Javy jako swoje.

Gdyby był napisany w C++, to nie mógłby ładować sobie bibliotek C++ jako
swoich bez wykonania pracy o rząd wielkości trudniejszej (musiałby być
zintegrowany z dużą częścią kompilatora C++).

Pomijam już to, że nawet znając interfejs biblioteki C++ na poziomie
języka C++ o wiele trudniej jest zrobić z niej sensowny interfejs
w innym języku niż w przypadku Javy albo Pythona. Na przykład interfejs
na poziomie C++ nie zawiera informacji o odpowiedzialności za czas
życia obiektów (a jest to potrzebne, żeby używać biblioteki C++),
nie rozróżnia wskaźnika na pojedynczy element od wskaźnika na tablicę
ani nie mówi o wyjątkach, które dana funkcja może rzucić (a jest to
potrzebne, żeby użyć tej funkcji i przetłumaczyć dowolny idący z niej
wyjątek na inny język, w przeciwieństwie do Javy, kiedy to wystarczy
złapać Throwable i rozpoznać typ w czasie wykonania).

> Ciekawe czy _Jython_ potrafi wołać klasy C#?

Nie potrafi. Ale mógłby potrafić, gdyby komuś się chciało włożyć w to
pracę i to zaimplementować. Najpierw trzeba by zorganizować współpracę
Javy i C#; nie wiem, czy ktoś się tym zajmował.

Mój Kogut może używać bibliotek CPythona i Perla. W przypadku Pythona
wyszło to bardzo wygodne, z Perlem jest gorzej, ale nie ze względu
na dynamizm czy introspekcję, tylko z powodu całkiem nieprzystających
do siebie systemów typów (np. Perl nie rozróżnia liczb i stringów).

> A czy to samo mógłbyś zrobić w C dla CPythona? Np. w jakimś module zaszyty
> dlopenik i parserek tego co wypluwa objdump z pliku .so? Teoretycznie .so
> jest samowystarczalny. On sam nie musi mieć headera, header potrzebują
> developerzy do kompilacji, aby kompilator wiedział, że coś jest w so.

Pliki nagłówkowe zawierają istotne informacje, których nie ma ani
w *.so, ani często nawet w standardowej dokumentacji danej biblioteki,
a są potrzebne, żeby dało się tej biblioteki używać:

- wartości stałych typów izomorficznych z liczbami całkowitymi
  (typów wyliczeniowych, używanych też czasem jako zbiory bitów)
- rozkład pól w strukturach (nazwy pól, typy, ich kolejność)
  i metod w klasach (w przypadku C++)
- typy argumentów funkcji (w przypadku C; w przypadku C++ można
  próbować to odmanglowywać), typy wyników funkcji (w przypadku C
  i C++) i typy globalnych zmiennych
- treść funkcji inline
- definicje makr
- treść szablonów (w przypadku C++)

Można próbować ręcznie kopiować potrzebne informacje z plików
nagłówkowych, ale efekt jest po pierwsze pracochłonny i błędogenny,
a po drugie wrażliwy na binarnie niekompatybilne zmiany w oryginalnej
bibliotece - i to w najgorszy możliwy sposób, czyli z niekontrolowaną
kaszaną w przypadku rozjechania się.

Niektóre implementacje różnych języków dorobiły się narzędzi
ułatwiających wyciąganie informacji z plików nagłówkowych C.
Metoda jest zazwyczaj jedna z dwojga: własny parser podzbioru C
albo generowanie programu w C i uruchamianie go przed kompilacją
kodu łączącego biblioteki, który swoją drogą poza najprostszymi
bibliotekami też trzeba ręcznie przygotować. Jestem pierwotnym
autorem takiego narzędzia do Haskella pod nazwą hsc2hs. Wcześniej
był c2hs kogoś innego. Implementacje Lispa miewają swoje. Jest
też SWIG, którego założeniem jest możliwość generowania od razu
łączenia do różnych języków z jednego opisu biblioteki C (nie
wgłębiałem się w jego szczegóły), a w najprostszych przypadkach
mogą mu wystarczyć same pliki nagłówkowe.

Łączenie z C++ jest jeszcze trudniejsze niż łączenie z C z powodu
bardziej skomplikowanego zbioru konstrukcji, na jakie możemy się
natknąć i które trzeba obsłużyć. Jeśli rantajm danego języka jest
w C, to tak czy siak trzeba przejść przez C. Np. do Koguta zrobiłem
wiązanie do kompresji LZMA, która jest zaimplementowana w C++.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/