On 16 Sty, 22:56, Maciej Sobczak <s...@g...com> wrote:
> > Chcesz
> > przesłać wskaźniki do obiektów z C++ to od strony Tcla jest to string.
>
> No i super. Przynajmniej mam pełną kontrolę nad tym, jak ten string
> wygląda. Świetnie się to sprawdza przy debugowaniu!
> Python tak nie pomaga.

Jako, że mam z tym styczność na co dzień, taka pomoc jest raczej
mizerna. Mogę sobie wyobrazić dodatkową funkcję CHandleToString. I w
czym to jest gorsze od jawnej postaci?. BTW. u nas wskaźniki C++
kodowane są w postaci adres obiektu + adres na id typu, a nie wskaźnik
+ najczęściej długa nazwa typu, ponieważ tak jest wydajniej. Więc i
tak wymusza to dodatkową funkcję informacji o obiekcie.

> > Jak chcesz kontrolę typów na tym wskaźnikami, to trzeba to zakodować w
> > stringu.
>
> Bo Python to robi automatycznie...

Zagalopowałem się trochę. Chodziło mi o to, że dzięki osobnemu
traktowaniu typów, można przekazać więcej informacji, np. można
zaalokować nowy obiekt, który oprócz wskaźnika ma dodatkowo
informacje. W Tclu nie ma takiej możliwości ponieważ zaalokowany
obiekt musi być jawnie zwolniony ( co jest upierdliwe ).

> Wracając do prawdziwej złośliwości: okazało się, że Pythona napisali
> geniusze, którzy myśleli, że wskaźniki są zawsze 32-bitowe:
>
> https://www.google.com/search?q=Python+ctypes+64+bug

Ale co mnie to interesuje jako użytkownika docelowego? Ja zacząłem
używać Pythona między innymi ze względu na dużą ilość bibliotek, co
jest jego największą zaletą.

> Niemniej, zgodzę się, że Tcl to język dla ludzi, który lubią Tcla.
> Dlatego nie będę się upierał, że jest on uniwersalny i że może być
> uniwersalnie lubiany. Ale żaden język taki nie jest, więc traktuję go
> jako ciekawą część ekosystemu.

Tak, to jest język typu kochaj albo rzuć. Nie istnieją stany
pośrednie :).

Pozdrawiam
KK