Loading
Original article: http://www.stroustrup.com/bs_faq.html

Veelgestelde vragen over Bjarne Stroustrup

 

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 C ++ -stijl en -techniek . Zie C ++ -woordenlijst voor C ++ -terminologie en -concepten. Zie mijn C ++ -pagina en mijn veelgestelde vragen over C ++ 11 voor koppelingen naar nuttige bronnen van C ++ -informatie. Zie mijn boekenlijst voor informatie over mijn boeken (inclusief recensies en ondersteuningsinformatie). Zie mijn publicatielijst voor 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 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, sommige worden uitgesteld totdat ik in de buurt ben om een ​​reeks gerelateerde berichten te beantwoorden (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 deze 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 was nooit een grote fan van pseudoniemen, 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 voor mij om 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 manier van veranderen snel. Ook downloaden en weergeven zeer eenvoudige html-downloads sneller 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 post naar nieuwsgroepen van mijn gmail-account, waar mijn gebruikersnaam "Bjarne" is; op de een of andere manier lijkt dat sommige mensen te verwarren. Houd bij twijfel rekening met 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 lessen 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 biedt 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 te allen tijde. 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 lidfunctie erop kan vertrouwen. Elke lidfunctie 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 bestandshandling-klasse heeft bijvoorbeeld de invariant dat deze een pointer naar een geopend bestand bevat. De bestandsgreepconstructor opent het bestand. Destructors gratis middelen verworven door constructeurs. De destructor voor een bestandsingang sluit bijvoorbeeld het bestand dat is geopend door de constructor:

class File_handle {

openbaar:

File_handle (const char * n, const char * rw)

{f = fopen (n, rw); als (f == 0) 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. Voor een minder gedetailleerd en gemakkelijker te benaderen boek, zie A Tour of C ++ . De meeste moderne C ++ -bibliotheken bestaan ​​(onder andere) uit klassen en een bibliotheek-tutorial 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 langverwachte uitleg van wat ik "objectgeoriënteerd" vind. Dat gezegd hebbende, object-georië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 enkele voorbeelden. U hebt bijvoorbeeld twee (of meer) apparaatstuurprogramma's met een gemeenschappelijke interface:

class Driver {// algemene driverinterface

openbaar:

virtuele int-lees (char * p, int n) = 0; // lees max n tekens van apparaat naar p

// retourneer het aantal gelezen tekens

virtuele bool-reset () = 0; // reset het apparaat

virtueel Statuscontrole () = 0; // lees status

};

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

class Driver1: public Driver {// een stuurprogramma

openbaar:

Driver1 (Register); // constructor

int read (char *, int n);

bool-reset ();

Statuscontrole ();

privaat:

// implementatiedetails, incl. vertegenwoordiging

};

 

class Driver2: public Driver {// een andere driver

openbaar:

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. lees (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 (Registreren (0xf00)); // maak een Driver1 voor apparaat

// met apparaatregister op adres 0xf00

 

Driver2 d2 (Register (0xa00)); // maak een Driver2 voor apparaat

// met apparaatregister op adres 0xa00

// ...

int dev;

cin >> dev;

 

if (dev == 1)

f (d1); // gebruik d1

anders

f (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 tussen de fundamentele concepten in uw probleem bestaan, zal geen enkele hoeveelheid hiërarchie en virtuele functies uw code verbeteren. De kracht van OOP is dat er veel problemen zijn die handig kunnen worden uitgedrukt met behulp van klassehiërarchieën - de belangrijkste zwakte van OOP is dat te veel mensen proberen om teveel 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 .

Generieke programmering is in sommige opzichten flexibeler dan objectgeoriënteerd programmeren. Het is met name niet afhankelijk van hiërarchieën. Er bestaat 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?

  • voor directe toegang tot hardware (bijvoorbeeld om een ​​integer te behandelen als een 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 gedachten te uiten (boekhandelaren geven meestal rooskleurige recensies 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 mij). 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 ++ te beheersen. Het is niet bedoeld voor niet-programmeurs die hun eerste programmeertaal willen leren of voor 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 precies zijn.Het beschrijft "pure C ++, dat wil zeggen, de taal onafhankelijk van een bepaalde software-ontwikkelomgeving 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, kijk dan eens naar 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 in C-stijl programmeren 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.

Als u daarentegen volledig op uw gemak wilt zijn met alle belangrijke C ++ -taalconstructies, met gegevensabstractie, objectgeoriënteerd programmeren, generieke programmering, objectgeoriënteerd ontwerp, enz., Kunt u 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 de tijdschaal die 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 discussie over 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 het 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 de reden waarom dingen zijn zoals ze zijn en welke voordelen je kunt verwachten (en die je niet zou mogen verwachten) van een techniek. 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 string uit de invoer zou er bijvoorbeeld ongeveer zo uit moeten zien

string s; // Standaard C ++ -stijl

cin >> 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 onthoud dat geen enkel boek het beste is voor iedereen . 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 met 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 verschillende 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 bedoeld 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 nieuwelingen die voor het eerst worden geconfronteerd "lees wat gegevens, doen er iets aan en produceren output", zijn wellicht geïnteresseerd in een 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 artikelen of boeken voor ideeën. Een manier om te denken aan abstracte klassen en sjablonen 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 moet 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 punten 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 te onderhouden 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 van de 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 de programmeurs die onder realistische omstandigheden werken schade te berokkenen. 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 lastigste manipulatie van laag-niveau aanwijzer 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 belangrijke 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 publiceert u 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 programmeertaal C ++ is voornamelijk 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, zal twee pagina's tonen - 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 van 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 heb ik de indruk dat vectoren altijd beter zijn dan gekoppelde lijsten en dat ik niet weet over andere datastructuren, zoals bomen (bijv. Std :: set ) en hash-tabellen (bijv. :: 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 vaak 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 geprobeerd (uiteindelijk komen lijsten in hun eentje)
  • Ik heb binair zoeken en direct invoegen gebruikt voor vectoren (ja, ze versnellen 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 de links vooraf gealloceerd (dat is beter dan de std :: lijst 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 gebruikelijk zijn (maar dat maakt niet uit voor mijn belangrijkste punt). We gebruiken veel structuren (groot en klein) waar er een keuze is tussen gekoppelde en aaneengesloten reprproductie.
  • Ik weet dat push_front () voor invoegen sneller is voor std :: list s en push_back () s is sneller voor vector s. U kunt voorbeelden construeren 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 creëren heel vaak een datastructuur, doen er een berekening op die toegang vereist (vaak, traversal) en verwijderen die vervolgens. 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 met C zou moeten zijn?

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. In veel opzichten lijkt Java dichter bij Smalltalk te zijn dan bij C ++.

Veel 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 meer gebaseerd op de realiteit en minder onnodig afwijkend van alternatieven. Dit was niet altijd zo. Vergelijk bijvoorbeeld het originele Java-witboek 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, u kunt programma's schrijven voor Windows / Intel of Java / JVM, en in beide gevallen schrijft u code voor een platform dat eigendom is van een enkele onderneming en wordt getweaked voor het commerciële voordeel van die onderneming. Er is op gewezen dat u programma's in elke taal voor de JVM- en bijbehorende besturingssystemen kunt schrijven. De JVM, enz., Zijn echter zwaar 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 je alleen 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 extreem volledige "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 elk kenmerk 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 rijkdom aan nieuwe taalfaciliteiten in C ++ / CLI ten opzichte van ISO Standard C ++ verleidt programmeurs tot het schrijven van niet-draagbare code die (vaak onzichtbaar) intiem verbonden raakt met Microsoft Windows.

De CLI biedt een reeks interfaces (naar systeemfaciliteiten) die sterk verschillen van traditionele interfaces met 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 de plannen van Microsoft niet veranderen) en een taal die niet al deze functies kan uitdrukken kan niet worden gebruikt voor de implementatie van middelen die bedoeld zijn om in andere talen bruikbaar te zijn. 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 overhead in vergelijking met andere talen. Ze zijn erop gericht C ++ te behouden als de dominante systeemprogrammeertaal voor Windows.

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 duidelijk 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 erken en dat Microsoft niet de enige C ++ -verkoper is met dergelijke extensies, ik geef er alleen de voorkeur aan om met dergelijke extensies om te gaan via een "dunne interface" gespecificeerd in ISO-standaard C ++.

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 te proberen 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 goede subset van C ++ te houden met de C ++ / CLI-extensies. De compatibiliteitsproblemen met C / C ++ laten zien 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 overleeft vaak 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-liefhebber 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 mij om C ++ te vergelijken met andere talen, en dat heb ik besloten om het niet te doen." Daarmee bevestigde ik een al 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 bij eerlijke pogingen tot taalvergelijkingen. De auteurs doen hun best 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 eenvoudigweg onbekend bij de mensen die de vergelijking maken of als onbevredigend worden beschouwd, omdat ze in de meer vertrouwde taal onwerkbaar zouden zijn.

Evenzo is informatie over de bekende taal vaak volledig 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 breed scala 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 die van 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 inferieur 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. Tenslotte is geen enkele taal op alle mogelijke manieren beter dan alle andere. C ++ is zeker niet perfect, maar selectieve waarheid kan het meest verleidelijk en soms volledig misleidend zijn.

Wanneer u naar een taalvergelijking kijkt, overweeg 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.

U vergelijkt C ++ niet met andere talen, maar u schrijft scheldwoorden over C ++?

Ik schrijf geen tirades (dat is een vijandige karakterisering van een tekst), 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 nooit een project gezien waarvoor C beter was dan C ++ voor 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 ongewoon 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 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 argumenttypes opsomt:

void f (); / * argumenttypes niet genoemd * /

 

ongeldig g ()

{

f (2); / * slechte stijl C. Niet C ++ * /

}

In C kan een ongeldige * impliciet worden geconverteerd naar elk type aanwijzer, en de toewijzing van vrije opslagplaatsen gebeurt meestal met behulp van malloc (), die niet kan controleren of er "voldoende" geheugen is vereist:

void * malloc (size_t);

 

void f (int n)

{

int * p = malloc (n * sizeof (char)); / * niet C ++. In C ++ toewijzen met `nieuw '* /

char c;

ongeldig * pv = & c;

int * pi = pv; / * impliciete conversie van leegte * naar 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 ++ * /

Met uitzondering van 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 een sterkere typecontrole 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 in plaats daarvan C te gebruiken. Er zijn echter niet veel van die overgebleven; zie mijn (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 ++ in één taal kunnen worden samengevoegd?

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 onverenigbaarheden zouden ontstaan. Of dat mogelijk is, is een andere zaak.

Mijn belangrijkste punt is dat de huidige C / C ++ incompatibiliteiten "ongelukken van de geschiedenis" zijn die geen fundamentele redenen achter hen hebben (hoewel ze allemaal "op het moment als een goed idee leken" voor sommige bekwame en goedbedoelende 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 weergave van mijn opvattingen over C / C ++ compatibiliteit de serie artikelen die ik hierover heb geschreven:

Ik stel me voor dat als incompatibiliteiten 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 werden geschreven, toen het nog steeds mogelijk was om gecoördineerde acties van de C en C ++ normcommissies 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 vrees voor 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, kreeg ik nooit te horen dat ik C moest gebruiken; ook werd mij nooit verteld om C. niet te gebruiken. In feite groeide de eerste C ++ -handleiding 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 dit 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 reflectie met het gebruik van de term. Het doet schadelijk.

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, duidt het meestal op een "C ++ is C met een paar nuttige en een heleboel nutteloze gecompliceerde functies toegevoegd" houding. Dat is vaak het gezichtspunt van mensen die graag hun eigen snaren 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 alleen C / C ++ 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 die wordt 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 aangemoedigd door Simula67. Om dat te doen, voegde ik faciliteiten toe voor een 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. Veel talen dwingen je om te kiezen tussen deze twee alternatieven.

De specifieke taken die me ertoe hebben aangezet om C ++ te ontwerpen en te implementeren (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 Evolueren 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 zij 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 ++ (tm)" 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 de vorm had van "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 kopieën 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 duidt de evolutionaire aard van de veranderingen van C aan; "++" is de C-verhogingsoperator. De iets kortere naam "C +" is een syntaxisfout; het is ook gebruikt als de naam van een niet-verwante 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 het Londense volk zich aansloot bij het project 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 with Classes '' - to-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 vertaling 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 de 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 wat bronniveau-optimalisatie op zijn interne boomstructuur van C ++ -constructies voordat C werd uitgevoerd. De versie die gegenereerde C, vertrouwde niet op C voor het controleren van het type. Het gebruikte eenvoudig C als assembler. De resulterende code was compromisloos snel. Zie D & Evoor 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 dat het succes van C ++ een soort ongeluk is. Ja, zulke 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 sjabloon-metaprogrammering!

Deze veelgestelde vraag werd ingegeven door het zien van deze en nog een aantal van hun ilk 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 lezen over het ontwerp en de evolutie van C ++ en mijn HOPL2- en HOPL3- documenten (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 tegengehouden in C ++ totdat ik RAII (1988) ontdekte. RAII is een integraal en noodzakelijk onderdeel van het C ++ uitzonderingsmehanisme.

Ik was zeer verbaasd toen Jeremy Siek voor het eerst liet zien wat de compileertijd was als dat later std: voorwaardelijk werd , maar ik had mikt op algemene (en kreeg volledige modulo-vertaalgrenzen voor Turing). 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 template-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 overgebruikt, maar dat betekent niet dat het fundamentele idee van compilatie-tijdrekening 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 referentiedelen 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 hoofdzaken meestal recht in mijn hoofd en ik weet waar ik de details kan vinden wanneer ik ze nodig heb.Bijvoorbeeld:

Waarom heeft C ++ garbage collection niet?

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 garbagecollecties. 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 onvolmaakte 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 behoefte aan een vuilnisbelt weg te nemen door geen afval te produceren. Dat is nu mogelijk. Hulpmiddelen die de programmeertechnieken ondersteunen en uitvoeren die worden bereikt. 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 platformleverancier 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, de normcommissie 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 te zijn gestegen. 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 professioneel onderzoek in 2015 schatte het aantal C ++ -programmeurs op 4,4 miljoen. 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. Als ik in 1985 aan een 'C ++ inside'-logo had gedacht, zou de programmeerwereld er vandaag misschien anders uit kunnen zien.

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 wanneer 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 beweringen 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 ook mijn 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 van 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, inclusief 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, meldt u het probleem aan de implementator van de grotere.

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

Het spreekt voor zich dat het aanroepen van C ++ een oude taal is (zie oude code ). Afgezien daarvan denken mensen 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 geworteld zijn in de OOP uit de jaren 1980 dan het begin van C ++ is.

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 gebruiken 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 is vereist 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 ontworpen is om een ​​minimale taal te zijn voor 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 30 jaar geleden, en moderne programmeertalen weerspiegelen dat.

De C ++ -standaard is 1151 pagina's; dat bevat 430 pagina's taaldefinitie en 770 pagina's standaardbibliotheekbeschrijving. De grootte van de taaldefinitie ligt binnen 5% van de taalbeschrijvingen van Java en C # (gemeten op paginatelling). Op dezelfde manier is TC ++ PL 1360 pagina's; van die 750 van die 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 toepassing" wilt schrijven, moet u rekening houden met besturingssysteeminterfaces, GUI, databases, webinterfaces, enz. De som van taalfuncties, bibliotheken en programmeerconventies en -standaarden die u moet gebruiken vertrouwd raken met Dwar de programmeertaal. Hier kan de grootte van C ++ een voordeel zijn voor zover het betere bibliotheken ondersteunt.

Ten slotte zijn de dagen waarin een beginnende programmeur al een taal kent, weg, althans voor de talen in wijdverbreid industrieel gebruik. Weinig mensen kennen 'alles van C' of 'heel Java', en geen van die mensen zijn nieuwelingen. Hieruit volgt dat niemand zich moet verontschuldigen voor het feit dat beginners niet alles van C ++ weten. 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 oefeningen 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 verkies 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 als het niet zo is, zou het moeten zijn.

Kijk voor de manier waarop ISO C ++ kan worden gebruikt voor serieuze ingebedde systeemprogrammering, zie de C ++ -coderingsnormen voor JSF-luchtvaartuigen .

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 overeenkomt met 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 voor een meer gedetailleerde bespreking een van mijn overzichts- of stijlartikelen uit mijn bibliografie . 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 simpele gevaren, krijgen ze nieuwe en minder voor de hand liggende problemen. Iemand die de simpele problemen vermijdt, kan simpelweg 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 Java of C # . Het citaat komt voor in een sectie getiteld "Beyond Files and Syntax". Ik wees erop dat de C ++ -semantiek veel schoner is dan de syntaxis ervan. Ik dacht aan programmeerstijlen, bibliotheken en programmeeromgevingen die de nadruk legden 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 garbage collection? 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 opriep.

"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 uitdrukken, biedt C ++ niet veel hulp" .

"De <random> -bibliotheek is wat een willekeurige bibliotheek wil worden als deze opgroeit, waardoor beginners rand () gebruiken" . 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 de code het oneens 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 ++ . Ook in andere contexten: bouwen aan de toekomst; je moet erin leven .

"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, want "slimme code" is moeilijk te schrijven, 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 data (empirie) en onvoldoende aandacht voor de connectie met computers. Het is geen frontale aanval op het idee dat computerwetenschap 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' geen techniek of 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 bestuurd 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 ontwikkeld, is software-ontwikkeling een waardige technische discipline, die resultaten oplevert die goed te vergelijken zijn met die van oudere technische disciplines.

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

"Het is gemakkelijk om vergeving te winnen omdat je ongelijk hebt, want gelijk krijgen is wat je in de problemen brengt" . Ja.

"Elk probleem in de informatica kan worden opgelost met een andere laag van indirecte richting" , 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 indirectie, behalve natuurlijk voor het probleem van te veel indirecte richtingen" . Ja, ik zei dat citaat (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 van 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 prestaties van de computer is de menselijke verwachting" . Ja, vaak sinds de late jaren tachtig. Het was mijn standaardantwoord op suggesties dat we echt niet meer hoefden te werken aan het efficiënter maken van software omdat hardware sneller wordt.Natuurlijk is de single-core prestatie vandaag niet jarenlang verbeterd.

"vriendschap is niet overgeërfd noch transitief" . Ja. Het is een C ++ -taalregel uit de vroegste dagen.

"Slechts de helft van de C ++ -gemeenschap is bovengemiddeld" . Ja, in een WG21-avondsessie over toekomstige richtingen. Het punt was om de commissieleden van de C ++ -normen eraan te herinneren dat ze voor de C ++-gemeenschap in het algemeen moesten ontwerpen, in plaats van alleen voor deskundigen zoals zijzelf.

"Iedereen die beweert de perfecte programmeertaal te hebben, is een dwaas of een verkoper of beide" . Ja; vele keren.

"Niemand zou zichzelf een professional moeten noemen als ze maar één taal kennen" . Betekenis professional als software-ontwikkelaar of directe manager van softwareontwikkelaars. Ja. Vele keren.

"Het belangrijkste aspect van softwareontwikkeling is om duidelijk te zijn over wat u probeert te bouwen" . Ja, in TC ++ PL2 en TC ++ PL3.

"Onze beschaving draait op software" . Ja, het voor de hand liggende vermelden. Het is een pleidooi voor meer betrouwbare en onderhoudbare code. Als onze geautomatiseerde systemen falen, zullen velen verhongeren.

"Voor veel managers lijkt het verwijderen van de arrogante, ongedisciplineerde, overbelaste, door technologie geobsedeerde, onjuist geklede etc. programmeurs een aanzienlijk bijkomend voordeel" . Ja, in TC ++ PL2 en TC ++ PL3.

"Om oude code te optimaliseren, moet je eerst van de mooie dingen af" . Ja, het punt is dat nieuwe C ++ -functies en betere optimalisers vaak schonere, moderne code sneller laten werken dan uitvoerig met de hand geoptimaliseerde code.

"Wanneer was de laatste keer dat u de geretourneerde waarde van printf hebt gecontroleerd?" Ja, het punt is dat zeldzame fouten vaak niet worden gepakt, wat tot verrassende crashes leidt. Dit is een argument voor het gebruik van uitzonderingen: ze kunnen niet worden genegeerd.

"Het probleem met veel professoren is dat hun vorige functie student was" . Ja. Je hebt ervaring nodig die verder gaat dan het leren van boeken om goed te leren.

"Ontwerpen en programmeren zijn menselijke activiteiten, vergeet dat en alles is verloren" . TC ++ PL3.

"Als je mensen de keuze geeft om goede code of snelle code te schrijven, is er iets mis: goede code moet snel zijn" . CppCon 2018-keynote.

"Ik haat het om te kiezen tussen elegantie en efficiëntie" . Ja. Vaak.

"Iemand die beweert een perfecte programmeertaal te hebben, is een verkoper of een dwaas, of allebei" . Ja. Vaak.

"Als je nooit faalt, probeer je niet hard genoeg" . Ja.

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 elk jaar nog steeds?

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 groeisnelheid 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 initieel ontworpen en geïmplementeerd als een reeks algemene voorzieningen om een ​​aantal specifieke problemen aan te pakken 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 bieden 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 van de 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-divisie van Morgan Stanley heeft een enorm scala aan informatica-uitdagingen, en een hoop slim, goed opgeleid en verrassend (gezien de popuarreputatie van mensen die voor `` Wall Street'' werken) 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 Noord-Oosten 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 wijkt academisch onderzoek nogal af van industrieel onderzoek dat ik gewend was. Smakelijk, het lesgeven aan eerstejaars en afgestudeerden is heel anders dan onderwijsprofessionals. Ik heb ook geholpen met het opbouwen van de afdeling Computer Science and Engineering . Ik ben nog steeds geassocieerd met TAMU als een universiteitskenmerkend hoogleraar.

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

Waarom ben je in 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 geen. 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-norm , 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 uit 2006, die de informatie tot 2006 brengt. Ook hebben veel van mijn interviews betrekking 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 verwijzingen, matrices en afgietsels. Deze faciliteiten zijn ( bijna identiek aan wat C biedt ) essentieel (in welke vorm dan ook) voor nauwgezet hardware werk.Dus, als u laagwaardige taalfaciliteiten wilt, biedt ja C ++ een beproefde reeks faciliteiten voor u. Wanneer u echter geen functies op laag niveau wilt gebruiken, hoeft u de C ++ -faciliteiten niet (rechtstreeks) te gebruiken. 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 op een laag niveau gebruikt, verspilt u vrijwel zeker tijd en maakt u het onderhoud moeilijker 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 permitteren 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 technisch rapport over prestaties 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 ++ norm heeft de commissie haar definitie verfijnd . Microsoft heeft een actieve en grotendeels positieve rol gespeeld in deze standaardisatie - evenals 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 ontworpen is 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 de balans 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 raken en code te schrijven die te slim is om bruikbaar te zijn als onderhoudbare productiecode.

Als je niet van functionele programmeerstijlen houdt, kun je template-metaprogramma's moeilijk te begrijpen vinden. 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 sjabloonmetaprogramming overbodig maken. Bovendien, als wat u wilt genereren een waarde (zeg en integerwaarde) is, zijn constexpr-functies veel gemakkelijker te gebruiken (en sneller te compileren).