🚀 go-pugleaf

Dnia Sun, 25 Nov 2007 00:43:40 +0100, Marcin ?Qrczak? Kowalczyk skrobie:
> 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)

Powiedzmy.

> - rozkład pól w strukturach (nazwy pól, typy, ich kolejność)
>   i metod w klasach (w przypadku C++)

Nie. No co ty. Jak obsłużysz np. sytuację, gdy pole jest takiego typu, które
ma jakiś własny operator przypisania i robi różne dziwactwa? Co ci w takim
przypadku po znajomości delty pola?

Musisz jedynie znać metody i ich sygnatury. Metody powinny ci zaś zapewnić
dostęp. Musisz ewentualnie dodatkowo mieć jakieś "object factory", jeśli
chcesz, żeby z poziomu innego języka można było tworzyć obiekty takich klas.
Ale rozkład pól niech już pozostanie prywatną sprawą klasy - tyylko wyjątkowo
ewentualnie dostępną dla interfejsu w C++.

Przypominam zresztą na marginesie, że w Javie też nie masz dostępu do
informacji o delcie pola (tzn. inaczej - informacja ta jest teoretycznie
dostępna, wraz z nazwami pól i deskryptorami ich typów, tyle że z tej
informacji nie jesteś w stanie zrobić żadnego użytku). W kodzie metod używane
jest na żywca przesunięcie liczbowe względem początku obiektu. A prawa dostępu
do pól są rozwiązywane podczas kompilacji (co innego w przypadku metod). Jest
to sensowne, bo jeśli dobierasz się do obiektu w sposób statyczny, to
kompilator ci ewentualnie odrzuci kod, który jest niezgodny z prawem dostępu
do pola, a jeśli w sposób dynamiczny, to dostępu do pól i tak nie masz w
ogóle.

(Oczywiście osobna sprawa jest gdy masz kod JVM-owy w innym języku, niż Java.
Ja mam we wstępnych zamysłach C++ na JVM-a i tam to dopiero będzie się
działo!).

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

Moment, bo mam wrażenie, że kręcimy się w kółko.

Jeśli już podałeś Javę, jako przykład, to przypominam ci, że z pliku *.class
można otrzymać z powrotem DOKŁADNIE IDENTYCZNE ŹRÓDŁO danej klasy. No, z
dokładnością do optymalizacji (typu zwijanie String + String na StringBuffer)
oraz nazw zmiennych lokalnych (nie ma ich w ogóle, więc trzeba wygenerować).
Swoją drogą ja tak ostatnio odzyskiwałem kod w Javie, jak skasowałem sobie
przypadkiem źródła.

To m.in. oznacza, że w pliku *.class dostępne są te informacje, które w
przypadku C++ zawierają się również w pliku nagłówkowym, więc niewykluczone,
że sensowne stanie się niedługo wykombinowanie jakiejś metody na ZAPAKOWANIE
PLIKU NAGŁÓWKOWEGO (lub "zbazodanowanego") do pliku biblioteki dynamicznej.

Pytanie tylko, do czego potrzebujemy tych dodatkowych informacji.

Bo jeśli - powiedzmy - mamy SKĄDŚ dostępne te informacje i chcemy tylko
wywołać sobie jakąś funkcję/metodę - to nie ma problemu. Jeśli natomiast
chcemy sobie automatycznie wygenerować interfejs w innym języku do takiej
biblioteki (przypominam na marginesie, że wśród popularnych bibliotek, które
mają dowiązania w wielu językach, żadna nie posiada generowanego automatycznie
interfejsu), to oczywiście potrzebujemy pliku nagłównowego, ale nie rozumiem,
co w tym dziwnego.

> - treść funkcji inline

Bzdura - do funkcji inline z biblioteki nie mają dostępu aplikacje kompilowane
osobno. Jeśli biblioteka UDOSTĘPNIA określoną funkcję, jako samo *.so, to ma
jej wersję outline.

> - definicje makr

I jak przepraszam przetłumaczysz treść takiego makra na, powiedzmy, Pythona?

> - treść szablonów (w przypadku C++)

Praktycznie wszystko to, co opisałeś wyżej, to są narzędzia służące TYLKO C++.
Jeśli zostały użyte, to znaczy że nikt nie przewidywał dostępu z żadnej innej
perspektywy, niż C++ (do tego celu często pisane są dowiązania do 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ę.

Albo generować automatycznie. Nie jest to żadna wielka filozofia, skoro od lat
tak właśnie robi SWIG.



-- 
//  _    ___         Michal "Sektor" Malecki <sektor(whirl)kis.p.lodz.pl>
\\ L_ |/ `|  /^\ ,()                         <ethouris(O)gmail.com>
// \_ |\  \/ \_/ /\ C++ bez cholesterolu: http://www.intercon.pl/~sektor/cbx
"Java is answer for a question that has never been stated"