On 4/1/2017 11:44 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 :)

Przykro mi że tak płytko oceniasz ludzi.

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

Wiadomo. Tylko po ch ?

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

Jak widzisz twoje kilka linijek lub słów do oceny kompetencji okazuje
się być picem na wodę.

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

Ktoś idzie na L4 i pada firma. Gratuluję.

Ktoś dostarcza skompilowane elementy na produkcję. Gratuluję.

Ciekawe, że zazwyczaj "programisci z dużym stażem" nigdy nie słyszeli o
takich wynalazkach jak np. ciągla intergracja. I zawsze ten sam argument
bez sensu: bo trzeba kompilować. Ojej. To lepiej faktycznie nie.

> zamiast zwyczajnie skorzystac z jedenj slusznej boiblioteki a w
> przypadku neizmieniana
> interface nawet po porstupodmienc dllke/so.

Znam taką jedną firmę. Mieli problem bo chcieli zmienić dllki i
interfejsy ale nie kompilować pozostałych bo szkoda bitów i cykli.
Wymyslili więc fantastyczny mechanizm "statycznych interfejsów" który
polegał że do każdej funkcji przekazywano zamiast listy argumentów jeden
argument: mapę "nazwa argumentu<->wartość". Oczywiscie wartości
zserializowane. Czy to nie wspaniałe osiągnięcie? W ciagu roku ze
stabilnego jezyka silnie typowanego zrobiono pistolet na wodę. Bo każda
nadmierna kompilacja dllki u sasiada jest szkodliwa i lewacka!

No dobra, to troche odbiega od tematu, ale dalej blisko tematu hackowania.

Mówisz że wystarczy podmienić dll jak się interfejsy nie zmieniły? No i
co z tego? Wszyscy to wiedza. Choć ... jesli pisza coś większego niż
hello worldy to może być dośc interesująco, szczególnie w okolicy templates.

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

Oczywiscie że przydałby się każdemu. Odbiegłeś jednak daleko od problemu
o którym jest ten nedzny trolling.

Ktoś ma problem z podkresleniami. I ktoś ma z tym problem mimo dostepu
do źrodeł. Nie, nie zmieniam zdania. To się nadaje do psychiatry.

Wymiana dllki na inna o identycznym interfejsie nie ma sie nijak do tego
problemu, ale doceniam twoje trudy lania wody w celu zastraszenia
przeciwnika.

Na marginesie: możesz pokazac z jaką latwością mozna uzyć dllki
napisanej w C w takiej Javie? Spodziewam się max 1 linijki overheat
skoro to taka łatwość.

Tak wiem jak to się robi w Javie. Nie, to nie jest łatwe, choć
oczywiscie można pokazać na przykładzie void foo(void){} że prawie łatwe.

>> A, czyli hackerstwo.
> Napisanie prostego inlineowego wrappera to hankertswo?

Czasem tak.

> Hehe.
> Zwykle takie rzeczy robi sie o wile lepiej/latwiej/pewniej przez
> *.dll/*so

Czasem nie.

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

A skąd wniosek że nie słyszalem i w jaki sposób UB ma pomagac w temacie
podkreśleń?

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

"Jakie jest niebezpieczenstwo w tym ze chcemy sie dobrac do np. symbolu
w DLLce". Ano takie że może sie ABI nie zgadzać. Bum.

> Jesli ABI jest wspolne (a jest) to moza miec rozne manglingi (od roznych
> kompilatorow C) i spokojnie da sie to wszystko bezpiecznie pozenic.

Jeśli ktoś by nie hackowal to by nie mial problemu z podkresleniami.

Jeśli.

I jeszcze jeśli ABI jest wspólne. Bo przecież w rzeczywistym świecie
jest tylko jeden kompilator wszystkich dllek.

>> A unwinding stosu jest kompatybilny?
> A nie?

Czasem 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

Czasem się to dzieje na zewnątrz. Ty sobie instacjonujesz gdzieś
foo<long int> a ktoś inny spodziewa się foo< long > i nagle jest jakiś
zabawny problem z bugami w kompilatorze.

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

API masz zdefiniowane, wszystko działa i nie ma problemu. Życ nie
umierać. A tymczasem w sąsiedniej rzeczywistości ktoś ma .so od
producenta który nie wie czym kompilował, ma dziwne manglowanie i
brakuje częsci symboli bo się inaczej inlineowały, a templates nie
pasują do nazw. I jeszcze jakis miszczu zhackowal podkreslenia. Co
robić, pozostało więcej hackowania.

>> Wiadomo co się stanie jak trafimy ponownie na ten sam symbol przy
>> linkowaniu? Etc.
> W "moich czasach" take cos bylo zawsze traktowane jako blad.

W tutejszej rzeczywistosci już niekoniecznie.

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

Wiadomo. Szczególnie jak dwóch idiotów zrobi "GetFactory" bez namespaces
i to sa dwie rózne firmy komercyjne. Przypadek z większego banku.
Workaroundem okazało się ukrywanie symboli recznie w .so poprzez
robienie so warppera. Problem hacked. Wczesniej mieli ręcznie edytowane
pliki binarne. Trudno się nie zgodzić że oba rozwiązania działają więc
sa dobre. Tak, sa dobre...

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

No to jak w końcu, mozna użyć czy nie? dllki mają ustandaryzowane cośtam
czy nie?

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

Nie ma tu mieszanka. To sa problemy z zycia wzięte. Mojego rownież. To
jest rzeczywistość spotykana na codzień w kodzie embedded.

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

Otóż to. Wrapper na wrapper i jedziemy dalej.

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

Miało byc coś o cięzkim przypadku a na koniec okazało się że jeśli
załozyć że nie będzie huraganu to ten płot da radę. Czyli problemu nie
ma. Moving on.

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

Mało mowi. W .so i w .dll wolno wsadzić w miejsce kodu dowolny film
porno w kodeku Indeo i nikt nie będzie marudził że dllka jest zla, choc
może bedzie marudził że kiepska jakość.

> Kazdy kompilator musi sie do tegi dostosowac (bo inaczej
> nic byz niczym nie wspolpracowalo) a nie odwrotnie.

Borland o tym nie widzial i zrobił inne ABI. Albo inaczej: wiedzial i z
premedytacją zrobił inne ABI. Pech.

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

Są kompilatory do embedded. Ich jest jak mrówków. Są rózne ABI co mnozy
ilośc kompilatorów. Są różne libc, wersje API, widzimisie konwencji
wołania, rozwijania templates, architektur kodu maszynowego, podejscia
do allokacji pamięci itp itd. Mało tego nie jest.

C++ jest bardzo bogaty w koncepcje jak skopilować a + 2 na różnych
maszynach i w ramach tej samej maszyny. Zakladanie ze dllki sa stabilne
jest niebezpieczne.

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

Ziew.

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

Nie. Nie masz absolutnie racji. Ale doskonale widzę jak bardzo mało
wiesz o innych pomimo "wystarczy mi kilka linijek/slow". Nie, nie
wystarczy. Oceniasz ludzi na podstawie swoich skostniałych poglądow.
Każdy może mieć jakieś poglądy, nie ma problemu, nawet skostniałe. Warto
jednak sobie zdawać sprawę że sie nie jest jasnowidzem. A juz na pewno
nie okazywać idiotyzmu twierdząc że mozna kogoś prześwietlić po paru
słowach. Jest to o tyle niebezpieczne że podczas takiego prześwietlania
może sie okazać że sam bedziesz prześwietlony - jak tutaj.