🚀 go-pugleaf

Witam

Marcin ?Qrczak? Kowalczyk wrote:

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

Rozumiem.

Zatem postawię częściowo otwarty problem.

To znaczy jest coś w linuxie na co nikt nie umie mi odpowiedzieć, 
ale wydaje mi się, że jest to częściowa odpowiedź na to zadanie.

Mam w swoich programach biblioteki .so w czyściutkim C++.
Żadnych dziwadeł z C, żadnej funkcji trampolinowej, żadnej fabryki.

Przykładowe fragmenty dump z .so

000036bc g     O .bss   00000004              communication::time_stamp::QUIT
000036b4 g     O .bss   00000004              communication::time_stamp::OBJECT_NAME
000036a0 g     O .bss   00000004              communication::controler::QUEUE_LENGTH
000036ac g     O .bss   00000004              communication::road::OBJECT_NAME

00007cf0 g     F .text  0000004c              YAMI::Agent::Agent(int, YAMI::Policies const&)
00007f00 g     F .text  0000003b              YAMI::Message::getStatus() const
00005cc0 g     F .text  00000011              YAMI::Policies::setMTUser(bool)
000086d0 g     F .text  00000042              YAMI::ParamSet::getStringBuffer(int) const
000066b0 g     F .text  000000e6              YAMI::RunTimeException::RunTimeException(int)
00006cf0 g     F .text  0000004a              YAMI::Semaphore::tryAcquire()
000068d0 g     F .text  00000040              YAMI::InternalException::InternalException()
00006090 g     F .text  00000021              YAMI::sleep(int)
00008890 g     F .text  00000042              YAMI::ParamSet::getBinarySize(int) const

Teraz program w C++ odpalam i on elegancko ładuje zarówno libstdc++, jak 
i moją bibliotekę. W C++ oczywiście muszę mieć header, żeby kompilator 
wiedział co zawołać.

Teraz mam pytanie jaka funkcja systemowa to wykonuje i czemu ten .so
umie być obsługiwany jak C++, a nie jak C? 
To nie jest dlopen w wersji udostępnianej dla ludu, chociażby dlatego, że tamten 
(tajemniczy) cxxdlopen umie rozmanglować nazwy, wie co to jest klasa w C++ itd.

Zatem mając tamten cxxdlopen, mogę ładować pure C++ pliki .so.
Natomiast .so daje możliwość listowania zawartości.

>> 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++).

Tego nie wiem. Moje C++ .so nie wymagają cudów mają tylko header, 
ale nie wiem czy nie wystarczy wołanie czegoś po nazwie.
 
> 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++),

Co to jest czas życia obiektów? W kontekście czegoś takiego? 

Przecież w specyfikacji CPythona jest wołem napisane, że ten kto alokuje ten
zwalnia, python nie potrafi zwalniać pamięci po {C}malloc.

A w J masz trywiał bo Jython wozi się na tej samej maszynie wirtualnej 
co sam moduł Javy, mają wspólne GC.

> nie rozróżnia wskaźnika na pojedynczy element od wskaźnika na tablicę

Temat omawiany z Sebastianem.

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

Rozumiem. I kto tłumaczy te wyjątki? Maszyna wie że JRantajWyjątek 
ma przenieść na PyWywaliłSięSystem?

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

No to samo można powiedzieć o C++ i C. Jeśli będzie w pełni zrobione
C++ <-> C to będzie C++ wspólpracował z CPythonem. 
A tak potrzeba CxxPythona, jakby był CxxPython oraz cxxdlopen jawnie podany,
to można próbować robić cuda na kiju. I tak bardzo dużo można zrobić za
pomocą boost::python.

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

Jeśli może używać CPythona to jest tylko zasługa tego co jest zawarte 
w plikach .so włączanych co CPythona. Jak byś użwał cxxdlopen to widziałbyć 
C++ również.

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

Tak.

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

A po co?

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

W C++ .so używając cxxdlopen nie musisz tego robić.

> - treść funkcji inline

One przecież mają być inline, a to znaczy, że są łączone 
w czasie kompilacji. Jak potrzebujesz mieć wersje nie inline, 
to np. przyjmujesz konwencję

inline int inline_moja_inline_funkcja(int)
int moja_inline_funkcja (int)

Nie zabieraj C++ tego co pomaga w optymalizacji kodu, bo funkcje 
inline to jest potężne narzędzie, którego inne języki nie chcą mieć.

> - definicje makr

Tak. A czy J ma w sobie zaszyty swój kompilator?

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

Ja Cię przepraszam, ale są używane tylko w kompilacji. 
Jeszcze raz napiszę J nie ma wsobie swojego kompilatora również.
A szablony skonkretyzowane są dostępne.

Jeszcze Ci wspomnę, że dzięki np. GNU export map potrafię cały 
bałagan w .so pochować. I wystawić tylko to co ma user faktycznie 
widzieć. Nawet narzędzia hakerów nie potrafią wiele pokombinować,
jak export map jest użyty. A to pozwala na bardzo zgrabne 
dzielenie interfejsu na interfejs usera i ten którego user ma nie widzieć.

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

SWIG: C -> C# C-> Py, C -> ...

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

To się tyczy np. C -> C#.
 
> Łą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ć.

Przykro mi że faftastyczne języki lepsze nie qmają co C++ potrafi robić.
I mówię to seria, bo ostatnio chciałem włączyć kod C++ do C# 
i widzę ciemność i to po stronie C#.

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

Bo koguta napisałeś w C. Jakbyś napisał w C++, to mógłbyś wołać C++ .so,
bez C -- ja tak mam w swoim sofcie.

Pozdrawiam.
 

-- 
|\/\/|   Seweryn Habdank-Wojewódzki
 \/\/