Evo ja skidam opengl primere pisane za VC++, i bez problema ih kompajliram Borlandovim 5.5.1 free compilerom.
Uopste nemam VC++.
Ponekad sam nailazio na problem da funkcija vraca bool, sto borland ne podrzava, ali to resim prosto, samo stavim da mu int bude povratna vrednost, i return true prebacim u return 1, i to radi.
Evo puno primera gde se upotrebljava cisti WinAPI za kreiranje prozora i ostalih GUI komponenti, a koji su pisani u VC++, rade i u Borlandu.
Cini mi se da se VC++ drzi ANSI standarda.

Ono sto sam ja zapravo hteo da kažem je to da je VC++ striktno vezan za jednu arhitekturu i par operativnih sistema. Kad sam pisao o portabilnom softveru prosto sam razmišljao da postoji zaista mali broj kompajlera koji su zapravo toliko dobri da sa njima čovek može da piše PORTABILNI kod u pravom smislu te reči - dakle sa sa ISTIM kompajlerom samo iskompajlira svoj kod i dobije izvršni kod koji RADI!

Ti kompajleri su:
- GNU Compiler Collection (što nije samo C i C++, već i Fortran, uskoro i Modula 2 i Liberty BASIC)
- Modula 3 (bilo da je Polytechnic ili Critical Mass Modula, ili Compaq-ova SRS Modula 3 - sve pomenute "module" rade na svim poznatijim platformama)
- TCL (kompajler)
- LCC (impozantan broj platformi na kojima radi, ali ne toliko kao GCC)

Nadam se da ste shvatili šta sam zapravo hteo da kažem - najkraće objašnjenje - za neku drugu platformu koristićete drugi kompajler i imaćete compiler-specific probleme priznali to ili ne (ako su vam projekti iole komplikovaniji)...

Borland ne podr?ava da funkcija vra?a BOOL? Izvini, ali ... ne, ne?u da komentari?em... :) Umesto svog komentara evo ti deo WINDEF.H:

Ovo ti valjda obja?njava za?to nemam komentara... Btw. ovaj WINDEF.H je iz Microsoft Visual C++ 6.0 stabla... Ako koristi? WinAPI onda si tek vezan za platformu! :) Ne radi se o portabilnosti tipa "ja pisem u VC++ a ti u BorlandC++ ili koristi? Watcom C/C++", ve? o recimo portabilnosti tipa "moj program treba da radi i na Windows 98 i na Windows XP, kao i na IRIX-u i MacOS-u

Pardon, bool radi, ono sto sam ja video cini mi se da je bio jedan bool array, nacicu kod veceras pa cu ga paste-ovati.
Inace, kad uporedjujes kompatabilnost kroz OSeve, dobro je uporediti i kroz compilere, why not?

[Ovu poruku je menjao zastita dana 27.01.2002 u 07:13 PM GMT]

Hmmm... znači misliš da je važno da postoji verzija istog kompajlera za razne platforme. Mislim da to nije baš toliki problem. Naravno, tačno je da bi to olakšalo stvari; na primer kada bi imao VC za Unix, mogao bi da iskoristiš podatke koji su sačuvani u dsw i dsp fajlovima, umesto da pišeš make file. Ali, uz dobru organizaciju to nije neki problem. Kao što sam već rekao, u firmi za koju radim, razvoj se obavlja skoro isključivo u VC-u, a ipak uspešno podržavamo nekoliko Unix varijanti. Naravno, bitna je disciplina; tako je strogo zabranjeno da koristimo Windows-specifične stvari, već se isključivo oslanjamo na portabilnu biblioteku. Na primer, umesto da koristim wchar_t koji pod Winom zauzima 2 bajta, a pod Unix-ima 4 bajta, koristim interno definisan tip UNICHAR, koji se isto ponaša na svim sistemima.

Hehe, Dragi Tata onda je to DRUGA stvar kod koje smo se mimoisli! :) Elem onda ne treba da pricamo o kompajlerima vec o razvojnim okruzenjima. Tebi je po tome sto si rekao VC zapravo samo jedna radna okolina koja radi onako kako ti volis... Onda mi je sve jasno...

Za mene je umetnost multiplatformskog programiranja recimo ZIP/UNZIP :)

Evo prilepicu unzip.h header fajl koji sam govori sve onima koji znaju da ga citaju...

Da, čuveni #ifdef... Ko voli još takvih primera, neka pogleda BOOST biblioteku. Ne znam napamet adresu, ali idite u Google i kucajte boost.

I LAME MP3 kompresor je prilicno multiplatform-friendly, mislim da cak moze da se kompajlira i na Amiga racunarima :)

softver na kojem ja radim se porta na 36 unix-a, windows, i novell.
iako se trudimo da radimo sve u ANSI C, ponekad nije moguce, tako da ako grepnes za
#ifdef u kodu, dobijes par miliona linija outputa :)

inace, na HP-UX-u i na solarisu cak koristimo MFC kod koji je portan uz pomoc Wind/U paketa od firme bristol.

kompajleri koje koristimo su iskljucivo native kompajleri, a ne gcc.

isto tako kao sto je tata pomenuo UNICHAR, mi koristimo tchar

Da, to mi zvuči poznato. Međutim, ja lično nikako ne volim te #ifdef-ove, jer jako umanjuju čitljivost koda, a i otežavaju izmene i održavanje. Moj ideal je da se sav OS-specific kod izolouje u posebne klase (u slučaju C-a, module) sa identičnim interfejsom i da se u zavisnosti od željene platforme
koristi odgovarajuća verzija tih modula. Tako nešto je zamišljeno da se izvede i ovde gde ja radim, ali nije baš dosledno sprovedeno.



Čuo sam da je to skupo kao sozgajz (ne pitajte me šta je "sozgajz", taj izraz sam čuo od babe). Valja li nešto?

Po meni je gcc fina solucija, pogotovo posle pojave cygwina. Tako da sad mozes sve sto je radilo pod nekim unixom iskompajlirati pod windozi ok. Tu se javlja jedan prolem poznatiji kao POSIX threads, ali ima leka apoteka - http://sources.redhat.com/pthreads-win32/

E sad ne znam da li gcc pravi problema oko jos necega, ali otprilike da je vecina problema ovim resena. (Naravno sto se tice portovanja na relaciji unix-windows).

Inace #ifdef je po meni sasvim dobra solucija. Mislim jeste da to umanjuje citljivost koda i sve to, al je ipak jeftina solucija

Ne kažem, pthreads je lakši i elegantniji interfejs nego Win32 threads. Međutim, ako koristiš nešto kao pthreads-win32 ili još bolje boost-threads, platićeš cenu za prenosivost u performansama, a donekle i u fleksibilnosti. Ono, najćešće se isplati, ali treba imati i to na umu.

A gcc je verovatno dobar za Open Source sisteme ali za Win ne može da priđe VC-u, Borlandu (ovde govorim o performansama) ili Intel-ovom kompajleru.


[/quote]

Može da bude dobra solucija za manje programe, ali ako radiš to sa većim projektima, održavanje ubrzo postaje noćna mora.

Hmmm, ovo za performance pthreads-win32 nisam znao, ali hvala ti na informacijama.

A sto se tice #ifdef, svakako da kod velikih projekata dolazi do problema sa odrzavanjem al imajmo na umu da tu postoje i oni, manji projekti :D

Inace, sto se tice vc++ /gcc/borland c+/intel c++ poredjenja, ne znam sta bih tu mogao da kazem. Vc++ nisam nikad koristio tako da i nemam sta da kazem za njega. Sto se tice gcc-a, zadovoljan sam. Borland Turbo C++ i Borland C++ Builder sam koristio ranije, i ne znam zasto smatras da su oni mnogo ozbiljniji od gcc, a intel c/c++ kompajlera sto se tice, tu stvarno nemam reci :D. Imao sam ga ranije i nisam ga nesto puno koristio (mozda zato i pisem ovako o njemu) al tu bih te stvarno molio da kazes sto je on bolji ...

Što se performansi sa pthreads-ovima tiče, to generalno važi za sve sisteme, a ne samo za Win. Kladim se da i na Linux-u možeš da postigneš bolje performanse ako direktno zoveš clone(), ali gubiš portabilnost.

Za #ifdef imaš pravo. Right tool for the right job ;)

Za kompajlere: gcc ima dve velike prednosti: raširenost na mnogim različitim platformama i dobra usaglašenost sa ISO standardom. Te dve stvari su dovoljne da gcc bude itekako ozbiljna alatka (nigde nisam rekao da je gcc neozbiljan). Sa druge strane, VC je rađen specifično za Win platforme i optimizovan je za tu svrhu. Dakle, sa VC-om i Borlandom nema prenosivosti, ali su zato performanse bolje. Slično važi i za Intel, uz napomenu da je on specifično optimizovan za Intelove procesore.

Znači: gcc donosi prenosivost; specijalizovani kompajleri donose nešto bolje performanse.

aha, sad mi je jasno

Ali posto je topic Portabilan kod, naravucenij je....

Evo i moj prvi post u "novom" [es]-u

Sto se tice Intel kompajlera, ja sam se razocarao sa kvalitetom istog - Za jedan moj projekat koji se razvijao 3 godine sam dosao do zanimljivih rezultata..

U pocetku razvoja je Intel kompajler davao mnogo brzi kod od VC++, medjutim kako je kod optimizovan za brzinu razlika izmedju ICL-a i CL-a je postajala sve manja da bi danas kod generisan ICL-om bio sporiji!!! (napomena: koriscene su sve optimizacije, i interproceduralne ekspanzije inline funkcija)

Osim toga, Intel kompajler ima neke probleme pa se desi da kod generisan ICL-om daje razlicite rezultate od VC++ koda!

A na kraju, sa legalne tacke gledista, ICL je papreno skup kompajler. Kada se uzme u obzir da Intel nudi besplatne performance libraries (SPL, IPP) koje imaju optimizovane funkcije - pitanje je koliko je ICL uopste potreban.

Vidiš, to nisam znao. Meni su Intela hvalili neki ljudi koji su ranije radili sa njim. Kažu, daje dobar kod, a lako se integriše sa Visual Studiom. No, ako si nedavno koristio Intel, onda ti treba verovati.