Back to site
Since 2004, our University project has become the Internet's most widespread web hosting directory. Here we like to talk a lot about web servers, web development, networking and security services. It is, after all, our expertise. To make things better we've launched this science section with the free access to educational resources and important scientific material translated to different languages.

Intervju sa Bjarne Stroustrup~om


Dr. Carlo Pescio


Ovo je originalni intervju na engleskom sa Bjarnom Stroustrupom,koji je kasnije preveden na italijanski i objavljen u 50.broju kompjuterskog programiranja u septembru 1996.Pratite ovaj link za prevodjenje .U narednom tekstu,CP predstavlja Carlo Pescio a BS Bjarne Stroustrup.

CP:Da li ste zadovoljni rezultatima i tempom C + + za standardizaciju napora?Po mom misljenju to je s jedne strane dokaz uspeha jezika,ali sa druge strane to je dodalo dosta birokratije.Da li vam nedostaje početna sloboda koju ste imali o kljucnim jezickim pitanjima?

BS:Naravno,moje strpljenje je bilo krajnje testirano ali i veliko,ja sam zadovoljan ishodom C + + standardizacije napora.Sa malim izuzetcima,IOS će imati karakteristike koje mislim da su zaista potrebne i da nece biti pronadjena nijedna mana.ISO C + + je mnogo moćniji i koherentniji jezik u odnosu na rane verzije C + + i nema glavnih karakteristika koje su dodate da ja nisam radio ili odobrio.Neki detalji o ISO C + + mogu pokazivati znake "dizajn odbora",ali ukupan skup objekata je bolji rezultat za moj originalni prikaz onoga što bi C + + trebalo da bude u odnosu na ranije jezicke verzije.

Glavni razlog što sam uzeo deo standardizacije napora je sto je odbor sazvan pre nego što sam bio u stanju da završim jezik.C + +,bi bez šablona i izuzetaka bio neprihvatljiv,kao i C + + bez prostora za imena i run-time tipa informacija jer bi nas ucinio mnogo siromašnijim u odnosu na danas.

Lako je preuveličavati svoju prvobitnu "slobodu".Odlučio sam na pocetku da zelim da moj jezik bude kompatibilan sa C i zeleo sam da podrži prave korisnike.Ovo ograničava ono šta sam mogao da uradim.Mislim alternativa bi bila da osmisle još jedan kultni jezik.Ne mogu da čekam da standard postane kompletan.C + + zajednici treba solidan standard a meni treba vreme koje sam imao da posvetim standardima napora tokom poslednjih šest godina.Mislim da je jezik značajno profitirao od mojih napora u odboru standarda.Ja sam bio predsednik prosirenja pod odbora koji obrađuju sve zahteve za proširenja i druge veće promene u jeziku i koji je generalno uključen u većinu glavnih pitanja-uključujući dizajn standardne biblioteke.Standardizacija je neophodna za jezik koji ima toliki broj korisnika kao sto ima C + + .Međutim,ja to ne bih doslovno nazvao standardizacijom.Mnogo kredita-mnogo više kredita nego što se obično dodeljuje "bezličnim odborima"-treba da idu desetinama ljudi koji su volontirali i ulozili vreme i veoma značajne napore za standarde iz godine u godinu.Dokumentovao sam mnoga njihova imena i napore,koje sam naveo u svojoj nedavno objavljenoj knjizi "The Design and Evolution of C + +"(koja se obično zove D & D).

CP:Mnogo čitalaca bi volelo da zna da li postoji neki"C + + jezik - 3D izdanje" ili drugo izdanje ARM ...

BS:Ja radim na trecem izdanju i razmišljam o nečemu sto bi moglo da zameni ARM.Međutim,ja ne vidim tačku u pisanju nove knjige,imam mnogo novih stvari koje zelim da kažem,pa je napredak spor.Moj cilj je da se trece izdanje poboljša u odnosu na moje drugo izdanje kao sto je to ucinilo drugo u odnosu na prvo izdanje.Drugim rečima,želim da proizvedem nešto još pristupačnije drugom izdanju ali ce sadržati informacije koje će biti nove i u sustini uzbudljive svakom C + + programeru.Ja ne mogu da predvidim kada cu zavrsiti,ali niko kome treba dobar udžbenik ne treba da čeka trece izdanje.Drugo izdanje je i dalje jedan od najkompletnijih udzbenika,temeljno,i do dana danasnjeg udzbenik koji je na raspolaganju.Naravno,ja ne mogu objaviti zamenu za ARM dok je standard u pribelesci.Dok ne dobijem te napisane knjige,D & E je najbolji izvor informacija o novim funkcijama i razlozima posebnosti dizajna C + + generalno.

CP:Da li u retrospektivi postoje tehničke odluke koje želite da promenite u C + + - ne nešto što nije imalo načina da bude prihvaceno,već nešto što je dodatnim iskustvom dokazano da je na neki nacin mana,i da želite da promenite ako za to imate priliku(čak i ako danas nije moguće zbog kompatibilnih razloga).

BS:Postoji puno detalja,kojima bi voleo da se vodim,ali ne postoje osnovne karakteristike koje bih želeo da izbrišem(cak i kad bih mogao)ili glavne karakteristike koje svakako volim i znam kako da ih dodam.Kada ljudi pitaju ovakva pitanja,obično imaju na umu nesto kao što su MUP i RTTI, pa mi dozvolite da kazem da bi C + + bez jednog od njih bio siromašniji jezik.Ja koristim oba intenzivno a zaobilaznice koristim samo ako ne postoje neke lepe precice.Naravno primeri i objašnjenja su u D & E.

CP:Zapravo,ja sam uglavnom imao[promene]virtuelne funkcije u vidu:na primer,ja nisam baš ljubitelj činjenice da virtuelna funkcija može biti redefinisana u *privatnu* izvedenu klasu .Funkcija nije dostupna-ipak je redefinisana;to malo dočarava svrsishodnost i bezbednost privatnog nasleđa.

U većoj meri,verovatno se sećate Sakkinen~sovih radova "nasledstvo principa C + +": on je napravio neke fine poene,a meni se posebno svidja činjenica da [pod mnogim restriktivnim pravilima] niko ne bi morao da proširi odgovornost pozivajući se konstruktor jednog virtuelnog bazne klase dalje od "neophodnog" u nasleđivanju grafikona.U stvari,dok sam razumeo razloge aktuelnih pravila za VBC u C + +,moram da priznam da je u izvesnom smislu,pozivajući se na jednog konstruktora za VBC,slabi enkapsulacija srednje klase.S druge strane,mi znamo jake i slabe tačke C + + kroz godine upotrebe-i verovatno Sakkinen~ovi predlozi bi odveli samo ka drugim slabim tačakama,i ako ih volim onoliko koliko je "programiranje stila" zabrinjavajuce.

BS:Fundamentalno,ova pitanja smatram čisto akademskim i bez interesa praktičnog programiranja.Možda jeste moguce da konstruktor dizajnira zlonameran pristup informacijama,ali da pokrene svoje podatke u osnovi jeste bezopasano.Štaviše,ako je virtuelna osnovna klasa u javnosti-kao što ja uvek preporučujem-sve klase bi trebalo da znate da postoje i njihov konstruktor bi trebao da ocekuje da bude prozvan.U ovome,baze virtuelne klase se ne razlikuju od drugih baza. Ako je virtuelna baza proglašena negde kao privatna i javna negde drugde i ako je većina izvedenih klasa koje ga pokreću na način koji iznenađuje pisca privatne virtuelne baze, pretpostavljam da je "enkapsulacija bezbednosti srednji klase" oslabljena.Međutim,ako je to neciji najveci problem,taj neko bi trebao da bude istinski blagosloven.

Ne vidim nikakav problem sa prevashodnom virtuelnom funkcijom,privatne funkcije ili iz baze u kojoj je baza.Ako razmotrimo osnovne klase interface~a,to nije zabrinjavajuce za korisnike tog interface~a kako njeni implementatori(izvedene klase)daju svoje implementacije.Mislim da je lako zamisliti izvedenu klasu koja čini njene bitne funkcije prihvatljive upravo da bi sprečile korišćenje izvedene klase,ovim putem koji je upravo interface~u bazne klase i da spreči dalje izvođenje.Ako je baza privatna,još uvek može biti dostupna prijateljima,ili izvedene klase mogu deliti savete svoje (privatne)baze na zahtev korisnika.Na primer,izvedena klasa može da vrati svoj interface osnovne klase,kao rezultat jedne operacije koja je objavljena na nivou sistema pristupa provere kontrole.
class A
  {
  virtual void f() ;
  } ;

class B : private A
  {
  void f(); // implementation 
  A* get_A(Rights& r) { /* check rights */ return (*A)this; }
  } ;
CP:Sa druge strane,privatno nasleđe nije tranzitivno,tako da u slučaju kao što su:.
class A
  {
  virtual void f() ;
  } ; 

class B : private A
  {
  void h() { f() ; }
  } ; 

class C : public B
  {
  virtual void f() ;
  } 
Klasa A nije interface za klasu C, A :: f () nije dostupna u C,ali je redefinisana u klasi C.Upravo smo mogli reći da je krivac implementator klase C,koji je bazirao svoju šifru na detaljima realizacije klase B(Činjenica da klasa B-sprovodi-pomoću klase A).Neki bi možda želeli da imaju tu jezicku zabranu ...

BS:Da,to je prljav primer.Međutim,nije lako znati skup pravila koja zabranju svaki prljav primer takođe bez ucinjene štete zabranom primera koji neki smatraju neurednim,dok drugi istovremeno smatraju od suštinskog značaja za njihov rad.U principu,ja sam protiv ograničenja za koja ne vidim praktičnu svrhu.Ne smatram da je ortogonalnost primarni cilj dizajna,ali svakako to preferiram kad god ne postoje razlozi prvog reda za nepoštovanje ortogonalnosti.Pravila pristupa C + + su veoma ortogonalna(sa pravilima imenovanja,prevashodnim pravila,itd.),i ne vidim jak razlog da ne bude tako.Ljudi mogu da budu iznenađeni sa pravilima,ali su na taj nacin mogli da prihvate manje ortogonalna pravila.

CP:Razumem vaše mišljenje i slažem se u velikoj meri sa njim.Zato sam rekao da ova vrsta "vladavine" može biti dobra dokle god je "programiranje stila" u pitanju.Sigurno postoje trenuci kada tako nešto može biti od koristi(na primer,u ponovnim bibliotekama bez izvornog koda),i u tom slučaju može se "kršiti pravilo" i uradi to, jer C + + nije majčinski,restriktivni jezik.

BS:Voleo bi da je C + + sposobniji da uhvati logičke greške napravljene od strane programera. Uostalom,mnoge od C + + funkcija imaju tačno taj efekat u poredjenju na ono šta bi morali da pišete u C da bi izvrši ekvivalentnu akciju.Međutim,ja ne mislim da bezbednost moze da se kupi po ceni od izraza komplikacija i dobrih rešenja do stvarnih životnih problema.Ovo i kompatibilnost brige-jesu ograničenja koja mogu učiniti i sam jezik cistijim.Preporučujem da koristite biblioteke kako biste ucinili C + + sigurnijim za specifične aplikacije.Na primer,ako neko brine o tome sto domet C nizova nisu provereni,oni bi trebali da koriste spektar provere klase vektora.Ja to radim većinu vremena lično sebi,naročito za debagovanje.

CP:Idemo nazad na retrospektivi u C + + ...

BS:Za dobre i loše,ja zadrzavam visok stepen C kompatibilnosti buduci da od najranijih dana C + + i odbor za standarde pratio moj ``što bliže C moguće~ali ne bliže'' politiku.Mnoge stvari u C + + mogu biti bolje sa jezicko tehnoloske tačke gledišta,ali to nije realno.Kada sam počeo,odlucio sam se za kompatibilnost i pokušao da zivim najbolje sto sam mogao sa manama drugog reda,fiksiranjem samo za probleme koji su vezani za tip sistema.Alternativa bi trebala da izgradi još jedan kultni jezik:Lep u očima svojih pristalica i koji bi izazivao ništa više paznje od gotovo svih onih koji su pokrenuli program da bi dobili rezultat.Da C nije tu da bude kompatibilan,ja bih izabrao neki drugi jezik,negde drugo sa kim bi bio kompatibilan.Bio sam i jos uvek sam uveren da moje vreme ne bi bilo dobro potrošeno izmisljanjem još jednog načina pisanja.

Konkurentnost je pitanje koje stalno nadolazi.Vecina ljudi voli neki oblik konkurentnosti koji bi zeleli da vide u direktnoj podrsci C + +.Međutim,ne postoji jedan oblik konkurentnost,koji služi više kao mali razlomak C + + programerima kojima je potrebna zaista dobra konkurentnost.Operativnim piscima treba jedan oblik konkurentnosti,korisnicima baze podataka neki drugi,i realizatorima mrezne aplikacije još jedan.Tako sam odlučio da ne uključim specifične karakteristike koje podržavaju konkurentnost u C + +.Ljudi koji žele neki oblik konkurentnosti mogu i ne moraju da podrže kroz jezicke nastavke(poželjne) preko biblioteke.Odbor za standarde me je takodje podržao po tom pitanju;znali smo mnoge atraktivne konkurentske seme,ali ne onu koja bi mogla da služi velikoj većini korisnika u C + +.Opseg oblasti gde se koristi C + + je zaista neverovatan.

Bio sam zamoljen da napišem članak o C + + za ACM-ovu drugu konferenciju o istoriji programskih jezika(oni imaju jednu konferenciju na svakih 15 godina!).Za tu konferenciju,bio sam pitan šta smatram svojom najvećom greškom sa C + +.U mojoj glavi nije bilo samo jedan kandidat za titulu "Najgora greška".Nisam uspeo da proizvedem prihvatljiv temeljac za biblioteku i da je posaljem sa 1,0 1985 godine.Moj izgovor je bio da nisam znao kako da napišem dovoljno dobru biblioteku i da je potrebno da se obezbedi efikasan šablon,fleksibilne i bezbedne kontejnere. Rezultat te greške je trenutna zbrka nekompatibilnih osnivackih biblioteka razlicite filozofije i kvaliteta.

Srećom,standardni komitet je bio u stanju da se dogovori o odličnoj standardnoj biblioteci.Mi sada imamo ono što nisam mogao da proizvedem i nešto što nisam znao kako da dizajniram i sprovem pre deset godina.Okvir kontejnera i osnovnih algoritama koji cine veliki deo standardne biblioteke je pre svega rad Aleksa Stepanova.To zapravo ima neke korene u našoj potrazi za principima i tehnikama za dobre komponente biblioteka u godinama pre i posle puštanja 1,0,tako da kašnjenje nije potpuno izgubilo funkciju.

CP:Kao što znate postoje predlozi da se nekim od funkcija C + + doda C9k,na primer ograničena podrška za nastavu.Imao sam utisak naivnog pristupa,npr. nemaju izvođača radova,dodelu preopterećenja i tako dalje.Koji je vaš stav o "novom ANSI C"informacije?

BS:Karakteristika nije izgledala naivno iz moje perspektive i ispunjena je objašnjenjima koja im daju izgled da odražavaju nedostatak apresijacije kako bi se C + + razvio kao povratni odgovor.Imao sam(i još uvek imam)opšti pogled na ono što je jezik trebao da uradi,ali u okviru tog opšteg gledišta,bio sam oprezan pri trazenju povratne informacije o jeziku iz razloga sto evoluira,da bi prilagodio svoje funkcije realnom iskustvu i potrebama.

Pokušaj da mali podskup funkcija iz C++ obezbedi "mnogo jednostavniji jezik sa skoro svim mocima C + +" je po mom mišljenju bio osuđen na propast.Osim u slucaju veoma pazljivog odabira na osnovu stvarnog iskustva,osobine će samo delimično da podrže koherentne stilove programiranja i jedna funkcija će voditi ka drugoj-samo kada je vođen ukupnim pogledom dizajna i stilova programiranja koji ce biti direktno podržani sa dodatcima koji ce dovesti do koherentanog jezika.

Ne bi bilo razumno od mene da pokusam da kažem kako bi C zajednica trebala da standardizuje svoj jezik.Da jesam,moj savet verovatno ne bi bio dobrodošao u svakom slučaju, zato sto su ljudi koji bi vrednovali moj savet većinom programeri u C + + .C zajednica će učiniti ono što želi sa C i verovatno znaju sta je najbolje za njihovu osnovnu zajednicu,bilo koje ekstenzije koje su kompatibilne sa C + + su uopste moguće.Programiranju zajednice nije potreban još jedan nekompatibilan C dijalekt.K&R C nije mrtav,ANSI C će trajati dugo nakon objavljivanja novog standarda,a različita godista C + + će takođe postojati i nakon što C + + standard postane zvaničan.Stvari uvek traju duže nego što mislimo da ce trajati,i duze nego sto smo želeli.Nove funkcije u C9k će nužno postati dodatni izvor nestabilnosti u C i C + + zajednici.

CP:Govoreci o sinovima C + +-a,ne mogu da izbegnem da pomenem Java~u ... Koliko je po vašem mišljenju velik voz efekat,i gde vidite(bilo gde) prave snage Jave?Znam da ste kao jezicki dizajner veoma oprezni u kritikovanju jezika-nekako"svaki jezik ima nišu"-ali šta su vaši unutrasnji osećaji?

BS:Java ima C + +-kao sintaksu,ali fundamentalno drugačiji jezik podržava drugačiju kulturu i (prilično uzak)spektar razlicitih programskih stilova.Java u ovom trenutku svakako nije C + +.Kao jezik koji sam dizajnirao u odsustvu kompatibilnosti ograničenja.Trenutno Java vozi sa neverovatno visokim ocekivanjima,Sun marketing novac i njegova integracija sa Veb~om.Vreme će pokazati kako će proći generalno kao svrha opste namene jezika,i kako ce većina programera i menadžera reagovati kada otkriju da "bezbednost" Jave i posebno Javascript~a ostaju samo kao zelja.Ljudi mešaju programski jezik bezbednosnog tipa(koji pruza ispravnu Java implementaciju)sa sigurnoscu,a to je očuvanje integriteta sistema i privatnosti(što može biti ozbiljno ugroženo korišćenjem Java).Naši ljudi iz obezbedjenja u sali kazu da se odnose prema Javi kao "jeziku virusa implementacije",a preporuka je da koristimo Java i Javascript iskljucene u našim net browsers~ima.Nazad na programiranje jezičkih pitanja:

C + +

- je bolji C

- podržava apstrakcije podatka

- podržava objektno orijentisane programe

- podržava generička programiranja

Od ovih,Java pokriva samo objektno orijentisani deo,i to radi na način na koji se značajno razlikuje od C + +.

CP:Neki od najnovijih C + + dodataka su korisceni ali mali detalji-eksplicitano,promenljivo-ili "bekstvo iz C" funkcije kao novi stil odlivaka.Da li vidite bilo kakvu budućnost za više dizajn orijentisanih funkcija u jeziku?Na primer,možda postoje neke dragocene inspiracije za projekte poput Annotated C + + ili Larch-C + +,naklonjena više prema povratnim specifikacijama a manje na kodiranju nivoa ili jos načina da se doda još neka semantika-na primer napraviti objekat-jasnije podele odluka Ili je vaša namera da ojačate jezik tamo gde je već jak-u sistemu za programiranje, performansama kritične oblasti programiranja?

BS:C + + je deo opšteg pomaka ka više deklarativnih stilova.Međutim,koliko to dotice zvaničnu definiciju jezika u smislu promena na jeziku i standardne biblioteke,sada mora da prestane sa realizatorima,korisnicima,nastavnicima,itd.,šansom da se nadoknadi.Naravno,eksperimentisanje će nastaviti(mada najverovatnije ne od mene),ali po mom mišljenju,C + + programerskoj zajednici je neophodna stabilnost više nego bilo šta drugo.C + + je sada završena i koherentna u onome sto jeste,dalji rad će morati da ostane u pod-zajednici(kao što je akademija)za nekoliko godina unapred.

Mislim da većina ljudi da pocne da ceni snage predloških mehanizma za različite specifikacijie.Na primer,ovde je prikazano kako neko može da definise listu,tako da jednu implementaciju deli svim listama pokazivača:

// general list<T>:

template<class T> class list { /* ... */ };

// specialization for lists of void*:

template<> class list<void*> { /* ... */ };

// general list of pointers (implemented using list<void*>):

template<class T> class list<T*> : list<void*> { /* ... */ };

Specijalizacija mehanizma koji se ovde koristi omogućava različitim implementacijama da budu izabrane(koristeći odbitak),dok i dalje obezbeđuje korisnika sa jednim opštim interface~om.Jedan važan aspekt ovoga je da jača deklarativnu prirodu C + + programiranja,dok pojednostavljuje interface korisniku i poboljšava efikasnost run-time~a.Takve tehnike u standardnoj biblioteci nam omogućavaju da se obezbedi jedna opsta sort()rutina koja je za pravi primer nadmašila C standardnu biblioteku sort () za faktor sedam.

CP:U IEEE Computer,februar 95,prof Wirth je oznacio C + + kao "jezik koji obeshrabruje strukturu razmišljanja i disciplinovanu izgradnju programiranja".Ne mogu da kažem da se slažem,ili da pronalazim Oberon podsticaje kao više struktuirano i disciplinovano od C + +,ali postoji li nešto što bi ste želeli da priznate puristima/akademicima,da moraju da odluče između predavanja o C + +,jer je korisno u stvarnom svetu,a ne da predaju zato što je suviše daleko od formalnog, specificnog pristupa često koristenog u CS nastavi... pa na kraju zavrse predavajuci Eiffel,zato sto svo "programiranje po ugovoru",promocija ili Smalltalk je "čista OO"...

BS:Profesor Wirt nije poznat po tome sto je velikodusan sa pohvalama za jezike kojie nije sam dizajnirao,tako da ne mogu da kažem da sam iznenađen njegovim napretkom.S druge strane, mislim da je on upravu.C + + je više nego adekvatan alat za dobar dizajn,za industrijsko programiranje obima,kao i za precizna razmišljanja o ozbiljnim problemima.Pretpostavljam da bi ovo bilo dobro mesto da izrazim svoju zahvalnost dizajneru Simula~u i C~u za pružanje solidne osnove za mene da se izgradi C + + i zbog toga što su originalno fini ljudi.Takođe sam naučio malo od mnogih drugih jezika.Ako znate gde da pogledate,možete pronaći tragove Algol68,ML,Ada i BCPL u C + +.Postoji mnogo sjajnih jezika u okolini.Svako bi trebao da ima cilj da bude vešt u sto više jezika-to važi za oba programska jezika i prirodne jezike.Drugi jezik dodaje značajno nečijim pogledima na svet i sposobnostima.Postoje mnogi koji bi mogli biti bolji u C + +.Međutim,to važi za svaki jezik u realnoj upotrebi.Čak i oni koji tvrde da su "čisti".Po mom iskustvu,problemi sa C + + nisu ozbiljni za nastavu ni za realno koriscenje.Naravno,studenti mogu da ne uče a nastavnik može da pristupi na nacin koji ce učini učenje nepotrebno bolnim.Međutim,to može da se desi u svakom jeziku.C + + ima tu prednost da primenjuje vagu za realne probleme u mnogim razlicitim svetskim oblastima primene.Mnogo je lakse učenje čistijeg/novijeg jezika gde dolazi do pojednostavljivanja te sile koja tera korisnike da napuste jezik kada su pogodili neku aplikaciju van domena gde je "čist" jezik razuman izbor.Naravno,to može da se desi i korisnicima C + +,ali samo retko u bilo kojoj oblasti da nekako dotiče sistem programiranja.C + + ima čiste pod grupe i složenost dolazi kada ljudi počinju da se igraju sa karakteristikama i programskim stilovima(``paradigme'')koji zahtevaju obimnije razumevanje.Ovo je mesto gde korisnici "čistijih" jezika često moraju da pribegnu alternativama,nižeg nivoa,i "nečistim" jezicima-obično C ili C + +. .Po mom mišljenju,C + + treba učiti u fazama i sa jakim akcentom na koncepte.

CP:Stvarno,dobra poenta.Ipak,mogao bi se zamisliti još čistiji pod skup,kao na primer"student-C + +",gde se ne baca niz na pokazivača bez korisnika tražeći za to i još neke ograničavajuće faktore u istom duhu.Da li mislite da bi to moglo biti korisno nastavno sredstvo(a možda i proizvodni alat za ljude manje vezane za C kompatibilnosti)?

BS:Zapravo,voleo bih da vidim``učenika C + +'',izgradjenog u oblastima gde nije bio uopšte koriscen.Umesto toga studenti će koristiti vektore,liste,i niske klase od nastavnika-pod uslovom biblioteke(na bazi standardne biblioteke gde nema sumnje).To je lako uraditi i lako primenjivo u nastavi-čak i bez promene prevodioca(samo smanjiti ocenu datu u ugrađenom nizu koji je korišćen).Slično tome, nastavnik ce lako naci nacin da zabrani eksplicitne odlivke,oni nemaju mesto u vrsti koda koji studenti treba da pišu na pocetku.Tezak deo učenja C + + - ili bilo kojeg drugog jezik-je učenje novih programskih i dizajn tehnika,a ne jezickih karakteristika koje se koriste da bi se izrazile funkcijama..

Prečesto ljudi postaju opsednuti jezičkim karakteristikama.Prečesto programeri bivaju izgubljeni u uzaludnom pokušavanju da razumeju svaki aspekt bogatog jezika,bez dovoljne pozadine da razumeju tehnike karakteristika koje postoje da bi podržale.Važno je napomenuti da čak i C + +ima naređenja od magnituda jednostavnijeg od okruženja,okvira,i velikih aplikacija

sa kojima radimo u realnom svetu.

u nastavi,C + + je povređen njen bliski,dragocen odnos sa C.Zbog C + + je (skoro) nad skup C, mnogi misle da moraju da uče(skoro) sve C funkcije i tehnike pre nego sto krenu sa C + +.To nije tako,C + + se u mnogo čemu bolje ponašao od C,i biblioteke mogu da se koriste da bi se izbeglo da se učenik suoči sa složenoscu C pokazivača manipulacija,livenja,nizova,itd. dok su osnove naučili u okruženju koje sadrži odgovarajuće vektore, žice, itd.C + + može biti odličan jezik za nastavu programiranja,programskih stilova, dizajna, itd.Međutim,moramo razlikovati učenje programiranja od učenja programskih jezika.Kada to uradimo,možda ćemo napraviti neki napredak i možda čak izbegnemo mnoge od smešnih jezičkih ratova koji precesto predstavljaju samo gubitak dragocenog vremena.

Jedna snaga C + + kao nastavnog jezika je da on sebe vodi ka ucenju različitih dizajna i tehnika programiranja.Alternativa je da nauči različite"čistijie"jezike kako bi ilustrovao isti domet tehnika. Ono što ja smatram ravno pogrešnom je prisutan jedan dizajn i stil programiranja-obično otelotvoren u jednom programskom jeziku-kao jedan i jedini pravi stil.Profesionalni programer ili kompjuterski naučnik bi na kraju trebalo da bude slobodan sa C + +,Smalltalk,ML,Lisp,i Eiffel- samo da pomenemo nekoliko.Naravno,malo ljudi mogu da budu pravi stručnjaci u više od jedne ili dve oblasti ili trenutno u nekoj,ali ideal bi morao da bude biti upoznat sa svim i svakodnevno isprobavati jednu po jednu u nekom realnom projektu.

CP:C + + izuzeci su kritikovani kao teški za pravilno koriscenje-CFR the Cargill je članak u C + + izveštaju,"potreba"da se uvede auto_ptr u standardnoj biblioteci da bi pokazivači više upravljali u prisustvu izuzetaka,neskladom između šablona i izuzetka specifikacije.Takođe se čini da je nekako teško sprovodi:Borland ima ozbiljne probleme da povezuje DLL sa i bez rukovanja izuzetcima.Da ne pominjem"Retri" debatu,koju sam dobro pokrio u D& E.Dakle,s obzirom da ce izuzetak takođe učiniti da učenje za C + + bude teze,da li mislite da je- kao što misle oni u C ++- da se izuzeci otplaćuju ikada?

BS:Svaka nova karakteristika se smatra teskom za korišćenje,skupom i nepotrebnom pojedinima kada se to prvi put pojavi.Od mnogih "problema",koji su istaknuti,par problema su realni problemi u realnim programima.Smatram da su izuzeci značajno pojednostavili moj kod.Kao i sve zaista vredne funkcije,one zahtevaju neku novu misao i neke nove načine organizovanja koda(ako nije, kako bi ova funkcija bila značajno poboljšanje?),ali mislim da su emitentno vredne.Smatram takozvani"nesklad između izuzetaka i šablona"lažnim.Izuzeci sluze za izgradnju zaštitnog zida protiv grešaka.To predstavlja,da izaberete određeni interface i odlučite da pustite samo pod skup grešaka.Skoro svi šabloni su loši kandidati za firewalls.Šabloni su namerno dizajnirani da komuniciraju vrlo blisko sa korisnički definisanim tipovima i ako imate osećaj da ne bi trebalo pokušati izgraditi zastitni zid pravo kroz tesni preplicuci kod.Ako je to neuskladjenost,neka tako bude.Međutim,ja to vidim samo kao nezavisnostavne pojmove.Oni rade razlicite stvari i mogu se koristiti u razlicitim kombinacijama.

CP:Tacno u izvesnoj meri,postoji neusklađenost između šablona i*specifikacije izuzetka*;od kad šabloni koriste stvarne argumente na neki način,gotovo je nemoguće završiti sa pravilnom specifikacijom,čak i nevinog izgleda,jednostavnog koda(npr. šablon funkcija za poređenje)... Ja bih rekao da ako uopšte postoji tamna strana zuzetaka,to je da oni prave kod nevinog izgleda koji više nije tako nevin.

BS:Zapravo mnogo takvih"nevinih tražista kodova"nikada nije bilo tako nevino.Takav jednostavan kod je često pun grešaka u neproverenim uslovima i zaobidjen od C-style setjmp/longjmp.Tako,izuzeci fokusiraju pažnju na problem koji mnogi vole da ignorišu,ali kompleksnost je već tu,ona nije uvedena rukovodjenjem izuzetaka.Ne mislim da ima smisla dodati specifikaciju izuzetaka funkcijama sablona-barem samo da ocene neobičnu funkciju sablona.Razlog je-kao što ste ispravno shvatili-da su izuzeci potencijalno bačeni po šablonu plus onih bačenih od šablona argumenata.To je jedan od razloga zašto sam rekao da šabloni obično nisu dobri kandidati za firewalls.Ne verujem da ima smisla da se svaki mali deo koda pretvara u neprobojne metke.Umesto toga,voleo bih da izrazim sistem u smislu pod sistema i da pod-sistem postavi granice firewall~a.To je mesto gde ja koristim izuzimanje specifikacije....

CP:Oblast u kojoj C + + izgleda još uvek slabo je objekat upornosti...postoji veliki broj biblioteka/alata,ali u većini slučajeva završavate sa prilagođavanjem korisnickim potrebama ili nekom rucnom funkcijom otkljucavanja.RTTI izgleda kao obećavajući nacin,ali ako ne postoji neki standard,to će biti samo još jedan neupotrebljiv dodatak ...

BS:Ja nisam uopšte siguran da upornost pripada generalno nameni programskog jezika.Različiti ljudi imaju potrebu za različitim tipovima podataka sa radikalno drugacijim zahtevima o performansama,pouzdanosti,kontroli pristupa,prirodnoj radoznalosti,itd.Mislim da je u redu da ovo pitanje ostavimo bibliotekarskim dobavlljacima i dobavljacima baza.Volim da se ograniči upotreba reprocesora i ekstra-jezičkih alata,ali ponekad su i oni potrebni.Po mom mišljenju,programski jezici ne treba da rade sve.Svakako ne mogu sve da urade kako treba. na taj nacin.I da,RTTI može biti od velike pomoći implementatorima različitih istrajnosti i usluga osnovne baze podataka.

CP:Vi ste dizajner jednog od najuspešnijih jezika ikada-da li imate bilo kakav predlog za veliki broj akademskog sveta,koji svakodnevno trazi drugi jeziku?

BS:Budite vođeni problemima.Koristan jezik je rešenje za dobro shvacen skup problema,vise nego nesto sto jednostavno ispunjava sve trenutno moderne kriterijume kako bi programski jezik trebao da izgleda.Ako nemate ozbiljan problem koji ne može da se resi razumno sa nekim postojećim jezikom,nemojte ni da razmisljate o dizajniranju novog jezika.Dizajn jezika je polje sa skoro 100% neuspeha.Niko pametan neće ući u to polje ako postoji alternativa.Dakle, tražite ozbiljne programske probleme bez prihvatljivih rešenja,i trudite se jako da se ne umešate u dizajn jezika.Ako morate da dizajnirate novi jezik,pozajmite koliko možete-sa priznanjem-od postojećeg jezika.Budite spremni na neuspeh,a za vanredne količine rada treba da pobedi šansa i uspeh..

CP:Drugi najuspešniji jezik je Visual basic.Neko je rekao da se dostavlja gde OOP/C + + obeća, to jest, mnogo priključnih komponenti,istina ponovo upotrebljivih.Da li je tačno da osećate interoperabilnost između različitih C + + i kompajlera koji je ostavljen kao nezavistan proizvod poput SOM,i nije deo standarda?Naravno,svaki binarni standard bi ograničio slobodu pisaca kompajlera,ali to je istina za *bilo koje* standardizovano pitanje.Čovek može iscediti malo vise performansi odustajanjem od nasledne podrške,ali to nije dobar razlog da bi se uklonio MI iz C + +. Zašto je binarni standard uopste drugačiji?[Naravno binarni standard je samo jedan korak ka "pravim" softverskim komponentama].

BS:C + + isporučuje ono što je obećao.Ne može se očekivati da ispune zahteve svakog jezika i sistema tvrdeci da su objektivno orijentisani ili šta god.C + + je programski jezik,a ne modul specifikacije jezika ili operativni sistem.Kao i u bilo kom drugom jeziku ne može biti sve svima. Možete napraviti "prikljucive komponente" pomoću C + +,ali to nije primarni cilj C + + i zahteva rad. Interoperabilnost je težak problem.Ljudi generalno ne cene samo kroz puno rada i puno sporazuma između konkurentskih organizacija koje mogu interoperabilnost C programskih fragmenata sastaviti od raznih dostignuca kompajlera.Mora da postoji dogovor o funkcijama pozivanja sekvenci,podacima rasporeda, itd.C + + je teži nego C,ali ne mnogo,jer skoro svi teški problemi su vise politički nego tehnički.Pitanje višestrukog nasleđivanja je potpuno odvojeno od bilo kojeg pitanja binarnih standarda i interoperabilnosti u C + + kompajleru.Verujem da odsustvo MI u poslednjim ranim verzijama SOM ne reflektuje nista osim sto se oslanja na Smalltallk i C objekte među pocetnim SOM dizajnima.U jeziku kao što je C + +,koji se oslanja na statički tip provere interface~a,neki od oblika višestrukog nasleđivanja su od suštinskog značaja.Alternativa je iskrivljen kod,nesiguran interface,ili oboje.

CP:Da li imate bilo kakvu novu koncepciju,ideju,ili funkciju koju planirate za "sledeću generaciju C + +" i koju želite da podelite sa nama?[Ja razumem da želite da C + + bude stabilan neko vreme, ali pretpostavljam da vas to ne sprečava da razmišljate o poboljšanju,možda čak i poboljšanju po nekim pitanjima implementacije za postojeće funkcije].

BS:Moj osećaj je da kada je u pitanju programski jezik,ljudi plaćaju za eksperimentisanje i pokušavaju da tretiraju tu oblast kao granu matematike i filozofije.Međutim,osećam da sledeća generacija C + + treba da dođe iz realnih problema u realnim aplikacijama i iz eksperimentisanja pre nego iz spekulacija i poliranja postojećeg jezika.Mislim da je mnogo lakše da se opiše ono što sam uradio i šta ja mislim o stvarima koje sam razumeo i pomocu nekih od njih pokušavam da predvidim budućnost.Volim naučnu fantastiku,ali ne i kada maskira tehničke članake.Mislim,da imamo previše "pravih vernika" i nekoliko eksperimenata u nekoj oblasti.Da bismo poboljšali svoje kompjuterske sisteme moramo da uradimo mnogo dobrih eksperimenata i da nadjemo tonu pouzdanih podataka.Iz toga može da dođe i uvid koji nam omogućava da utvrdimo šta su stvarni problemi i kako cemo ih rešiti.Suviše često,sedimo okruzeni filozofskim znacima o našim osećanjima,mišljenjima i teorijama,umesto da pravlimo istinske napredke.

Biografija:

Karlo Pescio ima doktorat u oblasti kompjuterske nauke i konsultant je i mentor za razne evropske kompanije i korporacije,uključujući i direkcije Evropske komisije.On je specijalizovan za objektno orijentisane tehnologije i član je IEEE Computer Societi,ACM,i Njujorške akademije nauka.Živi u Sevilji,u Italiji i može se kontaktirati na pescio@eptacom.net.




Published (Last edited): 16-09-2012 , source: http://www.eptacom.net/pubblicazioni/pub_eng/stroustr.html