Postoje dobri razlozi zasto se stvari rade kako se rade (uspostavljanje veze sa deljenom bibliotekom
prebacivanjem pokazivaca na interface).
Rezon #1:
jedan od glavnih razloga zasto se uopste pravi deljena biblioteka je enkapsulacija (u najklasicnijem
OO znacenju) - zelja da se izoluje i zastiti unutrasnje funkcionisanje minimizovanjem 'povrsine preseka'
sa spoljnim svetom. Za razliku od klasicnih 'jezickih' razloga (C++, Java) tu su i razni drugi sistemski
razlozi (kontrola pristupa konkretnim sistemskim modulima, device driverima, itd). Kao najmanja
zajednicka dodirna tacke se tipicno uzima interface (struktura pokazivaca na delove programske
memorije).
Rezon #2:
Bez obzira koliko se programski jezici razlikuju, njihove razlike postaju sve minimalnije sto se ide blize
hardveru (CPU, memorija, registri). Layout strukture (struct) u memoriji je vrlo verovatno sasvim isti,
takodje layout pokazivaca na rutinu u programskoj memoriji, odatle i na interface (sto je struktura
pokazivaca).
Poniranjem na najmanji zajednicki sadrzalac cela prica se svodi na najsigurniju i najbezbedniju varijantu,
koju je jezickim konstrukcijama C podrzao skoro potpuno.
Citat:
U c++ koristim exportovanje klasa.
Nije nemoguce, medjutim, postoji dosta potencijalnih problema, nekoliko prvih dolazi iz relativno labave
standardizacije C++ implementacija.
Kao najveci potencijalni problem u ovom pogledu stoji dijapazon mogucih shema za formiranje imena simbola
(name mangling) koji nije standardizovan, nego zavisi od kompajlera.
Export-ovanje klase obicno nije problem kad su i korisnik (onaj koji load-uje) i deljena biblioteka pisani po istoj
shemi (-> kreirani istim kompajlerom + istom verzijom run time biblioteka). Na Linux-u su svi simboli deljene
biblioteke po default-u vidljivi i dostupni. Na Windows-ima par makroa obavlja celu pricu bez problema.
Drugi problem je implementacija v-tabela (klasicna dilema: per object/per class je samo jedan od problema). Posle
toga nadire klasa problema vezanih za RTTI (real time type identification).
Treci problem je brzina load-ovanja.
Hajde da zazmurimo pa da kazemo da je sve 'podmazano' - isti kompajler, ista name-mangling konvencija, iste run
time biblioteke. Radi cistoce primera, izostavicu slucaj dobro utabanih sistema (Windows, Mac) recimo, gde je cela
hijerarhija klasa vecim delom uglavnom poznata unapred. Uzecemo primer custom C++ projekta sa bogatom hijerarhijom
klasa, slabo poznatom siroj javnosti, nema sanse da se na target masini nalazi u nekom .dll/.so fajlu, stize jedino
i samo preko jedne jedine deljene biblioteke, custom dizajnirane u firmi XYZ.
Ako se kod korisnika deljene biblioteke napise tako da zahteva instancijaciju bas C++ klase, linker ce morati da pred
loader stavi zadatak da at run-time pronadje i ucita v-tabele svih predaka zeljene C++ klase,...sto moze da traje vremena.
Daleko krace ce da traje loadovanje ako naznacis da ti at run-time treba iz biblioteke nista vise nego prosta struktura koja
sadrzi pokazivace na funkcije. Time nije nista zrtvovano - instanca C++ klase ce se odigrati svoju ulogu u procesu, samo ce
loader da 'posluzenje' njene funkcionalnosti izvede brze i elegantnije, bez potrebe da 'gost restorana onjusi lonce u kuhinji'.
Citat:
Mislio sam na koriscenje exportovanih c++ clasa iz c++ biblioteke u programu koji nije pisan u c++
Ovo do sada najbrojano su bili problemi u okviru istog jezika (C/C++). Verovatno je intuitivno jasno da razlike izmedju
implementacija klasa izmedju razlicitih programskih jezika rastu eksponencijalno:
- kod nekih je memory alignment probleme potpuno zbrinuo kompajler, kod drugih nije. Zaboravis (ili ne potrefis tacno) #pragma align,
problemi su neminovni, crash vrlo verovatan.
- calling konvencije mogu da budu znatno razlicite
- tipovi podataka nespojivi (pokazivaci u Javi = ?, unsigned short u Javi = ?,...da ne pominjem genijalne objective-C seme
gde se 'potpis' funkcije formira kao 'red slanine-red sunke-red slanine-red sunke')
- exceptions handling (izuzeci) se tretiraju vrlo raznoliko (Java finally = ? u C++)
Ono sto se moze uraditi su razni 'bindings'. Puko loadovanje u proces je nepotrebno komplikovana disciplina.