Veelgestelde vragen over Bjarne Stroustrup

Veelgestelde vragen overBjarne Stroustrup

(original article can be found here)

Dit zijn vragen die mensen me vaak stellen.Als u betere vragen of opmerkingen over de antwoorden heeft, kunt u me e-mailen.Houd er rekening mee dat ik niet al mijn tijd kan besteden aan het verbeteren van mijn startpagina’s.

Deze pagina concentreert zich op persoonlijke meningen en algemene vragen met betrekking tot filosofie. Voor vragen die meer direct betrekking hebben op taalfuncties van C ++ en het gebruik van C ++, raadpleeg de Veelgestelde vragen over de FAQ van de C ++ Foundation of mijn Veelgestelde vragen over techniek en techniek . Voor C ++ terminologie en concepten, zie mijn C ++ woordenlijst . Zie mijn C ++ -pagina en mijn veelgestelde vragen over C ++ 11 voor koppelingen naar nuttige bronnen van C ++ -informatie . Voor meer informatie over mijn boeken (incl. Reviews en ondersteuning), kunt u mijn boek lijst . Zie mijn publicatielijstvoor papieren en ISBN-nummers voor vertalingen van mijn boeken.

Inhoudsopgave


Hoe spreek je “Bjarne Stroustrup?” Uit

Het kan moeilijk zijn voor niet-Scandinaviërs. De beste suggestie die ik heb gehoord was “begin het een paar keer in het Noors te zeggen, stop dan een aardappel in je keel en doe het opnieuw :-)” Hier is een wav-bestand .

Voor mensen die geen geluid kunnen ontvangen, is hier een suggestie: mijn beide namen worden uitgesproken met twee lettergrepen: Bjar-ne Strou-strup. Noch de B noch de J in mijn voornaam zijn gestrest en de NE is nogal zwak, dus misschien zou Be-ar-neh of By-ar-ne een idee kunnen geven. De eerste U in mijn tweede naam had eigenlijk een V moeten zijn waardoor de eerste lettergreep tot ver in de keel kwam: Strov-strup. De tweede U is een beetje zoals de OO in OOP, maar nog steeds kort; misschien zal Strov-stroop een idee geven.

Ja, dit is waarschijnlijk de meest gestelde vraag 🙂

PS Mijn voornaam is Bjarne – niet Bjorn (geen naam), Bjørn (een verwante maar andere naam) en Barney (een niet-verwante naam). Mijn tweede naam is Stroustrup – niet Stroustroup, Stroustrop, Strustrup, Strustrop, Strustroup, Straustrup of Straustroup (documenten met elk van deze spelfouten zijn te vinden via google).


Mag ik je een vraag stellen?

Zeker. Ik probeer mijn e-mail te beantwoorden. Probeer echter te voorkomen dat u een vraag stelt die wordt beantwoord op mijn startpagina. Vertrouw ook niet op een snel antwoord. Ik krijg veel e-mail.

Hier zijn links naar


Waarom beantwoord je je e-mail niet?

Ik wel, maar ik krijg veel e-mail. Ik schat dat ik antwoord op meer dan 95% van de (niet-spam) berichten die ik ontvang. Soms word ik echter overweldigd. Sommige berichten gaan verloren in mijn mailbox, sommige zijn vertraagd totdat ik tijd kan vinden, andere zijn vertraagd totdat ik een reeks verwante berichten beantwoord (dit gebeurt vaak met opmerkingen over mogelijke fouten in mijn boeken). Helaas lopen langere en meer doordachte berichten meer vertraging op dan eenvoudige berichten met eenvoudige antwoorden.

Als je me mailt, probeer dan alsjeblieft ook dat ik je kan antwoorden. Ik haat het echt als ik een antwoord heb geschreven en verzonden, alleen maar om te ontdekken dat het retouradres ongeldig of ontoegankelijk is.

Twee soorten berichten hebben een relatief grote kans om te verdwalen: huiswerkvragen en vragen over de vorm “hoe gebruik ik deze eigen bibliotheek?”. Ik ben een beetje bedroefd dat ik de laatste vragen niet beantwoord, omdat de persoon die vraagt ​​vaak niet begrijpt dat de DOS, Windows of wat voor interface dan ook van C ++ geen deel uitmaakt van de C ++ -standaard (en ik kan het enorme aantal C ++ -bibliotheken ). Als u geen antwoord ontvangt, moet u overwegen of uw vraag van een van deze soorten was.

Bovendien zal ik het bericht waarschijnlijk ongelezen verwijderen, tenzij u uw naam opgeeft. Dit is een nieuw beleid. Ik ben nooit een grote fan van pseudoniemen geweest, maar ik vind dat de kans op een beleefd technisch gesprek met het soort persoon dat denkt dat het cool is om zich te verschuilen achter een naam als suuupergeeek of coolGuy3 te laag wordt om het proberen te proberen.


Waarom laat je je website er niet modern uitzien?

Ik ben een ‘content provider’ en geen websiteontwerper. Ik kan mijn tijd gebruiken om de inhoud of het uiterlijk te verbeteren, maar niet beide.

Wat er ‘cool en modern’ uitziet, wordt door iemand anders vaak als slechte smaak beschouwd, en de mode verandert snel. Ook downloadt html zeer eenvoudig en wordt sneller weergegeven dan wat dan ook, en veel mensen hebben nog steeds last van trage webverbindingen.


Is “bjarne” een bedrieger?

Waarschijnlijk niet. De meeste nieuwsgroeppostings, interviews, enz. Die beweren van mij te komen, komen van mij. De voor de hand liggende uitzondering is het beruchte IEEE “interview” , dat ik nogal ongeschikt vind. Het is mij bekend dat ik vanuit mijn gmail-account naar nieuwsgroepen plaats waar mijn gebruikersnaam “Bjarne” is; op de een of andere manier lijkt dat sommige mensen te verwarren. Als u twijfelt, overweeg dan de stijl en inhoud van het verdachte bericht, controleer op andere berichten op het forum of vraag het.


Wat is er zo geweldig aan lessen?

Klassen zijn er om je te helpen je code te organiseren en te redeneren over je programma’s. Je zou grofweg kunnen zeggen dat er klassen zijn om fouten te voorkomen en om je te helpen bij het vinden van fouten nadat je een fout hebt gemaakt. Op deze manier helpen klassen aanzienlijk bij het onderhoud.

Een klasse is de weergave van een idee, een concept, in de code. Een object van een klasse vertegenwoordigt een bepaald voorbeeld van het idee in de code. Zonder klassen zou een lezer van de code moeten raden over de relaties tussen gegevensitems en functies – klassen maken dergelijke relaties expliciet en “begrepen” door compilers. Met klassen wordt meer van de structuur op hoog niveau van uw programma weerspiegeld in de code, niet alleen in de opmerkingen.

Een goed ontworpen klasse presenteert een schone en eenvoudige interface voor zijn gebruikers, verbergt zijn representatie en bespaart zijn gebruikers op het moeten weten van die representatie. Als de representatie niet verborgen zou moeten zijn – bijvoorbeeld omdat gebruikers elk lid van de data op elke gewenste manier moeten kunnen wijzigen – kun je die class zien als “gewoon een eenvoudige oude datastructuur”; bijvoorbeeld:

struct Pair {         string naam, waarde;};

Merk op dat zelfs datastructuren kunnen profiteren van hulpfuncties, zoals constructeurs.

Bij het ontwerpen van een klas is het vaak handig om te overwegen wat waar is voor elk object van de klas en op elk moment. Zo’n eigenschap wordt een invariant genoemd. De invariant van een vector zou bijvoorbeeld kunnen zijn dat de weergave ervan bestaat uit een wijzer naar een aantal elementen en dat aantal elementen wordt opgeslagen in een geheel getal. Het is de taak van elke constructor om de klasse-invariant vast te stellen, zodat elke ledfunctie er op kan vertrouwen. Elke functie van een lid moet de invariant geldig laten bij het verlaten. Dit soort denken is vooral handig voor klassen die bronnen beheren, zoals sloten, sockets en bestanden. Een bestandshandvatklasse heeft bijvoorbeeld de invariant dat deze een pointer naar een geopend bestand bevat. De constructor van de bestandsgreep opent het bestand. Destructors gratis middelen verworven door constructeurs. Bijvoorbeeld,

class File_handle {openbaar:File_handle (const char * n, const char * rw){f = fopen (n, rw); if (f == 0) gooi Open_failure (n); }~ File_handle () {fclose (f); } // destructor// ...privaat:BESTAND * f;};

Als u niet met klassen hebt geprogrammeerd, zult u delen van deze verklaring onduidelijk vinden en zult u het nut van klassen onderschatten. Zoek naar voorbeelden. Zoals alle goede studieboeken heeft TC ++ PL veel voorbeelden. Zie A Tour of C ++ voor een minder gedetailleerd en gemakkelijker te benaderen boek . De meeste moderne C ++ -bibliotheken bestaan ​​(onder andere) uit klassen en een bibliotheekhandleiding is een van de beste plaatsen om te zoeken naar voorbeelden van bruikbare klassen.


Wat is “OOP” en wat is er zo geweldig aan?

Er zijn veel definities van “objectgeoriënteerd”, “objectgeoriënteerd programmeren” en “objectgeoriënteerde programmeertalen”. Zie Waarom C ++ niet zomaar een objectgeoriënteerde programmeertaal is voor een langdurende uitleg van wat ik beschouw als “objectgericht” . Dat gezegd hebbende, objectgeoriënteerd programmeren is een stijl van programmeren die voortkomt uit Simula (meer dan 40 jaar geleden!) Met betrekking tot inkapseling, overerving en polymorfisme. In de context van C ++ (en vele andere talen met hun roots in Simula), betekent dit programmeren met behulp van klassehiërarchieën en virtuele functies om objecten van verschillende typen te manipuleren via goed gedefinieerde interfaces en om een ​​programma incrementeel te kunnen uitbreiden door afleiding.

Zie Wat is er zo geweldig aan lessen? voor een idee over wat geweldig is aan “gewone klassen”. Het punt over het rangschikken van klassen in een klassenhiërarchie is om hiërarchische relaties tussen klassen uit te drukken en die relaties te gebruiken om code te vereenvoudigen.

Als u OOP echt wilt begrijpen, zoekt u naar enkele voorbeelden. U hebt bijvoorbeeld twee (of meer) apparaatstuurprogramma’s met een gemeenschappelijke interface:

class Driver {// algemene driverinterfaceopenbaar:virtuele int-lees (char * p, int n) = 0; // lees max n tekens van apparaat naar p// retourneer het aantal gelezen tekensvirtuele bool-reset () = 0; // reset het apparaatvirtuele statuscontrole () = 0; // lees status};

Dit stuurprogramma is gewoon een interface. Het wordt gedefinieerd zonder gegevensleden en een reeks pure virtuele functies. Via deze interface kan een stuurprogramma worden gebruikt en veel verschillende soorten stuurprogramma’s kunnen deze interface implementeren:

klasse Driver1: public Driver {// een stuurprogrammaopenbaar:Driver1 (Register); // constructorint read (char *, int n);bool-reset ();Statuscontrole ();privaat:// implementatiedetails, incl. vertegenwoordiging};class Driver2: public Driver {// een andere driveropenbaar:Driver2 (Register);int read (char *, int n);bool-reset ();Statuscontrole ();privaat:// implementatiedetails, incl. vertegenwoordiging};

Merk op dat deze stuurprogramma’s gegevens (status) bevatten en objecten ervan kunnen worden gemaakt. Ze implementeren de functies die zijn gedefinieerd in Driver. We kunnen ons voorstellen dat een stuurprogramma als volgt wordt gebruikt:

void f (Driver & d) // gebruik stuurprogramma{Status old_status = d.check ();// ...d.reset ();char buf [[512]];int x = d. read (buf, 512);// ...}

Het belangrijkste punt hier is dat f () niet hoeft te weten welk type stuurprogramma het gebruikt; alles wat het moet weten is dat het een bestuurder is geslaagd; dat is, een interface voor veel verschillende soorten stuurprogramma’s. We kunnen f () als volgt aanroepen:

ongeldig g (){Driver1 d1 (Register (0xf00)); // maak een Driver1 voor apparaat// met apparaatregister op adres 0xf00Driver2 d2 (Register (0xa00)); // maak een Driver2 voor apparaat// met apparaatregister op adres 0xa00// ...int dev;cin >> dev;if (dev == 1) f (d1); // gebruik d1andersf (d2); // gebruik d2// ...}

Merk op dat wanneer f () een stuurprogramma gebruikt, de juiste soort bewerkingen impliciet worden gekozen tijdens runtime. Als f () bijvoorbeeld d1 wordt doorgegeven, gebruikt d.read () Driver1 :: read (), terwijl als f () met d2 wordt doorgegeven, d.read () Driver2 :: read () gebruikt. Dit wordt soms run-time verzending of dynamische verzending genoemd. In dit geval is er geen manier waarop f () het soort apparaat kan kennen waarmee het wordt gebruikt, omdat we het op basis van een invoer kiezen.

Houd er rekening mee dat objectgeoriënteerd programmeren geen wondermiddel is. “OOP” betekent niet alleen “goed” – als er geen inherente hiërarchische relaties zijn tussen de fundamentele concepten in uw probleem, zal geen enkele hoeveelheid hiërarchie en virtuele functies uw code verbeteren. De kracht van OOP is dat er veel problemen zijn die nuttig kunnen worden uitgedrukt met behulp van klassehiërarchieën – de belangrijkste zwakte van OOP is dat te veel mensen proberen om te veel problemen in een hiërarchische vorm te forceren. Niet elk programma moet objectgeoriënteerd zijn. Als alternatieven, beschouw eenvoudige klassen ,generieke programmering en vrijstaande functies (zoals in wiskunde, C en Fortran).


Wat is “generieke programmering” en wat is er zo geweldig aan?

Generieke programmering is programmeren op basis van parametrering: u kunt een type parametreren met een ander (zoals een vector met zijn elementtypen) en een algoritme met een ander (zoals een sorteerfunctie met een vergelijkingsfunctie). Het doel van generieke programmering is om een ​​nuttig algoritme of gegevensstructuur te generaliseren naar de meest algemene en nuttige vorm. Een vector van gehele getallen is bijvoorbeeld prima en dat geldt ook voor een functie die de grootste waarde vindt in een vector van gehele getallen. Een generieke oplossing die een vector biedt van elk type dat de gebruiker wil gebruiken en een functie die de grootste waarde in een willekeurige vector vindt, is echter nog beter:

vector <string> :: iterator p = find (vs.begin (), vs.end (), "Grail");vector <int> :: iterator q = find (vi.begin (), vi.end (), 42);

Deze voorbeelden zijn van de STL (de containers en algoritmen deel van de ISO C ++ standaardbibliotheek); voor een korte introductie, zie Een rondleiding door C ++ van TC ++ PL .

Generiek programmeren is in sommige opzichten flexibeler dan objectgeoriënteerd programmeren. Het is met name niet afhankelijk van hiërarchieën. Er is bijvoorbeeld geen hiërarchische relatie tussen een int en een tekenreeks. Generieke programmering is over het algemeen meer gestructureerd dan OOP; in feite is een algemene term die wordt gebruikt om generieke programmering te beschrijven “parametrisch polymorfisme”, waarbij “ad hoc polymorfisme” de overeenkomstige term is voor objectgeoriënteerd programmeren. In de context van C ++ worden alle namen bij het compileren met generieke programmering opgelost; het gaat niet om een ​​dynamische (run-time) verzending. Dit heeft geleid tot generieke programmering om dominant te worden in gebieden waar runtime-prestaties belangrijk zijn.

Merk op dat generieke programmering geen wondermiddel is. Er zijn veel onderdelen van een programma die geen parametrering behoeven en veel voorbeelden waar ODP (run-time dispatch) nodig is.


Waarom staat C ++ onveilige code toe?

Dat wil zeggen, waarom ondersteunt C ++ -bewerkingen die kunnen worden gebruikt om de regels van statische (compileertijd) -typeveiligheid te schenden?

  • om rechtstreeks toegang te krijgen tot hardware (bijvoorbeeld om een ​​geheel getal te behandelen als aanwijzer naar (adres van) een apparaatregister)
  • om optimale run-time en ruimtevaartprestaties te bereiken (bijv. ongecontroleerde toegang tot elementen van een array en ongecontroleerde toegang tot een object via een pointer)
  • compatibel zijn met C

Dat gezegd hebbende, is het een goed idee om onveilige code zoals de pest te vermijden als u niet echt een van deze drie functies nodig heeft:

  • gebruik geen casts
  • houd arrays buiten interfaces (verberg ze in de ingewanden van krachtige functies en klassen waar ze nodig zijn en schrijf de rest van het programma op met de juiste strings, vectoren, etc.)
  • vermijd ongeldig * (bewaar ze binnen low-level functies en datastructuren als je ze echt nodig hebt en presenteer veilige interfaces van het type, meestal templates, aan je gebruikers)
  • vermijd vakbonden
  • als u twijfelt over de geldigheid van een aanwijzer, gebruikt u in plaats daarvan een slimme aanwijzer,
  • gebruik geen “naakt” nieuws en verwijderingen (gebruik in plaats daarvan containers, middelenhandvatten, enz.)
  • gebruik geen …- stijlvariadische functies (“printf-stijl”)
  • Voorkom dat macro’s excuus zijn voor bewakers

Bijna alle C ++ -codes kunnen deze eenvoudige regels volgen. Wees alsjeblieft niet in de war door het feit dat je deze regels niet kunt volgen als je C-code of C-stijlcode schrijft in C ++.

Voor een ambitieus project om C ++ gebruiksvriendelijker en veiliger te maken zonder de efficiëntie of flexibiliteit ervan te schaden, raadpleegt u de Core C ++ – richtlijnen .


Wat is het beste boek om C ++ van te leren?

Er is geen enkel boek dat het beste is voor elke persoon. Er kan er geen zijn. Mensen zijn te verschillend in de manier waarop ze leren, in wat ze al weten, in wat ze nodig hebben, in wat ze willen, en in wat voor soort inspanning ze bereid zijn te maken. Er zijn nogal wat uitstekende boeken over C ++. Bekijk de website van ACCU (de vereniging van C- en C ++ -gebruikers). Dit is een van de beste sites voor boekaanbevelingen door ervaren programmeurs die niet bang zijn om hun mening te geven (boekverkopers neigen ernaar om rooskleurige recensies te geven en beoordelingen van de vorm “Dit boek is perfect, ik vind het geweldig, ik heb bijna drie hoofdstukken gelezen , en kan niet wachten om meer te lezen “zijn slechter dan nutteloos – waarom zou iemand advies nemen over hoe C ++ te leren van iemand die helemaal geen C ++ ervaring heeft, verslaat me). De ACCU beoordeelt boeken voor het vereiste ervaringsniveau en de algehele kwaliteit.

Voor mensen die nog niet eerder hebben geprogrammeerd of die uit een andere taal komen en een relatief vriendelijke introductie tot de moderne C ++ willen, overweeg Programming: Principles and Practice met C ++ . Dit is het boek dat ik schreef voor een eerstejaars (1ejaars universitaire studenten) programmeercursus en het heeft geprofiteerd van drie jaar gebruik in de klas.

Voor mensen die programmeurs zijn en bereid zijn nieuwe concepten en technieken uit een klassiek tekstboek te leren, raad ik The C ++ Programming Language aan (4e editie) . Het boek is bedoeld voor programmeurs met enige ervaring en een wens om C ++ onder de knie te krijgen. Het is niet gericht op niet-programmeurs die proberen hun eerste programmeertaal te leren of op toevallige programmeurs die zo snel mogelijk oppervlakkig inzicht in C ++ proberen te krijgen. Daarom concentreert dit boek zich op concepten en technieken en gaat het tot op zekere hoogte compleet en nauwkeurig. Het beschrijft “pure C ++, dat wil zeggen, de taal onafhankelijk van een bepaalde software-ontwikkelingsomgeving of foundationbibliotheek (behalve de standaardbibliotheek, natuurlijk). Het bevat een uitgebreide dekking van de standaardbibliotheek.

Als je al een ervaren programmeur bent en snel een overzicht wilt hebben van wat C ++ te bieden heeft, overweeg dan A Tour of C ++ . Het presenteert de belangrijkste functies van C ++ en de standaardbibliotheek in 180 pagina’s.

Als je wilt weten waarom C ++ is zoals het is, bekijk dan eens het ontwerp en de evolutie van C ++ (D & E). Het begrijpen van de ontwerpcriteria en -beperkingen helpt bij het schrijven van betere programma’s.


Hoe lang duurt het om C ++ te leren?

Dat hangt ervan af wat je bedoelt met ‘leren’. Als je een C-programmeur bent, kun je genoeg C ++ leren om je effectiever te maken bij het programmeren in C-stijl op een dag.

Bij TAMU gebruiken we Programmeren: principes en oefenen met C ++ om eerstejaarsstudenten ( 1ejaars studenten ) in een semester door de fundamenten van C ++ en de programmeertechnieken die het ondersteunt (met name objectgeoriënteerde programmering en generieke programmering ) te halen.

Aan de andere kant, als je volledig op je gemak wilt zijn met alle belangrijke C ++ taalconstructies, met data-abstractie, object-georiënteerd programmeren, generieke programmering, object-georiënteerd ontwerp, enz., Kun je gemakkelijk een jaar of twee doorbrengen – als je bent niet al bekend met die technieken (bijvoorbeeld van Java of C #).

Is dat dan de tijd die het kost om C ++ te leren? Misschien, maar nogmaals, dat is het tijdsschema dat we moeten overwegen om betere ontwerpers en programmeurs te worden. Als een ingrijpende verandering in de manier waarop we werken en nadenken over het bouwen van systemen niet ons doel is, waarom dan de moeite nemen om een ​​nieuwe taal te leren? Vergeleken met de tijd die nodig is om de piano goed te leren spelen of om vloeiend in een vreemde (natuurlijke) taal te worden, is het gemakkelijk om een ​​nieuwe en andere programmeertaal en programmeerstijl te leren.

Voor meer observaties over het leren van C ++ zie D & E of een notitie van comp.lang.c ++ die ik enige tijd geleden heb geschreven.


C kennen is een vereiste om C ++ te leren, toch?

Fout. De gemeenschappelijke subset van C en C ++ is gemakkelijker te leren dan C. Er zullen minder typefouten zijn om handmatig te vangen (het C ++ type systeem is strikter en expressiever), minder trucs om te leren (C ++ stelt je in staat om meer dingen uit te drukken zonder circumlocution) en betere bibliotheken beschikbaar. De beste initiële subset van C ++ om te leren is niet “alles van C”.

Zie Standaard C ++ leren als een nieuwe taal voor een bespreking van de keuze van C ++ -constructies, -technieken en -bibliotheken voor vroeg leren. Zie Stroustrup: Programming: Principles and Practice voor een voorbeeld van boeken dat deze benadering systematisch benadert met C ++ en Koenig & Moo: “Accelerated C ++” uit de serie C ++ In Depth van Addison Wesley .


Moet ik een pure OO-taal leren voordat C ++ een echte OO-programmeur wordt?

Nee. Leren van iets nieuws is bijna altijd een goed idee. Elke taal is echter anders en heeft zijn eigen stijlen en eigenaardigheden. Code geschreven in een zogenaamd “pure” OO-stijl gemodelleerd op een andere taal (eigenaardigheden en al) is vaak niet optimaal en frustrerend wanneer deze te letterlijk in C ++ wordt getranscribeerd. Ook, “het schrijven van alleen pure object-georiënteerde code” is niet een van mijn idealen; zie mijn OOPSLA keynote Waarom C ++ niet zomaar een object-georiënteerde programmeertaal is . Als je een goede C ++ -programmeur wilt worden en niet over een paar maanden te besteden hebt, concentreer je je op C ++ en de concepten die het belichaamt.


Hoe begin ik C ++ te leren?

Natuurlijk hangt dat sterk af van wat je al weet en van je redenen om C ++ te leren. Als je een beginner bent in programmeren, raad ik je ten zeerste aan een ervaren programmeur te zoeken die je kan helpen. Anders kunnen de onvermijdelijke fouten over taalconcepten en praktische problemen met de implementatie die u gebruikt, worden uitgebreid tot ernstige frustraties.

Je hebt een leerboek nodig om C ++ te leren. Dit is het geval, zelfs wanneer uw implementatie wordt geleverd met voldoende on-line documentatie. De reden is dat taal- en bibliotheekdocumentatie samen met voorbeeldcode geen goede conceptendocenten zijn. Typisch zwijgen dergelijke bronnen over waarom de dingen zijn zoals ze zijn en welke voordelen je van een techniek kunt verwachten (en die je niet mag verwachten). Concentreer u op concepten en technieken in plaats van op taaltechnische details.

Wanneer u een boek kiest, zoek er dan naar met Standard C ++ en gebruik vanaf het begin de standaard bibliotheekfaciliteiten op een geïntegreerde manier. Het lezen van een tekenreeks uit de invoer zou er bijvoorbeeld ongeveer zo uit moeten zien

string s; // Standaard C ++ -stijlcin >> s;

en niet zo

char s [[MAX]]; / * Standaard C-stijl * /scanf ( "% s", s);

Zoek naar boekaanbevelingen van programmeurs met een solide C ++ -ervaring.

Ik raad aan om Programming: Principles and Practice te gebruiken met C ++ , maar vergeet niet dat niemand het beste voor iedereen is . Bekijk de boekbesprekingen op de website ACCU (de vereniging van C- en C ++ -gebruikers).

Richt op het schrijven van idiomatische C ++: vermijd simpelweg het schrijven van code in de stijl van je vorige taal met behulp van de C ++ syntaxis; er is weinig te winnen bij het veranderen van de syntaxis.


Wil je me helpen met mijn huiswerk?

Nee sorry. Ik doe geen (ander) huiswerk. Ik krijg te veel verzoeken om hulp bij huiswerk en help bij het vinden van fouten in studentenprogramma’s om de tijd te vinden. Hoe dan ook, het is niet de beste manier om een ​​verre expert te leren kennen om je programma’s te verbeteren. Probeer een lokale persoon met C ++ ervaring te vinden die u om begeleiding kunt vragen. Een goede mentor is de beste hulp die een student kan hebben; misschien zijn ze daarom niet gemakkelijk te vinden.

Ook nee, ik zal niet voorstellen “een goed project voor een student om aan te werken”. Mijn ervaring is dat het voldoende tijd kost om voldoende te leren over een student en zijn / haar cursus om te weten welke moeilijkheidsgraad vereist is en welk soort project van belang is. Een goed project bedenken is dan niet-triviaal, en om precies uit te leggen wat het project is en hoe het te benaderen, kan meerdere berichten en enkele uren duren. Ik heb gewoon niet zoveel tijd. Vergeet niet dat deze aanvraag minstens wekelijks komt. Ten slotte lijken sommige studenten het idee te hebben dat als ik een project voorstel, ik moreel verplicht ben om zeer gedetailleerde hulp te bieden bij de voltooiing ervan.

Ideeën: bekijk de oefeningen in TC ++ PL of andere goede studieboeken. Veel van die oefeningen zijn ontworpen om een ​​student een aantal dagen bezig te houden, en het lezen van die oefeningen kan een ondernemende student inspireren om iets dergelijks te doen. Of kijk naar het niet-computerwetenschappelijke deel van uw wereld: misschien zou een biologieproject ondersteuning kunnen gebruiken voor een nieuw meetinstrument of zou een vriend die geschiedenis bestudeert een verbeterde database-interface kunnen gebruiken. Veel van de beste projecten en het beste gebruik van computers vallen buiten de traditionele informatica.

Zie ook mijn veelgestelde vragen over C ++ -stijl en -technieken . Echte beginners die voor het eerst worden geconfronteerd “lees wat gegevens, doen er iets aan en produceren output”, zijn mogelijk geïnteresseerd ineen heel eenvoudig programma of een programma dat een string van input leest .


Waar kan ik een gratis C ++ -compiler krijgen?

Van veel plaatsen; zie mijn C ++ compilerslijst .


Jij bent Zweeds?

Nee. Ik ben Deens. Bekijk mijn biografie .


Wat is de beste manier om mijn C ++ -programma’s te verbeteren?

Ik kon het niet zeggen. Dat hangt ervan af hoe je het gebruikt. De meeste mensen onderschatten abstracte klassen en sjablonen. Omgekeerd gebruiken de meeste mensen serieus misbruik van afgietsels en macro’s. Bekijk een van mijn papers of boeken voor ideeën. Een manier om abstracte klassen en sjablonen te beschouwen, is als interfaces die een meer heldere en logische presentatie van services mogelijk maken dan eenvoudig te bieden is via functies of klassenhiërarchieën met één root. Zie mijn Veelgestelde vragen over stijl en technieken voor enkele specifieke voorbeelden en ideeën.


Maakt het uit welke programmeertaal ik gebruik?

Ja, maar verwacht geen wonderen. Sommige mensen lijken te geloven dat een programmeertaal de meeste van hun problemen met systeemopbouw kan of zou moeten oplossen. Ze zijn veroordeeld om voor eeuwig op zoek te gaan naar de perfecte programmeertaal en worden herhaaldelijk teleurgesteld. Anderen verwerpen programmeertalen als onbelangrijke “implementatiedetails” en stoppen hun geld in ontwikkelingsprocessen en ontwerpmethoden. Ze zijn veroordeeld om voor altijd te programmeren in COBOL-, C- en eigen ontwerptalen. Een goede taal – zoals C ++ – kan veel betekenen voor een ontwerper en een programmeur, zolang de sterke en beperkingen ervan duidelijk worden begrepen en gerespecteerd.


Heeft de ANSI / ISO-normcommissie C ++ bedorven?

Nee. Ze / we hebben goed werk geleverd. Je kunt met details kibbelen (en dat doe ik, soms luid), maar ik ben blij met de taal en de nieuwe standaardbibliotheek. ISO C ++ is een betere en meer samenhangende taal dan eerdere versies van C ++. Je kunt tegenwoordig veel elegantere en beter leesbare C ++ -programma’s schrijven dan toen het standaardproces begon. De nieuwe standaardbibliotheek is ook een echte zegen. Het aanbieden van strings, lijsten, vectoren, kaarten en basisalgoritmen voor dergelijke fundamentele typen maakt een groot verschil in de manier waarop men C ++ kan benaderen. Zie de bibliotheekhoofdstukken van de C ++ Programming Language of A Tour of C ++ of een van mijn recente papers .

C ++ 14 is zelfs beter.


Wanneer hebben we een C ++ -standaard?

We hebben er één gehad sinds 1998. De tweede standaard kwam in 2011.

De huidige standaard, C ++ 14 , is in 2014 goedgekeurd en goede implementatie wordt al verzonden . C ++ 11 / C ++ 14 wordt beschreven in de huidige edities van mijn boeken .


Waar kan ik een machineleesbare versie van de standaard krijgen?

De C ++ -standaard (ISO / IEC 14882) kan worden gedownload in de ANSI Electronic Store . Zoek naar “14882” om “INCITS / ISO / IEC 14882-2003 Programmeer Talen – C ++” te vinden. De kosten hiervan zijn (zoals ik dit schrijf) US $ 30,00, te betalen via creditcard. Het gedownloade document is in PDF-vorm, ongeveer 3Mb totale grootte.

Een laat werkdocument is gratis beschikbaar. Dit komt dicht in de buurt van de definitieve internationale ontwerpnorm die formeel werd aanvaard door een nationale 21-0-stem in augustus 2011.

Wees gewaarschuwd dat de standaard geen zelfstudie is; zelfs deskundige programmeurs zullen beter leren over C ++ en nieuwe C ++ -functies uit een studieboek.

Zie mijn veelgestelde vragen over C ++ 11 voor verwijzingen naar C ++ 11-materiaal.


Zijn er functies die u wilt verwijderen uit C ++?

Niet echt. Mensen die dit soort vragen stellen, denken meestal aan een van de belangrijkste functies, zoals multiple inheritance, exceptions, templates of run-time type-identificatie. C ++ zou zonder deze onvolledig zijn. Ik heb hun ontwerp in de loop der jaren herzien en samen met de normcommissie heb ik een aantal van hun details verbeterd, maar geen daarvan kon worden verwijderd zonder schade aan te richten.

De meeste functies die ik niet leuk vind vanuit een taalontwerpperspectief (bijvoorbeeld de syntaxis van declarators en array-decay) maken deel uit van de C-subset van C ++ en kunnen niet worden verwijderd zonder schade toe te brengen aan programmeurs die onder realistische omstandigheden werken. De C-compatibiliteit van C ++ was een ontwerp van een belangrijk taalontwerp in plaats van een marketinggimmick. Compatibiliteit was moeilijk te bereiken en te behouden, maar echte voordelen voor echte programmeurs resulteerden en zijn nog steeds het resultaat van vandaag. Inmiddels heeft C ++ functies waarmee een programmeur de meest lastige C-functies niet kan gebruiken. Standaardbibliotheekcontainers zoals vector, lijst, kaart en tekenreeks kunnen bijvoorbeeld worden gebruikt om de meest lastige manipulatie van laag-niveauaanwijzers te voorkomen.


Wat is het verschil tussen C ++ 98 en C ++ 11 en C ++ 14?

Dat is niet iets dat gemakkelijk kan worden samengevat. Voor de meeste praktische doeleinden is C ++ 14 achterwaarts compatibel met C ++ 11, dat achterwaarts compatibel is met C ++ 98. Er is een compatibiliteitssectie aan de achterkant van de standaard die compatibiliteitsproblemen beschrijft.

Er is een lange lijst van C ++ 11-extensies voor C ++ 98 op de pagina C ++ 11 . C ++ 14 is een relatief kleine verbetering ten opzichte van C ++ 11, bedoeld om C ++ 11 te voltooien, in plaats van nieuwe programmeertechnieken mogelijk te maken.


Hoe ziet de volgende standaard eruit?

Dat is C ++ 17. Het is een beetje vroeg om zeker te zeggen wat C ++ 17 zal bieden, maar het is bedoeld als een grote upgrade en ik presenteerde enkele van mijn ideeën tijdens een 2015-normvergadering . Merk op dat het onwaarschijnlijk is dat ik alles krijg wat ik wens. Zie de WG21-site voor een volledige lijst met voorstellen .


Wanneer publiceer je een 4e editie van “The C ++ Programming Language”?

Het is in druk: de programmeertaal C ++ (4de editie) . Addison-Wesley. ISBN 978-0321563842. Mei 2013.

Het wordt nu verzonden vanuit Amazon, van de uitgever en elders.

Er zijn geen lopende plannen voor een 5e editie.


Wat is het verschil tussen de boeken “TC ++ PL” en “Programming”?

De C ++ programmeertaal is in de eerste plaats geschreven voor ervaren programmeurs die C ++ willen leren. De stijl is die van een professioneel boek. Programmeren – Principes en praktijk met C ++ is voornamelijk geschreven voor mensen die willen leren programmeren met C ++. Het kan worden gebruikt / gelezen door mensen met geen of slechts een zwakke programmeerachtergrond en mensen die moderne programmeertechnieken willen leren, zoals objectgeoriënteerd programmeren en generieke programmering, zoals ondersteund door C ++. De stijl is die van een tekstboek.

Een samenvatting:

  • TC ++ PL4 : voor programmeurs die moderne C ++ diepgaand willen leren kennen
  • Tour ++ : voor programmeurs die een overzicht van moderne C ++ willen
  • PPP : voor beginners en programmeurs met een zwak begrip van C ++
  • D & E : voor mensen die geïnteresseerd zijn in ontwerpprincipes en geschiedenis
  • Anderen: lees ze niet; ze zijn verouderd

Houd je van e-books?

Ik hou van e-books voor misdaadverhalen en SF. Ik denk niet dat ze klaar zijn voor serieuze technische informatie. Daarvoor geef ik de voorkeur aan papier – zelfs als ik een paar dagen moet wachten en wat extra gewicht moet dragen. Een goed leerboek, geopend op een tafel, toont twee pagina’s – een gebied dat ongeveer drie keer groter is dan dat van een e-boeklezer. Lezen op een groot scherm van goede kwaliteit is OK, gewoon OK.


Waar vind ik gratis, machinaal leesbare exemplaren van uw boeken?

Er zijn geen legale gratis machineleesbare kopieën van mijn boeken. Als u een kopie vrij beschikbaar ziet, moet dit een schending van het auteursrecht zijn (dat wil zeggen, het is gestolen).

Addison-Wesley biedt elektronische versies aan via Safari online boeken en elders.


Welke C ++ -compiler raadt u aan? Welke bibliotheken?

Ik raad het niet aan. Het zou niet eerlijk zijn. Krijg echter een recente release. Uiteraard benaderen nieuwere compilers de ISO-norm veel nauwer dan die van compilers van een paar jaar geleden.

Zie mijn compilerslijst voor C ++ voor een onvolledige lijst met C ++ -implementaties .

Geef waar mogelijk ook de voorkeur aan de standaardbibliotheek voor niet-standaard ‘basisbibliotheken’ en probeer het gebruik van eigen extensies tot een minimum te beperken.


Zijn lijsten slecht?

Volgens sommige hoeken van het web, ik ben onder de indruk dat vectoren zijn altijd beter dan gelinkte lijsten en dat ik weet niet over andere data structuren, zoals bomen (bijv std :: set ) en hash tables (bijvoorbeeld std :: ongeordende_map ). Dat is natuurlijk absurd.

Het probleem lijkt een interessante kleine oefening te zijn die John Bentley me ooit heeft voorgesteld: voeg een reeks willekeurige gehele getallen in een gesorteerde reeks in, verwijder vervolgens die elementen één voor één zoals bepaald door een willekeurig aantal posities: gebruikt u een vector ( een opeenvolgend toegewezen reeks elementen) of een gekoppelde lijst? Zie bijvoorbeeld Software Development for Infrastructure . Ik gebruik dit voorbeeld om enkele punten te illustreren, het nadenken over algoritmen, datastructuren en machine-architectuur aan te moedigen en te besluiten:

  • bewaar gegevens niet onnodig,
  • gegevens compact houden, en
  • toegang tot het geheugen op een voorspelbare manier.

Let op de afwezigheid van “ lijst ” en “ vector ” in de conclusie. Verwar een voorbeeld niet met wat het voorbeeld bedoeld is om te illustreren.

Ik gebruikte dat voorbeeld in verschillende gesprekken, met name:

Deze video was populair: hij is meer dan 250.000 keer gedownload (plus nog eens 50.000 keer op andere sites). Mijn indruk is dat veel kijkers niet begrepen dat het doel van dat voorbeeld is om enkele algemene principes te illustreren en mensen aan het denken te zetten. Aanvankelijk zeggen de meeste mensen “ Lijst natuurlijk! ” (Ik heb die vraag vele malen geprobeerd) vanwege de vele invoegingen en verwijderingen “ in het midden ” (lijsten zijn goed in dat). Dat antwoord is volledig en dramatisch verkeerd, dus het is goed om te weten waarom.

Ik gebruik het voorbeeld al jaren en liet afgestudeerde studenten tientallen varianten van deze oefening en verschillende oefeningen uitvoeren en meten. Voorbeelden en metingen door anderen zijn te vinden op het internet. Natuurlijk,

  • Ik heb kaarten geprobeerd (ze zijn veel beter dan lijsten, maar nog steeds langzamer dan vectoren)
  • Ik heb veel grotere elementengroottes uitgeprobeerd (uiteindelijk komen lijsten tot hun recht)
  • Ik heb binaire zoekopdrachten en directe invoeging voor vectoren gebruikt (ja, ze versnellen zelfs nog verder)
  • Ik controleerde mijn theorie (nee ik overtreed geen enkele grote-O-complexiteitsregel, het is alleen dat sommige bewerkingen dramatisch duurder kunnen zijn voor de ene gegevensstructuur dan de andere)
  • Ik heb links vooraf geallocateerd (dat is beter dan std :: list maar de traversal doodt nog steeds de prestaties)
  • Ik heb enkelvoudig gelinkte lijsten gebruikt, forward_list s (dat maakt niet zoveel uit, maar maakt het een beetje moeilijker om ervoor te zorgen dat de gebruikerscode 100% equivalent is)
  • Ik weet (en zeg) dat 500K-lijsten niet vaak voorkomen (maar dat maakt niet uit voor mijn belangrijkste punt). We gebruiken veel structuren (groot en klein) waarbij er een keuze is tussen gekoppelde en aaneengesloten reprproductie.
  • Ik weet dat voor het invoegen push_front () sneller is voor std :: list s en push_back () s is sneller voor vector s. U kunt voorbeelden maken om dat te illustreren, maar dit voorbeeld is daar niet een van.

Mijn punt gaat niet over lijsten als zodanig. Ze hebben hun gebruik, maar dit voorbeeld is niet een van hen. Verwar dit voorbeeld niet met wat het voorbeeld illustreert. Dit voorbeeld gaat over het gebruik van geheugen: we maken heel vaak een datastructuur, doen er een berekening op die toegang vereist (vaak doorkruisen) en vervolgens verwijderen. De geordende volgorde is slechts een voorbeeld van een dergelijk gebruik en het voorbeeld wordt gepresenteerd om mensen te laten nadenken over wat er in dergelijke gevallen van belang is. Mijn suggestie is:

  • bewaar gegevens niet onnodig,
  • gegevens compact houden, en
  • toegang tot het geheugen op een voorspelbare manier.

Ik benadruk het belang van cache-effecten. In mijn ervaring vergeten vrijwel alle echte experts die algoritmen die worden besproken.

En ja, mijn aanbeveling is standaard std :: vector te gebruiken . Gebruik meer in het algemeen een aaneengesloten representatie tenzij er een goede reden is om dat niet te doen. Net als C is C ++ ontworpen om dat standaard te doen.

Geef ook geen uitspraken over prestaties zonder metingen. Ik heb een geval gezien waarbij het veranderen van een nul-naar-twee-elementenlijst naar een nul-naar-twee-elementenvector een factor-van-twee verschil maakte met een algoritme. Dat had ik niet verwacht. Ook andere experts keken niet naar de code.


Is Java de taal die je zou hebben ontworpen als je niet compatibel zou moeten zijn met C?

Nee. Java is niet eens in de buurt. Als mensen erop staan ​​C ++ en Java te vergelijken – zoals ze lijken te doen – raad ik aan om het ontwerp en de evolutie van C ++ (D & E) te lezen om te zien waarom C ++ is zoals het is, en beide talen te beschouwen in het licht van de ontwerpcriteria I ingesteld voor C ++. Die criteria zullen duidelijk verschillen van de criteria van Sun’s Java-team. Ondanks de syntactische overeenkomsten zijn C ++ en Java heel verschillende talen. Java lijkt in veel opzichten dichter bij Smalltalk dan bij C ++.

Een groot deel van de relatieve eenvoud van Java is – zoals voor de meeste nieuwe talen – deels een illusie en deels een functie van de incompleetheid ervan. Naarmate de tijd verstrijkt, zal Java aanzienlijk in omvang en complexiteit groeien. Het zal in omvang verdubbelen of verdrievoudigen en implementatieafhankelijke uitbreidingen of bibliotheken laten groeien. Dat is de manier waarop elke commercieel succesvolle taal zich heeft ontwikkeld. Kijk gewoon naar elke taal die u op grote schaal als succesvol beschouwt. Ik ken geen uitzonderingen en er zijn goede redenen voor dit fenomeen. [[Ik schreef dit vóór 2000; nu (2012) is het taalgedeelte van de Java 7-specificatie iets langer in termen van het aantal pagina’s dan de ISO C ++ 11-taalspecificatie.]]

Ik heb (negatief) gereageerd op de Java-hype en heb veel succes van Java toegeschreven aan marketing. Zie bijvoorbeeld mijn HOPL-3-document . Vandaag (2010) zijn de beweringen over Java gebaseerd op de realiteit en minder vrijblijvend op alternatieven. Dit was niet altijd zo. Vergelijk bijvoorbeeld het oorspronkelijke Java-whitepaper uit 1995 met de versies die u op internet vindt (soms aangeduid als “de originele Java whitepaper”); pagina 69 zou een goede plaats zijn om te beginnen.

Java is niet platformonafhankelijk; het is een platform. Net als Windows is het een eigen commercieel platform. Dat wil zeggen dat u programma’s voor Windows / Intel of Java / JVM kunt schrijven, en in beide gevallen schrijft u code voor een platform dat eigendom is van één bedrijf en wordt getweaked voor het commerciële voordeel van dat bedrijf. Er is op gewezen dat u programma’s in elke taal voor de JVM- en bijbehorende besturingssystemen kunt schrijven. De JVM, enz., Zijn echter sterk bevooroordeeld ten gunste van Java. Het is lang niet altijd een algemene, redelijk taalneutrale VM / OS.

Persoonlijk houd ik me aan redelijk draagbare C ++ voor het meeste werk waarvan ik denk dat het meest aan de hand is en voor de rest gebruik ik een verscheidenheid aan talen.


Wat denk je van C #?

Ik heb geen opmerkingen over C # als een taal. Het zal me veel kosten om me ervan te overtuigen dat de wereld nog een andere eigen taal nodig heeft. Het zal met name moeilijk zijn om mij ervan te overtuigen dat het een taal nodig heeft die nauw is geïntegreerd met een specifiek bedrijfseigen besturingssysteem.

Als u uitsluitend voor het .Net-platform wilt schrijven, is C # niet het slechtste alternatief, maar onthoud dat C ++ een sterk ondersteund, hoewel minder sterk gehyped alternatief is op dat platform.


Wat denk je van C ++ / CLI?

C ++ / CLI is een reeks uitbreidingen van ISO C ++ die een uiterst complete “binding” van C ++ aan Microsoft’s CLI (Common Language Infrastructure) biedt. Het is gestandaardiseerd door ECMA (ECMA-372). Ik ben blij dat alle functies van de CLI gemakkelijk toegankelijk zijn vanuit C ++ en blij zijn dat C ++ / CLI een veel betere taal is dan zijn voorganger “Managed C ++”. Ik ben echter minder blij dat C ++ / CLI zijn doelen bereikt door in wezen C ++ te vergroten met een aparte taalfunctie voor elke functie van CLI (interfaces, eigenschappen, generieken, verwijzingen, overerving, opsommingen en nog veel, veel meer). Dit zal een grote bron van verwarring zijn (wat iemand ook doet of zegt).

De CLI biedt een reeks interfaces (voor systeemfaciliteiten) die heel verschillend zijn van traditionele interfaces naar de faciliteiten en applicaties van het besturingssysteem. In het bijzonder hebben deze interfaces een semantiek die niet volledig of gemakkelijk in conventionele programmeertalen kan worden uitgedrukt. Een manier om CLI te beschrijven is als een (gedeeltelijk) “platform” of “virtuele machine”. Het bestaat uit een groot aantal taalkenmerken (overerving, methoden, lusconstructies, callback-mechanismen, enz.), Die een groot aantal basisbibliotheken ondersteunen (de BCL), plus een uitgebreid systeem van metadata. De CLI wordt soms beschreven als “taalneutraal”. Een taal die een groot deel van deze faciliteiten niet accepteert, kan echter zelfs geen gebruik maken van de basis .Net-faciliteiten (of toekomstige Microsoft Windows-faciliteiten, ervan uitgaande dat Microsoft ‘al deze functies kunnen niet worden gebruikt voor de implementatie van middelen die bedoeld zijn om door andere talen te worden gebruikt. CLI is dus alleen “taalneutraal” in die zin dat elke taal alle CLI-functies moet ondersteunen om “eersteklas” te zijn op .Net.

Ik geef de voorkeur aan een binding als een paar primitieven, die kunnen worden uitgedrukt als eenvoudige functieaanroepen en eenvoudige gegevensstructuren in elke taal, mogelijk ingekapseld in taalspecifieke bibliotheken. Voor de CLI kan dit in het beste geval alleen voor klanten van CLI-faciliteiten worden gedaan. Een taal die wordt gebruikt om CLI-modules te produceren, moet alle CLI-faciliteiten, inclusief de metadata, kunnen uitdrukken. Alleen een taal die dat kan doen kan worden beschouwd als een systeem programmeertaal op .Net. Zo concludeerde het Microsoft C ++ -team dat alleen ingebouwde taalfaciliteiten aanvaardbaar zijn voor hun klanten. Hun ontwerp weerspiegelt een weergave die absoluut geen beperkingen accepteert op welk deel van CLI kan worden uitgedrukt in C ++ met de C ++ / CLI-extensies, absoluut geen breedsprakigheid vergeleken met andere talen bij gebruik van CLI-faciliteiten en absoluut geen overheadkosten in vergelijking met andere talen.

Zoals altijd leg ik de nadruk op draagbaarheid en raad ik mensen aan om applicaties te ontwerpen, zodat toegang tot systeemspecifieke faciliteiten mogelijk is via goed gedefinieerde interfaces gespecificeerd in ISO C ++ (bv. Niet om C ++ / CLI rechtstreeks te gebruiken). In Windows is dit soms lastig in vergelijking met het rechtstreeks gebruiken van C ++ / CLI-faciliteiten, maar het is de enige manier om draagbaarheid en een zekere mate van leveranciersonafhankelijkheid te verkrijgen. Het is duidelijk dat die armlengte-benadering van de CLI niet kan worden gehandhaafd als het doel van een stuk code erin bestaat een CLI-interface te verschaffen die door andere code wordt verbruikt. Houd er rekening mee dat ik de behoefte aan systeemspecifieke uitbreidingen herken en dat Microsoft niet de enige C ++-leverancier is met dergelijke extensies, ik geef er alleen de voorkeur aan om met dergelijke extensies om te gaan via een “dunne interface”

Hoe om te gaan met systeem-specifieke uitbreidingen is inherent een moeilijke vraag. Het Microsoft C ++ -team, met name Herb Sutter, heeft een actieve dialoog onderhouden met (andere) leden van de ISO C ++ -standaardencommissie, zodat de relatie tussen ISO C ++ en zijn superset C ++ / CLI uiteindelijk zal worden uitgewerkt. We hebben een lange staat van dienst van constructief gezamenlijk werk in de ISO C ++ -commissie. Om de verwarring tussen ISO C ++ en de C ++ / CLI-uitbreidingen tot een minimum te beperken, herziet Microsoft nu hun Visual C ++ -documentatie om C ++ / CLI duidelijk te onderscheiden van ISO C ++ (gewoon niet-gekwalificeerd C ++ betekent ISO C ++). Ik hoop dat anderen die voorsprong zullen volgen.

Over de moeilijke en controversiële vraag wat de CLI-binding / -extensies aan C ++ moet worden genoemd, geef ik de voorkeur aan C ++ / CLI als een afkorting voor “De CLI-uitbreidingen van ISO C ++”. Het houden van C ++ als onderdeel van de naam herinnert mensen eraan wat de basistaal is en zal helpen C ++ een juiste subset van C ++ te houden met de C ++ / CLI-extensies. De compatibiliteitsproblemen met C / C ++ latenzien hoe belangrijk het is om die subset-eigenschap te behouden.

Hier zijn enkele documenten met betrekking tot C ++ / CLI:


Waarom ben je zo dol op portabiliteit?

Succesvolle software is langlevend; levensduren van tientallen jaren zijn niet ongewoon. Een goede applicatie / programma bestaat vaak uit de hardware waarvoor het is ontworpen, het besturingssysteem waarvoor het is geschreven, het databasesysteem dat het aanvankelijk gebruikte, enz. Vaak overleeft een goed stuk software de bedrijven die de basistechnologieën hebben geleverd die zijn gebruikt om te bouwen het.

Vaak hebben een succesvolle applicatie / programma klanten / gebruikers die verschillende platforms verkiezen. De set wenselijke platforms verandert als de gebruikerspopulatie verandert. Als u bent gebonden aan een enkel platform of een enkele leverancier, beperkt u het potentiële gebruik van de toepassing / het programma.

Uiteraard is volledige platformonafhankelijkheid onverenigbaar met het vermogen om alle platformspecifieke faciliteiten te gebruiken. U kunt de platformonafhankelijkheid van een toepassing echter vaak benaderen door toegang te krijgen tot platformfaciliteiten via een “dunne interface” die het beeld van de toepassing van zijn omgeving als bibliotheek weergeeft.


Raad je Ada echt aan voor grotere projecten via C ++?

Nee. Ik heb geen idee wie dat gerucht begon, maar het moet een overenthousiaste of kwaadwillende Ada-toegewijde zijn geweest.


Zou je C ++ kunnen vergelijken met “enige taal”?

Nee sorry, dat doe ik niet. Je kunt de reden vinden in de inleidende opmerkingen van The Design and Evolution of C ++ :

“Verschillende reviewers vroegen me om C ++ te vergelijken met andere talen, wat ik heb besloten om het niet te doen.” Daarmee bevestigde ik een reeds lang bestaande en sterk verdedigde opvatting: taalvergelijkingen zijn zelden zinvol en zelfs minder vaak redelijk. talen vereist meer inspanning dan de meeste mensen bereid zijn te besteden, ervaring in een breed scala van toepassingsgebieden, een rigide onderhoud van een vrijstaand en onpartijdig oogpunt, en een gevoel van eerlijkheid. Ik heb niet de tijd, en als de ontwerper van C ++, mijn onpartijdigheid zou nooit volledig geloofwaardig zijn.

Ik maak me ook zorgen over een fenomeen dat ik herhaaldelijk heb waargenomen in eerlijke pogingen tot taalvergelijkingen. De auteurs proberen hard om onpartijdig te zijn, maar zijn hopeloos vooringenomen door zich te concentreren op een enkele applicatie, een enkele programmeerstijl, of een enkele cultuur onder programmeurs. Erger nog, wanneer een taal significant beter bekend is dan andere, treedt een subtiele verschuiving in perspectief op: gebreken in de bekende taal worden als minder belangrijk beschouwd en eenvoudige oplossingen worden voorgesteld, terwijl soortgelijke tekortkomingen in andere talen als fundamenteel worden beschouwd. Vaak zijn de tijdelijke oplossingen die vaak worden gebruikt in de minder bekende talen eenvoudig onbekend voor de mensen die de vergelijking uitvoeren of worden als onbevredigend beschouwd omdat ze in de meer vertrouwde taal onwerkbaar zouden zijn.

Evenzo is informatie over de bekende taal vaak helemaal up-to-date, terwijl de auteurs voor de minder bekende taal vertrouwen op informatie van een aantal jaar oud. Voor talen die het waard zijn om te vergelijken, is een vergelijking van taal X zoals drie jaar geleden gedefinieerd versus taal Y zoals deze in de nieuwste experimentele implementatie voorkomt, niet eerlijk en informatief. Dus beperk ik mijn opmerkingen over andere talen dan C ++ tot algemeenheden en tot zeer specifieke opmerkingen. ”

Dat gezegd hebbende, beschouw ik C ++ als de beste keuze in programmeertaal voor een grote verscheidenheid aan mensen en toepassingen.


Anderen vergelijken hun talen met C ++; vind je dat niet erg?

Het doet wanneer het incompetent wordt gedaan of voor commercieel gewin. De meest verspreide vergelijkingen zijn meestal geschreven door voorstanders van een bepaalde taal, Z, om te bewijzen dat Z beter is dan andere talen. Gezien het brede gebruik ervan, staat C ++ vaak bovenaan de lijst met talen die de voorstanders van Z minderwaardig willen bewijzen. Dergelijke documenten worden vaak ‘gepubliceerd’ of verspreid door een bedrijf dat Z verkoopt als onderdeel van een marketingcampagne. Verrassend genoeg lijken velen een niet-gereviewed document te hebben geschreven door mensen die werken voor een bedrijf dat Z “bewijst” dat Z het beste serieus is. Een probleem is dat er altijd korrels van waarheid zijn in dergelijke vergelijkingen. Immers, geen enkele taal is beter dan alle andere op alle mogelijke manieren. C ++ is zeker niet perfect, maar selectieve waarheid kan het meest verleidelijk en soms volledig misleidend zijn.

Kijk bij het kijken naar een taalvergelijking wie het heeft geschreven, overweeg zorgvuldig of de beschrijvingen feitelijk en eerlijk zijn en of de vergelijkingscriteria zelf eerlijk zijn voor alle beschouwde talen. Dit is niet makkelijk.


Je zult C ++ niet vergelijken met andere talen, maar je schrijft scheldwoorden over C ++?

Ik schrijf geen tirades (dat is een vijandige karakterisering van sommige teksten), maar ik beschouw het als redelijk – mogelijk zelfs als een plicht – voor iemand die een taal heeft ontworpen om de deugden te verklaren en te verdedigen tegen vijandige karaktertrekken. Zie mijn publicatielijst . Zie in het bijzonder mijn uitgebreide en peer reviewed papers voor de ACM History of Programming Conference:

Vaak wijs ik ook op de beperkingen van C ++ en de fundamentele aannames van het ontwerp van C ++ (zie bijvoorbeeld D & E ).


C is beter dan C ++ voor kleine projecten, toch?

Niet naar mijn mening. Ik heb nog nooit een project gezien waarvoor C beter was dan C ++ om welke reden dan ook, maar het ontbreken van een goede C ++ -compiler.


Is C een subset van C ++?

In de strikte mathematische zin is C geen subset van C ++. Er zijn programma’s die geldig C zijn maar geen geldige C ++ en zelfs een paar manieren om code te schrijven die een andere betekenis heeft in C en C ++. C ++ ondersteunt echter elke programmeertechniek die door C. wordt ondersteund. Elk C-programma kan op vrijwel dezelfde manier worden geschreven in C ++ met dezelfde runtime- en ruimtebesparing. Het is niet ongebruikelijk om tienduizenden regels ANSI C naar C-stijl C ++ binnen enkele uren te kunnen converteren. Dus is C ++ net zo goed een superset van ANSI C als ANSI C is een superset van K & R C en veel als ISO C ++ is een superset van C ++ zoals het in 1985 bestond.

Goed geschreven C is meestal ook legaal C ++. Bijvoorbeeld, elk voorbeeld in Kernighan & Ritchie: “The C Programming Language (2nd Edition)” is ook een C ++ -programma.

Voorbeelden van compatibiliteitsproblemen met C / C ++:

int main (){dubbele sq2 = sqrt (2); / * Niet C ++: oproep niet-aangegeven functie * /int s = sizeof ('a'); / * stil verschil: 1 in C ++ sizeof (int) in C * /}

Het aanroepen van een niet-aangegeven functie is een slechte stijl in C en illegaal in C ++. Dus is het doorgeven van argumenten aan een functie met behulp van een declaratie die geen argument types bevat:

void f (); / * argumenttypes niet genoemd * /ongeldig g (){f (2); / * slechte stijl C. Niet C ++ * /}

In C kan een ongeldige * impliciet worden geconverteerd naar elk aanwijzertype en wordt de toewijzing van de vrije opslag meestal gedaan met behulp van malloc (), die niet kan controleren of er “voldoende” geheugen is aangevraagd:

void * malloc (size_t);void f (int n){int * p = malloc (n * sizeof (char)); / * niet C ++. In C ++ toewijzen met `nieuwe '* /char c;ongeldig * pv = & c;int * pi = pv; / * impliciete conversie van leegte * in int *. Niet in C ++ * /}

Let op de mogelijke uitlijnfout die wordt veroorzaakt door de impliciete conversie van de leegte * in een int *. Zie het C ++ -alternatief voor ongeldig * en malloc () .

Let er bij het converteren van C naar C ++ op dat C ++ meer sleutelwoorden heeft dan C:

int klasse = 2; / * ok in C. Syntaxisfout in C ++ * /int virtueel = 3; / * ok in C. Syntaxisfout in C ++ * /

Behalve enkele voorbeelden, zoals de hierboven weergegeven voorbeelden (en in detail vermeld in de C ++ -standaard en in Bijlage B van de C ++ Programming Language (3e editie) ), is C ++ een superset van C. (Bijlage B is beschikbaar om te downloaden) .

Houd er rekening mee dat “C” in de bovenstaande alinea’s verwijst naar Classic C en C89. C ++ is geen afstammeling van C99; C ++ en C99 zijn broers en zussen. C99 introduceert verschillende nieuwe mogelijkheden voor C / C ++ incompatibiliteit .


Wat is het verschil tussen C en C ++?

C ++ is een directe afstammeling van C die bijna alle C als een subset bevat. C ++ biedt sterkere typecontroles dan C en ondersteunt rechtstreeks een breder scala aan programmeerstijlen dan C. C ++ is “een betere C” in die zin dat het de programmeerstijlen ondersteunt die met C zijn gedaan met betere typecontrole en meer notatieve ondersteuning (zonder verlies) van efficiëntie). In dezelfde zin is ANSI C een betere C dan K & R C. Bovendien ondersteunt C ++ gegevensabstractie, objectgeoriënteerd programmeren en generieke programmering (zie mijn boeken ).

Ik heb nog nooit een programma gezien dat beter kon worden uitgedrukt in C dan in C ++ (en ik denk niet dat een dergelijk programma zou kunnen bestaan ​​- elk construct in C heeft een voor de hand liggend C ++ -equivalent). Er bestaan ​​echter nog steeds enkele omgevingen waar de ondersteuning voor C ++ zo zwak is dat het een voordeel is om C in plaats daarvan te gebruiken. Er zijn echter niet veel van die overgebleven; ziemijn (onvolledige) compilerslijst .

Voor een bespreking van het ontwerp van C ++ inclusief een bespreking van zijn relatie met C zie The Design and Evolution of C ++ .

Houd er rekening mee dat “C” in de bovenstaande alinea’s verwijst naar Classic C en C89. C ++ is geen afstammeling van C99; C ++ en C99 zijn broers en zussen. C99 introduceert verschillende nieuwe mogelijkheden voor C / C ++ incompatibiliteit . Hier is een beschrijving van de verschillen tussen C ++ 98 en C99 .


Denk je echt dat C en C ++ kunnen worden samengevoegd in één enkele taal?

Ik denk dat het heel goed zou zijn voor de C / C ++ -gemeenschap als ze dat waren. Dat wil zeggen, als de incompatibiliteit met C / C ++ systematisch en volledig werd geëlimineerd en de toekomstige evolutie werd georganiseerd om te voorkomen dat nieuwe incompatibiliteiten zouden ontstaan. Of dat mogelijk is, is een andere zaak.

Mijn belangrijkste punt is dat de huidige C / C ++ incompatibiliteiten “ongelukken in de geschiedenis” zijn die geen fundamentele redenen achter de rug hebben (hoewel ze op het moment “een goed idee waren voor sommige bekwame en goedwillende mensen”). De incompatibiliteit met C / C ++ biedt geen voordelen voor de gemeenschap in het algemeen, veroorzaakt ernstige problemen voor een groot deel van de C / C ++ -gemeenschap en kan – met grote moeite – worden geëlimineerd.

Zie voor een veel gedetailleerdere presentatie van mijn opvattingen over C / C ++ compatibiliteit de reeks artikelen die ik hierover heb geschreven:

Ik stel me voor dat als onverenigbaarheden werden geëlimineerd (door wijzigingen aan te brengen in zowel C als C ++), er nog steeds entiteiten zouden zijn met de naam C en C ++, maar dan zou C echt worden gedefinieerd als een subset van C ++ .

Houd er rekening mee dat deze papers eind 2001 en begin 2002 zijn geschreven toen het nog steeds mogelijk was om gecoördineerde acties van de C en C ++ standaardcommissies voor te stellen die tot praktische resultaten leidden tegen het einde van het decennium. Dit gebeurde niet.


Waarom heb je C ++ (bijna) compatibel gemaakt met C?

Ik wilde dat C ++ compatibel zou zijn met een volledige taal met voldoende prestaties en flexibiliteit voor zelfs de meest veeleisende systeemprogrammering. Ik had een perfecte ontzetting van het produceren van nog een andere mooie taal met onbedoelde beperkingen. Zie Paragraaf 2.7 van Het ontwerp en de evolutie van C ++ voor historische details en lees de artikelen in Denkt u echt …? voor een (retrospectieve) technische bespreking van compatibiliteitsproblemen met C / C ++.

Ik beschouwde C destijds als de beste beschikbare programmeertaal. Dat was niet zo vanzelfsprekend toen (1979) het later werd, maar ik had experts zoals Dennis Ritchie , Steve Johnson, Sandy Fraser , Greg Chesson,Doug McIlroy en Brian Kernighan in de gang van wie ik kon leren en feedback krijgen. Zonder hun hulp en advies, en zonder C, zou C ++ doodgeboren zijn.

In tegenstelling tot herhaalde geruchten, werd mij nooit verteld dat ik C moest gebruiken; ook werd nooit gezegd dat ik C niet moest gebruiken. In feite groeide het eerste C ++ -handboek uit de bron van de C-handleiding die Dennis mij gaf. Veel nieuwe talen zijn ontworpen in Bell Labs; in ‘onderzoek’ waren er tenminste geen regels die de dweperij van de taal afdwongen.


Wat denk je van C / C ++?

Nee, dat is niet echt een vraag die ik vaak krijg. In die zin is het de enige “nep-veelgestelde vraag” in deze FAQ. Het zou echter een veelgestelde vraag moeten zijn omdat mensen “C / C ++” gebruiken alsof het iets specifieks betekent en alsof ze wisten wat het betekende, wat leidde tot veel verwarring en ellende. Mensen zouden moeten vragen “Wat is C / C ++?” en stop dan bij het nadenken met het gebruik van de term. Het schaadt.

Er is geen taal die “C / C ++” wordt genoemd. De zin wordt meestal gebruikt door mensen die geen idee hebben van programmeren (bijvoorbeeld HR-personeel en slechte managers). Als alternatief wordt het gebruikt door mensen die C ++ niet kennen (en vaak ook C niet). Wanneer het door programmeurs wordt gebruikt, geeft het meestal aan dat een “C ++ is C met een paar nuttige en een heleboel nutteloze gecompliceerde functies toegevoegde” attitude. Vaak is dat het gezichtspunt van mensen die graag hun eigen tekenreeksen en hashtabellen schrijven met weinig kennis van de standaardbibliotheek voorbij printf en memcpy. Er zijn mensen die zich om volkomen goede redenen aan een beperkte subset van C ++ houden, maar ze zijn (voor zover ik heb opgemerkt) niet de mensen die ‘C / C ++’ zeggen.

Ik gebruik C / C ++ alleen in uitdrukkingen als “C / C ++ -compatibiliteit” en “C / C ++ -community”.


Wanneer werd C ++ uitgevonden?

Ik begon te werken aan wat C ++ werd in 1979. De eerste versie heette “C with Classes”. De eerste versie van C ++ werd intern gebruikt in AT & T in augustus 1983. De naam “C ++” werd eind dat jaar gebruikt. De eerste commerciële implementatie werd in oktober 1985 gelijktijdig met de publicatie van de 1e editie van The C ++ Programming Language uitgebracht . Sjablonen en afhandeling van uitzonderingen zijn later in de jaren tachtig opgenomen en gedocumenteerd in The Annotated C ++ Reference Manual en The C ++ Programming Language (2rd Edition) . De eerste ISO C ++ -standaard was C ++ 98 zoals beschreven in The C ++ Programming Language (3e editie) .

De huidige definitie van C ++ De ISO C ++ standaard uit 2011 beschreven in The C ++ Programming Language (4e editie) .

Je vindt een meer complete tijdlijn en meer gedetailleerde uitleg in The Design and Evolution van C ++ en A History of C ++: 1979-1991 en Evolving a language in and for the real world: C ++ 19 .


Waarom heb je C ++ uitgevonden?

Ik wilde efficiënte systeemprogramma’s schrijven in de stijlen die door Simula67 worden aangemoedigd. Om dat te doen, voegde ik faciliteiten toe voor betere typecontrole, gegevensabstractie en objectgeoriënteerd programmeren naar C. Het meer algemene doel was om een ​​taal te ontwerpen waarin ik programma’s kon schrijven die zowel efficiënt als elegant waren. Vele talen dwingen je om te kiezen tussen deze twee alternatieven.

De specifieke taken die me ertoe hebben aangezet om te beginnen met het ontwerpen en implementeren van C ++ (aanvankelijk “C met klassen” genoemd) hadden te maken met het distribueren van faciliteiten van het besturingssysteem over een netwerk.

U kunt meer gedetailleerde uitleg vinden in Het ontwerp en de evolutie van C ++ . Zie ook A History of C ++: 1979-1991 en Evolving van een taal in en voor de echte wereld: C ++ 1991-2006 .


Waarom ondersteunde AT & T de ontwikkeling van C ++?

Toen ik voor het eerst C ++ ontwikkelde, bouwde AT & T systemen van grotere complexiteit en met hogere betrouwbaarheidseisen dan de meeste organisaties. Daarom moesten we de markt beïnvloeden en normen opstellen die aan onze behoeften voldeden – anders hadden we niet de tools om onze systemen te bouwen. Overgelaten aan zichzelf “de industrie” zal talen en hulpmiddelen creëren voor het omgaan met “gemiddelde” problemen. Op dezelfde manier hebben leraren de neiging zich te concentreren op talen en hulpmiddelen die studenten en onderzoekers goed van pas komen – zelfs als ze niet schalen naar de meest veeleisende taken.

Op het moment dat ik C ++ ontwikkelde – en daarvoor, toen Ken Thompson en Dennis Ritchie Unix en C ontwikkelden – was AT & T waarschijnlijk ‘s werelds grootste civiele gebruiker van (en consumenten van) softwaretools. Vervolgens hebben we waarschijnlijk een breder scala aan systemen gebruikt – van de kleinste ingesloten processors tot de grootste supercomputers en gegevensverwerkingssystemen. Dat betekende een premie op systemen die van toepassing waren in veel technische culturen en op veel platforms. C en C ++ zijn ontworpen met dergelijke eisen in gedachten.

Generaliteit is dus essentieel en eigendomskenmerken worden gezien als een beperking van de keuze van platforms en leveranciers. Als gevolg hiervan was en is AT & T een belangrijke voorstander van formele normen (bijvoorbeeld ISO C en ISO C ++).

AT & T heeft eigenlijk genoeg geld verdiend aan Cfront, mijn oorspronkelijke C ++ – compiler, om de ontwikkeling van C ++ meermaals te betalen.


Bezit je C ++?

Nee. Als iemand ‘eigenaar is van C ++’, moet dit de ISO zijn. AT & T gaf de rechten op de C ++ -handleiding die ik aan de ISO schreef. De ISO C ++ -standaard is auteursrechtelijk beschermd door ISO.

Compilerververkopers betalen geen royalty’s aan mij of aan AT & T voor C ++, en ISO-normen zijn specificaties die bedoeld zijn voor royalty-vrij gebruik door iedereen (nadat ze de ISO of een nationaal normcomité hebben betaald voor hun exemplaar van de norm). De afzonderlijke compilers zijn eigendom van hun respectieve leveranciers / leveranciers.

“Maar iemand van SCO beweerde dat ze eigenaar waren van C ++”; is dat niet waar? Het is complete onzin. Ik zag dat interview. De SCO-gozer had duidelijk geen idee wat C ++ was, en noemde het “de C ++ -talen”. Hoogstens kan SCO een 15-jarige en serieus verouderde versie van Cfront bezitten – mijn oorspronkelijke C ++ -compiler. Ik heb ervoor gezorgd dat ik geen patent of handelsmerk heb voor iets dat met C ++ te maken heeft. Dat is een reden waarom we gewoon “C ++” en niet “C ++ ™” schrijven. De C ++ -standaard is niet belast met octrooien – de commissie heeft dat ook zorgvuldig gecontroleerd.


Waar komt de naam “C ++” vandaan?

Hoofdstuk 3 van D & E : “ Ik koos voor C ++ omdat het kort was, mooie interpretaties had, en niet van de vorm was “bijvoeglijk naamwoord C.”. In C kan ++, afhankelijk van de context, worden gelezen als “volgende” “opvolger” of “increment”, hoewel het altijd wordt uitgesproken als “plus plus.” De naam C ++ en zijn tweede plaats ++ C zijn vruchtbare bronnen voor moppen en woordspelingen – bijna allemaal bekend en gewaardeerd voordat de naam werd gekozen. De naam C ++ is gesuggereerd door Rick Mascitti. Het werd voor het eerst gebruikt in december 1983 toen het werd bewerkt tot de definitieve exemplaren van [[Stroustrup, 1984]] en [[Stroustrup, 1984c]].

Hoofdstuk 1 van TC ++ PL : “ De naam C ++ (uitgesproken als “zie plus plus”) werd bedacht door Rick Mascitti in de zomer van 1983. De naam betekent de evolutionaire aard van de veranderingen van C; “++” is de C-verhogingsoperator. De iets kortere naam “C +” is een syntaxisfout; het is ook gebruikt als de naam van een niet-gerelateerde taal. Kenners van C-semantiek vinden C ++ minder dan ++ C. De taal wordt niet D genoemd, omdat het een extensie van C is en het probeert geen problemen op te lossen door functies te verwijderen. Zie voor nog een andere interpretatie van de naam C ++ de appendix van [[Orwell, 1949]]. ”

De “ C ” in C ++ heeft een lange geschiedenis. Natuurlijk is het de naam van de taal die Dennis Ritchie ontwierp. De directe voorloper van C was een geïnterpreteerde afstammeling van BCPL genaamd B, ontworpen door Ken Thompson. BCPL is ontworpen en geïmplementeerd door Martin Richards van Cambridge University tijdens een bezoek aan MIT in het andere Cambridge. BCPL was op zijn beurt Basic CPL, waarbij CPL de naam is van een vrij grote (voor zijn tijd) en elegante programmeertaal die gezamenlijk is ontwikkeld door de universiteiten van Cambridge en Londen. Voordat de Londenmers bij het project kwamen, stond “C” voor Cambridge. Later stond “C” officieel voor Gecombineerd. Officieus stond “C” voor Christopher omdat Christopher Strachey de belangrijkste kracht achter CPL was. ”


Welke taal heb je gebruikt om C ++ te schrijven?

De eerste C ++ -compiler (Cfront) is geschreven in C ++. Om dat te bouwen, heb ik eerst C gebruikt om een ​​“ C met klassen”-naar-C preprocessor te schrijven. “ C met klassen ” was een C-dialect dat de directe voorouder van C ++ werd. Die preprocessor vertaalde “C met klassen” -constructies (zoals klassen en constructors) naar C. Het was een traditionele preprocessor die de taal niet helemaal begreep, de meeste typecontrole liet voor de C-compiler om te doen en de individuele vertaalde bouwt zonder volledige kennis. Ik schreef toen de eerste versie van Cfront in “C with Classes”.

Cfront was een traditionele compiler die de syntaxis en semantische controle van de C ++ -bron volledig had voltooid. Daarvoor had het een complete parser, bouwde symbooltabellen en bouwde het een volledige interne boomstructuur van elke klasse, functie, etc. Het deed ook enige optimalisatie van het bronniveau op de interne boomstructuur van C ++ -constructies voordat C werd uitgevoerd. De versie die gegenereerde C, heeft niet op C vertrouwen voor het controleren van het type. Het gebruikte eenvoudig C als assembler. De resulterende code was compromisloos snel. Zie D & E voor meer informatie .


Heb je echt niet begrepen wat je aan het doen was?

Deze lijkt erg populair. Of liever gezegd, het lijkt populair om te beweren dat ik geen idee had, zodat het succes van C ++ een soort ongeluk is. Ja, dergelijke uitspraken irriteren me, omdat ze mijn werk decennialang afdanken en het harde werk van veel van mijn vrienden.

Laten we eerst volkomen duidelijk zijn: nee, ik anticipeerde niet op het wegloop-succes van C ++ en nee, ik zag niet elke techniek die met C ++ of elke toepassing van C ++ werd gebruikt. Natuurlijk niet!

Verklaringen zoals deze zijn echter erg misleidend:

  • Bjarne begrijpt C ++ niet!
  • Bjarne anticipeerde RAII en deterministische vernietiging niet!
  • Bjarne anticipeerde niet op template-metaprogramming!

Deze veelgestelde vraag is ontstaan ​​door het zien van deze en nog een aantal van hun kennis vandaag.

Ik heb de criteria voor het ontwerp en de implementatie van C ++ beschreven. Ik streefde expliciet naar algemeenheid: “Ik ben niet geïnteresseerd in een taal die alleen kan doen wat ik kan bedenken” en voor efficiëntie “een faciliteit moet niet alleen nuttig zijn, maar ook betaalbaar.” Ik stel voor dat twijfelaars het ontwerp en de evolutie van C ++ en mijn HOPL2- en HOPL3- documenten lezen (dit zijn collegiaal getoetste artikelen). Wat betreft deterministische vernietiging, was het in “C with Classes” in de eerste week of twee (1979). Ik heb de introductie van uitzonderingen een half jaar lang in C ++ gehouden totdat ik RAII (1988) ontdekte. RAII is een integraal en noodzakelijk onderdeel van het C ++ uitzonderingsmehanisme.

Ik was zeer verrast toen Jeremy Siek voor het eerst mijn compileertijd liet zien als dat later std: voorwaardelijk werd, maar ik had naar generieke (en kreeg Turing volledigheid modulo vertaling limieten). Ik verzette me onmiddellijk tegen beperkingen voor C ++ toen Erwin Unruh presenteerde wat naar men aanneemt het eerste sjabloonmetaprogramma is voor de evolutiewerkgroep van het ISO-normcomité. Om sjabloon-metaprogrammering te doden, hoefde ik alleen nog maar niets te zeggen. In plaats daarvan was mijn commentaar in de trant van: “Wauw, dat is netjes, we mogen het niet schaden, het kan nuttig zijn.” Net als bij alle krachtige ideeën kan sjabloon-metaprogrammering worden misbruikt en te veel worden gebruikt, maar dat betekent niet dat het fundamentele idee van berekening van de compileertijd slecht is. En net als bij alle krachtige ideeën kwamen de implicaties en technieken in de loop van de tijd naar voren met bijdragen van veel mensen.

Scolarship biedt meer dan een blik op de wikipedia, een snelle Google-zoekopdracht en een aantal blogposts. Er is meer aan de uitvinding dan het geven van een eenvoudige lijst met implicaties. Fundamentele principes en ontwerprichtlijnen zijn essentieel. Mijn deel van het C ++ ontwerp opende de mogelijkheid voor velen om bij te dragen, en als je naar mijn geschriften en posting kijkt, zie je dat ik heel hard mijn best doe om credits te geven (zie bijvoorbeeld de referentiesecties van mijn veelgestelde vragen over C ++ 11 ) of de geschiedenissecties van mijn boeken .

En nee, ik ben geen wandelend C ++ -woordenboek. Ik bewaar niet altijd alle technische details in mijn hoofd. Als ik dat zou doen, zou ik een veel slechtere programmeur zijn. Ik houd de hoofdpunten meestal recht in mijn hoofd, en ik weet waar ik de details kan vinden wanneer ik ze nodig heb. Bijvoorbeeld:


Waarom heeft C ++ geen garbagecollection?

Als je automatische garbage collection wilt, zijn er goede commerciële en publieke domein garbage verzamelaars voor C ++. Voor toepassingen waar garbage collection geschikt is, is C ++ een uitstekende garbagecollectie met een prestatie die gunstig afsteken bij andere talen die met vuilnis worden verzameld. Zie De C ++ programmeertaal voor een bespreking van automatische garbage collection in C ++. Zie ook, Hans-J. Boehm’s site voor C en C ++ garbage collection .

C ++ ondersteunt ook programmeertechnieken waarmee geheugenbeheer veilig en impliciet kan zijn zonder een garbage collector . Ik beschouw afvalophaling als een laatste keuze en een gebrekkige manier van omgaan met resourcebeheer. Dat betekent niet dat het nooit nuttig is, alleen als er in veel situaties betere benaderingen zijn.

C ++ 11 biedt een GC ABI.

Ik hou niet van afval. Ik hou niet van zwerfvuil. Mijn ideaal is om de noodzaak van een vuilnisbelt weg te nemen door geen afval te produceren. Dat is nu mogelijk. Tools ter ondersteuning en handhaving van de programmeertechnieken die worden bereikt die worden geproduceerd. Voor een overzicht, zie Een korte inleiding tot het C ++ -model voor type- en resource-veiligheid. .


Waarom heeft C ++ geen GUI?

C ++ heeft veel commerciële en open source GUI’s (bijv. Gtkmm , SmartWin ++ , V C ++ GUI , FLTK en Qt ). In het bijzonder biedt elke platformverkoper een C ++ -bibliotheek voor toegang tot zijn GUI. Het probleem is dat het geen standaard GUI heeft en dat is inderdaad een groot probleem.

Merk op dat het verschaffen van een GUI zowel een technisch als een politiek probleem is. Er zijn veel GUI’s met veel gebruikers, en over het algemeen zouden ze niet graag zien dat een andere GUI standaard wordt verklaard. Hoe dan ook, het normcomité heeft niet de middelen om een ​​nieuwe en betere GUI te bouwen.


Waarom ondersteunt C ++ geen threads?

C ++ 11 biedt threads.


Wordt C ++ geweigerd?

Nee, ik denk het niet. C ++ -gebruik lijkt in sommige gebieden af ​​te nemen en in andere op te lopen. Als ik moest raden, zou ik ergens in de periode 2002-2004 een netto daling verwachten en een netto toename in 2005-2007 en opnieuw in 2010-2011, maar ik betwijfel of iemand het echt weet. De meeste populaire maatregelen meten in principe lawaai en zouden hun bevindingen in decibel moeten rapporteren in plaats van ‘populariteit’. Een professionele enquête in 2015 schatte het aantal C ++ -programmeurs om 4,4 miljoen te zijn. Veel van de belangrijkste toepassingen van C ++ zijn in infrastructuur (telecommunicatie, bankieren, embedded systemen, enz.) Waar programmeurs niet naar conferenties gaan of hun code in het openbaar beschrijven. Veel van de meest interessante en belangrijke C ++ -toepassingen worden niet opgemerkt, ze zijn niet te koop aan het publiek als programmeerproducten en hun implementatietaal wordt nooit genoemd. Voorbeelden zijn Google- en ‘800’-telefoonnummers. Had ik in 1985 aan een “C ++ inside” -logo gedacht, dan was de programmeerwereld vandaag misschien anders geweest.

Een eenvoudig ding dat vele discussies over taalgebruik / populariteit verwart, is het onderscheid tussen relatieve en absolute maatregelen. Ik zeg bijvoorbeeld (in 2011) dat het gebruik van C ++ toeneemt als ik de gebruikerspopulatie zie groeien met 200.000 programmeurs van 3,1 miljoen naar 3,3 miljoen. Iemand anders kan echter beweren dat “C ++ doodgaat” omdat het “populariteit” is gedaald van 16 procent naar 11 procent van het totale aantal programmeurs. Beide claims zouden tegelijkertijd waar kunnen zijn naarmate het aantal programmeurs blijft groeien en vooral omdat wat wordt beschouwd als programmeren, blijft veranderen. Ik denk dat C ++ meer is dan zich staande te houden in zijn traditionele kerndomeinen, zoals infrastructuur, systeemprogrammering, ingebedde systemen en toepassingen met serieuze beperkingen qua tijd en / of ruimte en / of stroomverbruik. Zie ookmijn DevX-interview .


Wat wordt er gedaan om C ++ te verbeteren?

Uitvoerders verbeteren voortdurend hun compilers , bibliotheken en hulpmiddelen. In de afgelopen vijf jaar zijn de kwaliteit aanzienlijk verbeterd. Dit is wat het meest direct en het meest direct mensen helpt; dat, en de host van eigen en open source bibliotheken en tools die continu worden geproduceerd door de C ++ community. Zie mijn C ++ -pagina voor voorbeelden.

De eerste ISO C ++ -norm werd in 1998 geratificeerd. De volgende versie C ++ 11 is compleet en wordt verzonden. U kunt artikelen over C ++ 11 op mijn publicatiespagina en alle documenten met betrekking tot de nieuwe norm op de homepages van de ISO C ++-commissie vinden . Mijn HOPL-iii-paper over de laatste 15 jaar C ++ -evolutie is misschien de beste verklaring voor wat er wordt gedaan en waarom. Een recent interview bevat lijsten met nieuwe taalfuncties en standaardbibliotheken.

Bij het beschouwen van de evolutie van C ++, is het de moeite waard eraan te denken dat het niet de bedoeling is om het grootste aantal nieuwe functies toe te voegen, maar om C ++ te verbeteren voor de belangrijkste toepassingsdomeinen, waaronder systeemprogrammering en bibliotheekopbouw, zonder oudere code te onderbreken (er zijn miljarden van lijnen van C ++ “daar”).


Waarom is de code die is gegenereerd voor het programma ‘Hallo wereld’ tien keer groter voor C ++ dan voor C?

Het staat niet op mijn computer en het hoort niet van jou te zijn. Ik heb zelfs de C ++ -versie van het “Hello World” -programma kleiner gezien dan de C-versie. In 2004 heb ik getest met behulp van gcc-O2 op een Unix en de twee versies (iostreams en stdio) leverden identieke maten op. Er is geen taalreden waarom de ene versie groter zou moeten zijn dan de andere. Het is allemaal een kwestie van hoe een implementeerder de standaardbibliotheken organiseert (bijvoorbeeld statische koppeling versus dynamische koppeling, locale ondersteuning standaard versus locale ondersteuning ingeschakeld via en optie, etc.). Als de ene versie aanzienlijk groter is dan de andere, rapporteer dan het probleem aan de implementator van de grotere.


Hoe kan een legacy-taal als C ++ concurreren met moderne, geavanceerde talen?

Vanzelfsprekend spreekt C ++ een oude taal aan als vertekening (zie oude code ). Dat terzijde, mensen denken meestal aan Java of C # als ze zo’n vraag stellen. Ik zal C ++ niet vergelijken met die talen , maar ik kan erop wijzen dat “modern” niet noodzakelijk “beter” betekent, en dat zowel Java als C # in een nog grotere mate zijn geworteld in de OOP van de jaren 1980 dan in het begin van C ++.

Sinds 1987 of zo is de focus van de ontwikkeling van de C ++ -taal en de bijbehorende programmeerstijlen het gebruik van sjablonen, statisch polymorfisme, generieke programmering en multiparadigm-programmering geweest. Dit gaat ver buiten het bereik van de veel-hyped gepatenteerde talen. Een ander belangrijk verschil is dat C ++ door de gebruiker gedefinieerde typen in dezelfde mate ondersteunt als ingebouwde typen. Dit – vooral in combinatie met het gebruik van sjablonen, constructors en destructors – maakt het de C ++ -programmeur mogelijk om programmeer- en ontwerptechnieken te gebruiken die (IMO) geavanceerder zijn dan wat wordt ondersteund in de talen waarmee C ++ het vaakst wordt vergeleken; zie bijvoorbeeld RAII .

Standaard C ++ en de ontwerp- en programmeerstijlen die het ondersteunt zijn een schuld aan de functionele talen verschuldigd, vooral aan ML. Vroege varianten van ML’s type deductiemechanismen waren (samen met veel andere) onderdeel van de inspiratie van sjablonen. Enkele van de effectievere functionele programmeertechnieken waren onderdeel van de inspiratie van de STL en het gebruik van functieobjecten in C ++. Aan de andere kant miste de functionele gemeenschap de boot met objectgeoriënteerd programmeren, en enkele talen en gereedschappen uit die gemeenschap profiteerden van de volwassen ervaring van grootschalig industrieel gebruik.

Het is duidelijk dat ik denk dat garbage collection niet het enige bepalende kenmerk is van ‘geavanceerd’ in de context van programmeertalen. Merk in het bijzonder op dat C ++ ondersteuning biedt voor effectieve en efficiënte technieken voor geheugenbeheer die lekken van bronnen kunnen elimineren zonder het gebruik van een afvalverzamelaar. Als u het niet eens bent, kunt u gewoon beginnen met het gebruik van een garbage collector voor C ++; er zijn goede degenen beschikbaar.


Wat is “multiparadigm programming”?

Multiparadigm-programmering is een mooie manier om “ programmeren te zeggen met behulp van meer dan één programmeerstijl, elk op zijn best. ” Bijvoorbeeld door objectgeoriënteerd programmeren te gebruiken wanneer runtime-resolutie tussen verschillende objecttypen vereist is en generieke programmering wanneer statisch type veiligheid en runtime-prestaties zijn van het allergrootste belang. Natuurlijk is de belangrijkste kracht van multiparadigm programmeren in programma’s waarin meer dan één paradigma (programmeerstijl) wordt gebruikt, zodat het moeilijk zou zijn om hetzelfde effect te krijgen door een systeem samen te stellen uit delen die zijn geschreven in talen die verschillende paradigma’s ondersteunen. Ik vind de meest overtuigende cases voor multiparadigm-programmering gevonden waarbij technieken uit verschillende paradigma’s in nauwe samenwerking worden gebruikt om code te schrijven die eleganter en beter te onderhouden is dan mogelijk zou zijn binnen een enkel paradigma. Een eenvoudig voorbeeld is het doorlopen van een statisch getypeerde container van objecten van een polymorf type:

void draw_all (vector <Shape *> & vs) // teken elk element van een standaardvector{for_each (vs.begin (), vs.end (), [[]] (Shape * p) {p-> draw ();});}

Hier zal Shape een abstracte basisklasse zijn die de interface definieert tot een hiërarchie van geometrische vormen. Dit voorbeeld wordt eenvoudig gegeneraliseerd naar elke standaard bibliotheekcontainer:

sjabloon <klasse C>void draw_all (C & cs) // teken elk element van een standaard container{for_each (cs.begin (), cs.end (), [[]] (Shape * p) {p-> draw ();});}

Jim Coplien’s boek “Multiparadigm Design for C ++” (Addison Wesley, 1998) onderzoekt het gebruik van meerdere paradigma’s in de context van ontwerp- en ontwerpmethoden.

We hebben een betere – meer beschrijvende – term nodig om “ multi-paradigma ” te vervangen. ‘


Waarom is C ++ zo GROOT?

C ++ is niet zo groot als sommige mensen zich voorstellen. Het is geen kleine taal die is ontworpen om een ​​minimale taal te zijn voor het lesgeven, maar ook de talen waarmee mensen het meest vergelijken, zoals C, Java en C #. Ook zij zijn enorm vergeleken met zeggen, Pascal zoals Dr. Wirth het oorspronkelijk heeft gedefinieerd – om goede redenen, denk ik. De programmeerwereld is tegenwoordig veel complexer dan dertig jaar geleden, en moderne programmeertalen weerspiegelen dat.

De C ++ -standaard is 1151 pagina’s; dat bevat 430 pagina’s met taaldefinities en 770 pagina’s standaardbibliotheekbeschrijving. De grootte van de taaldefinitie ligt binnen 5% van de taalbeschrijvingen van Java en C # (gemeten op paginatelling). Evenzo is TC ++ PL 1360 pagina’s; van die 750 daarvan zijn gewijd aan taalfaciliteiten en programmeertechnieken; de rest discussieert over bibliotheken, etc.

C ++ ondersteunt direct (dwz in de taal) wat sommige andere talen ondersteunen via bibliotheken, dus het taalgedeelte zal relatief groter zijn. Aan de andere kant, als u een “typisch moderne applicatie” wilt schrijven, moet u de besturingssystemen, GUI, databases, webinterfaces, enz. Beschouwen als de som van taalfuncties, bibliotheken en programmeerconventies en -standaarden die u moet hebben vertrouwd raken met Dwerg de programmeertaal. Hier kan de grootte van C ++ een voordeel zijn voor zover het betere bibliotheken ondersteunt.

Ten slotte zijn de dagen dat een beginnende programmeur al een taal kent, weg, althans voor de talen in wijdverbreid industrieel gebruik. Weinig mensen kennen “alle C” of “alle Java” en geen van deze zijn nieuwelingen. Hieruit volgt dat niemand zich moet verontschuldigen voor het feit dat beginners niet alles van C ++ kennen. Wat je moet doen – in welke taal dan ook – is om een ​​deelverzameling te kiezen, werkcode te schrijven en geleidelijk meer te leren van de taal, zijn bibliotheken en zijn hulpmiddelen. Voor mijn suggestie over hoe beginners C ++ kunnen benaderen, zie Programmeren: principes en praktijk met C ++ .


Wat vind je van EC ++?

EC ++ is een (bijna) subset van C ++ zonder uitzonderingen, sjablonen, naamruimten, RTTI-ondersteuning, meerdere overerving, enz. Die worden gedefinieerd door een “industrieconsortium”. Ik ben geen voorstander van taalsubsets of dialecten. Ik ben vooral niet dol op subsets die de standaardbibliotheek niet kunnen ondersteunen, zodat de gebruikers van die subset hun eigen incompatibele basisbibliotheken moeten uitvinden. Ik vrees dat een gedefinieerde subset van C ++ de gebruikerscommunity zou kunnen splitsen en acrimony zou veroorzaken (31/03/1999: ik zag zojuist een advertentie met levendige grafische afbeeldingen om aan te geven hoe EC ++ “vet” (dwz geheugenruimte) verminderde door – onder andere dingen – naamruimten, sjablonen en C ++ standaardstrings. Zucht!). Ik vind het sterk dat werk op “standaarden” plaatsvindt in een open forum (zoals ISO of een nationale standaardorganisatie).

Voor een bespreking van hoe embedded systems-implementeerders prestatieproblemen kunnen aanpakken met behulp van Standard C ++ (beter dan door dialecten te gebruiken), raadpleegt u het rapport van de ISO C ++ -commissie over prestaties . Voor zover ik weet is EC ++ dood (2004), en zo niet, zou het moeten zijn.

Zie de JSF C ++ -coderingsstandaarden voor luchtvoertuigen voor een blik op hoe ISO C ++ kan worden gebruikt voor serieuze embedded systeemprogrammering .


C ++ kreeg zijn object-georiënteerde concepten van Smalltalk?

Nee. C ++ kreeg de sleutelbegrippen van klassen, afgeleide klassen, virtuele functies (met andere woorden, de begrippen inkapseling, overerving en polymorfisme) van Simula, net zoals Smalltalk deed. In termen van gezinsrelaties zijn C ++ en Smalltalk broers en zussen.


Is C ++ een object-georiënteerde taal?

C ++ is een programmeertaal met meerdere paradigma’s die objectgeoriënteerde en andere nuttige programmeerstijlen ondersteunt. Als wat je zoekt iets is dat je dwingt om dingen op precies dezelfde manier te doen, C ++ is het niet. Er is niemand een goede manier om elk programma te schrijven – en zelfs als er waren, zou er geen mogelijkheid zijn om programmeurs te dwingen het te gebruiken.

Dat gezegd hebbende, het schrijven van C-style programma’s in C ++ is voor de meeste applicaties geen optimaal gebruik van C ++. Om een ​​echt effectieve C ++ -programmeur te zijn, moet je de abstractiemechanismen en het type systeem gebruiken op een manier die redelijk past bij hun intentie. Proberen het C ++ -typestelsel te negeren of te verslaan is een zeer frustrerende ervaring.

Het schrijven van Java-stijl code in C ++ kan net zo frustrerend en suboptimaal zijn als het schrijven van C-stijl code in C ++.

Zie een van mijn overzichts- of stijlartikelen uit mijn bibliografie voor een meer gedetailleerde discussie . Zie met name mijn OOPSLA-document “Waarom C ++ niet zomaar een objectgerichte programmeertaal is”.


Heb je dat echt gezegd?

“C maakt het gemakkelijk om jezelf in de voet te schieten; C ++ maakt het moeilijker, maar als je het doet, schiet je hele been eraf” . Ja, ik zei zoiets (in 1986 of zo). Wat mensen vaak missen, is dat wat ik daar zei over C ++ in verschillende mate geldt voor alle krachtige talen. Omdat je mensen beschermt tegen eenvoudige gevaren, krijgen ze nieuwe en minder voor de hand liggende problemen. Iemand die de simpele problemen vermijdt, kan gewoon op weg zijn naar een niet-zo eenvoudig probleem. Een probleem met zeer ondersteunende en beschermende omgevingen is dat de harde problemen mogelijk te laat worden ontdekt of te moeilijk zijn om te verhelpen zodra ze zijn ontdekt. Ook is een zeldzaam probleem moeilijker te vinden dan een frequent probleem, omdat je het niet vermoedt.

“Binnen C ++ is er een veel kleinere en schonere taal die worstelt om eruit te komen” . Ja, dat citaat is te vinden op pagina 207 van The Design and Evolution of C ++ . En nee, die kleinere en schonere taal is geen Javaof C # . Het citaat komt voor in een gedeelte getiteld “Beyond Files and Syntax”. Ik wees erop dat de C ++ -semantiek veel schoner is dan de syntaxis. Ik dacht aan programmeerstijlen, bibliotheken en programmeeromgevingen waarin de nadruk werd gelegd op schonere en effectievere praktijken over archaïsche toepassingen gericht op de low-level aspecten van C.

“Ik heb altijd gewild dat mijn computer net zo gemakkelijk te gebruiken was als mijn telefoon, mijn wens is uitgekomen omdat ik niet meer weet hoe ik mijn telefoon moet gebruiken” . Ik zei dat na een frustrerende poging om ergens in 1990 een “feature-rijke” telefoon te gebruiken. Ik ben er zeker van dat het sentiment niet origineel was, en waarschijnlijk niet eens de algemene formulering; daar moet iemand voor mij aan hebben gedacht.

“Er zijn slechts twee soorten talen: die waarover mensen klagen en die niemand gebruikt” . Ja. Nogmaals, ik betwijfel ten zeerste of het sentiment origineel is. Natuurlijk moeten alle “er zijn maar twee” citaten worden genomen met een korrel zout.

“Bewijs door analogie is fraude” . Ja; pagina 692 van TC ++ PL. Een goede analogie is een uitstekende manier om een ​​idee te illustreren, maar veel te vaak gaan dergelijke analogieën niet gepaard met solide redenering, gegevens, enz.

“Mensen die denken dat ze alles weten, irriteren echt degenen onder ons die weten dat we dat niet doen” . Ja.

“C ++ Is mijn favoriete garbagecollectie omdat het zo weinig afval genereert” . Ja; zie Waarom heeft C ++ geen garbagecollection? en Hoe ga ik om met geheugenlekken .

“Als je denkt dat het eenvoudig is, dan heb je het probleem verkeerd begrepen” . Ja, maar nee, ik weet niet meer welke vraag dat antwoord heeft opgeroepen.

“Er zijn meer nuttige systemen ontwikkeld in talen die als vreselijk worden beschouwd dan in talen die worden geprezen om mooi te zijn – veel meer” . Ja, in het MIT Technology Review-interview en elders. Daar zei ik ook:

  • “Ik denk dat we moeten zoeken naar elegantie in de ontwikkelde applicaties, in plaats van in de talen zelf” . Ik had moeten zeggen “meer dan” in plaats van “in plaats van”.
  • “Om C ++ goed te kunnen gebruiken, moet je de ontwerp- en programmeertechniek begrijpen” .
  • “C ++ is ontworpen om u ideeën te laten uiten, maar als u geen ideeën hebt of geen idee hebt hoe u ze moet uiten, biedt C ++ niet veel hulp” .

De <random> -bibliotheek is wat een willekeurige bibliotheek wil zijn als deze opgroeit. Daarom gebruiken beginners rand () . Ja. In de openingstoespraak van CppCon 2017: The Learning and Teaching Modern C ++ .

Het feit dat ‘goto’ alles kan, is precies waarom we het niet gebruiken . Ja. In de openingstoespraak van CppCon 2017: The Learning and Teaching Modern C ++ . Ik heb / wijs erop dat ‘goto’ uitstekend is in machinegegenereerde code.

Als de opmerking en code het niet eens zijn, zijn beide waarschijnlijk verkeerd . Ja, ik citeer Norm Schryer, denk ik. In de openingstoespraak van CppCon 2017: The Learning and Teaching Modern C ++ .

Onderwijs voor de toekomst, je moet erin leven . Ja. In de openingstoespraak van CppCon 2017: The Learning and Teaching Modern C ++ .

Wees niet slim . Ja. In de openingstoespraak van CppCon 2017: The Learning and Teaching Modern C ++ . De begeleidende dia zegt: “Wees niet (te) slim”, maar ik kan geen haakjes plaatsen :-). Mijn punt was om overdreven slimme code te ontmoedigen, omdat “slimme code” moeilijk te schrijven is, gemakkelijk om fout te raken, moeilijker te onderhouden en vaak niet sneller dan eenvoudigere alternatieven omdat het moeilijk kan zijn om te optimaliseren.

Veel te vaak is ‘computerwetenschap’ een vorm van wiskunde-afgunst . Ja, maar vergeet alsjeblieft niet dat “veel te vaak”. Het citaat komt uit een context waarin ik me zorgen maak over onvoldoende aandacht voor gegevens (empirie) en onvoldoende aandacht voor de connectie met computers. Het is geen frontale aanval op het idee dat informatica wetenschap kan zijn (zie bijvoorbeeld Knuth over algoritmen en de analyse van algoritmen, dat is wetenschap en het is geen andere wetenschap). En nee, ik ga geen concrete voorbeelden of namen geven.

Veel te vaak is ‘software engineering’ noch engineering, noch software . Ja, maar vergeet alsjeblieft niet dat “veel te vaak”. Het citaat komt uit een context waarin ik me zorgen maak over onvoldoende aandacht voor data (empirie) en onvoldoende aandacht voor de connectie met code. Ik ben bang dat de realiteit van het moeten leveren van nuttige en onderhoudbare code kan worden verdronken in processen, bedrijfsstandaarden en marketingstudies; dat softwareontwikkeling soms wordt beheerst door mensen die geen goede code herkennen als deze opspringt en ze op de neus slaat, en daar trots op zijn. En nee, ik ga geen concrete voorbeelden of namen geven. Goed geoefend is softwareontwikkeling een waardige technische discipline,

Wanneer (niet als) automatische garbage collection onderdeel wordt van C ++, is dit optioneel . Ja in een interview in 2000 met /. .

Het is gemakkelijk om vergeving te winnen omdat je fout bent; gelijk hebben is wat je in de problemen brengt. Ja.

Elk probleem in de informatica kan worden opgelost met een andere laag van indirectie , bekend als de 1e wet van de informatica. Het volledige citaat is. Elk probleem in de informatica kan worden opgelost met een andere laag van indirectheid, behalve natuurlijk voor het probleem van te veel indirecties. Ja, ik zei dat citeren (mijn thesis-adviseur) David J. Wheeler. Voeg het mij alsjeblieft niet toe.

Ik moet nog een programma zien dat beter in C geschreven kan worden dan in C ++. Ja, vaak, inclusief mijn elektronische ontwerpinterview . Ik geloof niet dat zo’n programma kan bestaan. Met “ beter ” bedoel ik kleiner, efficiënter of beter onderhouden. Als er niets anders is, kun je het programma in C-stijl schrijven en profiteren van de sterkere typecontrole van C ++ en betere notationele ondersteuning, maar de meeste programma’s kunnen baat hebben bij de ondersteuning door C ++ voor generieke en objectgeoriënteerde programmering zonder afbreuk te doen aan de grootte of prestaties. Vasthouden aan de C-achtige subset van C ++ is meestal contraproductief.

Test vroeg en vaak. Ja, vaak, inclusief hoofdstuk 22 van Programmeren: principes en praktijk met C ++ .

Ruimte is tijd. Ja, verwijzend naar het feit dat compacte gegevens sneller kunnen worden overgestoken dan verspreide gegevens (een doorkruising van een vector kan bijvoorbeeld aanzienlijk sneller zijn dan het doorlopen van een gekoppelde lijst) en sneller naar invoer en uitvoer.

Het enige dat sneller groeit dan de computerprestaties is de menselijke verwachting , ja, vaak sinds de late jaren tachtig. Het was mijn standaardantwoord op suggesties dat we echt niet meer moesten werken aan het efficiënter maken van software omdat hardware sneller wordt. Uiteraard is de single-core prestatie vandaag niet jarenlang verbeterd.


Heb je echt een interview gegeven aan IEEE?

waarin je bekende dat C ++ opzettelijk is gemaakt als een vreselijke taal voor het schrijven van niet-verdedigbare code om de salarissen van programmeurs te verhogen?

Natuurlijk niet. Lees het echte IEEE-interview .


Wat is “oude code”?

“Legacy code” is een term die vaak afwijkend wordt gebruikt om code te karakteriseren die is geschreven in een taal of stijl die (1) de spreker / schrijver als verouderd beschouwt en / of (2) concurreert met iets verkocht / gepromoot door de spreker / schrijver. “Legacy-code” verschilt vaak van het voorgestelde alternatief door daadwerkelijk te werken en te schalen.


Verdubbelt het aantal C ++ -gebruikers nog steeds elk jaar?

Nee. In de periode 1980-1991 verdubbelde het aantal gebruikers elke zeven en een halve maand (zie Het ontwerp en de evolutie van C ++ ). Er zijn echter simpelweg niet genoeg programmeurs om dat vol te houden. Van de weinige nummers die ik kan krijgen (compilerverkoop, boekverkoop, werklast van consultants die ik toevallig ken, IDC, enz.), Schat ik dat de groei een paar procent is. Stabiel en zeker positief . IDC schatte dat in 1996 1,2 miljoen C ++ -implementaties werden verkocht. Hun schatting van het aantal C ++ -programmeurs in 2001 bedroeg “ongeveer 3 miljoen”; hun nummer uit 2004 was “meer dan 3 miljoen”. Een professionele enquête van 2015 vond 4,4 miljoen C ++ -programmeurs. Dat lijkt plausibel en duidt op een aanhoudende groei.


Gebruikt iemand tegenwoordig C ++?

Ja, veel doen. Er zijn te veel C ++ -gebruikers om ze effectief te tellen, maar het aantal is in de miljoenen. C ++ wordt ondersteund door alle grote leveranciers . Zie mijn application sampler voor voorbeelden van C ++ gebruik .


Waarom wordt C ++ niet gebruikt voor besturingssystemen?

Het is, en het is al meer dan een decennium; zie mijn lijst met C ++ -toepassingen . Een recent voorbeeld is Cloudius .


Had je verwacht dat C ++ zo’n succes zou worden?

Natuurlijk niet. Het slagingspercentage voor algemene programmeertalen is vanishingly klein. Ik wist dat en ik wist dat de kans op succes werd beïnvloed door de invloed van marketing, die ik niet had.

C ++ is in eerste instantie ontworpen en geïmplementeerd als een reeks algemene faciliteiten die een aantal specifieke problemen aanpakken waarmee ik en mijn collega’s werden geconfronteerd. De algemeenheid – en efficiëntie – van de aangeboden faciliteiten bleken veel bredere behoeften te dienen dan ik had verwacht. De nadruk op algemene voorzieningen – in tegenstelling tot het aanbieden van specifieke oplossingen voor specifieke problemen – is bij C ++ gebleven en heeft de gemeenschap goed gediend, aangezien de specifieke problemen waarmee de gemeenschap wordt geconfronteerd in de loop der jaren zijn veranderd.


Wat is een goede certificering voor C ++ -programmeurs?

Voor zover ik weet, is er geen goed certificeringsprogramma voor C ++ -programmeurs. Dat is jammer. Een goed certificeringsprogramma zou het nuttigst zijn. C ++ mist echter de centrale organisatie die een solide certificeringsprogramma zou produceren, en een certificeringsprogramma zonder autoriteit of gericht op syntaxis zou slechter zijn dan nutteloos.


Waarom ben je bij Morgan Stanley gaan werken?

Ik vond dat het tijd was om terug te gaan naar de industrie. Ik miste de uitdagingen van real-world, grootschalige projecten met echte gevolgen in het geval van succes en mislukking. Academia begon een beetje kushy en “ Ivory tower ” voor mij te voelen (dat is niet de manier waarop academia is voor jongere faculteit en adjunct faculteit – die hebben en verdienen veel meer steun dan ze krijgen). De technologie-afdeling van Morgan Stanley heeft een enorm scala aan informatica-uitdagingen, en een heleboel slim, goed opgeleid en verrassend (gezien de popuar reputatie van mensen die werken voor “ Wall Street”) aardige mensen. Morgan Stanley heeft veel serieus C ++ -gebruik. Daarnaast zorg ik voor C ++ standaardisatie (C ++ 17 is onderweg) en doe ik wat onderzoek in mijn hoedanigheid van professor aan Columbia University en Texas A & M University . Het was tijd om terug te gaan naar het noordoosten en naar mijn familie daar.

PS. Ik werk voor Morgan Stanley, niet voor JP Morgan. Morgan Stanley is een vrij zwaar gereguleerde bank in plaats van een generieke “ financiële instelling ” en IMO een van de meest ethisch beheerde financiële instellingen.

PPS. Je kunt eenvoudigweg geen moderne samenleving runnen zonder banken.


Waarom ben je gaan werken bij Texas A & M University?

De stoom was op van Bell Labs en zijn opvolgers, AT & T Labs en Lucent Bell Labs. Het was gewoon niet meer wat het was. Ik had (en heb) vrienden bij TAMU en vond het een goede plek om de verschillende vaardigheden van het academische leven te leren. Om te beginnen verschilt academisch onderzoek nogal van industrieel onderzoek dat ik gewend was. Smakelijk, het lesgeven aan eerstejaars en afgestudeerden is heel anders dan onderwijsprofessionals. Ik heb ook geholpen bij het opbouwen van de afdeling Computer Science and Engineering . Ik ben nog steeds verbonden aan TAMU als een universiteitskenmerk hoogleraar.

PS. Texas A & M University! = University of Texas.


Waarom ben je bij Bell Labs gaan werken?

Omdat ik het kon. In de jaren tachtig (en jaren daarvoor en daarna) was er geen plaats op aarde zoals deze. Er is nog steeds niet. Bell Labs was het belangrijkste toegepaste wetenschappelijke en technische onderzoekscentrum ter wereld. Het was een zeer opwindende en uitdagende plek om te werken, met buitengewone collega’s. Ik maakte deel uit van het Computer Science Research Center . Ik verliet AT & T Labs (een van de twee opvolgers van AT & T Bell Labs) op goede voorwaarden en werd nog een decennium lang geassocieerd met AT & T als AT & T Fellow.


Waar werk je nu aan?

Een betere FAQ 🙂

Serieus, ik ben op zoek naar fundamentele manieren om de tools en technieken te verbeteren die we gebruiken om grote real-world systemen te bouwen. Een deel van mijn werk is C ++ 11 .


Wat is C ++?

C ++ is een algemene programmeertaal met een voorkeur voor systeemprogrammering

Het wordt gedefinieerd door een ISO-standaard , biedt stabiliteit over decennia en heeft een grote en levendige gebruikersgemeenschap. Zie ook De C ++ programmeertaal en Evolueren van een taal in en voor de echte wereld: C ++ 1991-2006 .


Waar kan ik de achtergrond van C ++ leren kennen?

Over het ontwerp van C ++? Over de geschiedenis van C ++?

Kijk naar mijn papieren voor HOPL-2 en HOPL-3 ; HOPL staat voor ‘History Of Programming Languages’, de belangrijkste conferentie over dat onderwerp, gesponsord door de ACM. Dit zijn zwaar collegiaal getoetste artikelen. Zie voor meer informatie mijn boek Het ontwerp en de evolutie van C ++ en het voorwoord bij de Japanse vertaling van D & E 2006, die de informatie tot 2006 brengt. Ook hebben veel van mijn interviewsbetrekking op de achtergrond, het ontwerp en de geschiedenis van C ++ .


Is het waar dat …?

Veel vragen komen naar me toe in de vorm van beweringen

  • C ++ is low-level (?)
  • C ++ is te traag voor laag werk (?)
  • C ++ is alleen nuttig als je echt objectgeoriënteerde code schrijft (?)
  • Modern C ++ is alle generieke programmering en sjabloonmetaprogrammering (?)
  • C ++ is ontworpen door Microsoft (?)

Vaak beschouwt de persoon die een van deze punten opvraagt ​​de verklaring als een feit (maar geen van deze beweringen is waar); soms is er een impliciet vraagteken. Zo,

  • C ++ is laag niveau? Nee. C ++ biedt zowel functies op laag niveau als op hoog niveau. C ++ heeft delen op laag niveau, zoals pointers, arrays en casts. Deze faciliteiten zijn ( bijna identiek aan wat C biedt) zijn essentieel (in een of andere vorm) voor nauwgezet hardware werk. Dus, als u laagwaardige taalfaciliteiten wilt, biedt ja C ++ een beproefde reeks faciliteiten voor u. Als u echter geen functies op laag niveau wilt gebruiken, hoeft u de C ++ -faciliteiten niet te gebruiken (rechtstreeks). In plaats daarvan kunt u vertrouwen op hogere voorzieningen, waaronder bibliotheken. Als u bijvoorbeeld geen arrays en aanwijzers wilt gebruiken, zijn standaardbibliotheekreeksen en -containers in veel gevallen een (beter) alternatief. Als u alleen faciliteiten van een laag niveau gebruikt, verspilt u vrijwel zeker tijd en maakt u onderhoud moeilijk zonder prestatievoordelen (zie Learning Standard C ++ als een nieuwe taal ). Je kunt ook je systemen blootstellen aan aanvallen (bijv. Buffer overflows).
  • C ++ te traag voor laag werk? Nee. Als u het zich kunt veroorloven om C te gebruiken, kunt u het zich veroorloven om C ++ te gebruiken, zelfs de hogere voorzieningen van C ++ waar u hun functionaliteit nodig hebt. Zie Abstractie en het C ++ machinemodel en het Technical Report on Performance van de ISO C ++ normcommissie .
  • C ++ is alleen nuttig als je echt objectgeoriënteerde code schrijft? Nee. Dat is “nee” voor zowat elke redelijke definitie van “objectgericht”. C ++ biedt ondersteuning voor een breed scala aan behoeften, niet alleen voor één stijl of voor één soort toepassing. In feite biedt C ++, in vergelijking met C, meer ondersteuning voor zeer eenvoudige programmeeropdrachten. De standaardbibliotheek en andere bibliotheken vereenvoudigen bijvoorbeeld radicaal veel anders saaie en foutgevoelige taken. C ++ wordt veel gebruikt voor grote toepassingen, maar biedt ook voordelen voor zelfs maar kleine programmeertaken.
  • Modern C ++ is alle generieke programmering en sjabloonmetaprogrammering? Nee. C ++ ondersteunt verschillende nuttige programmeertechnieken , waaronder traditionele procedurele programmering, objectgeoriënteerd programmeren en generieke programmering. Geen van deze is beter dan alle andere voor alle toepassingen en de meest effectieve oplossing voor een reëel probleem is meestal een combinatie van technieken.
  • C ++ is ontworpen door Microsoft? Nee. Oorspronkelijk heb ik C ++ ontworpen en geïmplementeerd en samen met de ISO C ++ -standaarden heeft de commissie haar definitie verfijnd . Microsoft heeft een actieve en grotendeels positieve rol gespeeld in deze standaardisatie – net als Apple, GNU, IBM, Sun en vele anderen. Net als andere – bijvoorbeeld Apple – probeert Microsoft hun gebruikers te helpen / vergrendelen met eigen extensies (in het bijzonder Microsoft C ++ / CLI ).

Wat denk je van Boost?

Boost is een grote en groeiende verzameling bibliotheken die is ontworpen om goed te werken met de ISO C ++ standaardbibliotheek. Het bevat veel uiterst nuttige en goed ontworpen bibliotheken, zoals asio, bestandssysteem, regex en thread (excuses voor het niet proberen om meer bruikbare bibliotheken te identificeren, er zijn er gewoon te veel). Eén bibliotheek, TR1, bevat een goede benadering van nieuwe standaard C ++ 11-bibliotheekcomponenten.

De Boost-bibliotheken hebben testsuites, documentatie, zijn getest op meerdere systemen en zijn peer-reviewed.

Ik heb echter twee problemen met Boost, waarvan ik hoop dat het uiteindelijk zal worden afgehandeld:

  • Het is te moeilijk om slechts één Boost-bibliotheek te downloaden en te gebruiken; de bibliotheken lijken overdreven gekoppeld, waardoor het moeilijk is om te kiezen en te kiezen.
  • Sommige bibliotheken zijn te slim voor mijn smaak. Soms vallen algemeenheid en eenvoud samen; in Boost is het evenwicht IMO te vaak zo ver weg dat generieken en gemiddelde gebruikers verloren gaan.

Dat gezegd hebbende, is het meestal een heel dom idee om een ​​wiel opnieuw uit te vinden dat al een boost biedt.


Wat denk je van template metaprogramming?

Sjabloon-metaprogrammering is een reeks krachtige programmeertechnieken, die bij gebruik met zorg en smaak kunnen helpen bij het oplossen van vrij lastige problemen, meestal met betrekking tot de architectuur van grotere systemen, de draagbaarheid en het onderhoud ervan (zie Abrahams en Gurtovoy: C ++ Template Metaprogramming en sommige van de Boost-bibliotheken .

Zoals alle krachtige technieken zijn ze gemakkelijk te veel gebruikt. Persoonlijk gebruik ik sjablonen voornamelijk voor generieke programmering (bijvoorbeeld het definiëren van containers en algoritmen boven containers) en voor sjablonen die redelijk voor de hand liggende code genereren op basis van sjabloonargumenten (bijvoorbeeld het genereren van buffers en het registreren van toegangscode); dat wordt soms generatief programmeren genoemd. Wees voorzichtig met de complexiteit van de sjablonen die u schrijft of gebruikt; het is gemakkelijk om overenthousiast te worden en code te schrijven die te slim is om bruikbaar te zijn als onderhoudbare productiecode.

Als u niet van functionele programmeerstijlen houdt, vindt u template-metaprogramma’s misschien moeilijk te begrijpen. Als je functionele programmering leuk vindt, vind je de sjabloonversie misschien een beetje primitief, maar onthoud dat deze sjablonen tijdens het compileren worden uitgevoerd.

De ondersteuning van C ++ voor metaprogrammering verbetert. Concepten zullen generieke programmering drastisch vereenvoudigen en een groot deel van de steigers voor het metaprogrammeren van sjablonen overbodig maken. Verder, als wat u wilt genereren een waarde (zeg en integer waarde) is, zijn constexpr-functies veel gemakkelijker te gebruiken (en sneller te compileren).

WordPress Theme built by Shufflehound. Orange Idea 2018 - Links - Alle rechten voorbehouden.