[C++] Borland compiler

manjkajo ti sistemske spremenljivke v polknah.

Najbolje bo, da odpres ukazno vrstico Start / Run / cmd in potem nastavis tiste potrebne spremenljivke:
set include = c:\bp\include
set lib = c:\bp\lib
set path=%path%;c:\bp\bin

potem pa probas prevesti.

borland turbo c je prišel ven za windows?
predlani pa sem se za seminarsko moral zajebavat z emulatorji da sem spravil v pogon borland turbo c za dos

ubistvu ti priporočam brezplačen Dev-c++ ... Zlo dober prevajalnik, zmožnost dodajanja novih knjižnic z devpaki itd... Problem z microsoftovim je (imho !!!) da ni pisan po ANSI standardu in tako boš znal pisatli le v microsoftovih orodjih...

Lp

Drugače učim programiranje v sklopu informatike na srednji šoli. Prišel sem do spoznanja, da je za začetnike najboljši Borland C++ 3.0. Ima zelo preprost IDE, možnost koračnega izvajanja in pregledovanja vrednosti spremenljivk.

Mogoče se pa motim in ima kdo boljši predlog?

@bozjak: Morda te bo zanimalo, da ima MS javno objavljen seznam vseh odstopanj od ISO (oziroma ANSI) standarda. Druga zanimiva malenkost je, da Microsoft že od produkta VC++ 6.0 vlaga veliko dela in energije v čim bolj standardno implementacijo C++ prevajalnika, saj so zaradi slabih knjižnic poželi ogromno kritik. Tako je naslednja verzija (VS.NET, oziroma 7.0) že pokazala zobe, saj se je pokazalo, da Microsoft še vedno posluša razvijalce (če že uporabnikov več ne). Tretja malenkost je, da Microsoft ravno zaradi hudih kritik zaposlil kar nekaj avtoritet na področju jezika C++, kar tudi govori v prid dobri implementaciji standardov v tem prevajalniku, saj na tem prevajalniku in knjižnicah delajo tisti, ki so pisali tudi standard sam.

Sicer pa obstaja ena stara primerjava prevajalnikov. Sicer je res stara, vendar pa zelo lepo prikazuje vpliv strokovnjakov, ki jih je Microsoft nakupil v letih 1998-2000, na stopnjo kompatibilnosti prevajalnika. VC++ 6.0 je tako iz svojih 97% v VC.NET (7.0) napredoval na zavidljivih 99%. Res pa je, da je bil GCC, ki je prevajalnik "skrit" v Dev-c++ paketu, takrat šele v verziji 3.x, kar pojasni njegov slab rezultat, ker je bila večina dela s standardi opravljena v verziji 4.x. Zanimivo, da šele takrat, ko je Microsoft že nekaj let uspešno prodajal precej bolj "standarden" prevajalnik. Še posebej pa je zanimivo dejstvo, da dva rezultata za VC++ 6.0 (84% brez posebne knjižnice in 97% s posebno knjižnico) lepo ilustrirata, da je imel Microsoft večino težav v implementaciji standardnih knjižnic, ne pa toliko v prevajalniku samem. GCC-jev rezultat pa lepo pokaže, da je imel prevajalnik sam veliko omejitev, ki so onemogočale uporabno implementacijo standardnih knjižnic.

Trenutne primerjalne ocene sicer nimam, ker tudi nihče ne vodi jasnega seznama GCC-jevih odstopanj od standarda. Dejstvo pa je, da danes vsi gledajo na GCC kot na enega izmed uporabnih prevajalnikov za C++, saj je po svoji ustreznosti standardu primerljiv z drugimi prevajalniki (MS C++, Forte C++, Intel C++, ...). Zaradi tega bi rekel, da je stvar osebne presoje kater prevajalnik si izbrati, saj večina aplikacij stoji in pade na upoštevanju platforme (operacijskega sistema) kateri so namenjeni. To pa že preprosto zato, ker se kakršni koli standardi zaključijo v tistem trenutku, ko se začne uporabljati stvari, ki presegajo programsko logiko in začno posegati v večopravilnost, večnitnost, medprocesno komunikacijo, uporabo omrežja, grafični uporabniški vmesniki, ... Za te stvari pa so bile že razvite druge knjižnice, ki zapirajo posamezne implementacije v bolj abstraktne paradigme.

Skratka, en kup zadev, ki jih je IMHO potrebno upoštevati, ko nekdo ustvarja svoje mnenje (svoj HO).

@64202: Če pogledaš samo seznam sprememb v 4.x, je razvidno, da je bil GCC 3.x, vsaj kar se tiče ISO standarda za C++, prava mala katastrofa. MS določenih delov ni implementiral, GCC pa jih je implementiral narobe, ali pa je imel drugačno funkcionalnost, ki je bila v konfliktu s standardom. Že zaradi tega se veliko C++ kode, ki se je pod 3.3.x prevedla OK, ni hotelo niti prevesti, nekatera, kar je bilo še hujše, pa je delovala nekoliko drugače.

Skratka: GCC 3.x je bil v praksi za C++ katastrofalen prevajalnik, ki mu je pomagalo samo to, da so tik pred zaključkom razvoja v njega iz verzije 4.0 prinesli novo verzijo C++ fronta. Glede na to, da so s tem razvijalci povzročili še nekaj dodatnih težav za distribucije, ki so želele iz različnih razlogov obdržati 3.x serijo, je bil končen rezultat takšen, da je bila 3.x serija (v merilu GCC-jevih verzij) zelo hitro zaključena (ubita), delo se pa sedaj lepo nadaljuje v 4.x. Zaradi vsega tega je za celotno 3.x serijo (vključno z "delujočo" vejo 3.4.x) najbolje, da ostane tam, kjer ji je mesto: v zgodovini.

Če naj bom še malo nesramen, so razvijalci GCC opazili vse pomankljivosti C++ fronta šele potem, ko je MS poslal ven svojo verzijo 7.0, ki je bila po takratnih in današnjih merilih precej "standardna". Od takrat, pa do sedaj, so pri MS vse skupaj samo še malo brusili. V bistvu je bila takratna verzija 3.3 v trenutku, ko je MS dal ven svojo verzijo 7.0, najslabši obstoječ C++ prevajalnik.

Vse kar sem pa želel povedati je to, da si svoje mnenje vsak ustvarja sam. Vsi smo v svojih spominih malo selektivni. Na koncu pa se mi zdi nepošteno oceniti današnjo verzijo MS C++ prevajalnika za "nestandardno", samo zato, ker je MS imel slabo verzijo 6.0. Po isti logiki bi se lahko tudi GCC 4.x obtožilo "nestandardnosti," vendar pa je to čista krivica za oba prevajalnika. Krivica predvsem zato, ker so se vsi učili na napakah preteklosti, zaradi česar imamo danes na voljo ne samo enega ali dva dobra prevajalnika za C++, temveč kar nekaj njih. Vsekakor pa sta med njimi tudi MS C++ 7.x in GCC C++ 4.x.

> Skratka: GCC 3.x je bil v praksi za C++ katastrofalen prevajalnik

No to se meni zdi hudo pretiravanje. Dejansko sem imel zelo malo problemov, a tebi je ratalo na toliko hroščev stopit? Kolikor sem videl, je g++ 3.x predvsem sprejel veliko preveč nestandardnih zadev, če se držiš standarda (da ti dela na vc7) bi moralo bolj ali manj vse laufat na g++ 3.x*. To zdaj rečem iz mojih izkušenj, ne spremljam ravno bug reportov za gcc :)

* za vc7 -> vc6 pa to ne velja recimo