Zavisi C nikada nije bio sjajan kada dolazi u obzir neko GUI programiranje, OOP nekako bolje lezi za GUI. Iako je moguce iz cistog C-a to raditi(primer je GTK). Sa druge strane kada su hardverski resursi jako mali(mikrokontroleri npr.) tu je C i dalje tata za sve ostale jezike. Ja ga u principu i dalje koristim za nesto sitno do 1000 linija koda. Za bilo sta krupnije prelazim na C++.

Ne mislim da C gubi na popularnosti. On je odavno izgubio na popularnosti. Naravno ne kazem da nije popularan. On ce uvek da zivi i uvek ce imati svoju namenu. Samo kazem da se vec dug niz godina za GUI, skriptove i sl. koriste mnogi drugi programski jezici tako da je C odavno izgubio na popularnosti a u poslednje vreme ne gubi jer ne verujem da je sada manje popularan nego recimo pre 3 godine.

Pretpostavljam da mislis na C/C++ a ne samo na C.

Kratak odgovor je naravno da gubi.

Malo duzi odgovor je da je u jednom trenutku C imao skoro 90% trzista, tako da svaki napredak ostalih jezika znaci da je C izgubio market share. Business apps se vec duze vreme ne pisu u Cu, web strane takodje, a sa napretkom kompjutera sve je vise stvari moguce uraditi u nekom jeziku koji je laksi za razvoj i manje efikasan.

Taj trend ce se nastaviti, jer je cena pravljenja i odrzavanja koda nesto sto ce nastaviti da se minimizuje. Naravno, to ne znaci da ce C potpuno izumreti, ali ce biti relegiran na nekoliko visoko specijalizovanih primena. Drugim recima, sve manje programera ce imati priliku da u svakodnevnom poslu radi sa C-om.

Slazem se sa Reljom da je C/C++ izgubio na popularnosti, ali se ne slazem sa procenom
krajnjeg ishoda i ukupnih proporcija pada.

Pre svega, C je bio i ostao 'sluzbeni jezik' inzenjera. Iako druge programerske
delatnosti odavno mogu bez C-a, u ovom domenu se algoritmi narocito u
telekomunikacijama, signal processingu (DSP), upravljanju u realnom vremenu
opisuju upravo u C-u. To je bilo i bice jos dugo. Ne kazem da ne moze i u C++-u,
Javi, perl-u, Matlabu, ali C je optimalan za ove namene.

Ako pogledate bilo koji od tehnickih standarda: MPEG1, MPEG2, AC-3, AAC - sintaksa
bitstream-ova je opisana sintaksom koja je gotovo 100% sintaksa C-a (tu i tamo se
uvede neka pseudo-language oznaka). Mnogo je striktnije kad su u pitanju video,
audio ili graficki algoritmi.

Razvoj device drivera je jos uvek 90% u C-u, 10% u asembleru.

U prilog C-u ide i cinjenica da je C znacajno preoteo trziste asemblerima. Pre desetak
godina, ko god je radio embedded programiranje, morao je pre ili kasnije da zasuce
rukave i da pise u asembleru. Danas, samo deceniju kasnije, svaka nova embedded
platforma (tj. cip) dolazi sa odlicnim C cross-compilerom, tako da ne znam da iko vise
pise u asembleru, osim u izolovanim delovima koda gde se radi optimizacija brzine.

Takodje, iako je potreban, klasican C vise nije dovoljan - trazi se poznavanje
multitasking/multithreading tehnika, kao i pomalo kernel programiranja.

Da li je C izgubio popularnost ? Da, odavno vise nije potreban bas svima.
Da li ce C propasti ? U nekim oblastima nece jos dugo.
Vredi li uciti C ? Jos uvek je dobra osnova za dalje.
Da li je trazen ? Znam dosta inzenjera koji od jezika cestito znaju samo C i dobro
prolaze u delatnosti kojom se bave.

Ne, mislio sam samo na C jer je u prvom pitanju receno C u odnosu na C++.

C++ gubi na popularnosti ali C ne gubi. C je odavno izgubio na popularnosti u koristi C++-a i vise ne gubi na popularnosti nego se koristi tamo gde ce se i ubuduce koristiti (programiranje DSP cipova, drajvera, kontrolera itd...).

A C++ gubi na popularnosti jer su deo trzista preuzeli programski jezici Java, C#, VB, Delphi, Python itd...

C i C++ ce uvek biti popularni jer kada je u pitanju brzina tu su nenadmasni ali C++ ce nastaviti da gubi na popularsnoti jer se brzine masina povecavaju i sve vise se prelazi na .NET, J2EE....

Milanche, mislim da pricamo o istoj stvari.

Ja se bavim 3D grafikom, tj rendering komponentom za ceo OS. Naravno da se to pise u Cu, i da ce to verovatno ostati tako jos dugo. Medjutim, broj poslova koji zahtevaju C opadaju u poredjenju sa brojem poslova koji se rade u drugim jezicima. Tacno je da ce inzenjerski poslovi biti uglavnom radjeni u Cu, ali boom programerskih poslova nije u inzenjerskim aplikacijama: naprotiv pre je u business logic appsima. Naravno, to ima i smisla, jer je broj ljudi koji mogu da rade inzenjerske C programe manji od broja ljudi koji moze da pise business logic.

Tu ima jos jedan faktor, a to je sto se inzenjerski C programi koncentrisu na relativno mali broj mesta u svetu. Ti ces u San Francisku moci da nadjes C posao, ja u Sijetlu takodje, ali neko u Beogradu danas vise mozda i nece moci (ima ih, ali maaalo).

Device driveri se danas pisu za klase uredjaja, nema svaka firma koja pravi skener ili digitalni fotoaparat svoj drajver. Ljudi danas ne pisu kodeke nego ih licenciraju od drugih. Cak i poneki fakulteti ovde predaju Javu umesto Ca.

Ne radi se o propasti, vec o jednom dugom procesu marginalizacije. Meni nije zao sto znam C, naprotiv, ali ne mogu da danas nekom kazem "e, moras da znas C da bi radio kao programer", kao sto sam mogao pre 5 godina.

[Napomena: ovde sam pod C pricao o C/C++ familiji. Za sirov C je taj proces marginalizacije vec zavrsen, C vise nema ni par % trzista.]

www.monster.com

Jezik / broj oglasa za posao u USA
---------------------------------
java 1743
c++ 1216
vb 854
c# 532
delphi 57

Znaci spao je na 27% sa 90%. A i jos ce da spada procenat.

Ma, cak i ti procenti ne znace nista.
Bitno je samo da izaberes alat kojim ces najbolje odraditi posao...

C programeri jos uvek su prilicno trazeni na unix platformama (ili da budem precizniji, jos uvek su trazeni programeri za development na unix platformama), ali paleta poslova je prilicno uska. na *nix-u je jos uvek 1:1 (izmedju C-a i C++-a) i tako ce jos dugo ostati.

Dovodim u pitanje ovu tvoju tvrdnju. Sto se tice programskog jezika C, tacna je samo ako se odnosi na razvoj C aplikacija pod Windows okruzenjem.
S druge strane, C++ se ne predaje tako lako.
Kada cete videti neki operativni sistem napisan u, nazovimo ih programskim jezicima: VB, C#, Python, Java ?
Kako trenutno stvari stoje, ako ste tipican korisnik Windows operativnog sistema, 85% aplikacija koje koristite je napisano u C++, 10% procenata u Delphi-u, a 5% u preostalim programskim jezicima.
Navedite JEDNU ozbiljniju opste koriscenu aplikaciju napisanu u VB.
U Rapid Application Development programskim jezicima se uglavnom pise Company Software.

Blazo, radi se o broju poslova. Pogledaj sve postove gore, relativna potraznja za C++om se smanjuje, a za cist C je spala na manje vise konstantan i zanemariv deo trzista.

Naravno da postoje primene gde ce se koristiti C ili C++, ali njih ima malo, i geografski su koncentrisane na par mesta na planeti.

U svakom slucaju odogovor na originalno pitanje je: "da, popularnost Ca se smanjuje".

zasto razdvajas c i c++ ?! svaki ozbiljniji programer (bar oni koji traze posao) nije da zna samo c vec (pod obavezno) i c++. To je isto kao da npr koristis win95 i izadje 98,me,nt*/2k,xp... a ti jos uvijek na 95ici i neces ni da vidis ostale :)

Možda ja nisam "tipičan", ali sam prilično siguran da ni jedna aplikacija koju koristim nije pisana u Delphiju.

Može li neko da mi navede neku popularnu aplikaciju pisanu u ovom programskom jeziku?

Delphi :))

pa svaki iskusniji programer bi ti rekao da su razlike velike i u dizajnu i u implementaciji. obicno poslodavac napomene sta mu je potrebno, c, c++ ili c/c++. pored toga se obicno zahteva i poznavanje odredjenog api-a/framework-a/arhitekture.

MV2 player ;)))

Milioner, naseg dragog Milike Delica. http://ww1.infosky.net/~milika/
OllyDbg, http://home.t-online.de/home/Ollydbg/
Kao sto rece Cheda, najbolji player, MV2Player http://mv2.czweb.org/
Itd...itd...

Mislim da nikako ne gubi jer ipak on nema adekvatnu zamenu za ono za sta je napravljen.
Mislim da on radi sve sto se u danasnje vreme moze ocekivati od nekog proceduralnog programskog jezika sa veoma bliskim pristupom hardverskim resursima.

C jezik je namenski, i danas je u kombinaciji sa asemblerom
prava stvar za programiranje mikrokontrolera.

Nokia/VW/ ...

Ako ne verujete pogledajte http://www.ristancase.com
PROJEKTNI EDITOR i CASE ALAT za C projekte za sve
najpoznatije svetske proizvodjace C kompajlera, i to:
D E L O D O M A C E P A M E T I

Moja malenkost je nekada radila u toj firmi (TeleJob),
a koliko vidim - projekat se i dalje razvija i ljudi nisu
umrli od gladi.

Uporedio si C sa VB-om. Eto M$ ih je napustio...

Uporedjivati C sa VB-om nije bas ozbiljna stvar.

Pa u smislu popularnosti jeste ozbiljno poredjenje. Nekada kada nije bilo VB-a maltene su se sve stvari radile u C-u. Posle je C++ preuzeo popularnost C-u a kasnije je VB preuzeo dosta poslova C++-u. C je izgubio na popularnosti ali ce uvek ostati popularan za programiranje mikrokontrolera itd...Retko ko sada pravi program koji ima Gui i pristup bazi podataka u cistom C-u.

Srki,
VB je jezik koji je tacno imao svoj 'rok trajanja' i 'svoju ulogu'.
Dokazao je da razvojna okruzenja ne moraju da budu odbojna
i slicno. VB je jezik za softver visoke srednje klase. Ali, da li bi
se ikada moglo razgovarati o mogucnosti da na primer neki
ozbiljan OS bude napisan na VB-u? Npr svojevremeno UNIX.

C jezik se nikada i nije takmicio u GUI-ju. Cim je na svet dosao
C++ nema C programera koji nije presao na C++.

Inace, svojevremeno sam se poprilicno bavio Amiga-ma koje su
imale graficki OS (Workbench) kad je Bill Gates cukao DIR i
COPY. Tada su postojali fantasticni C jezici za razvoj GUI-ja
(Aztec C, Lattice C).

Sve je bilo isto. Samo su umesto klasa bile jasne strukture sa
puno lancanih lista.

Naravno, nije mi cilj da blatim VB (taman posla), nego sam hteo
da kazem da to jednostavno nije ista kategorija jezika i da nisu
merljivi na taj nacin.

Pozdrav.

a kako si tako siguran?

popularniji za koje sam siguran
- wincmd (total commander, najpopularniji file manager)
- topstyle (verovatno najpopularniji css editor)
- feed deamon (najpopularniji win rss agregator)
- jajc (najpopularniji win32 jabber klijent)

manje popularni, i manje siguran
- infran view
- phpedit
- spybot - search & distroy
- myinfo

i ima možda još toliko, ali su delom vezani za delphi razvoj, delom manje poznati, a delom i nisam toliko siguran..

dakle, možda ni ja nisam tipičan korisnik, ali meni je taj procenat vrlo blizu 20% čak i ako ne računam alate vezane za delphi razvoj (a imam instalirano baš doosta programa. četiri pune kolone u Start/Programs meniju). plus još možda koji procenat koji sam zaboravio, ili onih koje koristim, a ni nemam pojma da su rađeni u delphiju, jer to stvarno nije tako lako uočljivo. delphi aplikacije niti (moraju da) izgledaju značajno različito, niti (moraju da budu) primetno sporije od c++ pandama..

(i ne, ni jednu od ovih aplikacija ne koristim zato što je rađena u delphiju.. za više od pola nisam ni znao pre nego sam počeo da ih koristim)

dakle, moram da ponovim pitanje sa početka, zbog čega si tako siguran da ni jedna aplikacija koju koristiš nije rađena u delphiju (osim recimo ako ne koristiš manje od 20 aplikacija, i za sve znaš konkretno da su pisane u c++).

(a druga pojenta je i da bi preko 90% aplikacija mogle biti napisane u delphiju, uz isto ili manje truda, a da razlika bude neprimetna)

Od "popularnijih" sam čuo jedino za wincmd, ali ni njega ne koristim. Od "manje popularnih" nisam čuo ni za jedan.

Inače, za aplikacije koje koristim sam siguran da nisu pisane u Delphiju - jednostavno znam koje su ih kompanije pravile i sa kojim alatima. Jedini izuzetak bi mogao da bude Random House rečnik za koji nisam siguran kojim alatima je pravljen, ali to je daleko manje od 10%.

Da ne bude zabune, ovim ne želim da osporavam kvalitet Delphija - jedino njegovu zastupljenost i popularnost. Izgleda da je ovaj jezik/okruženje prilično popularan kod nas - verovatno jer se Paskal uči u školama, međutim u Americi je vrlo slabo tražen i korišćen.

Prije svega nevidim razliku da se barem danas razdvaja C od C++ kad je C na neki nacin sastavni dio C++,pa mozemo govoriti o jednom jeziku C/C++ ili samo C++.
Po mom skromnom misljenju C++ je jedan od najfleksibilnijih jezika koji postoji danas,jer on moze da bude proceduralan(postaje C-olik) i objektan(postaje C++-olik).Izmedju ostaloga ja cu reci samo ovo,radio sam i u C/C++ Java i VB C# te ostale internet tehnologije kao sto su ASP,PHP,HTML itd,te vise manje poznajem vecinu ovih tehnologija i nema razloga da favoriziram samo jednu jer samo nju poznajem.
Dakle ni dan danas nista se ne moze mjeriti sa C/C++-om,iako njihova popularnost pada.A zasto ona pada?Pada zato sto se danas svaki papak koji malo zna o racunarima naziva programerom i u stanju je pomocu VB-a razviti neke komercijalne aplikacije,i time on sam postaje sretan i nezeli uciti C/C++ jer je to pretesko za njega,a nije ni svjestan da nije u mogucnosti sa VB-om napraviti nesto ozbiljno pogotovo sto se tice grafike,a da nepricam ozbiljnim stvarima kao sto su OS itd.
Dakle,cinjenica je da C/C++ se sve manje koristi,ali cinjenica je da nisu umrli.Ovaj jezik ostaje za rad sa velikim projektima i sa njime ce raditi samo inzinjeri,koji rade na ozbiljnim projektima.,dakle samo privilegirani.
A recimo ko se ne zeli baviti necim ozbiljnim ipak mu preporucam kad pocne uciti programirati da nauci osnove C/C++-a pa onda neka kasnije prelazi na druge jezike.jer programiranje ce mu se kasnije znatno olaksati,jer ce sa C/C++-om nauciti neke stvari koje nece upoznati pri radu sa javom,a one se u pozadini odvijaju.

Ja ne znam odakle neko zna u kom su programskom jeziku razvijani programi zatvorenog koda u čijem razvoju ista osoba nije učestvovala, ali ja ću navesti neke open source primere, budući da tu postoje dokazi crno na belo u kom su jeziku ti programi pisani. U Delphi-ju je napisano integrisano razvojno okruženje Dev-C++, kao i integrisano razvojno okruženje Dev-Pas.

Inače, da li neko može da mi kaže barem jednu prednost jezika C# nad jezikom C++? Zbog čega mnogi programeri prelze na taj programmski jezik, i pored toga što programski jezik C++ ima očiglednu prednost da ga isti ti programeri već znaju? Zbog čega je pored poznavanja jezika C++ isplativo učiti C#?

Uvek je moguće pitati ljude u čemu su pisali program, ili pročitati na matičnom sajtu, ili na kraju krajeva pogledati binarni kod: često biblioteke imaju prepoznatljive „potpise“ po kojima se može zaključiti kom alatu pripadaju.



Prednost je verovatno to što C# nije opterećen vertikalnom kompatibilnošću zbog koje je C++ dugo pravio kompromise i još uvek ih pravi. Inače C# je jezik IMHO osmišljen isključivo da bi kontrirao Sun-ovoj JAVI i u odnosu na nju ne nudi ništa fundamentalno novo. Jeste, ima tu koječega što u JAVI ne postoji, ali to uopšte ne znači da je sam jezik posebno bolji. Stara priča o izvoru i dva putića; jedni dizajneri izabrali su jedan, drugi su izabrali drugi. Opet IMHO, ništa oko čega se vredi preterano uzbuđivati, osim u slučaju ako želiš da konkurišeš na posao gde se traže isključivo C# programeri. Priča o C# je više priča o parama i burgijama, a manje o računarskoj nauci i tehnologiji.

f

kao i vecina drugih prica. ;)

Sto se tice price Java vs C#, ideja jeste ista, ali implementacija te ideje nije - u tome je i razlika. A pare i burgije... sve su pare i burgije, ali ima i jos jedna komponenta - komfor. Onog trenutka kada su ljudi prestali da pisu u asembleru, pa onda kada su prestali da pisu u sirovom Cu, radilo se i o parama i burgijama ali i prelasku na nesto sto je lakse. Vremenom kompleksnost programa raste, programi moraju da rade vise, da imaju bolji UI, da se ponasaju na mrezi itd. Treba izabrati pravi alat za to.

Stvar je relativno jednostavno kvantifikovati: pitaj sebe sta bi od malih side-projectsa uradio u low level, a sta u high level jezicima. Videces da neke stvari ne bi ni pokusavao da radis u low level jezicima osim ako bas ne moras. Ja tvrdim da ce ta crta vremenom polako da se pomera na dole (naravno, ako imas uniforman izbor projekata :) ). Isto kao sto ces danas izabrati da jako malo stvari radis u asembleru, tako ces i sutra da izaberes da manje stvari radis u sirovom Cu. A prekosutra u sirovom C++u.

Rekao bih, razlika je samo u tome i ni u čemu drugom, što tu razliku ne čini posebno zanimljivom.



Rekao bih da nisu sve pare i burgije. Prelazak sa asemblera na više programske jezike zahtevao je da se razvije teorija vezana za kompajlere i analizu teksta, nešto što pre kompajlera nije postojalo. Prelazak na OO jezike zahtevao je da sazru OO metodologije i da se promeni način razmišljanja o programima. Opet nešto što pre OO (uslovno rečeno) nije postojalo.

Takve stvari čine fundamentalne razlike među programskim jezicima, dok je izbor između Jave i C# manje-više kao izbor između dva sladoleda od čokolade kog prave dve različite firme. Rastojanje između asemblera i C-a, ili LISP-a i C-a (itd.) meri se izvanrednim otkrićima i nadahnućem velikih imena u računarstvu. Rastojanje između Jave i C#-a meri se u inženjer-satima. IMHO tu leži razlika koja ne sme da se zaboravi.



Ovde nemam šta da dodam; baš je tako kao što kažeš.

f

"Izgleda da se nismo razumeli" (da pozajmim cuvenu izreku cuvenog coveka) - pricao sam o razlici izmedju C++a i managed jezika (Java i .NET). To je generacijski skok kao i ostali do tada asm -> C, C -> C++. Po svemu ostalom se slazemo...

U stvari izgleda da imamo razlicit stav i po pitanju implementacija: ja smatram da je implementacija krucijalna stvar, dok tebe vise zanima sama ideja. To each his own.

Čisto tehnički gledano, i Java i C# su po mom mišljenju prilično kilavi pokušaji da se "popravi" C++. Doduše, izvesno je da C++ ima problema (najviše, mada ne isključivo, zbog C nasleđa), ali oba pomenuta jezika rešavaju te probleme na potpuno pogrešan način i u mnogo čemu su korak nazad u odnosu na C++. Mislim da je, tehnički gledano, programski jezik D najkvalitetniji pokušaj "krpljenja" C++a, ali ne verujem da ima neke šanse da ikada postane "mainstream".

Naravno, tu je i druga strana medalje, koja je još važnija - tržište se zaista pomera ka Javi i C#-u i bilo bi suludo ignorisati te jezike ako nameravate da živite od programiranja.

da li bi hteo da malo elaboriraš na tu temu?

šta to ne valja C++u, kako to valja popraviti, i zašto to nisu uspeli java i c#?

Možda najinteresantniji citat o problemima C++a sam našao na jednom Java sajtu. Mada Java programeri često potežu potpuno pogrešne argumente kad kritikuju C++, ovaj tip zna šta priča:

http://www.theserverside.com/n...read.tss?thread_id=21924#98770



Ovo je ozbiljan problem. u jednom velikom projektu koji povremeno održavam, srećem se sa bar 5 različitih klasa za string. Tu su naravno MFC CString, standardan std::string i std::wstring, pa Xerces-ov DOMString, pa neki in-house stringovi, a i da ne pominjem stari, dobri char*. U poslednjih godinu dana, usvojili smo neke fine code standarde kojima se sprečavaju ovakve stvari u budućim projektima, međutim vrlo malo projekata počinjemo "od nule", već uglavnom nadograđujemo stare. Čak i u slučajevima kad krećemo iz početka, često želimo da koristimo neke gotove biblioteke i problem se opet javlja.

Uostalom, i sam Bjarne kaže:

http://www.research.att.com/~bs/bs_faq.html#really-say-that



E sad, kako su kreatori Jave i C#a "rešili" te probleme:

1) Iz jezika su izbacili sve što je po njihovom mišljenju "komplikovano", uključujući neke nesumnjivo korisne elemente (šabloni, const metodi, podrazumevani parametri višestruko nasleđivanje) i tako de facto napravili korak nazad. Sad vraćaju neke od tih elementata (generics), ali šteta je već napravljena - napisana je gomila koda koja se oslanja na prevaziđene metode generičkog programiranja i to treba održavati.

2) Usvojili su prevaziđen i rigidan objektni model po kome se sve trpa u jednu "kosmičku" hijerarhiju. Ovo onemogućava primenu modernih OO metodologija kao što su mixins-i i vodi nepotrebnom dupliranju koda. Ostavio sam neke interesantne linkove sa tim u vezi na temi o višestrukom nasleđivanju u Javi.

3) Vezali su jezike za obavezan, nedeterministički Gargbage Collector. Da se razumemo, ja nisam jedan od onih hardcore C supermena koji smatraju da pravi muškarci sami brinu o memoriji i drugim resursima. Naprotiv, automatska kontrola resursa je vrlo poželjna stvar - međutim rešenje koje nam nude i Java i .NET je jednostavno pogrešno i pruža lažnu sigurnost programeru dok se u suštini otvaraju vrata za razna curenja resursa. C# pruža dodatni mehanizam da zakrpi ovu rupu (IDispose interfejs), ali je to rešenje komplikovanije i rogobatnije nego čak i delete u C++u, a da i ne pominjemo čist i jednostavan RAII idiom (Googlajte malo ako niste čuli za RAII) koji stoji na raspolaganu C++ programerima (avaj, malo njih ga poznaje, a kamoli koristi). Posebna priča je što programi pisani u ovim jezicima u praksi "jedu" tolike količine memorije da je to često potpuno neprihvatljivo - posebno za desktop aplikacije.

4) Ogromne loše dizajnirane biblioteke koje sadrže sve i svašta i koje vremenom postaju pune "deprecated" klasa i metoda. Dobar primer za ovo je java.util.Date klasa:

http://java.sun.com/j2se/1.4.2/docs/api/java/util/Date.html

Od 6 konstruktora, 4 su "deprecated", a od 28 (ako sam dobro izbrojao) "običnih" metoda, 17 su "deprecated" !!!!! .NET klase za sad nemaju takvih problema jer su nove, međutim čekajte samo Visual Studio 2005 - kladim se da će taj fenomen da se pojavi.

Ne kažem, postoje i stvari koje mi se dopadaju, posebno kod C#-a, a jedna od njih je "kontrolisana virtualnost" sa new i override.

Najzad, da odgovorim na pitanje - ja ne bih "krpio" C++ - idealno bih voleo neki jezik koji sintaksom uopšte ne podseća na njega a nudi njegovu fleksibilnost i moć.

E sad si me stvarno povukao za jezik.

1) Prva stvar koja C++u nedostaje je class library. Standardni CRT je smesan, gomila stvari na koje treba da mozes da se oslonis jednostavno ne postoje. U C++u ne postoji standardan nacin da se *nista* uradi osim namestanja sistemskog vremena (), subseta rada sa fajlovima i najrudimentarnijih operacija na stringovima - koje su uzgred sada deprecated. Da ne pricamo o tome sto je ta biblioteka 'dizajnirana' pre koliko, 25 godina? Sta cemo sa biserima poput 'strtok'? Ako ces da pricas o losim bibiliotekama, C++ je tu najgore prosao - ako neko ima lose dizajnirane biblioteke, to je C++.

Ne znam na sta si mislio pod 'kosmickom hijerarhijom' - sistem namespaceova? To je mnogo bolje od sistema gde sve ide u globalni namespace osim 2% klasa ko je napisao neko ko se o tome brinuo.

2) Mulitple inheritence se ne preporucuje da se koristi ni u C++u (osim za interfejse - apstraktne klase) jer dovodi do vrlo zabavnih operacija gde ti se vrednost pointera menja u zavisnosti od nacina na koji mu pristupas. Jos ako pogledas iole moderniji sistem u kojima se klase izvode iz sistemskih baznih klasa (koje recimo rade serijalizaciju, i sta ti ja znam), MI postaje veliki problem. Ta prica kako je MI neophodan i kako bez toga propada svet se svodi na nekoliko edge caseova koji se resavaju containmentom.

3) Garbage collector: ah, omiljena diskusija. Najvise volim te price o 'laznoj sigurnosti', 'videcete vi', 'ko zna sta ti radi iza ledja' - to je upravo ta prica o pravom muskarcu koji u svakom trenutku zna tacno gde se nalaze njegova zena, auto i memorija. Dispose semantika je ista kao i delete, ali nju za razliku od C-a koristis u 1% slucajeva (za objekte koji moraju da se deterministicki releasuju), a ostatak radi automatski. Jako je tesko iskreno tvrditi da je to losije resenje...

Da svi ti managed jezici gutaju memoriju, gutaju. I u njima ne mozes danas da pises Word i Excel. Ali to i nije njihov cilj, ideja je da danas u njima pises poslovne aplikacije za koje to ima smisla, a za par godina kada masine budu imale par gigabajta memorije, onda ces moci i ostalo. Nikad neces moci da pises sve, ali kao sto sam rekao u nekom postu gore, crta ide na gore.

Slažem se, ali kao prvo CRT je C nasleđe, a kao drugo nisam ni pominjao C++ biblioteke kao uzor za dobre biblioteke, naprotiv. To i dalje ne znači da su .NET i Java biblioteke dobre.



Kosmička hijerarhija je prilično raširen naziv za Single-rooted hijerarhije.



A ko ga to ne preporučuje?

http://www.artima.com/intv/modern.html

"People quite correctly say that you don't need multiple inheritance, because anything you can do with multiple inheritance you can also do with single inheritance. You just use the delegation trick I mentioned. Furthermore, you don't need any inheritance at all, because anything you do with single inheritance you can also do without inheritance by forwarding through a class. Actually, you don't need any classes either, because you can do it all with pointers and data structures. But why would you want to do that? When is it convenient to use the language facilities? When would you prefer a workaround? I've seen cases where multiple inheritance is useful, and I've even seen cases where quite complicated multiple inheritance is useful. Generally, I prefer to use the facilities offered by the language to doing workarounds."



Probaj malo da pratiš C# forum na Code Projectu. Svaki čas se neko žali da mu baza prijavljuje da nema više konekcija ili da naprasno ne može da otvori neki fajl. Zašto se to dešava? Isključivo zato što su dizajneri .NET-a smatrali da je memorija jedini resurs o kome treba voditi računa. Niko ne može da me ubedi da je nedetrministički GC superiornije rešenje nego RAII osim u veoma specifičnim okolnostima.

Budući da vam na polju programskih jezika očigledno nisam dorastao, dozvolite mi da malo lupetam.

Java je interpreterski programski jezik (koji valjda ima i mogućnost kompajliranja), ali se u web svrhe koristi kao interpreterski jezik koji može da interpretira svaki web čitač koji ima podršku za Javu, a takav je danas svaki ozbiljan web čitač. Sa druge strane, C# je tzv. kompajlerski programski jezik koji web čitači ne mogu da interpretiraju. Dakle, on je u tom pogledu sličan jeziku C++, dok Java nije. Kako onda mogu Java i C# da budu konkurentni kada se koriste na sasvim različite načine?

pa nije baš tako.. Java VM (virtuelna mašina) i .NET CLR (common language runtime) su gotovo ekvivalentni što se tehnologije tiče. dobro, lažem malo, .net je malo napredniji (ili je bolje reći naštelovaniji) jer je rađen par godina kasnije, sa iskustvima koja su MS i drugi imali u implementacijama jave (i zbog činjenice da nisu morali da brinu o kompatibilnosti sa starijim verzijama).

oba jezika se mogu i interpretirati, ali češće se radi JIT (just in time) kompajliranje, tj kompajliranje iz "bajtkoda" u native mašinske instrukcije platforme, neposredno pre izvršavanja (ima smisla zašto, ali nije za ovu priču).

usput, .net poseduje i nešto što se zove AOT (ahead of time) kompajliranje, što znači pre pokretanja aplikacije (recimo pri instalaciji, ili tako nešto), što je moguće odraditi i za javu (valjda postoje takvi alati), ali se u praxi ne koristi, jer je to totalno u suprotnosti sa osnovnim javinim postulatom (write/compile once, run everywhere).

e sad, tebe je najviše zbunilo što za javu postoji JVM plugin za browsere, a za .net ne postoji. to ne znači apsolutno ništa, jer je moguće napraviti plugin i za .net u browserima (što će se najverovatnije i desiti sa internet explorerom u novoj verziji windowsa).

U svakom clučaju, po pitanju brzine se ni nedan od tih jezika ne može trkati sa jezikom C++ na kome se i dan danas pišu video igre. Po čemu onda ti jezici rete da zamene C++ ?

Po tome sto igre ne cine trziste. Najveci deo programiranja danas se radi po internim IT departmentima firmi, i to je trziste na koje ova dva jezika ciljaju. Procitaj ponovo thread, videces o cemu se radi.

Uzgred, relativna sporost Jave i .NETa u odnosu na native kod proizilazi iz memory managementa, a ne iz bytecodea.

Koliko te shvatam, ti govoriš o softveru koji se radi po narudžbini. Ako govorimo o gotovom komercijalnom softveru (recimo velikihsoftverskih kompanija), onda su tržište operativnih sistema, tržište knacelarijskih alata i tržište video igara tri najveća softverska tržišta.

Takođe, ako sam te dobro razumeo, jezici Java, C++ i C# se ne koriste za baš iste stvari, ali im se namena delimično preoklapa, to jest postoje poslovi na kojima su međusobno konkurentni i tu se uloga jezika C++ smanjuje.

Da li sam vas sada bolje razumeo?

Da, tako je. Obojica se potpuno slazemo jedan sa drugim :)

Iako je trziste komercijalnog softvera najvece po kolicini para, ono je relativno malo po broju ljudi. Ako uzmes da jedan Microsoft ima nekoliko hiljada programera, to nije nista nasuprot armijama programera po firmama koji prave raznorazne access front endove.

Tu se najvise i oseca taj opad popularnosti Ca. Primera radi, danas je mnogo teze u Beogradu naci C posao nego sto je to bilo pre recimo 5 godina. Naravno, to ima veze sa vrstom softverske industrije koje cveta kod nas, kao i sa tim sto generalno u Evropi i nema mnogo gotovog komercijalnog softvera (koji se mahom pise u Cu) i sam tim i poslova u toj oblasti. To je ujedno i najveca razlika izmedju programiranja u Evropi i Americi.

Da se vratim na preklapanje namene - postoji tendencija da se ta oblast gde se preklapaju namene Ca i ostalih jezika povecava na stetu Ca zbog rasta hardvera. Sa brzim hardverom optimizacija i brzina vecine klasa softvera postaje sve manje bitna, i tu onda polako ulecu managed jezici.

Naravno, ne radi se niokakvoj revoluciji preko noci, niti o tome da ce sutra biti sve zajedno 15 C poslova na svetu (i da ce svi oni biti u Redmondu), vec o jednom sporom procesu koji je ponovo krenuo - vec smo ga vidjali ranije. C nece izumreti, ali ce verovatno biti marginalizovan, a posle je samo stvar dogovora gde je crta u % trzista poslova ispod koje se neki jezik moze smatrati prakticno mrtav.

Nekada je pod operativnim sistemom MS DOS postojao programski jezik Clipper koji je bio specijalizovan za baze podataka. Clipper kompajler je zapravo proizvodio pseudokod koji je interpretirao interpreter ugrađen u svaki bogovetni izvršni fajl koji je proizveo taj kompajler.

Pseudokod je neka vrsta mašinski nezavisnog koda koji je optimizovan za brzo izvršavanje, a ne za čitanje i menjanje od strane programera, kao što je to slučaj sa čistim interpreterskim jezicima gde se program poklapa sa sorsom. Naravno, interpreter pseudokoda je mašinski zavisan.

No, takav kod se ne može po brzini meriti sa mašinski zavisnim kodom koji proizvede kompajler nekog čistog komajlerskog jezika, ali se izvršava mnogo brže od programa pisanih na čistim interpreterskim jezicima.

Čisto sumnjam da izvršavanje programa u okviru plugin-ova ne usporava program u odnosu na izvršavanje mašinski zavisnog programa koji je generisao kompajler čistog kompajlerskog jezika, ali ako jezici Java i C# dopuštaju kompajliranje tako da s dobije klasičan mašinski zavisan .exe fajl (kao da je rađeno nu nekom čisto kompajlerskom jeziku), onda si svakako u pravu.

Upravo se o tome radi. I .NET i Java kompajliraju svoj bytecode u native masinski kod prilikom ucitavanja programa. To znaci da ucitavanje traje duze, ali to je jednokratna stvar, i obicno nije problem. .NET cak ima i mogucnost da se program iskompajlira za vreme instalacije.

Ali kao sto sam rekao ranije, memory management je veci problem. Zato je i MC++ vrlo interesantan - to je C++ koji moze ali ne mora da koristi GC, a kompajlira se u bytecode. Znaci mozes da uzmes najobicniji C kod sa new/delete i da dobijes .NET bytecode. E to vec ne bi trebalo da bude bitno sporije od obicnog Ca.

A mislim da je i najbrzi tu u konkurenciji Java VS C# VS D

http://www.digitalmars.com/d/

Relja, hvala na odgovoru, a da li bi mogao da mi objasniš pojmove bytecode i GC?



Koji je najbrži?

Bytecode je taj 'metaasembler' u koji se kompajliraju Java i .NET jezici. To je nesto sto lici na asembler, samo je dosta viseg nivoa. Pred izvrsavanje programa se bytecode iskompajlira u pravi native asembler za konkretnu masinu.

GC je garbage collector, to je ono sto povremeno pauzira .NET porgram i krece da brise memoriju koja se vise ne koristi.

jos pohadjam srednju skolu i moje misljenje je da c/c++ kao jezik nikad nece izumrjet ili past u zaborav... na to me navelo nekoliko stvari... imam dosta prijatelja koji se bave programiranjem (uce programirati) i to bas u tim jezicima, u skolama koje imaju informatiku 4 godine uce upravo ti jezici, svake godine odrzava se nekoliko natjecanja u tim jezicima, na faksevima se uce ti jezici...

kako ja to vidim c & cpp nikad nece sici s scene vec njihova primjena moze biti samo umanjena... znam da nisam rekao nista novo ali morao sam iznjeti svoje misljenje

A koje su prednosti bytecode-a nad normalnim mašinski zavisnim kodom? Može li .NET da proizvede .exe fajl sa najnormalnijim mašinskim kodom, pa da se program učitava brže?

Nisam neki ekspert za programske jezike, ali čini mi se da je izrečeno par nepreciznih tvrđenja o javi. Ako grešim ispravite me.

Pominje se da JVM radi JIT, međutim to nije podrazumevan režim rada još od prošlog milenijuma. Ukoliko se ne navede opcija -server radi se u client odnosno hotspot modu. JVM interpretira bajtkod sve dok ne naiđe na usko grlo ili ti bottleneck, hotspot. Tada se taj deo koda kompajlira u mašinski.

Javini stručnjaci misle da je ovo najbolji režim rada. Najstarije JVM su isključivo interpretirale bajtkod što je bilo presporo. Sledeća generacija JVM je sve kompajlirala u startu što je dovodilo do sporog pokretanja programa i velike upotrebe memorije.

C#VM još koristi JIT kompajliranje.

Današnje JVM rade GC u prilagodljivom modu. Kada se pravi velika količina "smeća" koristi se "stop and copy" pristup kada se izvršavanje programa zaustavlja da bi se pokupilo smeće. Ako se ne pravi mnogo smeća tada se VM prilagođava i koristi 2. tehniku skupljanja smeća "mark and sweep" koja ne stopira program.

Zar se java ne koristi i za programiranje nekih običnih desktop aplikacija? Ja sam čuo da je OpenOffice.org u njoj napisan kao i SPSS pa čak i simulaciona igra IL-2M Sturmovik. I po meni jedan od najboljih free editora jEdit je čedo jave, a da ne pominjem UML alate i alate za java programiranje.

Ne znam za ostale, ali OpenOffice je napisan u C++-u.

dobro zlatko, u pravu si oko JVMa, ali to nije bilo toliko bitno, tj nismo hteli da širimo priču na tu stranu..

nego, nedeljko je pokrenuo otprilike isto pitanje koje sam ja hteo da postavim..

za Javu je bytecode bitan, jer omogućava izvršavanje aplikacije na svakoj platformi. nasuprot tome, .NET cilja na jednu do dve platforme (čak i ako računamo i mobilne uređaje), tako da mi uopšte nije jasna svrha postojanja bajtkoda u istom.

GC može da se implementira i bez njega, kao što i postoje C++ biblioteke sa GCom.

takođe, menaged api je moguđe sprovesti i bez bajtkoda, ako se koriste samo indirektni načini pristupa resursima/memoriji. na primer, bounds checking na nizovima u toku izvršavanja programa (runtime) je vrlo lako moguće dobiti čak i sa običnom C++ kompajlerom.

čak ni RTTI nije nemoguć sa kompajliranim jezicima, recimo delphi ima to još odaaavno.

dakle reljam, jer možeš navedeš bar jedan dobar razlog za korišćenje bajtkoda u .NET?

MS navodi mnoge razloge, od kojih neki stoje, a neki kao što si i sam napomenuo baš i ne stoje, ali je po mom mišljenju ključna stvar sigurnost. Sa VM-om je lakše sprečiti "zao" kod da čini razne nepodopštine.

U stvari ono sto pitate je zasto se konacni JIT korak ne obavi prilikom samog builda, vec se radi prilikom instalacije ili startovanja.

Ima nekoliko razloga - nezavisnost od frameworka, podrska za vise platformi, optimizacija za konkretan procesor, mali fajlovi. Windows se danas vrti na tri platforme (x86, x64, ia64), i to je neracunajuci gomilu CE varijanti i raznoraznih drugih MS embedded uredjaja (VoIP telefoni, bankomati, BMWovi :)).

Nezavisnost od frameworka znaci da ti mozes da pokrenes da program pisan za v1.0 na frameworku v1.1 i da dobijes sve security fixove i optimizacije koje su sredjene u novoj verziji. Slicnu stvar je moguce uraditi samo na nivou DLLova, ali to ti ne resava problem nekih malo centralnijih stvari kao sto su recimo reflection, koji je deo samo jezika i kao takav ne bi lako mogao da ga izdvojis u DLL.

Optimizacija za konkretan procesor je takodje zanimljiva stvar. Ako ja danas napisem .NET program, ja cu sutra moci da ga pokrenem na Pentiumu V i odgovarajucem frameworku, i sve ce da radi sa novim instrukcijama / velicinom kesa / cime vec. Ako bi se program direktno kompajlirao u native, onda bi zauvek ostao na verziji za koju je kompajliran. Bas zbog toga gomila programa danas radi sporije jer mora da targetuje instruction set od recimo Pentiuma II da bi svuda radila. Jako je malo programa gde dobijes odvojenu verziju za Athlon, odvojenu za Pentium II i odvojenu za Pentium IV. Sa JITovanjem uvek dobijas odgovarajucu verziju.

Konacno, fajlovi su mnogo, mnogo manji. Mali .NET EXEi su nekoliko kilobajta i to bez kompresije. Srednji .NET programi sa par prozora itd, su obicno reda velicine dvadesetak kilobajta sto je jako malo. Za godinu-dve ce svako imati na masini .NET framework, i onda ces moci da distribuiras samo jedan mali EXE koji se zipuje na desetak kilobajta.

Sve u svemu JITovanje je Dobra Stvar, ali zato i postoji opcija da se JITuje prilikom instalacije da ne bi moralo svaki put kada se startuje program. JITovanje je doduse dovoljno brzo da i nije neki problem osim ako nemas neki program koji pozivas desetine puta u sekundi - za tako nesto je bolje da ga JITujes prilikom instalacije, ili da redizajniras sistem tako da ne dize novi proces toliko cesto.

Čisto da napomenem da pomoću alata Dev C++ 4 može da se napravi kompletna MDI aplikacija veličine 10K bez ikakvog .NET Framework-a i bytecode-a. Pritom, ta MDI aplikacija ne zahteva nikakve dodatne .dll fajlove da bi radila. Štos je u tome što je cela funkcionalnost Windows-a već isprogramirana u Win API-ju koji je uključen u Windows (koji drugačije ne bi mogao da radi), pa samim tim nema potrebe da se taj kod uključuje u sam program, već program sadrži samo kod koji poziva Win API.

Svaki kompajler ima biblioteku funkcija koje ugrađuje u svaki bogovetni .exe fajl, i biblioteke koje uključuje samo ako se to eksplicitno traži. Što je ona prva biblioteka manja, to su programi sa osnovnom funkcionalnošću manji, ali je češće potrebno tražiti uključivanje neke druge biblioteke da bi se koristile neke funkcije.

E sad, mana Win API-ja je na primer što nije objektno orjentisan, pa se teže koristi. Stotga su napravljeni objektni omotači oko Win API-ja kao što su OWL, MFC, VCL i CLX, koji su povećavali veličinu izvršnog fajla koji je bio opterećen tim bibliotekama budući da ni jedna od njih nije nikada bila standardni deo Windows-a kao Win API. Čak i ako .NET Framework postane sastavni deo Windows-a kao Direct X, sačekajte samo da i on dobije svoj omotač, pa da vidite kako će .exe fajlovi ponovo da se goje.

Zašto se koristi VM i bajtkod?
Prvo radi politike kompajliraj jednom teraj svugde. To baš nije potrebno MS-u, ali je javi veoma važno.
Radi sigurnosti jer se ipak čitav program odvija u VM-u koja služi kao sandbox.
Program je mnogo manji nego exe varijanta, sto je za mreže potrebno. Npr. slanje objekata preko mreže, ranije je bilo primanje appleta, iyvršavanje koda ne nekim prenosnim uređajima...
VM optimizira izvršavanje bajtkoda za svaku mašinu, OS, i svaku priliku. Dakle ako se isti program pokrene nekoliko puta on će svaki put biti rayličito optimiziran zavisno koji se delovi koriste. Ako se ne koristi neki deo programa koji je u nekoj odvojenoj klasi, ta se klasa neće ni učitati.
Bajtkod može da se dobije kompajliranjem raznih programskih jezika. To je ono na šta se .NET fura. Kada su MS-ovci prezentovali na faxu tu revolucionarnu tehnologiju pominjali su čak i da se klase pisane u COBOL-u mogu koristiti u .NET-u. To je i ranije moglo da se radi korisćenjem CORBA i sl. ali je ovako mnogo jednostavnije i sigurnije. Čak i JVM može slično, npr. da se python kod kompajlira u javin bajtkod i/ili da se u pythonu koriste javine klase.

Jel'? Odakle ti to... Pogledaj moj post gore. Portabilnost na razlicitim platformama jeste bitan scenario za MS.

Čini mi se da je Au197/97 u pravu. MS prodaje softver zatvorenog koda za nekoliko tačno određenih platformi tako da mu ne treba kompatibilnost na nivou izvršnog koda, već samo na nivou sorsa, budući da je onda sors lako iskompajlirati za nekoliko ciljnih platformi.

1. U igri IL2 Java je koriscenja kao script-jezik, odnosno za kontrolu toka igre. Low-level/mission-critical stvari (engine) su u C++u.

2. jEdit je fenomenalan editor, ali je spor do bola, zahvaljujuci vec pomenutoj javi :)

Može i uz pomoć VC++a. Ja sam nedavno napravio jednu stand-alone aplikacijicu (dobro, nije baš MDI) od 4k - naravno nisam linkovao CRT. Uz pomoć ATLa i WTLa je moguće praviti gotovo podjednako male aplikacije u OO/generičkom maniru.