Haastattelussa Bjarne Stroustrup

Link: http://www.eptacom.net/pubblicazioni/pub_eng/stroustr.html

Tämä on alkuperäinen englanti tekstiä haastattelussa Bjarne Stroustrup, myöhemmin käännetty italiaksi ja julkaistu Tietokoneen Ohjelmointi Ei 50, syyskuu 1996. Seuraa tätä linkkiä käännetty versio. Tämä artikkeli on myös käännetty Serbo-Croatian Web Geeks.

Seuraava teksti CP on lyhenne sanoista Carlo Pescio ja BS Bjarne Stroustrup.

CP: oletko tyytyväinen tuloksiin ja vauhti C++ standardointi vaivaa? Tarkoitan, toisaalta, se on todiste siitä, että menestys kieltä, mutta toisaalta se on lisäämällä paljon byrokratiaa; kaipaatko alkuperäisen vapaus oli ydin kielen kysymyksiä?

BS: Luonnollisesti, minun kärsivällisyyteni on ollut huutava testattu, mutta yleisesti olen tyytyväinen lopputulokseen C++ standardointi vaivaa. Yksi pieniä poikkeuksia lukuun ottamatta, ISO on ominaisuuksia, tuntuu se todella tarvitsee ja ei mitään, että mielestäni haitallista. ISO C++ on paljon enemmän voimakas ja johdonmukainen kieli kuin varhaisten versioiden C++ oli – ja ei ole suuria ominaisuuksia on lisätty, että en työtä ja hyväksyä. Joitakin yksityiskohtia ISO C++ voi osoittaa merkkejä “design by komitea”, mutta koko joukko palveluita, on parempi ottelu minun alkuperäinen näkemys siitä, mitä C++ pitäisi olla kuin aiemmissa versioissa kieli.

Ensisijainen syy, miksi otin osa-standardien vaivaa oli, että komitea oli kutsuttu koolle ennen minulla oli ollut mahdollisuus suorittaa kieli. C++ ilman malleja ja poikkeukset olisi voinut hyväksyä, ja C++ ilman nimiavaruudet ja run-time type information olisi jättänyt meille paljon köyhempiä kuin me tänään.

Se on helppo liioitella “alkuperäisen vapauden.” Päätin jo varhain, että halusin minun kieli on yhteensopiva C-ja että halusin tukea todellisia käyttäjiä. Tämä on asettanut rajoitteita, mitä voisin tehdä. Luulen, että vaihtoehtona olisi ollut suunnitella vielä toinen kultti kieli. En voi odottaa standardi tulee täydellinen. C++ yhteisön on kiinteä vakio-ja tarvitsen aikaa minulla on ollut omistautua standardien vaivaa viimeisen kuuden vuoden aikana tai niin. Mielestäni kieli on hyötynyt merkittävästi minun pyrkimyksiä standards committee. Olin puheenjohtaja laajennukset sub-committee, että käsitellään kaikki pyynnöt laajennuksia ja muita merkittäviä muutoksia kielen ja oli yleensä mukana useimmissa merkittäviä kysymyksiä – mukaan lukien suunnittelu standardin kirjasto. Standardointi on välttämätöntä, että kieli, jolla C++: n käyttäjien määrä. Kuitenkin, en kutsuisi standardointi hauskaa. Paljon luotto – paljon enemmän luotto kuin yleensä myönnetään “kasvoton valiokunnat” – pitäisi mennä kymmeniä ihmisiä, jotka vapaaehtoisesti käyttävät aikaansa ja hyvin huomattavia ponnisteluja standardin vuosi vuoden jälkeen. Olen dokumentoitu monet nimet ja ponnisteluja äskettäin kirjan “The Design and Evolution of C++” (yleensä nimeltään D&E).

CP: Paljon lukijoita haluaisin tietää, jos siellä on “c++ – kieli- 3rd edition” ja/tai 2. painos KÄSIVARREN alla tavalla…

BS: olen työskennellyt 3rd edition ja ajatellut jotain korvata KÄSIVARTEEN. Kuitenkin, en näe järkeä kirjoittaa uutta kirjaa, ellei minulla ole paljon uutta sanottavaa, joten edistyminen on hidasta. Tavoitteenani on tehdä 3rd edition niin paljon parannus minun 2. 2. on yli 1. Toisin sanoen, haluan tuottaa jotain vielä enemmän lähestyttävissä, että 2nd vielä sisältävät tietoa, joka on uusi ja exhiting olennaisesti jokainen C++ – ohjelmoija. En voi ennustaa, milloin olen valmis, mutta kukaan, joka tarvitsee hyvä oppikirja pitäisi odottaa 3rd edition. 2. painos on edelleen yksi eniten täydellisiä, tarkkoja ja ajantasaisia oppikirjoja saatavilla. En tietenkään voi julkaista KÄDEN vaihto, kunnes on vakio merkitä. Kunnes saan ne kirjat kirjoitettu, D&E on paras lähde tietoa uusista ominaisuuksista erityisesti ja syitä suunnittelu C++ yleisesti.

CP: onko mitään teknisiä päätöksiä, että takautuva haluat muuttaa C++ – ei jotain, sinulla ei ole tapa saada hyväksytty, mutta jotain se edelleen kokemus osoittautui jotenkin virheellinen, ja että haluat muuttua, jos sinulla oli mahdollisuus (vaikka tänään ei ole mahdollista yhteensopivuussyistä).

BS: On olemassa paljon yksityiskohtia, haluaisin korjailla, mutta ei ole suuria ominaisuuksia haluaisin poistaa (vaikka voisin) tai merkittäviä ominaisuuksia, että molemmat, kuten ja tietää, miten lisätä. Kun ihmiset kysyvät tällaisia kysymyksiä, he tavallisesti on jokin ominaisuus, kuten MI tai RTTI mielessä, niin haluan sanoa, että C++ ilman, että yksi niistä olisi köyhempi kieli. Käytän sekä laajasti ja kiertoteitä en olisi käyttöä, jos he eivät olleet siellä eivät ole kauniita nähtävyyksiä. On toki esimerkkejä ja selityksiä D&E.

CP: Itse olen enimmäkseen ollut [muutokset] virtual toiminnot mielessä: esimerkiksi, en ole kovin ihastunut siihen, että virtuaalinen toiminta voidaan määritellä uudelleen *yksityisesti* johdettu luokka. Toiminto ei ole käytettävissä – vielä on redefinable; tämä loihtia hieman hyödyllisyyttä ja turvallisuutta yksityinen perintö.

Suuremmassa määrin, luultavasti muistaa, Sakkinen: n paperit, “perintö principles of C++”: hän teki muutamia hienoja kohtia, ja pidin erityisesti siitä, että [alle tiukempia sääntöjä] yksi ei olisi laajentaa vastuuta vetoamalla rakentajan virtuaalinen perustaa luokan kauempana kuin “tarpeen” perintö kuvaaja. Itse asiassa, kun minä ymmärtää syyt, joiden vuoksi nykyiset säännöt VBC C++, täytyy myöntää, että jossain mielessä vetoaa rakentaja VBC heikentää kapselointi esittänyt intermediate-luokissa. Toisaalta, me tiedämme, vahvat ja heikot kohdat C++ läpi vuoden käyttö – ja luultavasti Sakkinen on ehdotuksia olisi johtanut vain muita heikkoja kohtia, vaikka tykkään niitä niin paljon kuin “ohjelmointi tyyli” on huolissaan.

BS: Pohjimmiltaan, pidän näitä asioita puhtaasti akateemista ja ei kiinnosta käytännön ohjelmointi. Se on mahdollisesti suunnitella rakentaja vihamielisesti saada tietoa, mutta rakentaja kirjoitettu alustaa omat tiedot on täysin vaaraton. Lisäksi, jos virtuaalinen perustaa luokan on julkinen, kuten olen aina suositella – kaikki luokat pitäisi tietää se on olemassa, ja meidän pitäisi odottaa sen rakentaja, voidaan käyttää. Tässä, virtual base classes ei poikkea muista emäkset. Jos virtuaalinen pohja on ilmoitettu yksityinen jonnekin ja julkisen muualla, ja jos kaikkein johdettu luokka alustaa se tavalla, joka yllättää kirjailija yksityinen virtuaalinen pohja, kai “kapselointi esittänyt keskitason luokkaa” on heikentynyt. Kuitenkin, jos se on joku pahin ongelma, että joku on todella siunattu.

En näe mitään ongelmaa kanssa ensisijainen virtuaalinen toiminta yksityinen toiminta tai perustaa, jonka pohja on yksityinen. Jos ajatellaan, perustaa luokan rajapinnan, se ei kuulu käyttäjien interface, miten sen toteuttajina (johdettu luokat) antaa niiden toteutuksia. Minusta on helppo kuvitella, johdettu luokka, joka tekee sen ensisijainen toiminnot yksityinen täsmälleen estää käytön johdettu luokka paitsi kautta tarkoituksena on perustaa luokan käyttöliittymä ja estää edelleen johtaminen. Jos pohja on yksityinen, se voi silti olla käytettävissä ystävien, tai johdettu luokka voi olla jakamassa viitteitä sen (yksityinen) pohja pyynnöstä. Esimerkiksi, johdettu luokka voi palauttaa sen perustaa luokan käyttöliittymä seurauksena operaatio, joka suoritetaan järjestelmä-tason acccess tarkastuksia.

class A
  {
  virtual void f() ;
  } ;

class B : private A
  {
  void f(); // implementation 
  A* get_A(Rights& r) { /* check rights */ return (*A)this; }
  } ;

CP: On the other hand, private inheritance is not transitive, so in a case like:

class A
  {
  virtual void f() ;
  } ; 

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

class C : public B
  {
  virtual void f() ;
  } 

luokka A ei ole rajapinnan luokan C, A :: f() ei ole käytettävissä C, mutta on redefinable luokassa C. Voimme vain sanoa, että syyllinen on C-luokan toteuttaja, joka perustuu hänen koodin täytäntöönpanon yksityiskohtia luokan B (siitä, että luokka B on toteutettu käyttämällä A-luokan). Jotkut voivat olla, että saa kielen…

BS: Kyllä, se on sotkuinen esimerkki. Kuitenkin, se ei ole helppoa veneet joukko sääntöjä, jotka lainsuojattomia aina sotkuinen esimerkiksi ilman, että myös tekee vahinkoa kieltämällä esimerkkejä siitä, että jotkut pitävät sotkuinen, mutta toiset pitävät oleellista heidän työstään. Yleensä olen vastaan rajoituksia, joita en näe mitään käytännön hyötyä. En pidä orthogonality ensisijainen suunnittelu tavoite, mutta varmasti mieluummin sitä, kun ei ole ensin-järjestykseen liittyvistä syistä ei-ortogonality. C++ pääsyä koskevat säännöt ovat hyvin ortogonaaliset (nimeämissäännöt, pakottavia sääntöjä, jne.) ja en näe mitään syytä, että heihin ei saa. Ihmiset voivat olla yllättynyt sääntöjä, mutta niin ne voisi vähemmän ortogonaaliset sääntöjä.

CP: ymmärrän mielipiteesi ja olen samaa mieltä pitkälti. Siksi sanoin, että tällainen “sääntö” voi olla hyvä, sikäli kuin “ohjelmointi tyyli” on huolissaan. On varmasti aikoja, jolloin jotain, kuten jotka voivat olla hyödyllisiä (esimerkiksi uudelleenkäyttö-kirjastoon ilman lähdekoodia) ja siinä tapauksessa voi “rikkoa sääntöä” ja tehdä se, koska C++ ei ole äidillinen, rajoittavat kieli.

BS: olisin halunnut, että C++ on enemmän, joka pystyy kiinni loogisia virheitä tekemiä ohjelmoijat. Sen jälkeen, kun kaikki, monet C++ – ominaisuuksia on juuri sen vaikutus verrattuna siihen, mitä olisit voinut kirjoittaa C suorittaa vastaavan toiminnan. Kuitenkin, en usko, että turvallisuutta pitäisi ostaa kustannukset vaikeuttaa ilmaus hyviä ratkaisuja tosielämän ongelmiin. Tämä – ja yhteensopivuus koskee – rajoja, mitä voidaan tehdä sen eteen, että kieli itsessään cleaner. Suosittelen käyttää kirjastoja käyttää C++ turvallisempaa tiettyjä sovelluksia. Esimerkiksi, jos joku huolehtia siitä, että C-taulukot eivät ole alue valittu, ne pitäisi käyttää alue-tarkastetaan vector-luokan. Minä, että suurimman osan ajasta itse, varsinkin virheenjäljitykseen.

CP: mennään takaisin retrospektiivinen C++…

BS: hyvää ja huonoa, olen säilyttänyt korkea astetta C yhteensopivuus alkuajoista lähtien C++ ja standardien komitea on seurannut minun `niin lähellä C kuin mahdollista – mutta ei lähempänä” politiikkaa. Monet asiat C++ voisi olla parempi kieli-teknisestä näkökulmasta, mutta se ei ole realistinen. Kun aloitin, päätin yhteensopivuus ja yrittänyt parhaani mukaan elää toisen kertaluvun virheitä, korjaus vain ongelmia, jotka liittyvät tyyppinen järjestelmä. Vaihtoehtona olisi ollut rakentaa vielä toinen kultti kieli: Kaunis silmissä sen kannattajia ja nostattamaan mitään muuta kuin ayawn lähes kaikki, jotka ohjelma saada tuloksia. Oli C ei ollut siellä olla yhteensopivia, en olisi valinnut jokin muu kieli muu yhteensopiva. Olin – ja olen vakuuttunut siitä, että aikani ei olisi käytetty hyvin keksiä vielä toinen tapa kirjoittaa silmukka.

Samanaikaisuuden on asia, joka pitää tulossa. Useimmat ihmiset pitävät jonkinlaista samanaikaisuuden ja haluaisin nähdä sitä suoraan tue C++. Kuitenkin, ei ole yksi muotoa samanaikaisuuden, joka palvelee enemmän kuin pieni murto-osa C++ ohjelmoijat, jotka tarvitsevat samanaikaisuuden todella hyvin. OS kirjailijoita tarvitsee yksi muoto samanaikaisuuden, tietokannan käyttäjät toisen, ja verkon sovellus toteuttajat vielä toinen. Näin ollen päätin sisällyttää erityisiä ominaisuuksia tukeminen, samanaikaisuuden C++. Ihmiset, jotka haluaa jonkinlaista samanaikaisuuden voi – ja ei – tukea sitä kautta kieli laajennukset (mieluiten) kirjastot. Standardin komitea kannatti minua, että asia myös; me tiesimme monia houkuttelevia samanaikaisuuden schemens, mutta ei yksi, joka voi palvella suuren enemmistön C++ käyttäjät. Erilaisia alueita, joissa C++ on käyttänyt sitä todella hämmästyttävä.

Minua pyydettiin kirjoittamaan artikkeli C++ ACM: n toisen konferenssin historian ohjelmointikieliä (heillä on yksi joka 15 vuotta!). Kyseisen kirjan, minulta kysyttiin, mitä minulla pitää minun suurin virhe, C++. Mielessäni oli vain yksi ehdokas otsikko “pahin virhe:” en ole esittänyt hyväksyttävää foundation library ja lähettää sen kanssa release 1.0 vuonna 1985. Minun selitys oli, että en tiennyt, miten kirjoittaa tarpeeksi hyvä kirjasto ja että tarvitsin malleja tarjota tehokas, joustava, ja tyyppi-turvallinen säiliöihin. Tulos, että virhe on nykyinen sotku ristiriidassa säätiön kirjastojen erilaiset filosofiat ja ominaisuuksia.

Onneksi standardien komitea pystyi sopimaan erinomainen standardin kirjasto. Meillä on nyt mitä olen jättänyt tuottaa ja jotain, että en tiedä, miten suunnitella ja toteuttaa kymmenen vuotta sitten. Puitteet konttien ja perusvapauksien algoritmeja, jotka on merkittävä osa standardin kirjasto oli ensisijaisesti työn Alex Stepanov. Se todella on joitakin juuret meidän etsiä periaatteita ja tekniikoita hyvä kirjasto osat takaisin vuotta ennen ja jälkeen versio 1.0, joten viive ei ollut täysin hukkaan.

CP: Kuten tiedätte, on olemassa ehdotuksia, lisätä joitakin C++: n ominaisuuksia C9x, esimerkiksi rajoitettu tuki luokat. Sain vaikutelman, naiivi lähestymistapa, esim. heillä ei ole rakennuttajat, tehtävä ylikuormitus, ja niin edelleen. Mikä on kantanne “uusi ANSI-C”?

BS: ominaisuudet ei näytä naiivi minun näkökulmastani ja selityksiä, jotka acompanied ne näyttää heijastaa puute arvostusta, kuinka C++ oli kehittynyt vastauksena palautetta. Minulla oli (ja yhä on) kokonaisnäkemyksen siitä, mitä kieltä on tarkoitus tehdä, mutta sisällä, että yleinen näkemys, olin varovainen ja pyytää palautetta siitä, kuinka kieli, koska se kehittynyt säätää sen ominaisuuksia todellinen kokemus ja tarpeet.

Yrittää poimia pieni osajoukko ominaisuuksia C++ antaa “paljon yksinkertaisempi kieli, jossa lähes kaikki valta C++” on mielestäni tuomittu epäonnistumaan. Ellei erittäin huolellisesti valittu perustuu todellinen kokemus, ominaisuudet ovat vain osittain tukea johdonmukainen ohjelmointi tyylejä ja yksi ominaisuus johtaa toiseen – vain silloin, kun ohjaa kokonaisvaltainen näkemys siitä, mitä suunnittelu ja ohjelmointi tyylit ovat suoraan tuettuja tulee lisäyksiä johtaa yhtenäinen kieli.

Se ei olisi järkevää minulle yrittää kertoa C-yhteisön, miten ne pitäisi yhtenäistää niiden kieli. Jos tein, minun neuvoni ei todennäköisesti olisi wellcome joka tapauksessa, koska ihmiset, jotka olisi arvo minun neuvoja useimmat olisivat ohjelmointi C++ muutenkin. C-komitea tekee mitä se haluaa C ja oletettavasti he tietävät parhaiten heidän core-yhteisön. mitään laajennuksia, yhteensopiva C++ kuin suinkin mahdollista. Ohjelmointi yhteisön ei tarvitse vielä toinen yhteensopimattomat C murre. K&R-C ei ole vielä kuollut, nykyinen ANSI C jatkuu kauan sen jälkeen, kun uusi standardi on julkaistava, ja eri vuosikertojen C++ on myös olemassa, samoin kun C++ – standardi tulee virallinen. Asiat aina kestää kauemmin kuin uskomme ja haluaisimme. Uusia ominaisuuksia C9x välttämättä tullut ylimääräistä epävakautta C-ja C++ – yhteisön.

CP: Talking C++’s sons, en voi välttää mainita Java. kuinka suuri on mielestänne kelkkaan vaikutus, ja olivat (jos missään) näet Java todelliset vahvuudet. Tiedän, että kieli suunnittelija, olet hyvin varovainen kritisoi kielellä – eräänlainen “mikä tahansa kieli on niche” – mutta mikä on teidän gut tunteita?

BS: Java on C++-syntaksi, mutta on täysin erilainen kieli tukevat eri kulttuuri ja eri (melko kapea) alue ohjelmointi tyylejä. Javassa ei ole C++: n kaltainen kieli, en olisi suunniteltu ilman yhteensopivuus-rajoitukset. Tällä hetkellä Java ratsastaa hämmästyttävän korkea odotus, Aurinko markkinointi rahaa, ja sen integrointi Web. Aika kertoo, miten se on hinta kuin yleiskäyttöinen kieli, ja kuinka suurin osa ohjelmoijat ja johtajat reagoivat, kun he huomaavat, että “turvallisuus” Java ja erityisesti Javascript-jättää paljon toivomisen varaa. Ihmiset sekoittavat ohjelmointikieli tyyppi turvallisuus (mikä on oikea Java-toteutus tarjoaa) turvallisuus; että on, säilyttäminen järjestelmän eheys ja tietosuoja (joka voi olla vakavasti vaarantua käyttämällä Java). Meidän turvallisuus ihmiset leikillään viittaa Java, kuten “virus täytäntöönpanoa kieltä” ja suosittelee, että me ajaa Java-ja Javascript pois käytöstä meidän netbrowsers. Takaisin ohjelmointikieli kysymyksiä:

C++

– on parempi C

– tukee tietojen abstraktio

– tukee olio-ohjelmointi

– tukee generic ohjelmointi

Näistä Java kattaa olio-vain osa, ja se tekee sen tavoilla, jotka poikkeavat huomattavasti C++.

CP: Jotkut uusin C++ lisäykset ovat olleet hyödyllisiä, mutta pieniä yksityiskohtia – selkeä, vaihteleva – tai “paeta C” ominaisuuksia, kuten uusi-tyyli heittää. Näetkö tulevaisuudessa enemmän design-suuntautunut ominaisuudet kielellä? Esimerkiksi, ehkä on olemassa joitakin arvokkaita inspiraatioita projekteihin, kuten Selityksin C++ tai Lehtikuusi-C++, nojaten enemmän kohti tekniset tiedot ja vähemmän koodausta tasolla, tai joitakin tapoja lisätä joitakin enemmän semantiikkaa, esimerkiksi tehdä objekti-jaon päätöksiä selvemmin. Tai on tarkoitus vahvistaa kieli oli jo vahva – upotettu / järjestelmän ohjelmointi / performance-kriittiset alueet?

BS: C++ on osa yleistä suuntausta kohti enemmän declarative tyylejä ohjelmointi. Kuitenkin, sikäli virallinen määritelmä kieli on huolissaan muutoksista, kieli ja standardin kirjastoon on nyt lopettaa antaa toteuttajat, käyttäjät, työkalu, rakentajat, opettajat, jne. mahdollisuus kiinni. Luonnollisesti, kokeilu jatkuu (vaikka todennäköisesti ei minua), mutta olen sitä mieltä, C++ kehittäjä yhteisö tarvitsee vakautta enemmän kuin mitään muuta. C++ on nyt valmis ja johdonmukaista mitä se tekee; lisätyötä on jäädä osa-yhteisöä (kuten korkeakoulut) muutaman vuoden ajan.

Uskon, että useimmat ihmiset vielä arvostavat voimia mallin mekanismi eri muotojen erittely. Esimerkiksi, tässä on ääriviivat on miten voi määrittää luettelon niin, että yhden täytäntöönpano on jaettu kaikki luettelot viitteitä:

// 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*> { /* ... */ };

Erikoistuminen käytetyn mekanismin avulla eri implemetations valitaan (käyttäen tyyppi vähennys) mutta ne tarjoavat silti käyttäjälle yksi yleinen rajapinta. Yksi tärkeä näkökohta tässä on se, että se vahvistaa declarative luonne, C++ ohjelmointi ja samalla yksinkertaistaa käyttäjän käyttöliittymä ja parantaa run-time hyötysuhde. Tällaisia tekniikoita standardin kirjasto antaa meille mahdollisuuden tarjota yhden yleisen sort () – rutiinia, että todellisia esimerkkejä ovat päihitti C standard library qsort() kertoimella seitsemän.

CP: IEEE Computer, helmikuu 95, Prof., Wirth, merkitty C++ kuin “kieli, joka ei kannusta jäsennelty ajattelu ja kurinalainen ohjelmointi rakentaminen”. En voi sanoa, olen samaa mieltä, tai että en etsi Oberon kannustamalla rakenne ja kurinalaisuutta kuin C++, mutta on siellä jotain haluat myönsivät puristeja/tutkijoita siellä, että täytyy päättää, välillä opetus-C++, koska se on hyödyllinen todellisessa maailmassa, ja ei ole opetusta, koska se on liian kaukana muodollinen, erittely perustuvaa lähestymistapaa käytetään usein CS opetus… joten he päätyvät opetuksen Eiffel-koska kaikki “ohjelmointi sopimus” edistäminen tai Smalltalk, koska “on puhdasta OO”…

BS: Professori Wirth ei ole tunnettu siitä, että antelias kiitosta kieliä hän ei ole suunniteltu itse, joten en voi sanoa olevani yllättynyt hänen eveluation. Toisaalta, luulen, että hän on väärässä. C++ on enemmän kuin riittävä työkalu hyvä suunnittelu, teollisen mittakaavan ohjelmointi, ja tarkkaan miettiä vakavia ongelmia. Luulen, että tämä olisi hyvä paikka kiittää suunnittelijat Simula ja C antaa vankan pohjan rakentaa C++ ja siitä, että tällainen aito mukavia ihmisiä. Olen myös oppinut melkoisesti monista muista kielistä. Jos et tiedä mistä etsiä, voit löytää jälkiä Algol68, ML, Ada, ja BCPL C++. On olemassa paljon hienoja kielillä ympäri. Kaikkien tavoitteena tulisi olla taitava enemmän kuin yksi kieli – se pätee sekä ohjelmointikieliä ja luonnollisella kielellä. Toinen kieli lisää merkittävästi ihmisen maailmankuva ja kykyjä. Siellä on paljon, että voisi olla parempi C++. Kuitenkin, se on totta jokaisen kielen todellista käyttöä. Jopa ne, jotka väittävät olevansa “puhdas.” Kokemukseni ongelmat C++ eivät ole vakavia opetuksen eikä todellista käyttöä. Luonnollisesti, opiskelija voi epäonnistua, oppia ja opettaja voi ottaa lähestymistapa, joka tekee oppimisesta turhan tuskallista. Kuitenkin, että voi ja ei tapahdu kaikilla kielillä. C++ on se etu, että sen käyttö asteikot reaalimaailman ongelmia useilla eri sovellusalueilla. Paljon helppous oppimisen cleaner/uudempia kieliä tulee yksinkertaistuksia, jotka pakottavat sen käyttäjät voivat luopua kieli, kun ne osuvat sovelluksen ulkopuolella verkkotunnuksen, jossa “puhdas” kieli on järkevä valinta. Luonnollisesti, tämä voi tapahtua, C++ käyttäjät myös, mutta vain harvoin millään alalla, joka jotenkin sivuaa järjestelmien ohjelmointi. C++ on puhdas osajoukkoja ja monimutkaisuus tulee, kun ihmiset alkaa pelissä ominaisuuksia ja ohjelmointi tyylejä (`paradigmat”), jotka vaativat laajempaa ymmärrystä. Tämä on, jossa käyttäjät “puhtaampaa” kieliä on usein turvautumaan vaihtoehto, alemman tason, ja “epäpuhdas” kielellä – yleensä C-tai C++. Mielestäni, C++ pitäisi opettaa vaiheittain, ja joilla on vahva painotetaan käsitteitä.

CP: Hyvä pointti, tosiaan. Silti voisi kuvitella jopa puhtaampaa osajoukko, esimerkiksi “opiskelija-C++”, jossa array ei ole valettu osoitin ilman, että käyttäjä pyytää sitä, ja jotkut enemmän rajoittavia tekijöitä samassa hengessä. Luuletko, että se voisi olla hyödyllinen opetusväline (ja ehkä tuotannon väline kansojen vähemmän sitovat C yhteensopivuus), tai vain aiheuttaa sekaannusta?

BS: Itse asiassa, haluaisin nähdä `opiskelija C++”, jossa sisäänrakennettu paneelit ei ollut käytetty lainkaan. Sen sijaan opiskelijoiden olisi käyttää vektori, lista, ja string luokat opettaja-edellyttäen, kirjasto (perustuu standardin kirjasto ei ole epäilystäkään). Se on helppo tehdä ja helposti täytäntöön opetus-tilanne – jopa ilman compiler muutokset (vain vähentää arvosana annetaan sisäänrakennettu joukko oli käytetty). Samoin opettaja olisi löytää se helppo kieltää nimenomaisesti heittää; ne eivät kuulu sellainen koodi alkua opiskelijan olisi kirjallisesti. Vaikein osa oppimista, C++ – tai muita kieli – on oppimisen uusi ohjelmointi ja suunnittelu tekniikoita, ei kielen ominaisuuksia, joita käytetään ilmaisemaan niitä.

Aivan liian usein, ihmiset saa pakkomielle kielen ominaisuuksia. Aivan liian usein, ohjelmoijat eksyä turhaa yrittää ymmärtää jokaista yksityiskohtaa rikas kieli ilman riittävää tausta ymmärtää tekniikoita, ominaisuuksia olemassa tukea. On syytä huomata, että vaikka C++ on tilauksia suuruudet yksinkertaisempi kuin ympäristöissä, puitteet ja merkittäviä sovelluksia

teemme yhteistyötä reaalimaailman sovellusten kehittämiseen.

Opetus -, C++ on loukkaantunut sen lähellä – ja arvokas – suhde C, Koska C++ on (lähes) pääjoukko C, monet ajattelevat, että heidän täytyy oppia (melkein) kaikki C: n ominaisuudet ja tekniikoita ennen lähestyy C++. Tämä ei ole niin, että C++ on monin tavoin paremmin käyttäytyviä kuin C, ja kirjastot voidaan välttää oppilaan kasvot monimutkaisia C osoitin manipulointia, valu, taulukot, jne. kunnes perusasiat on opittu ympäristössä, joka sisältää oikea vektorit, jouset, jne. C++ voi olla – ja occationally on – erinomainen kielen opetus, ohjelmointi, ohjelmointi tyylejä, suunnittelu, jne. Meidän on kuitenkin erottaa opetus ohjelmoinnin opetus ohjelmointikieliä. Näin tapahtuu, voimme tehdä jonkin verran, ja se saattaa jopa välttää monet typerä kieli sodat, jotka liian usein tuhlaa meidän aikaa.

Yksi vahvuus C++ opetuksen kieli on, että se soveltuu opetuksen erilaisia suunnittelu ja ohjelmointi tekniikoita. Vaihtoehtona on opettaa erilaisia “puhtaampaa” kielet kuvaavat samalla erilaisia tekniikoita. Mielestäni taulu on väärin nykyistä suunnittelu ja ohjelmointi tyyli – yleensä sisältyvän yhden ohjelmointi kieli – yksi ja ainoa oikea tyyli. Ammatillinen ohjelmoija tai tietokoneen tiedemies olisi lopulta olla tyytyväinen C++, Smalltalk, ML, Lisp, Eiffel – vain muutamia mainitakseni. Luonnollisesti, harvat ihmiset voivat olla todellisia asiantuntijoita enemmän kuin yksi tai kaksi tai niitä kerralla, mutta ihanteellinen on olla perehtynyt kaikki ja ajan kokeilla jokainen joissakin todellinen projekti.

CP: C++ poikkeuksia on kritisoitu, koska vaikea käyttää oikein – cfr Cargill on artiklan C++ Report, “täytyy” esitellä auto_ptr standardin kirjaston tehdä osoittimia enemmän hallittavissa alle läsnäolo poikkeuksia, epäsuhta malleja ja poikkeus tekniset tiedot. Se myös näyttää olevan jotenkin vaikea toteuttaa: Borland oli vakavia ongelmia yhdistää yhdessä Dll kanssa ja ilman poikkeusten käsittely. Puhumattakaan “yritä uudelleen” keskustelua, että et kuulu hyvin D&E. Joten, kun otetaan huomioon, että poikkeuksen tekee myös oppimiskäyrä C++ jyrkempi, luuletko, että – koska ne ovat C++ – poikkeukset ovat maksaa pois?

BS: Jokainen uusi ominaisuus katsotaan vaikea käyttää, kallis, ja tarpeeton jotkut, kun se ensin näyttää. Monet “ongelmat” huomautti, harvat ovat todellisia ongelmia, todellisia ohjelmia. Huomaan, että poikkeuksia merkittävästi yksinkertaistaa koodia. Kuten kaikki todella arvokas ominaisuuksia, ne vaativat uutta ajattelua ja uusia tapoja järjestää koodi (jos ei, niin miten ominaisuus olla merkittävä parannus?), mutta luulen, että he ovat emminently kannattavaa. Pidän ns. “epäsuhta poikkeuksia ja malleja” väärä. Poikkeuksia ovat rakennuksen palomuurit vastaan virhe ehtoja. Että on, voit valita erityinen käyttöliittymä ja päättää antaa vain osajoukko virhe ehtoja kautta. Lähes kaikki mallit ovat köyhiä ehdokkaita palomuurit. Mallit ovat tarkoituksella suunniteltu vuorovaikutuksessa hyvin tarkasti käyttäjän määrittämät tyypit ja jos sinulla olisi mitään järkeä olisit yritä rakentaa palomuurin läpi tiiviisti kudottu koodi. Jos se on epäsuhta, niin on se. Näen kuitenkin, se yksinkertaisesti riippumattomuuden käsitteitä. He tekevät eri asioita ja niitä voidaan käyttää yhdessä.

CP:, jossain määrin, on olemassa epäsuhta malleja ja *poikkeuksena tekniset tiedot*; koska malleja käyttää todellisten argumenttien jotenkin, se on lähes mahdotonta päätyä oikea erittely, jopa viattoman näköinen, yksinkertainen koodi (esim. malli-toiminto vertailu)… sanoisin yleisesti, että jos on jokin pimeä puoli on poikkeuksia, on, että ne tekee viattoman näköinen koodi ei niin viaton enää.

BS: Itse asiassa, paljon tällaisia “viattoman näköinen koodi” ei ole koskaan ollut niin viaton. Tällainen yksinkertainen koodi on usein täynnä valitsematta virhe ehtoja ja aihe on ohittaa C-tyyli setjmp/longjmp. Näin ollen poikkeuksia huomiota ongelma, että monet haluavat sivuuttaa, mutta monimutkaisuus on siellä jo, sitä ei ole otettu käyttöön viimeistään poikkeusten käsittely. En usko, että on järkevää lisätä poikkeus tekniset tiedot malli toiminnot – ainakin vain melko epätavallinen malli toiminnot. Syynä on – kuten aivan oikein huomauttaa, että poikkeuksia mahdollisesti heitetty ovat niitä heittänyt malli plus ne heittänyt malli argumentteja. Tämä on yksi syy siihen, että sanon, että mallit ovat yleensä ole hyviä ehdokkaita palomuurit. En usko, että on järkevää tehdä jokainen pieni pala koodia luodinkestävä. Sen sijaan, olen mieluummin ilmaista järjestelmien kannalta osa-järjestelmät ja tehdä sub-järjestelmän rajat palomuurit. Että on, jos käytän poikkeus tekniset tiedot.

CP: alue, jossa C++ tuntuu vielä heikko on object pysyvyys… on olemassa useita kirjastoja/työkalut, mutta useimmissa tapauksissa päädyt tarvitsevat mukautetun preprocessor tai jotkut handcoded toiminto. RTTI näyttää lupaava tapa mennä, mutta jos siellä on joitakin standardin, se olisi vain yksi nonportable tiedostotunnistetta…

BS: en ole ollenkaan varma, että pysyvyys kuuluu yleiskäyttöinen ohjelmointikieli. Eri ihmiset tarvitsevat eri tyyppisiä pysyviä tietoja, joilla radikaalisti erilaisia vaatimuksia suorituskyky, luotettavuus -, kulunvalvonta -, luonne quiries, jne. Luulen, että se on oikein jättää tämä asia kirjaston myyjät ja tietokanta myyjät. Mieluummin rajoittaa käyttöä esiprosessorit ja extra-kielellisiä välineitä, mutta joskus niitä tarvitaan. Mielestäni ohjelmointikieli ei pitäisi yrittää tehdä kaiken. Se ei voi tehdä kaikkea hyvin muutenkin. Ja kyllä, RTTI, voi olla huomattavaa apua toteuttajina eri pysyvyys ja tietokannan palveluja.

CP: Olet suunnittelija yksi menestyksekkäimmistä kielet koskaan – onko sinulla ehdotuksia lukemattomia kansat academy, joka crunch vielä-toinen-kieli joka toinen päivä?

BS: ohjaavat ongelmia. Hyödyllinen kieli on ratkaisu hyvin ymmärrettävä joukko ongelmia, eikä vain jotain, että fullfils kaikki tällä hetkellä muodikas kriteerit, mitä ohjelmointi kieli pitäisi näyttää. Jos sinulla ei ole vakava ongelma, jota ei voida käsitellä kohtuudella, jossa mitään olemassa olevaa kieltä, älä edes ajattele suunnitella vielä toinen kieli. Kielen suunnittelu on kenttä, jossa on lähes 100% kuolleisuus. Kukaan järkevä ihminen kirjoita se kenttään, jos siellä oli yksi vaihtoehto. Joten, etsiä vakavia ohjelmointi ongelmia ilman hyväksyttäviä ratkaisuja, ja yritä vaikea olla saada mukana kieli suunnittelu. Jos sinun täytyy suunnitella uusi kieli, lainata niin paljon kuin voit – kiitokset – olemassa olevan kielen. Varaudu vika, ja satunnaisia määriä työtä, sinun pitäisi voittaa kertoimet ja menestyä.

CP: muut menestynein kieli on visual basic. Jotkut sanoivat, että se tuottaa missä OOP/C++ lupaa, että on paljon pluggable osia, totta uudelleen, ehkä kustannuksella joitakin underengineering. Tuntuuko sinusta oikein, että yhteentoimivuus eri C++ – kääntäjiä on jätetty kolmannen osapuolen tuotteita, kuten SOM, ja ei ole osa standardia? Tietenkin binary standardi ei rajoita vapautta kääntäjät kirjailijoita, mutta se on totta, että *kaikki* standardoitu kysymys. Yksi voi puristaa ulos lisää suorituskykyä antamalla useita perintö tukea, mutta se ei ole hyvä syy poistaa MI C++. Miksi on binary standardin kaikki eri? [luonnollisesti binary-standardi on vain yksi askel kohti “totta” ohjelmiston osia]

BS: C++ tarjoaa mitä se lupasi. Se ei voi odottaa tavata hype jokaisen kielen ja järjestelmä väittää olla olio-tai mitä tahansa. C++ on ohjelmointikieli, ei moduuli erittely kieli tai käyttöjärjestelmä. Se – kuten mikä tahansa muu kieli – ei voi olla kaikkea kaikille. Voit rakentaa “kytkettävien komponenttien” käyttäen C++, mutta se ei ole ensisijainen tavoite, C++ ja se vaatii työtä. Yhteentoimivuus on vaikea ongelma. Ihmiset yleensä eivät ymmärrä, että vain läpi paljon työtä on paljon sopimuksia kilpailevien organisaatioiden voi jopa yhteentoimivuus C-ohjelma palasista koottu eri kääntäjät voidaan saavuttaa. On oltava sopimus toiminto soittaa sekvenssien -, data-layout, liukuluku aritmeettinen tiedot, jne. C++ on vaikeampaa kuin C, mutta ei paljon, koska lähes kaikki kovan ongelmat ovat pikemminkin poliittisia kuin teknisiä. Kysymys moniperiytyminen on täysin erillinen mistä tahansa, kysymys binary standardit ja yhteentoimivuus, C++ kääntäjät. Uskon, että ilman MI vähintään varhaisten versioiden SOM heijastaa mitään, mutta nojaa kohti Smallatlk ja Tavoite C joukossa alkuperäisen SOM suunnittelijat. Kieli kuten C++, joka perustuu staattinen tyyppi tarkkailun käyttöliittymät, jonkinlaista moniperiytyminen on välttämätöntä. Vaihtoehtona on kieroja, vaarallinen rajapinnat, tai molemmat.

CP: Onko sinulla uusi ajatus, idea tai ominaisuus, että olet ajatellut “seuraavan sukupolven C++” ja että haluaisit ennakoida? [Ymmärrän, että haluat C++ olevan vakaa; kai se ei estä sinua ajattelemasta parannuksia, ehkä jopa parannuksia joitakin täytäntöönpanoon liittyviä kysymyksiä nykyisten ominaisuudet].

BS: Minun tunne on, että kun se tulee ohjelmointi kielet, ihmiset maksavat lipservice kokeilemalla ja yrittää hoitaa kentän haara matematiikka tai filosofia. Luulen kuitenkin, että seuraavan sukupolven C++ pitäisi tulla todellisia ongelmia, todellisia sovelluksia ja kokeilun sijaan spekulointia ja kiillotus olemassa oleva kieli. Minusta se on paljon helpompi kuvata, mitä olen tehnyt ja mitä minä ajattelen asioita, joita en ymmärrä joitakin kuin yrittää ennustaa tulevaisuutta. Rakastan Science Fiction, mutta ei silloin, kun se masquarades sekä teknisiä artikkeleita. Olen kuitenkin sitä mieltä, että meillä on liian paljon “uskovaisia” ja liian vähän kokeilijoita alalla. Parantaa tietojärjestelmien meillä on paljon hyviä kokeiluja ja tonnia luotettavia tietoja. Siitä voi tulla oivalluksia, jotka antaa meille mahdollisuuden määrittää, mitä ovat todellisia ongelmia ja miten ratkaista ne. Aivan liian usein me vain istua ja miettiä meidän tunteita, mielipiteitä ja teorioita sen sijaan, että todellista edistystä.

Elämäkerta

Carlo Pescio omistaa tohtorin tutkinto Computer Science, ja on konsultti ja mentori Euroopan eri yritykset ja yritykset, mukaan lukien Euroopan Komission pääosastoista. Hän on erikoistunut olio-ohjelmoinnin tekniikoita ja on jäsenenä IEEE Computer Society, ACM, New York Academy of Sciences. Hän asuu Savona, Italia ja voi ottaa yhteyttä [email protected]

Leave a Reply