Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał:
> On 4/1/2017 7:48 PM, AK wrote:

> Nie mów "doucz się". Nie masz pojęcia o wiedzy kogokolwiek na podstawie paru
linijek.

Po 30 latach "siedzenia" w C/C++ wystarczy mi kilka linijek/slow do
oceny czyichs kompetencji. Zapewniam :)

>> Zarowno w samym C jak i w laczeniu go (czystego C) z C++
>> (czy innymi jezykami programowania).
>
> Serio? To skad te kłopoty kilka postów wyżej o podkresleniach? Czyżby dlatego że
ktoś probował
> hackować bibliotekę nie przeznaczoną do C++?

Jesli jakis programista nie potrafi sobie poradzic z podkresleniami w externalach C
to lepiej niech przekresli swoje "programistyczne" dokonania i zajmie sie rymarstwem.
_KAZDA_ biblioteka w C da sie wykorzystac w C++ i to bez znaczenia czy
*lib czy nie dll.

>> PS: Zreszta to jest technika ktora zecydownie preferuje niz mixowanie
>> kodu w C z kodem C++ w jednym przebiegu kompilacji/w jednym lib-ie
>> (nawet jesli mam pelny dostep do zrodel).
>
> Jak się ma pelny dostęp do źródeł to nie da się wytlumaczyć tych kłopotów inaczej
jak
> psychiatrycznie.

Pachniesz mi przedszkolem programistycznym.
Tak wlasnie powstaje bajzel w sofcie gdzie kazdy sobie lokalnie
skompiluje/statycznjie zlinkuje jakas biblioteke i pozniej jakakolwiek zmiana
w niej skutkuje potrzeba rekompilacji zrodel i u kazdego (a co jesli ktos bedzie na
L4:)?
zamiast zwyczajnie skorzystac z jedenj slusznej boiblioteki a w przypadku
neizmieniana
interface nawet po porstupodmienc dllke/so.
Jesli w dakszym ciagu nie rozumiesz dlaczego (ze nie wspomne latwosci z jaka
biblioteka dll/so w C moze byc wykorzystana w innych jezykach priogramowania),
to raczej Tobie przydalby sie psychatra,

>> Dlatego takie mixowanie interkompilatorowe C++ robi sie
>> np.wlasnie za posrednictwem C a w C++ robi sie lekkie owijki
>> obiektowe (same *.h) (to niestety pracochlonne, ale to nie moja wina
>> ze C++ "tak ma"), albo za posrednictwem dll/so.
>
> A, czyli hackerstwo.

Napisanie prostego inlineowego wrappera to hankertswo?
Hehe.
Zwykle takie rzeczy robi sie o wile lepiej/latwiej/pewniej przez
*.dll/*so

>
>> PS: Natomiast "niezdefiniowany" to _jest_ dokladny opis.
>
> Tak, oczywiście. "Nie wiadomo jak wygląda krowa" jest niezwykle precyzyjnym opisem
krowy. Moving
> on.

Ale owszem.
Wtedy trzeba dzialac "per compiler" - jak np w przyoadku manglingu.
O UB w raportach C/C++ nie slyszales ?


>>> No wreszcie.
>> Co "no wreszcie"?
>
> Dostrzegasz hackerstwo.
>
>> Jakie jest niebezpieczenstwo w tym ze chcemy sie dobrac
>> do np. symbolu w DLLce (a wiec ustandarysowanej systemowo
>> biblioteki) ktorego mangling jest "nieznany" (czylli nazwa w DLLce jest
>> niewiadoma) ?
>
> A ABI jest wiadome skoro takiego detalu jak mangling nie znamy?

Co ma ABI wspolnego z manglingiem ?
Jesli ABI jest wspolne (a jest) to moza miec rozne manglingi (od roznych
kompilatorow C) i spokojnie da sie to wszystko bezpiecznie pozenic.

> A unwinding stosu jest kompatybilny?

A nie?

> A sposob instancjacji templates jest znany? Wiadomo jak się robia funkcjie inline?

A co mnie to obchodzi co sie dzieje w srodku dll-ki jesli mam pewne/dobrze
zdefiniowane
jej API publiczne i zachowuje pewne oczywiste zasady tyuczace bibliotek dzielonych
i programownai w srodowisku wielokompilatorowym (np ze ta sama dll-ka powinna
obslugiwac i zwalnic zasoby przez siebie przydzielone/utworzone . Np pamiec,
otwierane pliki
itp)?

> Wiadomo co się stanie jak trafimy ponownie na ten sam symbol przy linkowaniu? Etc.

W "moich czasach" take cos bylo zawsze traktowane jako blad.
Do dzisaj zawsze staram sie miec mam wlaczona opcje traktowani tego jako bledu
a nie (zwykle przez mlodych) ignorowanego ostrzezenia.
No ale to abc przecie, a nie zadne hackerstwo :)

>> Jelsi znalibysmy ta nazwe to spokojnie mozlinbysmy takigo
>> symbolu/funkcji uzyc
>> (gdyz wolanie z dll-ki jest systempowo usystematyzowane - czylio ponad
>> kompilatorowe/jezykowe)?
>
> Serio jest ustandaryzowane? No no. To się developerzy Delphi zdziwią po co im te
wszystkie
> _fastcall i _stdcall. Wychodzi że po nic. Biedacy.

No jelsi ktos nie chce standardowo tylko specyficzne dla swego env.
to wiadomo ze moze korzystac tylko lokalnie, ale przeciez zawsze jest mozliwosc
"otwarcia" sie na swiat :)

> A .so jest ustandaryzowane? Sugeruje dla sportu zerknąć co to za dziwne SYSV
pokazuje mc kiedy sie
> zrobi F3 na pliku .so. I dlaczego czasem tam pisza Linux. Moża też zerknąc co to
jest arm-[e]abi i
> na przykład jakieś ciekawostki jak thumb mieszany z arm w jednym .so.

Blele ble o wszytskim czyli klasyczne meiszanko i sciema :).

>> Problemm polega tylko na tymze my tej nazwy nie znamy.
>> Trzeba ja wiec poznac i w tym celu nalezy zmanglowac nazwa C++wa
>> i uzyc tej zmanglowanej np w dynamicznym pobraniu adresu z dll-ki
>> (GetProcAddress()/dlsym()).
>
> Aha. Dziękujemy kapitanie Obvious.

A tak. To jest zupelnie obvious:)

>> Jedyny problem jest tym ze mangling jest per-compiler-specyfic
>
> No przeciez o tym mowa od poczatku. Ja nawet niegrzecznie zauważę że jest równiez
version-specyfic
> co było swego czasu bardzo bolesne w egozytycznych kompiltorach uC bo niedzielni
hackerzy w
> embedded nie raz sobie zęby wybili po upgrade.

No cos.. Jelsi kompiler sam sie nie wspiera to nic na to nie poradze :)
/z tym tez sobie mozna poradzic - robiac wrapping ze starego mnglingu na nowy/.


>
>> i dlatego
>
> Hack on my mark in 1 ...
>
>> 1.trzeba wiedziec jakim kompilatorem dll-ka jest uskuteczniona
>
> 2...
>
>> 2. uzyc mangkera z tego wlasnie kompilatora.
>
> 3...
>
>> Gdy DLL-a jest w czystym ten nazwa (bez wzledu na kompilator C
>> ktorym jest tworzona) jest _zawsze_ zgodny z nazwa w zrodle
>> (a w przypadku obj/lib-ow: _ + nazwa_w_zrodle_C)
>> wiec problemow 1. i 2. w C zwyczjnie nie ma.
>
> Fail.

Co fail?
>
>> Tymczasem to nie zaden hacker ale zwykly niedouczony palant :(.
>> Tymczasem mozna prosto i latwo i zgodnie ze standardami.
>> Trzeba "tylko" wiedziec co to jest *.obj, *.lib, *.dll/*.so i co tak
>> naprawde
>
> C++ nic nie mówi co to jest .so i .dll

Ale OS mowi. I to bardziej szzczegolowo niz kompilatory
Kazdy kompilator musi sie do tegi dostosowac (bo inaczej
nic byz niczym nie wspolpracowalo) a nie odwrotnie.

> a ludzie piszacy kod jednoczesnie na 5 róznych platform mają
> w nosie hackowanie każdej z nich osobno.

Mangling jest (poza pomijalnymi wyjatkami) per-compiler
a nie per-system. Tych kompilatorow C++ nie ma za duzo
(raptem 4-6 na wszytskie platformy) wiec jest to mniejszy
problem niz w przypadku per-os.

>
>> PS: Nie moge "wyjsc z podziwu" jak Wy mlodzi dzis piszecie w C/C++
>> nie znajac tak podstawowych systemowych rzeczy :(
>
> Ponieważ jak każdy bardzo stary programista jestes już sterowany lokalną ideologią
i widzisz tylko
> swoje urojenia. Na przykład takie urojenie że ktoś nie ma pojęcia jak to działa
mimo że wie
> wystarczająco dokładnie jak to działa.

Potwierdzam. Nie masz _zielonego_ pojecia ani i *.obj/*.o ani
kwestiach linkowania, a juz szczegolnie nie masz zielonego pojecia o *.dll/*.so.

Jestes typowym niedoukiem co to tylko potrafi byc glosny/szpanuje na
fachowca a nie zna podstawowych rzeczy systemowych zwiazanych z C/C++
i stad wszedzie widzi koniecznosc "hanckowania" miast normalnego
(bezpiecznego) poruszania sie w temacie.

AK