C++

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 31 juli 2022; kontroller kräver 14 redigeringar .

C++

Semantik	multiparadigm : objektorienterad , generisk , procedurell , metaprogrammering
Språkklass	objektorienterat programmeringsspråk , programmeringsspråk med flera paradigm , procedurspråk , funktionellt programmeringsspråk , generiskt programmeringsspråk , programmeringsspråk , språk i fritt format [d] och kompilerat programmeringsspråk
Utförandetyp	sammanställt
Framträdde i	1983
Författare	Stroustrup, Björn
Filtillägg _	.cc, .cpp, .cxx, .c, .c++, .h, .hpp, eller .hh_.hxx.h++
Släpp	C++20 ( december 2020 ) [1]
Typ system	statisk
Stora implementeringar	GNU C++ , Microsoft Visual C++ , Intel C++ kompilator , Open64 C++ kompilator , Clang , Comeau C/C++ , Embarcadero C++ Builder , Watcom C++ kompilator , Digital Mars C++, Oracle Solaris Studio C++ kompilator, Turbo C++
Dialekter	ISO/IEC 14882 C++
Blivit påverkad	C , Simula , Algol 68 , Clu , ML och Ada
Hemsida	isocpp.org _
Mediafiler på Wikimedia Commons

C ++ (uttalas c-plus-plus [2] [3] ) är ett kompilerat , statiskt skrivet , allmänt programmeringsspråk .

Stöder sådana programmeringsparadigm som procedurprogrammering , objektorienterad programmering , generisk programmering . Språket har ett rikt standardbibliotek som inkluderar vanliga behållare och algoritmer , I/O, reguljära uttryck, stöd för flera trådar och mer. C++ kombinerar funktioner från både högnivå- och lågnivåspråk [4] [5] . I jämförelse med sin föregångare - C -språket - ägnas den största uppmärksamheten åt stöd för objektorienterad och generisk programmering [5] .

C++ används ofta för mjukvaruutveckling och är ett av de mest populära programmeringsspråken [opinions 1] [opinions 2] . Dess omfattning inkluderar skapandet av operativsystem , en mängd olika applikationsprogram, drivrutiner , applikationer för inbäddade system, högpresterande servrar och datorspel. Det finns många implementeringar av C++-språket, både gratis och kommersiellt, och för olika plattformar. Till exempel på x86- plattformen är dessa GCC , Visual C++ , Intel C++ Compiler , Embarcadero (Borland) C++ Builder och andra. C++ har haft en enorm inverkan på andra programmeringsspråk, framför allt Java och C# .

C++-syntaxen ärvs från C- språket . En av de ursprungliga designprinciperna var att bibehålla kompatibilitet med C. Men C++ är inte strikt en superset av C; Uppsättningen av program som kan översättas lika bra av både C- och C++-kompilatorer är ganska stor, men inkluderar inte alla möjliga C-program .

Historik

Historiskt utvecklingsstadium [6]	År
BCPL- språk	1966
B - språket (ursprunglig utveckling av Thompson under UNIX )	1969
C språk	1972
C med klasser	1980
C84	1984
Cfront (Edition E)	1984
cfront (version 1.0)	1985
Multipelt/virtuellt arv	1988
Generisk programmering ( mallar )	1991
ANSI C++ / ISO-C++	1996
ISO/IEC 14882:1998	1998
ISO/IEC 14882:2003	2003
C++/CLI	2005
TR1	2005
C++11	2011
C++14	2014
C++17	2017
C++20	2020

Skapande

Språket uppstod i början av 1980 -talet , när Bell Labs medarbetare Björn Stroustrup kom med ett antal förbättringar av C -språket för sina egna behov [7] . När Stroustrup började arbeta på Bell Labs i slutet av 1970 -talet med problem i köteori (som tillämpat på modellering av telefonsamtal), fann han att försök att använda befintliga modelleringsspråk vid den tiden var ineffektiva, och användningen av högeffektiva maskinspråk var för svårt på grund av deras begränsade uttrycksfullhet. Simula- språket har till exempel funktioner som skulle vara mycket användbara för att utveckla stora program, men som är för långsamt, och BCPL -språket är tillräckligt snabbt, men för nära lågnivåspråk, och är inte lämpligt för att utveckla stora program.

Med tanke på upplevelsen av sin avhandling beslutade Stroustrup att komplettera C-språket (efterföljaren till BCPL) med de möjligheter som finns tillgängliga i Simula-språket. C-språket, som är basspråket i UNIX -systemet som Bell-datorerna körde på, är snabbt, funktionsrikt och bärbart. Stroustrup lade till det möjligheten att arbeta med klasser och objekt. Som ett resultat visade sig praktiska modelleringsproblem vara tillgängliga både när det gäller utvecklingstid (på grund av användningen av Simula-liknande klasser) och när det gäller beräkningstid (på grund av hastigheten på C). De första tilläggen till C var klasser (med inkapsling ), klassarv, strikt typkontroll, inline-funktioner och standardargument . Tidiga versioner av språket, som ursprungligen kallades "C med klasser", har varit tillgängliga sedan 1980- talet .

Under utvecklingen av C med klasser skrev Stroustrup programmet cfront , en kompilator som omarbetar C-källkod med klasser till vanlig C-källkod. Detta gjorde det möjligt för oss att arbeta med ett nytt språk och använda det i praktiken, med hjälp av den infrastruktur som redan finns tillgänglig i UNIX för utveckling i C. Ett nytt språk, oväntat för författaren, fick han stor popularitet bland kollegor och snart kunde Stroustrup inte längre personligen stödja honom, svarade på tusentals frågor.

År 1983 lades nya funktioner till i språket, såsom virtuella funktioner, funktions- och operatöröverbelastning, referenser, konstanter, användarkontroll över ledig minneshantering, förbättrad typkontroll och en ny kommentarstil ( //). Det resulterande språket är inte längre bara en utökad version av klassisk C och har bytt namn från C med klasser till "C++". Dess första kommersiella release ägde rum i oktober 1985 .

Innan den officiella standardiseringen började utvecklades språket huvudsakligen av Stroustrup som svar på förfrågningar från programmeringsgemenskapen. Funktionen av standardspråksbeskrivningar utfördes av Stroustrups tryckta verk på C ++ (en beskrivning av språket, en referensmanual, och så vidare). Det var först 1998 som den internationella standarden för C++-språket ratificerades: ISO/IEC 14882:1998 "Standard for the C++ Programming Language"; efter antagandet av tekniska korrigeringar av standarden 2003, är nästa version av denna standard ISO/IEC 14882:2003 [8] .

Utveckling och standardisering av språket

1985 kom den första utgåvan av The C++ Programming Language , som gav den första beskrivningen av språket, vilket var extremt viktigt på grund av avsaknaden av en officiell standard. 1989 släpptes C++ version 2.0. Dess nya funktioner inkluderade multipelt arv, abstrakta klasser, statiska medlemsfunktioner, konstanta funktioner och skyddade medlemmar. 1990 publicerades "Commented Reference Guide to C++", som senare blev grunden för standarden. De senaste uppdateringarna har inkluderat mallar, undantag, namnutrymmen, nya casts och den booleska typen. Standardmallbiblioteket (STL) utvecklat av Alexander Stepanov och Meng Li valdes som grund för lagring och åtkomst av generiska algoritmer .

C++ Standard Library har också utvecklats tillsammans med det. Det första tillägget till C++-standardbiblioteket var I/O-strömmar, vilket gav ett sätt att ersätta traditionella C printfoch scanf. Senare var den viktigaste utvecklingen av standardbiblioteket införandet av standardmallbiblioteket .

Officiell standardisering av språket började 1998 med publiceringen av språkstandarden ISO/IEC 14882:1998 (känd som C++98) [9] , utvecklad av C++ standardiseringskommittén ( ISO / IEC JTC1/SC22/WG21 arbetsgruppen ). C++-standarden beskrev inte objektnamnkonventioner, vissa undantagshanteringsdetaljer och andra implementeringsrelaterade funktioner, vilket gjorde objektkod som genererats av olika kompilatorer inkompatibel. Men många standarder har skapats för detta av tredje part för specifika arkitekturer och operativsystem .
2003 publicerades standarden C++ ISO/IEC 14882:2003, där de identifierade felen och bristerna i den tidigare versionen av standarden korrigerades. 2005 publicerades Biblioteksteknisk rapport 1 (förkortad TR1). Även om den inte officiellt ingår i standarden, beskriver rapporten tillägg till standardbiblioteket som författarna anser bör inkluderas i nästa version av standarden. TR1-stödet förbättras i nästan alla C++-kompilatorer som stöds.
Sedan 2009 har ett arbete pågått med att uppdatera den tidigare standarden. Den preliminära versionen hette C++09, nästa år döptes den om till C++0x. Standarden publicerades 2011 under namnet C++11 . Det innehåller tillägg till kärnan av språket och en tillägg till standardbiblioteket, inklusive mycket av TR1.
Nästa version av standarden, C++14 , släpptes i augusti 2014. Den innehåller mestadels förtydliganden och buggfixar från den tidigare versionen.
C ++ 17-standarden , som publicerades i december 2017, inkluderade parallella versioner av standardalgoritmer i standardbiblioteket och tog bort några föråldrade och extremt sällan använda element.
Den senaste stabila aktuella versionen av standarden är C++20 . Den innehåller bland annat en grundläggande innovation – stöd för moduler.
C++23-standarden är för närvarande under aktiv diskussion i ISO-kommittén.

C++ fortsätter att utvecklas för att möta moderna krav. En av grupperna som utvecklar C++-språket och skickar förslag på förbättringar till C++-standardiseringskommittén är Boost , som bland annat sysslar med att förbättra språkets kapacitet genom att lägga till metaprogrammeringsfunktioner till det .

Ingen äger rättigheterna till C++-språket, det är gratis. Själva språkstandarddokumentet (med undantag för utkast) är dock inte fritt tillgängligt [10] . Som en del av standardiseringsprocessen producerar ISO flera typer av publikationer. Speciellt publiceras tekniska rapporter och tekniska specifikationer när "framtiden är i sikte, men det inte finns någon omedelbar möjlighet att komma överens om publicering av en internationell standard." Fram till 2011 publicerades tre tekniska rapporter om C++: TR 19768: 2007 (även känd som C++ Technical Report 1) för biblioteksutvidgningar huvudsakligen integrerade i C++11, TR 29124: 2010 för speciella matematiska funktioner och TR 24733: 20113: decimal flyttalsaritmetik. Teknisk specifikation DTS 18822:. 2014 (av filsystem) godkändes i början av 2015, och resten av specifikationerna är under utveckling och väntar på godkännande [11] .

I mars 2016 skapades arbetsgruppen WG21 C++ i Ryssland . Gruppen organiserades för att samla in förslag till C++-standarden, överlämna dem till kommittén och försvara dem vid allmänna möten i International Organization for Standardization (ISO) [12] .

Historik för namnet

Det resulterande språknamnet kommer från C unary postfix inkrementoperatorn++ (ökar värdet på en variabel med en). Namnet C+ användes inte eftersom det är ett syntaxfel i C och dessutom togs namnet av ett annat språk. Språket hette inte heller D eftersom "det är en förlängning av C och inte försöker fixa problem genom att ta bort C-element " [7] .

Filosofi för C++

I The Design and Evolution of C++ [13] beskriver Björn Stroustrup de principer han följde när han designade C++. Dessa principer förklarar varför C++ är som det är. Några av dem:

Få ett universellt språk med statiska datatyper, effektiviteten och portabiliteten hos C.
Stöder direkt och heltäckande många programmeringsstilar, inklusive procedurprogrammering , dataabstraktion , objektorienterad programmering och generisk programmering .
Ge programmeraren valfrihet, även om det ger honom möjlighet att välja fel.
Behåll kompatibiliteten med C så mycket som möjligt, vilket gör det möjligt att enkelt byta från programmering till C.
Undvik inkonsekvenser mellan C och C++: alla konstruktioner som är giltiga på båda språken måste betyda samma sak i vart och ett av dem och leda till samma programbeteende.
Undvik funktioner som är plattformsberoende eller inte universella.
"Betala inte för det du inte använder" - Ingen språkfunktion ska orsaka prestandaförsämring för program som inte använder den.
Kräv inte för komplicerad programmeringsmiljö.

Språköversikt

C++-standarden består av två huvuddelar: en beskrivning av kärnspråket och en beskrivning av standardbiblioteket.

Till en början utvecklades språket utanför den formella ramen, spontant, i enlighet med de uppgifter som det stod inför. Utvecklingen av språket åtföljdes av utvecklingen av cfront cross-kompilatorn . Innovationer i språket återspeglades i ändringen av versionsnumret för korskompilatorn. Dessa korskompilatorversionsnummer utökades till själva språket, men C++-versioner diskuteras för närvarande inte. Det var inte förrän 1998 som språket blev standardiserat.

C++ stöder både kommentarer i C-stil ( /* комментарий */) och kommentarer på en rad ( // вся оставшаяся часть строки является комментарием), där det //anger början på en kommentar, och den närmaste efterföljande nyraden som inte föregås av ett tecken \(eller motsvarande ??/) anses avsluta kommentaren. Fördelen med denna kommentar är att det inte är nödvändigt att avsluta den, det vill säga att ange slutet på kommentaren.
Funktionsspecifikation inline. En funktion som definieras i en klasskropp är inline som standard. Denna specificering är ett tips till kompilatorn och kan bädda in funktionens kropp i koden istället för att anropa den direkt.
Kvalificeringar constoch volatile. Till skillnad från C, där det constbetecknar skrivskyddad åtkomst, constmåste i C++ en variabel med en kvalificerare initieras. volatileanvänds i variabeldeklarationer och informerar kompilatorn om att värdet på den givna variabeln kan ändras på ett sätt som kompilatorn inte kan spåra. För variabler som deklareras volatilemed , får kompilatorn inte använda optimeringar som ändrar variabelns placering i minnet (till exempel genom att placera den i ett register) eller förlita sig på att variabelns värde förblir oförändrat mellan två tilldelningar till den. volatileHjälper till att undvika minnesbarriärer av typ 2 i ett flerkärnigt system .
Namnutrymmen ( namespace). Exempel:

namnutrymme Foo { const int x = 5 ; } const int y = Foo :: x ;

Ett namnutrymme utan namn är ett specialfall. Alla namn som beskrivs i den är endast tillgängliga i den aktuella översättningsenheten och har lokal bindning. Namnutrymmet stdinnehåller standard C++-bibliotek.

newOperatörerna , new[]och introduceras deleteför att arbeta med minne delete[]. Till skillnad från biblioteket malloc och gratis som kom från C, initierar dessa operatörer ett objekt. För klasser är detta ett konstruktoranrop, för POD - typer kan initiering antingen utelämnas ( new Pod;), eller initieras med nollvärden ( new Pod(); new Pod {};).

Typer

Följande inbyggda typer är tillgängliga i C++. C++-typer är nästan identiska med C-datatyper :

tecken: char, wchar_t( char16_toch char32_t, i C++11- standarden );
heltal med tecken: signed char, short int, int, long int(och long long, i C++11- standarden );
heltal utan tecken: unsigned char, unsigned short int, unsigned int, unsigned long int(och unsigned long long, i C++11- standarden );
flyttal : , , ; _floatdoublelong double
boolean: boolhar värdena antingen true, eller false.

Jämförelseoperatörers returtyp bool. Uttryck inom parentes efter if, while omvandlas till typ bool[14] .

Språket introducerade begreppet referenser, och från C++11-standarden , rvalues- referenser och vidarebefordran av referenser . (se länk (C++) )

C++ lägger till objektorienterade funktioner i C. Den introducerar klasser som tillhandahåller de tre viktigaste egenskaperna hos OOP : inkapsling , nedärvning och polymorfism .

I C++-standarden är en klass en användardefinierad typ som deklareras med ett av nyckelorden , eller class, structen unionstruktur är en klass som definieras av struct, och en union är en klass som definieras av union. Beroende på vilket nyckelord som används ändras även vissa egenskaper för själva klassen. Till exempel, i en klass som deklareras med struct, kommer medlemmar utan en manuellt tilldelad åtkomstmodifierare som standard till offentlig snarare än privat.

I brödtexten i en klassdefinition kan du ange både funktionsdeklarationer och deras definition. I det senare fallet är funktionen inline ( inline). Icke-statiska medlemsfunktioner kan ha constoch qualifiers volatile, såväl som en referens qualifier ( &eller &&).

Arv

C++ stöder flera arv . Basklasser (förfäderklasser) anges i huvudet på klassdeklarationen, eventuellt med åtkomstspecifikatorer. Arv från varje klass kan vara offentligt, skyddat eller privat:

Basklassmedlemsåtkomst/arvningsläge	privat medlem	skyddad medlem	offentlig medlem
privat arv	inte tillgänglig	privat	privat
skyddat arv	inte tillgänglig	skyddad	skyddad
offentligt arv	inte tillgänglig	skyddad	offentlig

Som standard ärvs basklassen som privat.

Som ett resultat av arv får barnklassen alla fält av förfäderklasserna och alla deras metoder; vi kan säga att varje instans av ättlingklassen innehåller en underinstans av var och en av förfaderklasserna. Om en förfaderklass ärvs flera gånger (detta är möjligt om det är förfadern till flera basklasser av klassen som skapas), kommer instanser av den efterkommande klassen att inkludera lika många underinstanser av denna förfaderklass. För att undvika denna effekt om det inte är önskvärt, stöder C++ konceptet virtuellt arv . Vid ärvning kan basklassen deklareras virtuell; för alla virtuella förekomster av förfaderklassen i arvsträdet för den efterkommande klassen skapas endast en underinstans i den efterkommande.

Polymorfism

C++ stöder dynamisk polymorfism och parametrisk polymorfism .

Parametrisk polymorfism representeras av:

Standardargument för funktioner. Till exempel, för en funktion void f(int x, int y=5, int z=10)är anropen till och f(1)likvärdiga .f(1,5)f(1,5,10)
Funktionsöverbelastning : En funktion med samma namn kan ha olika antal och typ av argument. Till exempel :voidPrint ( int x ) ; voidPrint ( dubbel x ) ; void Skriv ut ( int x , int y );

Operatörsöverbelastning är ett specialfall av funktionsöverbelastning .

mallmotor

Dynamisk polymorfism implementeras med hjälp av virtuella metoder och en arvshierarki. I C++ är en typ polymorf om den har minst en virtuell metod. Hierarkiexempel:

klassfigur _ { offentliga : virtuell void Draw () = 0 ; // ren virtuell metod virtuell ~ Figur (); // om det finns minst en virtuell metod ska förstöraren göras virtuell }; klass Square : offentlig person { offentliga : void Rita () åsidosätta ; }; klass Cirkel : offentlig person { offentliga : void Rita () åsidosätta ; };

Här är figurklassen abstrakt (och till och med gränssnittsklassen ), eftersom Draw-metoden inte är definierad. Objekt av denna klass kan inte skapas, men referenser eller pekare med typen Figur kan användas. Valet av implementering av Draw-metoden kommer att göras vid körning baserat på den faktiska typen av objekt.

Inkapsling

Inkapsling i C++ implementeras genom att specificera nivån av åtkomst till klassmedlemmar: de är offentliga (offentliga, public), skyddade ( protected) och privata (privata, private). I C++ skiljer sig strukturer formellt endast från klasser genom att som standard är åtkomstnivån till klassmedlemmar och typen av arv för en struktur offentliga, medan de för en klass är privata.

Tillgång	privat	skyddad	offentlig
Själva klassen	Ja	Ja	Ja
Vänner	Ja	Ja	Ja
arvingar	Nej	Ja	Ja
Från utsidan	Nej	Nej	Ja

Åtkomstkontroll sker vid kompilering, försök att komma åt en otillgänglig klassmedlem kommer att orsaka ett kompileringsfel.

Vänner

Vänfunktioner är funktioner som inte är medlemsfunktioner och som ändå har tillgång till skyddade och privata medlemmar i klassen. De måste deklareras i klassens brödtext som friend. Till exempel:

klass Matrix { vän Matrix Multiplicera ( Matrix m1 , Matrix m2 ); };

Här kan funktionen Multiplykomma åt alla fält och medlemsfunktioner i Matrix.

Både hela klassen och en medlemsfunktion i klassen kan förklaras som vän. Fyra viktiga begränsningar för vänrelationer i C++ är:

Vänlighet är inte transitiv. Om A förklarar en vän till B, och B i sin tur förklarar en vän till C, så blir C inte automatiskt vän till A. För att göra detta måste A uttryckligen förklara C som vän.
Vänskap är inte ömsesidigt. Om klass A förklarar en vän till klass B, så blir den inte automatiskt vän till B. För detta måste det finnas en uttrycklig vänlighetsförklaring av A i klass B.
Vänlighet går inte i arv. Om A förklarar en klass B som en vän, så blir inte B:s barn automatiskt vänner till A. För att göra detta måste var och en av dem uttryckligen förklaras som vän till A.
Vänskap sträcker sig inte till ättlingar. Om en klass A förklarar B som vän, blir B inte automatiskt vän till A:s ättlingklasser. Varje ättling måste vid behov förklara B för sin egen vän.

Generellt kan denna regel formuleras på följande sätt: "Vänlighetsrelationen existerar endast mellan de klasser (klass och funktion) för vilka den uttryckligen deklareras i koden, och agerar endast i den riktning i vilken den deklareras."

Specialfunktioner

En standardklass kan ha sex specialfunktioner: default constructor, copy constructor, move constructor, destructor, copy assignment operator, move assignment operator. Det är också möjligt att uttryckligen definiera dem alla (se treregeln ).

klass Array { offentliga : Array ( ) = standard // kompilatorn kommer att skapa en standardkonstruktor för Array själv ( size_t _len ) : len ( _len ) { val = ny dubbel [ _len ]; } Array ( const Array & a ) = radera ; // copy constructor har explicit tagit bort Array ( Array && a ); // flytta konstruktör ~ Array () { ta bort [] val ; } Array & operator = ( const Array & rhs ); // copy assignment operator Array & operator = ( Array && rhs ); // flytta tilldelningsoperator dubbel & operator []( size_t i ) { returvärde [ i ] ; } const double & operator []( size_t i ) const { returvärde [ i ] ; } skyddad : std :: size_t len = 0 ; // fältinitiering dubbel * val { nullptr }; };

Konstruktorn anropas för att initiera objektet (av lämplig typ) när det skapas, och destruktorn anropas för att förstöra objektet. En klass kan ha flera konstruktörer, men en destruktor kan bara ha en. Konstruktörer i C++ kan inte deklareras som virtuella, men destruktorer kan, och deklareras vanligtvis för alla polymorfa typer, för att säkerställa att ett refererat eller pekartillgängligt objekt förstörs korrekt, oavsett vilken typ referensen eller pekaren är. Om minst en av basklasserna har en virtuell förstörare, blir destruktören för den underordnade klassen automatiskt virtuell.

Mallar

Mallar låter dig generera funktioner och klasser som parametriseras med en specifik typ eller värde. Till exempel kunde den föregående klassen implementera en array för vilken datatyp som helst:

mall < typnamnT > _ klass Array { ... T & operator []( size_t i ) { returvärde [ i ] ; } skyddad : std :: size_t len { 0 }; // fältinitiering T * val { nullptr }; };

Standardbibliotek

Allmän struktur

C++ Standard Library innehåller en uppsättning verktyg som bör vara tillgängliga för alla implementeringar av språket för att ge programmerare en bekväm användning av språkfunktioner och ge en grund för att utveckla både ett brett utbud av applikationsapplikationer och specialiserade bibliotek. C++ Standard Library inkluderar en del av C Standard Library. C++ Standard innehåller en normativ referens till 1990 C Standard och definierar inte självständigt de standardbiblioteksfunktioner som är lånade från C Standard Library.

#includeÅtkomst till funktionerna i C++ standardbiblioteket tillhandahålls genom att inkludera lämpliga standardhuvudfiler i programmet (via direktivet ). Totalt är 79 sådana filer definierade i C++11-standarden. Standardbiblioteksfaciliteter deklareras som en del av standardnamnutrymmet. Header-filer vars namn matchar mönstret "cX", där X är header-filnamnet för C Standard Library utan tillägg (cstdlib, cstring, cstdio, etc.), innehåller deklarationer som motsvarar den del av C Standard Library. standardbiblioteksfunktioner finns också i namnrymden std.

Komposition

Standardbiblioteket innehåller följande sektioner:

Språkstöd . Innehåller verktyg som är nödvändiga för att programmen ska fungera, samt information om implementeringsfunktioner. Minnestilldelning , RTTI , grundläggande undantag, värdegränser för numeriska datatyper, grundläggande miljöinteraktioner såsom systemklockan, UNIX-signalhantering, programavslutning.
standardbehållare . _ Standardbiblioteket innehåller mallar för följande behållare: dynamisk array (vektor), statisk array (array), enkelriktade och dubbelriktade listor (forward_list, list), stack (stack), deque (deque), associativa arrays (map, multimap), set (uppsättning, multiset), prioritetskö (prioritetskö).
Grundläggande verktyg . Det här avsnittet innehåller en beskrivning av de huvudsakliga baselementen som används i standardbiblioteket, minnesallokatorer och stöd för tid och datum i C-stil.
Iteratorer . Tillhandahåll iteratormallar som tillhandahåller en standardmekanism i standardbiblioteket för att tillämpa databearbetningsalgoritmer i partier på behållarelement.
Algoritmer . Mallar för att beskriva bearbetningsoperationer som, med hjälp av standardbibliotekets mekanismer, kan appliceras på vilken sekvens av element som helst, inklusive element i behållare. I det här avsnittet ingår också beskrivningar av funktionerna bsearch() och qsort() från C-standardbiblioteket.
Strängar . C++ stil strängmallar. Det här avsnittet innehåller också några av biblioteken för att arbeta med strängar och symboler i C-stil.
Ingång-utgång . Mallar och hjälpklasser för generella I/O-strömmar, sträng-I/O, manipulatorer (kontroller för ström I/O-format i C++-stil).
Lokalisering . Definitioner som används för att stödja C++-stil och C-stil nationaliteter och presentationsformat (datum, valutor, etc.).
Diagnostik . Definitioner av ett antal undantag och mekanismer för påståendekontroll vid körning (assert). Stöd för C-stil felhantering.
Siffror . Definitioner för att arbeta med komplexa tal, matematiska vektorer, stöd för generella matematiska funktioner, slumptalsgenerator.

Behållare, strängar, algoritmer, iteratorer och grundläggande verktyg, med undantag för lån från C-biblioteket, kallas gemensamt för STL (Standard Template Library - standard template library). Ursprungligen var detta bibliotek en separat produkt och dess förkortning dechiffrerades annorlunda, men sedan gick det in i C ++ standardbiblioteket som ett integrerat element. Namnet återspeglar det faktum att generaliserade programmeringsmekanismer (C++-mallar - mall) används för att implementera generella verktyg (behållare, strängar, algoritmer). Stroustrups skrifter beskriver skälen till varför detta val gjordes. De viktigaste är den större universaliteten hos den valda lösningen (mallbehållare, till skillnad från objektbehållare, kan enkelt användas för icke-objekttyper och kräver inte en gemensam förfader för elementtyper) och dess tekniska effektivitet (som regel, mallbehållare operationer kräver inga virtuella funktionsanrop och kan enkelt bäddas in (inline), vilket i slutändan ger en prestandavinst.

Från och med C++11-standarden har följande funktioner lagts till:

<regex>-biblioteket har lagts till, som implementerar vanliga sök- och ersättningsmekanismer med hjälp av reguljära uttryck.
Tillagt stöd för multithreading.
Atomverksamhet
oordnade varianter av associativa arrayer och uppsättningar.
Smarta pekare som automatiskt omallokerar tilldelat minne.

Implementeringar

STL, innan den ingick i C++-standarden, var en tredjepartsutveckling, först av HP och sedan av SGI . Språkstandarden kallar det inte "STL" eftersom detta bibliotek har blivit en integrerad del av språket, men många använder fortfarande detta namn för att skilja det från resten av standardbiblioteket (I/O-strömmar ( iostream ), undersektion C och andra).

Ett projekt kallat STLport [15] baserat på SGI STL håller STL-, IOstream- och strängklasserna uppdaterade. Flera andra projekt utvecklar också privat användning av standardbiblioteket.

Skillnader från C-språket

Kompatibilitet med C-språk

Valet av C som grund för att skapa ett nytt programmeringsspråk förklaras av att C-språket:

är ett multifunktionellt, kortfattat och relativt lågnivåspråk;
lämplig för de flesta systemuppgifter;
uppträdde överallt och på allt;
gränssnitt med UNIX-programmeringsmiljön.

— B. Stroustrup. C++ programmeringsspråk. Avsnitt 1.6 [16]

Trots ett antal välkända brister i C-språket valde Stroustrup att använda det som bas eftersom "C har sina problem, men ett språk designat från grunden skulle ha dem, och vi känner till problemen med C." Dessutom tillät detta oss att snabbt få en kompilatorprototyp ( cfront ) som endast översatte de tillagda syntaxelementen till det ursprungliga C-språket.

När C++ utvecklades inkluderades andra funktioner som åsidosätter funktionerna hos C-konstruktioner, och frågan om att överge språkkompatibilitet genom att ta bort föråldrade konstruktioner togs upp upprepade gånger. Kompatibiliteten har dock bibehållits av följande skäl:

bevarande av den nuvarande koden, ursprungligen skriven i C och direkt portad till C++;
eliminerar behovet av att omskola programmerare som tidigare har studerat C (de behöver bara lära sig nya C++-verktyg);
eliminering av förvirring mellan språk när de används tillsammans ("om två språk används tillsammans, bör deras skillnader vara antingen minimala eller så stora att språken inte kan förväxlas").

Nya funktioner

Nya C++-funktioner inkluderar uttrycksdeklarationer, funktionstypkonverteringar, operatorer newoch delete, typ bool, referenser, utökad beständighet, inline-funktioner, standardargument, åsidosättningar, namnrymder, klasser (inklusive alla klassrelaterade funktioner som arv, medlemsfunktioner, virtuella funktioner, abstrakt klasser och konstruktörer ), operatörsöverstyrningar, mallar, operatör ::, undantagshantering, dynamisk identifiering med mera. C++-språket är också, i många fall, mer strikt när det gäller typkontroll än C.

C++ introducerade kommentarer med dubbla snedstreck ( //) som fanns i C:s föregångare, BCPL .

constVissa funktioner i C++ portades senare till C, såsom nyckelorden och , loop- inlinedeklarationer foroch kommentarer i C++-stil ( //). Senare implementeringar av C introducerade också funktioner som inte finns i C++, såsom makron va_argoch förbättrad hantering av arrayparameter.

C++ inkluderar inte C

Medan de flesta C-koder också kommer att vara giltiga för C++, är C++ inte en superset av C och inkluderar den inte. Det finns också en del kod som är sant för C men inte sant för C++. Detta skiljer den från Objective C , en annan C-förbättring för OOP , som bara är en superset av C.

Det finns andra skillnader också. Till exempel tillåter inte C++ att anropa en funktion main()i ett program, medan det i C är lagligt. Dessutom är C++ mer strikt i vissa avseenden; till exempel tillåter den inte implicit casting mellan orelaterade pekartyper och tillåter inte funktioner som ännu inte har deklarerats.

Dessutom kan kod som är giltig för båda språken ge olika resultat beroende på vilket språks kompilator den är översatt till. Till exempel, på de flesta plattformar skriver följande program ut "C" om det kompileras av en C-kompilator och "C++" om det kompileras av en C++-kompilator. Detta beror på att teckenkonstanter i C (till exempel 'a') är av typen int, men i C++ är de av typen char, och storlekarna på dessa typer skiljer sig vanligtvis åt.

#include <stdio.h> int main () { printf ( "%s \n " , ( storlek på ( 'a' ) == storlek på ( char )) ? "C++" : "C" ); returnera 0 ; }

C Medel att undvika

Som Stroustrup noterar, "Ju bättre du känner till C, desto svårare blir det för dig att undvika C++-programmering i C-stil, samtidigt som du förlorar de potentiella fördelarna med C++." För det ändamålet ger han följande rekommendationer för C-programmerare för att dra full nytta av C++:

Använd inte makron #define. För att deklarera konstanter, använd const, grupper av konstanter (uppräkningar) - enum, för direkt inkludering av funktioner - inline, för att definiera familjer av funktioner eller typer - template.
Använd inte framåtriktade variabeldeklarationer. Deklarera variabler i blocket där de faktiskt används, och kombinera alltid deklaration med initiering.
Överge användningen av malloc()[17] till förmån för operatören new, från realloc()[18] till förmån för typen vector. Det blir säkrare att använda smarta pekare, som shared_ptroch unique_ptr, tillgängliga från den elfte versionen av standarden.
Undvik otypade pekare, aritmetik för pekare, implicita casts, fackföreningar, utom möjligen i lågnivåkod. Använd omvandlingar av "ny" typ, eftersom de mer exakt uttrycker programmerarens faktiska avsikter och är säkrare.
Minimera användningen av teckenuppsättningar och strängar i C-stil genom att ersätta dem med stringoch vectorfrån STL-typer. I allmänhet, försök inte skapa dina egna implementeringar av det som redan finns i standardbiblioteket.

Vidareutveckling

Den nuvarande språkstandarden ISO/IEC 14882:2017 publicerades i december 2017 . Det kallas inofficiellt C++17 . Nästa version av standarden, planerad till 2020, har den inofficiella beteckningen C++20 .

Allmänna anvisningar för C++-utveckling

Enligt språkets författare, Björn Stroustrup [19] [20] [21] , talade om språkets vidare utveckling och framtidsutsikter, kan följande urskiljas:

I grund och botten kommer ytterligare utveckling av språket att följa vägen för att göra tillägg till standardbiblioteket. En av huvudkällorna för dessa tillägg är det berömda Boost -biblioteket .
Ändringar av språkets kärna bör inte minska effektiviteten hos C++ som redan har uppnåtts. Ur Stroustrups synvinkel är det att föredra att göra några större stora förändringar i kärnan än många små förändringar.
De grundläggande riktningarna för utvecklingen av C++ inom den närmaste framtiden är utvidgningen av kapaciteten och förfining av generiska programmeringsverktyg, standardisering av parallella bearbetningsmekanismer, samt förfining av säkra programmeringsverktyg, såsom olika kontroller och säkra typkonverteringar, tillståndskontroll och så vidare.
Generellt sett är C++ designat och utvecklat som ett multiparadigmspråk som absorberar olika programmeringsmetoder och teknologier, men implementerar dem på en plattform som ger hög teknisk effektivitet. Därför är det i framtiden möjligt att funktionella programmeringsverktyg, automatisk sophämtning och andra mekanismer som för närvarande saknas i det kommer att läggas till språket. Men i alla fall kommer detta att göras på den befintliga plattformen av ett mycket effektivt kompilerat språk.
Även om en av principerna för C++ formellt återstår att upprätthålla kompatibilitet med C-språket, interagerar faktiskt inte standardiseringsgrupperna för dessa språk, och ändringarna de gör inte bara korrelerar inte, utan motsäger ofta i grunden varandra ideologiskt. Så, de element som de nya C-standarderna lägger till i kärnan är element i standardbiblioteket i C++-standarden och är i allmänhet frånvarande i kärnan, till exempel dynamiska arrayer, arrayer med fasta gränser, parallella bearbetningsfaciliteter. Stroustrup tror att det skulle vara till stor nytta att kombinera utvecklingen av dessa två språk, men det är knappast möjligt av politiska skäl. Så praktisk kompatibilitet mellan C och C++ kommer gradvis att gå förlorad.

C++11-standarden: tillägg till kärnan i språket

Explicit definierade konstantfunktioner och uttryck constexpr.
Generisk initiering.
Konstruktörer och uppdragsoperatörer med transfersemantik.
Skriv slutledning.

För användning i mallar, där det är svårt att specificera en specifik typ av variabel, har två nya mekanismer införts: typvariabler autooch deklaration decltype.

Cykla genom samlingen.

Efter många moderna språk introducerade C++ konstruktionen "loop through collection" av formuläret for (type &x: array) {...}. Här exekveras loopkroppen för varje element i samlingen array, och xi varje iteration kommer det att hänvisa till nästa element i samlingen. Samlingen kan vara en C-array eller vilken standardbiblioteksbehållare som helst som definierar iteratorer beginoch end.

Lambda uttryck.

Lagt till möjligheten att deklarera lambda-uttryck (namnlösa funktioner definierade vid applikationsstället), inklusive de som beror på externa variabler (stängningar). Lambda-uttryck kan tilldelas variabler och användas varhelst en funktion av motsvarande typ krävs, till exempel i standardbiblioteksalgoritmer.

Ändringar i beskrivningen av virtuella metoder.

En valfri modifierare har lagts till overridesom används i deklarationen av en metod som ersätter den virtuella metoden för den överordnade klassen. Beskrivningen av substitution med overrideorsakar en kontroll av förekomsten av metoden som ersätts i den överordnade klassen och för en matchning i metodsignaturerna. En modifierare har också lagts till final, som i Java, som förbjuder ytterligare ersättning av den metod som är markerad med den. En finalklass kan också deklareras - i det här fallet är det förbjudet att ärva nya klasser från den.

Tillagd möjlighet att beskriva variabelmallar .
Olika syntaktiska tillägg.

Ett nyckelord definieras för en konstant - en nollpekare: nullptr. Förändringar har gjorts i semantiken och, delvis, syntaxen för uppräkningar och fackföreningar. Möjligheten att skapa typsäkra uppräkningar har lagts till, ett antal strukturrestriktioner har tagits bort från förbund. Kompilatorn måste korrekt tolka programmets text med flera stängningsvinkelparenteser i rad (tidigare >>uppfattades sekvensen " " otvetydigt som en bitvis högerskiftningsoperation, därför krävdes det i notationen av kapslade mallkonstruktioner för att separera "större än"-tecknen med mellanslag eller radbrytningar).

Programexempel

Exempel #1

Detta är ett exempelprogram Hej världen! , som skriver ut ett meddelande till konsolen med standardbiblioteket och avslutar.

#include <iostream> använder namnutrymme std ; int main () { cout << "Hej världen!" << endl ; returnera 0 ; }

Exempel #2

Modern C++ låter dig lösa mer komplexa problem på ett enkelt sätt. Det här exemplet visar bland annat användningen av STL- behållare (Standard Template Library).

#include <iostream> // för att använda std::cout #include <vektor> // innehåller en dynamisk array #include <map> // innehåller ordboksdatatyp #inkludera <sträng> int main () { // Importera alla deklarationer i "std"-namnområdet till det globala namnområdet. använder namnutrymme std ; // Vi deklarerar en associativ behållare med strängnycklar och data som strängvektorer. map < sträng , vektor < sträng > > objekt ; // Lägg till ett par personer i den här associativa behållaren och ge dem några föremål. objekt [ "Anya" ]. push_back ( "halsduk" ); objekt [ "Dmitry" ]. push_back ( "biljetter" ); objekt [ "Anya" ]. push_back ( "valp" ); // Gå igenom alla objekt i behållaren för ( const auto & person : items ) { // person är ett par av två objekt: person.first är dess namn, // person.second är en lista över dess objekt (vektor av strängar) cout << person . första << " bär " << person . andra . storlek () << "artiklar" << endl ; } }

Det här exemplet importerar alla namn från std-namnområdet för enkelhets skull. I ett riktigt program rekommenderas inte detta, eftersom du kan stöta på namnkollisioner. Språket låter dig importera enskilda objekt:

#inkludera <vektor> int main () { använder std :: vektor ; vektor < int > min_vektor ; }

I C++ (som i C), om programexekveringen når slutet av funktionen main(), så motsvarar detta return 0;. Detta gäller inte för någon annan funktion än main().

Jämförelse med alternativa språk

Flera studier är kända där man försökte mer eller mindre objektivt jämföra flera programmeringsspråk, varav ett är C++. Särskilt:

I den vetenskapliga artikeln "Haskell vs. Ada vs. C++ vs. Awk vs. …” Paul Hudak och Mark Jones [22] rapporterar om studiet av ett antal imperativa och funktionella språk om lösningen av ett modellproblem för snabb prototypframställning av ett militärt GIS-system.
I den vetenskapliga artikeln "DSL implementation in metaocaml, template haskell, and C++" av fyra författare [23] , en metodisk studie av användningen av C++ och två funktionella språk som grundläggande verktyg för språkorienterad programmering med den generativa programmeringsmetoden genomförs .
Lutz Prehelt [24] övervägde sju språk (C, C++, Java, Perl, Python, Rexx och Tcl) i uppgiften att skriva ett enkelt program för att konvertera telefonnummer till ord enligt vissa regler.
I David Whelers artikel "Ada, C, C++ och Java vs. The Steelman [25] jämför språken Ada, C++, C, Java med dokumentet " Steelman " - en lista över språkkrav för militär utveckling av inbyggda system, som utvecklades av High-Level Language Committee of det amerikanska försvarsdepartementet 1978. Även om detta dokument är mycket föråldrat och inte tar hänsyn till många av de väsentliga egenskaperna hos moderna språk, visar jämförelsen att C++, när det gäller den uppsättning funktioner som efterfrågas i branschen, inte skiljer sig så mycket från språk som kan vara betraktas som dess verkliga konkurrenter.
En artikel av Matthew Forment och Michael Gillings [26] beskriver en studie [27] av implementering på sex språk – C++, C, C#, Java, Perl, Python – av tre specifika algoritmer som används inom bioinformatik: närmaste granne-metod , global sekvensanpassning ( Needleman Algorithm-Wunsha ) och tolka BLAST - resultat .

C++ och Ada

Ada-språket är nära C++ när det gäller dess uppsättning funktioner och användningsområden: det är ett kompilerat strukturspråk med en Simula-liknande objektorienterad tillägg (samma "Algol med klasser"-modell som i C++), statisk typning , generiska programmeringsverktyg, designade för utveckling av stora och komplexa mjukvarusystem. Samtidigt är det fundamentalt annorlunda i ideologi: till skillnad från C++ byggdes Ada utifrån tidigare noggrant utarbetade villkor från komplexa mjukvarutillverkare med ökade krav på tillförlitlighet, vilket satt avtryck på syntaxen och semantiken i språk.

Det finns få direkta jämförelser av Ada och C++ kodningseffektivitet. I artikeln [22] som nämns ovan resulterade lösningen av modellproblemet i Ada i en kod som var ungefär 30 % mindre i storlek (i rader) än i C++. Jämförelse av egenskaperna hos språken själva ges i många källor, till exempel listar Jim Rogers artikel om AdaHome [28] mer än 50 punkter av skillnader i egenskaperna hos dessa språk, varav de flesta är till förmån för Ada (fler funktioner, mer flexibelt beteende, mindre risk för fel). Även om många av uttalandena från Ada-anhängarna är kontroversiella, och några av dem är klart föråldrade, kan man generellt dra slutsatsen:

Ada-syntaxen är mycket strängare än C++. Språket kräver att man håller sig till disciplinen programmering, uppmuntrar inte till "programmeringsknep", uppmuntrar till att skriva enkel, logisk och lättförståelig kod som är lätt att underhålla.
Till skillnad från C++ är Ada extremt typsäker. Ett utvecklat system av typer tillåter, med förbehåll för disciplinen för deras deklaration och användning, att statiskt kontrollera riktigheten av dataanvändningen så fullständigt som möjligt och skyddar mot oavsiktliga fel. Automatiska typkonverteringar hålls till ett minimum.
Pekare i Ada är mycket strängare kontrollerade än i C++, och adressaritmetik är endast tillgänglig via ett separat systembibliotek.
Anpassade Ada-moduler liknar C++-mallar i funktionalitet, men ger bättre kontroll.
Ada har inbyggd modularitet och ett standardiserat separat kompileringssystem, medan C++ använder textfilinkludering och externa kompilerings- och byggkontroller.
Adas inbyggda multitasking inkluderar parallella uppgifter och deras kommunikationsmekanism (ingångar, möte, operatör select). I C++ implementeras allt detta endast på biblioteksnivå.
Ada är strikt standardiserad, vilket ger bättre portabilitet.

I en artikel av Stephen Zeiger från Rational Software Corporation [29] påstås det att utveckling i Ada generellt är 60 % billigare och resulterar i kod med 9 gånger färre defekter än i C. Även om dessa resultat inte kan överföras direkt till C++, är de fortfarande intressanta med tanke på att många av bristerna i C++ ärvs från C.

C++ och Java

Java kan inte betraktas som en fullständig ersättning för C++, det är designat som ett säkert språk med en låg ingångströskel för att utveckla anpassade applikationer med hög portabilitet [30] och är i grunden olämplig för vissa typer av applikationer som är utvecklade i C++. Men inom dess omfattning är Java en mycket verklig konkurrent till C++. Fördelarna med Java nämns vanligtvis som:

Säkerhet: inget stöd för pekare och adressaritmetik, automatisk minneshantering med skräpinsamling, inbyggt skydd mot vanliga C++ programfel som buffertspill eller arrayöverskridningar.
Närvaron av ett utvecklat system av moduler och separat kompilering, mycket snabbare och mindre felbenägen än förprocessorn och manuell montering av C ++.
Fullständig standardisering och exekvering i en virtuell maskin, en utvecklad miljö, inklusive bibliotek för grafik, användargränssnitt, tillgång till databaser och andra typiska uppgifter, som ett resultat - riktig multiplattform.
Inbyggd multithreading.
Java-objektsubsystemet, i mycket högre grad än C++, överensstämmer med den grundläggande OOP-principen " allt är ett objekt ". Gränssnitt gör att du kan tillhandahålla de flesta av fördelarna med multipelt arv utan att orsaka negativa effekter.
Reflektion är mycket mer avancerad än i C++ och låter dig faktiskt definiera och ändra strukturen på objekt medan programmet körs.

Samtidigt skapar användningen av sopsamlaren och den virtuella maskinen begränsningar som är svåra att övervinna. Java-program tenderar att vara långsammare, kräver betydligt mer minne, och den virtuella maskinen isolerar programmet från operativsystemet, vilket gör programmering på låg nivå omöjlig.

En empirisk studie [24] fann ingen signifikant skillnad i utvecklingshastigheten i C++ och Java. Studien [26] visade också att idén om en signifikant skillnad i hastigheten för program på dessa språk inte alltid är korrekt: i två av tre tester visade sig hastigheten på applikationer i Java och C++ vara jämförbar. Samtidigt är Java mer kortfattat - skillnaden i mängden kod var cirka 10-15%.

C++ och C

Den ursprungliga C fortsätter att utvecklas, många storskaliga projekt utvecklas i den: det är huvudspråket för att utveckla operativsystem, spelmotorerna för många dynamiska spel och ett stort antal applikationsapplikationer skrivs i det. Ett antal experter hävdar att att ersätta C med C++ inte ökar utvecklingseffektiviteten, utan leder till onödig komplikation av projektet, minskad tillförlitlighet och ökade underhållskostnader. Särskilt:

Enligt Linus Torvalds, "C++ provocerar att skriva ... en betydande mängd kod som inte är av någon grundläggande betydelse när det gäller programmets funktionalitet" [åsikter 3] .
OOP-stöd, mallar och STL är ingen avgörande fördel med C++, eftersom allt de används till också implementeras med C-verktyg. Samtidigt elimineras koduppblåsthet, och viss komplikation, som dessutom är långt ifrån nödvändig, kompenseras av större flexibilitet, enklare testning och bättre prestandaindikatorer.
Att automatisera minnesåtkomst i C++ ökar minneskostnaderna och saktar ner program.
Användningen av C++-undantag tvingar dig att följa RAII , leder till tillväxten av körbara filer, vilket saktar ner program. Ytterligare svårigheter uppstår i parallella och distribuerade program. Viktigt är att Googles kodningsstandard för C++ uttryckligen förbjuder användningen av undantag [31] .
C++-kod är svårare att förstå och testa, och felsökning försvåras genom användning av komplexa klasshierarkier med beteende och mallarv. Dessutom finns det fler buggar i C++-programmeringsmiljöer, både i kompilatorer och i bibliotek.
Många detaljer om kodbeteende specificeras inte av C++-standarden, vilket försämrar portabiliteten och kan orsaka svåra att hitta buggar.
Det finns betydligt fler skickliga programmerare i C än i C++.

Det finns inga övertygande bevis för att C++ är överlägset C vare sig när det gäller programmerares produktivitet eller programegenskaper. Även om det finns studier [32] som anger att C-programmerare spenderar cirka 30-40 % av den totala utvecklingstiden (exklusive felsökning) på minneshantering, när man jämför utvecklarnas totala produktivitet [22] , ligger C och C++ nära.

I lågnivåprogrammering görs många av de nya funktionerna i C++ otillämpliga på grund av ökad overhead: virtuella funktioner kräver dynamisk realadressberäkning (RVA), mallar leder till koduppsvällning och dåliga optimeringsmöjligheter, runtime-biblioteket (RTL) är mycket stor, och förkastandet av det berövar de flesta funktionerna i C ++ (om så bara på grund av att new/ operationer inte är tillgängliga delete). Som ett resultat måste programmeraren begränsa sig till den funktionalitet som ärvs från C, vilket gör det meningslöst att använda C ++:

… det enda sättet att ha bra, effektiv, lågnivå, bärbar C++ är att begränsa dig till alla de saker som är trivialt tillgängliga i C. Och att begränsa projektet till C kommer att innebära att folk inte kommer att kasta det, och att det kommer att finnas många programmerare tillgängliga som verkligen förstår lågnivåfunktionerna och inte överger dem på grund av den idiotiska "objektmodellen" dumheter.
… när effektivitet är av största vikt kommer "fördelarna" med C++ att vara ett stort misstag.

— Linus Torvalds , [33]

C++ och funktionella språk och skriptspråk

I ett experiment [22] visade skript och funktionella språk, i synnerhet Haskell , en 2-3-faldig vinst i programmeringstid och kodstorlek jämfört med C++-program. Å andra sidan visade sig C++-program vara lika mycket snabbare. Författarna erkänner att deras data inte utgör ett representativt urval och avstår från att dra kategoriska slutsatser.

I ett annat experiment [34] visade strikta funktionella språk ( Standard ML , OCaml ) en generell utvecklingsacceleration med en faktor 10 (främst på grund av tidig upptäckt av fel) med ungefär lika prestandaindikatorer (många kompilatorer i flera lägen var Begagnade).

I en studie av Lutz Prehelt [24] , baserad på resultaten från bearbetning av cirka 80 lösningar skrivna av frivilliga, erhölls följande slutsatser, särskilt:

Perl, Python, Rexx, Tcl gav dubbelt så hög utvecklingshastighet som C, C++ och Java, och den resulterande koden var också hälften så lång.
Program på skriptspråk förbrukade ungefär dubbelt så mycket minne som C/C++

Kritik

Om kritik av C++ i allmänhet

Oftast motsätter sig kritiker inte C++ till något annat specifikt språk, utan hävdar att förkastandet av att använda ett enda språk som har många brister till förmån för att bryta ner ett projekt i deluppgifter som kan lösas på olika språk som är mest lämpade för de gör utvecklingen betydligt mindre tidskrävande samtidigt som de förbättrar programkvalitetsindikatorerna [35] [36] . Av samma anledning kritiseras att upprätthålla kompatibilitet med C: om en del av uppgiften kräver funktioner på låg nivå är det mer rimligt att separera denna del i ett separat delsystem och skriva det i C.

Anhängare av C++ hävdar i sin tur att elimineringen av tekniska och organisatoriska problem med interspråklig interaktion genom att använda ett universellt språk istället för flera specialiserade är viktigare än förlusterna från ofullkomligheten i detta universella språk, det vill säga mycket bredd av C++-funktionsuppsättningen är en ursäkt för bristerna i varje enskild funktion; inklusive de nackdelar som ärvts från C motiveras av fördelarna med kompatibilitet (se ovan ).

Således anses samma egenskaper hos C ++ - volym, komplexitet, eklekticism och avsaknad av en specifik målnisch för tillämpning - av anhängare som "den största fördelen " och av kritiker - som " den största nackdelen ".

Kritik av enskilda element och begrepp

Beteendekontroll

Språkets ideologi förväxlar " beteendekontroll " med " effektivitetskontroll ": principen " du betalar inte för det du inte använder " föreslår att ge programmeraren fullständig kontroll över alla aspekter av programexekveringen på en ganska låg nivå är ett nödvändigt och tillräckligt villkor för att uppnå hög kodeffektivitet. Faktum är att detta inte är sant för några stora program: att påtvinga programmeraren optimering på låg nivå, vilket en högkvalitativ domänspecifik språkkompilator uppenbarligen kan utföra mer effektivt, leder bara till en ökning av mängden kod, en ökning i programmeringsarbetsintensitet och en minskning av kodförståelighet och testbarhet. Principen om "betala inte för det som inte används" ger alltså inte riktigt de önskade fördelarna i effektivitet, utan påverkar kvaliteten negativt.

Komponent- och objektorienterad programmering

Enligt Alan Kay är objektmodellen " Algol med klasser" som används i C++ sämre än modellen "allt är ett objekt" [37] som används i Objective-C när det gäller övergripande omfattning, återanvändning av kod , förståelighet, modifierbarhet och testbarhet. .

C++-arvsmodellen är komplex, svår att implementera och provocerar samtidigt skapandet av komplexa hierarkier med onaturliga relationer mellan klasser (till exempel arv istället för kapsling). Resultatet är skapandet av tätt kopplade klasser med vagt separerade funktionalitet. Till exempel, i [38] ges ett pedagogiskt och rekommendationsexempel på implementeringen av klassen "list" som en underklass till klassen "listelement", som i sin tur innehåller åtkomstfunktioner för andra listelement. Denna typrelation är matematiskt absurd och irreproducerbar i mer rigorösa språk. Ideologin för vissa bibliotek kräver manuell typkastning upp och ner i klasshierarkin ( static_castoch dynamic_cast), vilket bryter mot språkets typsäkerhet . Den höga viskositeten hos C++-lösningar kan kräva att stora delar av projektet återutvecklas med minimala förändringar senare i utvecklingsprocessen. Ett levande exempel på sådana problem finns i [35]

Som Ian Joyner [39] påpekar , sätter C++ felaktigt likhetstecken mellan inkapsling (det vill säga att placera data inuti objekt och separera implementering från gränssnitt) och implementeringsdöljning. Detta komplicerar åtkomsten till klassdata och kräver att dess gränssnitt implementeras nästan uteslutande genom accessorfunktioner (vilket i sin tur ökar mängden kod och komplicerar den).

Typmatchning i C++ definieras på nivån för identifierare, inte signaturer. Detta gör det omöjligt att ersätta komponenter baserade på gränssnittsmatchning, varför införandet av ny funktionalitet implementerad på biblioteksnivå i systemet kräver manuell modifiering av befintlig kod [40] . Som Linus Torvalds [33] påpekar , i C++, "Kod verkar abstrakt bara så länge den inte behöver ändras."

Kritik av C++ ur OOPs synvinkel ges i [39] .

Metaprogrammering

C++:s generativa metaprogrammering är mall- och förprocessorbaserad , arbetskrävande och begränsad i omfattning. C++-mallsystemet är faktiskt en kompileringstidsvariant av det primitiva funktionella programmeringsspråket . Detta språk har nästan ingen överlappning med C++ i sig, varför potentialen för tillväxt i komplexiteten av abstraktioner är begränsad. Program som använder C++-mallar har extremt dålig förståelse och testbarhet, och malluppackning genererar i sig ineffektiv kod, eftersom mallspråket inte ger några medel för optimering (se även avsnittet #Computational efficiency ). Inbäddade domänspecifika språk som implementeras på detta sätt kräver fortfarande kunskap om själva C++, vilket inte ger en fullvärdig arbetsfördelning. Således är förmågan för C++ att utöka kapaciteten för C++ själv ganska begränsad [41] [42] .

Cross-platform

Att skriva bärbar C++-kod kräver en hel del skicklighet och erfarenhet, och "slarvig" C++-kod är högst sannolikt icke-portabel [43] . Enligt Linus Torvalds , för att uppnå C++-portabilitet som liknar C, måste programmeraren begränsa sig till C++-funktionerna som ärvts från C [33] . Standarden innehåller många element definierade som "implementationsdefinierade" (till exempel varierar storleken på pekare till klassmetoder i olika kompilatorer från 4 till 20 byte [44] ), vilket försämrar portabiliteten för program som använder dem.

Språkstandardiseringens direktiva karaktär , ofullständig bakåtkompatibilitet och inkonsekvens av kraven för olika versioner av standarden leder till problem med att porta program mellan olika kompilatorer och till och med versioner av samma kompilatorer .

Brist på möjligheter

Reflekterande metaprogrammering Introspektion i C++ implementeras separat från huvudtypsystemet, vilket gör det nästan värdelöst. Det största som kan erhållas är parametriseringen av beteendet på en tidigare känd uppsättning alternativ. Detta förhindrar användningen av C++ i de flesta metoder för implementering av artificiell intelligens . Funktionell programmering Explicit stöd för funktionell programmering finns endast i C++0x- standarden , tidigare fylldes luckan av bibliotek ( Loki , Boost ) som använder mallspråket, men deras kvalitet är betydligt sämre än lösningar inbyggda i funktionella språk [förklaringar] 1] , såväl som kvaliteten på implementeringar av C++-funktioner (som OOP) genom funktionella språk. FP-funktionerna implementerade i C++ tillåter inte användningen av optimeringstekniker som är inneboende i funktionell programmering , utan är begränsade till att anropa funktionella bibliotek och implementera individuella metoder. Detta har liten eller ingen fördel i programdesign (se Curry-Howard-korrespondens ).

Överflödiga och farliga möjligheter

Inbyggda förbikopplingar

Språket innehåller verktyg som tillåter programmeraren att bryta mot den programmeringsdisciplin som ges i ett visst fall. En modifierare constställer till exempel in egenskapen för tillståndets oföränderlighet för ett objekt, men modifieraren mutableär utformad specifikt för att tvinga tillstånd att ändra tillståndet inuti ett konstobjekt, det vill säga att bryta mot restriktionen. Dessutom är det tillåtet att dynamiskt ta bort ett attribut constfrån ett konstant objekt och omvandla det till ett L-värde. Närvaron av sådana funktioner i språket gör försök att formellt verifiera koden meningslösa, och användningen av begränsningar för optimering är omöjlig.

Okontrollerad makrosubstitution

C-makrosubstitutionsfaciliteterna ( #define) är lika kraftfulla som farliga. De behålls i C++ trots att C++, för alla uppgifter som de tillhandahållits för i C, tillhandahållit mer strikta och specialiserade faciliteter - mallar, funktionsöverbelastning, inline-funktioner, namnrymder, mer avancerad skrivning, utvidgning av applikationen const-modifieraren , etc. Det finns många potentiellt farliga makron i standardbiblioteken som ärvts från C [45] . Mallmetaprogrammering kombineras också ibland med användning av makrosubstitution för att tillhandahålla sk. " syntaktisk socker ".

Överbelastningsproblem

C++-principerna för funktion och operatörsöverbelastning leder till betydande kodduplicering. Ursprungligen avsett att introducera så kallat " syntaktisk socker ", uppmuntrar operatörsöverbelastning i C++ det okontrollerade beteendet hos elementära operatörer för olika typer. Detta ökar dramatiskt risken för fel, särskilt eftersom det är omöjligt att införa en ny syntax och ändra den befintliga (till exempel skapa nya operatorer eller ändra prioriteringar eller associativitet), även om syntaxen för standard C++ operatorer är tillräcklig för att semantik av långt ifrån alla typer som kan behöva införas i programmet. Vissa problem skapas av möjligheten till lätt överbelastning av operatörerna / , vilket kan generera extremt lömska och svårupptäckta fel. Samtidigt utförs inte vissa intuitivt förväntade operationer (rensning av dynamiska objekt i händelse av att slänga undantag) i C++, och en betydande del av överbelastade funktioner och operatörer anropas implicit (typcasting, skapande av tillfälliga instanser av klasser, etc. .). Som ett resultat blev verktyg som ursprungligen var avsedda att göra program tydligare och förbättra utveckling och underhåll ännu en källa till onödigt komplicerad och opålitlig kod. newdelete

Beräkningseffektivitet

Den resulterande mängden körbar kod

Användningen av C++-mallar är parametrisk polymorfism på källkodsnivå, men när den översätts övergår den till ad hoc-polymorfism (dvs funktionsöverbelastning), vilket leder till en betydande ökning av mängden maskinkod jämfört med språk som har ett system av äkta polymorft typ (avkomlingar till ML ). För att minska storleken på maskinkoden försöker de att automatiskt bearbeta källkoden före steget att linda upp mallar [46] [47] . En annan lösning skulle kunna vara möjligheten att exportera mallar, som standardiserades redan 1998, men den är inte tillgänglig i alla kompilatorer, eftersom det är svårt att implementera [48] [49] [åsikter 4] och att importera C++-mallbibliotek i språk med en väsentligt annorlunda C++-semantik skulle det fortfarande vara värdelöst. Förespråkare för C++ bestrider omfattningen av koduppblåsthet som överdriven [50] , och ignorerar till och med det faktum att i C översätts parametrisk polymorfism direkt, det vill säga utan att duplicera funktionskroppar alls. Samtidigt tror anhängare av C++ att parametrisk polymorfism i C är farlig – det vill säga farligare än övergången från C till C++ (motståndare till C++ hävdar motsatsen – se ovan).

Optimeringspotential

På grund av det svaga typsystemet och överflöd av biverkningar blir det extremt svårt att likvärdigt konvertera program, och därför bädda in många optimeringsalgoritmer i kompilatorn, såsom automatisk parallellisering av program , borttagning av vanliga underuttryck , λ-lyftning, anrop till procedurer med fortsättningspassering , superkompilering , etc. Som ett resultat begränsas den faktiska effektiviteten av C++-program av programmerarnas färdigheter och de ansträngningar som investeras i ett visst projekt, och en "slarvig" implementering kan vara betydligt sämre i effektivitet än "slarvig" ”-implementeringar på språk på högre nivå, vilket bekräftas av jämförande tester av språk [34] . Detta är en betydande barriär mot användningen av C++ i datautvinningsindustrin .

Effektiv minneshantering

Ansvaret för effektiv minneshantering faller på utvecklarens axlar och beror på utvecklarens kompetens. För automatisk minneshantering i C ++, den sk. "smarta pekare", manuell minneshantering minskar effektiviteten hos programmerarna själva (se avsnittet Effektivitet ) . Många implementeringar av sophämtning , såsom statisk slutledning av regioner , är inte tillämpliga för C++-program (mer exakt, detta kräver implementering av en ny språktolk ovanpå C++-språket, vilket skiljer sig mycket från C++ både i de flesta objektiva egenskaper och i allmän ideologi) på grund av behovet av direkt tillgång till AST .

Effektivitet

Korrelationen av prestandafaktorer med utvecklingskostnader, såväl som den allmänna disciplinen och programmeringskulturen som odlas i programmeringsgemenskapen, är viktiga för kunder som väljer ett språk (och följaktligen föredrar detta utvecklarspråk) för genomförandet av sina projekt, såväl som för människor som börjar lära sig programmering, speciellt med avsikten att programmera för dina egna behov.

Programmeringskvalitet och kultur

Principen för C++ " att inte påtvinga en" bra "programmeringsstil " strider mot det industriella förhållningssättet till programmering, där den ledande rollen spelas av kvaliteten på programvaran och möjligheten att underhålla koden inte bara av författaren , och för vilka språk som minimerar inflytandet av den mänskliga faktorn är att föredra , det vill säga bara " påtvinga en "bra" programmeringsstil ", även om sådana språk kan ha en högre ingångströskel.

Det finns en åsikt att preferensen för att använda C++ (med möjlighet att välja alternativa språk) negativt kännetecknar en programmerares professionella egenskaper. Specifikt säger Linus Torvalds att han använder kandidaternas positiva åsikter om C++ som ett bortfallskriterium [åsikter 3] :

C++ är ett hemskt språk. Vad som gör det ännu mer fruktansvärt är det faktum att många programmerare som inte är läskunniga använder det... Ärligt talat, även om det inte finns någon anledning att välja C annat än att hålla C++-programmerare borta, skulle det bara vara en tillräckligt bra anledning att använda C.
…Jag har kommit fram till att jag verkligen skulle föredra att sparka ut alla som skulle föredra att utveckla ett projekt i C++ snarare än i C, så att den här personen inte förstör projektet där jag är involverad.

— Linus Torvalds , [33] Åtgärda en defekt

Den kontinuerliga utvecklingen av språket uppmuntrar (och ibland tvingar) programmerare att ändra redan felsökt kod om och om igen - detta ökar inte bara kostnaderna för utveckling, utan medför också risken att introducera nya fel i den felsökta koden. I synnerhet, även om bakåtkompatibilitet med C ursprungligen var en av kärnprinciperna för C++, har C sedan 1999 upphört att vara en delmängd av C++, så att felsökt C-kod inte längre kan användas i ett C++-projekt utan modifiering.

Komplexitet för sin egen skull

C++ definieras av dess apologeter som "den mest kraftfulla" just för att den är fylld av farliga, ömsesidigt motstridiga egenskaper. Enligt Eric Raymond gör detta språket i sig till en grund för personlig självbekräftelse av programmerare, vilket gör utvecklingsprocessen till ett mål i sig:

Programmerare är ofta flamboyanta individer som är stolta över … sin förmåga att hantera komplexitet och hantera abstraktioner med skicklighet. Ofta tävlar de med varandra och försöker ta reda på vem som kan skapa "de mest invecklade och vackra komplexiteterna." ... rivaler tror att de måste konkurrera med andras "dekorationer" genom att lägga till sina egna. Ganska snart blir "massiv tumör" industristandard, och alla kör stora, buggiga program som inte ens deras skapare kan tillfredsställa.
…
… det här tillvägagångssättet kan hamna i problem om programmerare gör enkla saker på komplexa sätt, helt enkelt för att de känner till dessa sätt och vet hur de ska använda dem.

— Eric Raymond vid [51] Sabotage

Fall har noterats när slarviga programmerare, som använder det starka sammanhangsberoendet av C ++ och avsaknaden av förmågan att spåra makrodefinitioner av kompilatorn, saktade ner utvecklingen av projektet genom att skriva en eller två extra, korrekt från kompilatorns punkt. visning, rader med kod, men införa ett svårt att upptäcka spontant manifesterat fel på deras bekostnad. Till exempel:

#define if(a) if(rand())

#definiera ji

På språk med bevisad korrekthet , även med avancerade makrofaciliteter, är det omöjligt att göra skada på detta sätt.

Otillförlitlig produkt

Ett orimligt överflöd av biverkningar, i kombination med bristande kontroll från språkets runtime-system och ett system av svag typ, gör C++-program benägna att få oförutsägbara dödskrascher (de välkända kraschen med meddelanden som "Access violation", "Ren virtuell funktion call" eller "Programmet utförde en olaglig operation och kommer att stängas"), vilket utesluter användningen av C++ med höga krav på feltolerans. Dessutom ökar det varaktigheten av själva utvecklingsprocessen [34] .

Projektledning

Faktorerna som anges ovan gör komplexiteten i C++-projektledning till en av de högsta inom mjukvaruutvecklingsbranschen.

James Coggins, en fyraårig krönikör för The C++ Report , förklarar:
Problemet är att OOP-programmerare har experimenterat med incestuösa applikationer och strävat efter en låg abstraktionsnivå. Till exempel byggde de klasser som "länkad lista" istället för "användargränssnitt" eller "strålningsstråle" eller "finita elementmodell". Tyvärr gör stark typkontroll, som hjälper C++-programmerare att undvika buggar, det också svårare att bygga stora objekt från små.

— F. Brooks , Den mytiska man-månaden

Inflytande och alternativ

Den enda direkta ättlingen till C++ är D-språket , avsett att vara en omarbetning av C++ för att lösa dess mest uppenbara problem. Författarna övergav kompatibiliteten med C, behöll syntaxen och många av de grundläggande principerna för C++ och introducerade funktioner i språket som är karakteristiska för nya språk. D har ingen förprocessor, inga header-filer, inget multipelt arv, utan ett modulsystem, gränssnitt, associativa arrayer, stöd för unicode i strängar, skräpinsamling (med bibehållen möjlighet till manuell minneshantering), inbyggd multithreading, typinferens , explicit deklaration av rena funktioner och oföränderliga värden. Användningen av D är mycket begränsad, den kan inte betraktas som en riktig konkurrent till C++.

Den äldsta konkurrenten till C++ i lågnivåuppgifter är Objective-C , också byggt på principen att kombinera C med en objektmodell, endast objektmodellen ärvs från Smalltalk . Objective-C, liksom dess ättling Swift , används ofta för mjukvaruutveckling för macOS och iOS.

Ett av de första alternativen till C++ inom applikationsprogrammering var Java-språket . Det anses ofta felaktigt vara en direkt ättling till C++; i själva verket ärvs Javas semantik från Modula-2- språket , och den grundläggande semantiken för C++ går inte att spåra i Java. Med tanke på detta, och släktforskningen av språk (Modula-2 är en ättling till Simula , som C++, men det är inte C), kallas Java mer korrekt för " andra kusin " till C++, snarare än " arvingen ". Detsamma kan sägas om C# -språket , även om andelen affinitet med C++ är något högre än för Java.

Ett försök att kombinera säkerheten och utvecklingshastigheten för Java och C# med funktionerna i C++ var Managed C++ dialekten (senare C++/CLI ). Det utvecklades av Microsoft främst för att porta befintliga C++-projekt till Microsoft .NET-plattformen. Program körs under CLR och kan använda hela utbudet av .NET-bibliotek, men det finns ett antal begränsningar för användningen av C++-funktioner, vilket effektivt reducerar C++ till C#. Denna dialekt har inte fått bred erkännande och används främst för att länka bibliotek skrivna i ren C++ med C #-applikationer.

Ett alternativt sätt att utveckla C-språket är att kombinera det inte med objektorienterad programmering, utan med applikativ programmering , det vill säga att förbättra abstraktionen, rigoriteten och modulariteten hos lågnivåprogram genom att tillhandahålla förutsägbart beteende och referenstransparens . Exempel på arbete i denna anda är språken BitC , Cyclone och Limbo . Även om det också finns framgångsrika försök att använda FP i realtidsproblem utan integration med C-verktyg [52] [53] [54] , fortfarande för närvarande (2013) i lågnivåutveckling, användningen av C-verktyg i viss utsträckning har ett bättre förhållande mellan arbetsintensitet och effektivitet. Mycket ansträngning har lagts ner på Python och Lua av Python och Lua- utvecklarna för att säkerställa att dessa språk används av C++-programmerare, så av alla språk som är nära besläktade med FP, är de de som oftast noteras att användas tillsammans med C++ i samma projekt. De viktigaste kontaktpunkterna mellan C++ och FP är bindningarna av wxWidgets och Qt- bibliotek utvecklade i C++ med en C++-specifik ideologi till Lisp , Haskell och Python (i de flesta fall görs bindningar till funktionella språk för bibliotek skrivna i C eller andra funktionella språk).

Ett annat språk som anses vara en konkurrent till C++ är Nemerle , som är resultatet av ett försök att kombinera Hindley-Milners typmodell och en makroundergrupp av Common Lisp med C# [55] . I samma veva är Microsofts F# , en dialekt av ML anpassad för .NET-miljön.

Ett försök att skapa en industriell ersättning för C/C++ var programmeringsspråket Go som utvecklades av Google 2009 . Författarna till språket påpekar direkt att motivet för dess skapande var bristerna i utvecklingsprocessen orsakade av särdragen hos C- och C++-språken [56] . Go är ett kompakt, okomplicerat imperativt språk med C-liknande syntax, ingen förprocessor, statisk typning, stark typning, paketeringssystem, automatisk minneshantering, några funktionella funktioner, ekonomiskt byggt OOP-undersystem utan stöd för implementeringsarv, men med gränssnitt och duck typing , inbyggd multithreading baserad på koroutiner och rör (a-la Occam ). Språket är placerat som ett alternativ till C++, det vill säga, först och främst, ett medel för grupputveckling av mycket komplexa mycket komplexa datorsystem, inklusive distribuerade sådana, som vid behov tillåter lågnivåprogrammering.

I samma ekologiska nisch med C/C++ finns Rust, utvecklad 2010 och underhållen av Mozilla Corporation , fokuserad på säker minneshantering utan användning av en sophämtare . I synnerhet tillkännagavs planer på att delvis ersätta C/C++ med Rust 2019 av Microsoft [57] .

Se även

Anteckningar

↑ ISO/IEC 14882:2020 Programmeringsspråk - C++ - 2020.
↑ Gubina G. G. Datorengelska . Del I. Datorengelska. Del I. Handledning . — S. 385. Arkiverad 3 december 2017 på Wayback Machine
↑ Bjarne Stroustrups FAQ . Bjarne Stroustrup (1 oktober 2017). - "Namnet C++ (uttalas "se plus plus")". Datum för åtkomst: 4 december 2017. Arkiverad från originalet 6 februari 2016.
↑ Schildt, 1998 .
↑ 1 2 Stroustrup, 1999 , 2.1. Vad är C++?, sid. 57.
↑ Stanley Lippman, Pure C++: Hej, C++/CLI Arkiverad 6 juni 2011 på Wayback Machine
↑ 1 2 Stroustrup, 1999 , 1.4. Historiska anmärkningar, sid. 46.
↑ C++-Standards . Hämtad 14 november 2010. Arkiverad från originalet 20 november 2010. (obestämd)
↑ Bjarne Stroustrup. C++ Ordlista (inte tillgänglig länk) . Hämtad 8 juni 2007. Arkiverad från originalet 1 maj 2011. (obestämd)
↑ Var hittar jag de aktuella C- eller C++-standarddokumenten? http://stackoverflow.com/questions/81656/where-do-i-find-the-current-c-or-c-standard-documents Arkiverad 29 november 2015 på Wayback Machine
↑ Se en lista på http://en.cppreference.com/w/cpp/experimental Arkiverad 18 november 2015 på Wayback Machine besökt 5 januari 2015.
↑ Yandex organiserar en arbetsgrupp för att standardisera C++-språket . ICS Media. Hämtad 29 augusti 2018. Arkiverad från originalet 29 augusti 2018. (ryska)
↑ Stroustrup, Designen och utvecklingen av C++, 2007 .
↑ ISO/IEC 14882:1998, avsnitt 6.4, klausul 4: "Värdet på ett villkor som är en initialiserad deklaration i en annan sats än en switchsats är värdet på den deklarerade variabeln implicit omvandlad till bool... Värdet av ett villkor dvs ett uttryck är uttryckets värde, implicit omvandlat till boolför andra påståenden än switch; om den omvandlingen är dåligt utformad, är programmet dåligt utformat".
↑ STLport: Välkommen! . Hämtad 26 juli 2007. Arkiverad från originalet 7 juni 2018. (obestämd)
↑ Stroustrup, 1999 , 1.6.
↑ std::vector - cppreference.com . Datum för åtkomst: 28 november 2015. Arkiverad från originalet 27 november 2015. (obestämd)
↑ std::realloc - cppreference.com . Tillträdesdatum: 28 november 2015. Arkiverad från originalet 4 december 2015. (obestämd)
↑ B. Stroustrup intervju med LinuxWorld.com . Hämtad 4 januari 2013. Arkiverad från originalet 27 januari 2013. (obestämd)
↑ B. Stroustrups intervju med tidningen System Administrator . Datum för åtkomst: 4 januari 2013. Arkiverad från originalet den 9 februari 2013. (obestämd)
↑ CNews: Exklusiv intervju med skaparen av programmeringsspråket C++ (länk ej tillgänglig) . Hämtad 1 november 2019. Arkiverad från originalet 17 mars 2015. (obestämd)
↑ 1 2 3 4 Ett experiment i mjukvaruprototypproduktivitet. Paul Hudak, Mark P. Jones. Yale University, Institutionen för datavetenskap, New Haven, CT 06518. 4 juli 1994.
↑ K. Czarnecki, J. O'Donnell, J. Striegnitz, W. Taha. DSL-implementering i metaocaml, mall haskell och C++ . — University of Waterloo, University of Glasgow, Research Centre Julich, Rice University, 2004. Arkiverad från originalet den 7 april 2022. .
Citat: C++ Template Metaprogramming lider av ett antal begränsningar, inklusive portabilitetsproblem på grund av kompilatorbegränsningar (även om detta har förbättrats avsevärt under de senaste åren), brist på felsökningsstöd eller IO under mallinstansiering, långa kompileringstider, långa och obegripliga fel , dålig läsbarhet för koden och dålig felrapportering.
↑ 1 2 3 Lutz Prechelt ( Universität Karlsruhe ). En empirisk jämförelse av C, C++, Java, Perl, Python, Rexx och Tcl för ett sök-/strängbearbetningsprogram ( pdf) Freie Universität Berlin (14 mars 2000). Hämtad 20 november 2019. Arkiverad från originalet 3 januari 2020.
↑ Ada, C, C++ och Java vs. The Steelman" David A. Wheeler juli/augusti 1997 (länk ej tillgänglig) . Hämtad 23 mars 2019. Arkiverad från originalet 23 mars 2019. (obestämd)
↑ 1 2 "En jämförelse av vanliga programmeringsspråk som används i bioinformatik" . Hämtad 2 september 2021. Arkiverad från originalet 2 september 2021. (obestämd)
↑ Jämförelse av programmeringsspråk vid implementering av bioinformatikalgoritmer - beskrivning av experimentet. . Hämtad 2 september 2021. Arkiverad från originalet 2 september 2021. (obestämd)
↑ Jämförelse av Ada- och C++-funktioner (sv) . Hämtad 23 mars 2019. Arkiverad från originalet 23 mars 2019. (obestämd)
↑ Stephen Zeigler, Jämföra utvecklingskostnader för C och Ada. Arkiverad från originalet den 4 april 2007.
↑ 1.2 Designmål för programmeringsspråket Java™ . Java -språkmiljön . Oracle (1 januari 1999) . Hämtad 14 januari 2013. Arkiverad från originalet 23 januari 2013.
↑ Stilguide för Google C++. Undantag. . Hämtad 31 mars 2019. Arkiverad från originalet 16 mars 2019. (obestämd)
↑ Boehm H. Fördelar och nackdelar med den konservativa sophämtningen . Arkiverad från originalet den 24 juli 2013.
(länk från Raymond, Eric . The Art of Unix Programming. - 2005. - s. 357. - 544 s. - ISBN 5-8459-0791-8 . )
↑ 1 2 3 4 Öppna korrespondens gmane.comp.version-control.git daterad 09/06/2007 (otillgänglig länk) . Hämtad 5 augusti 2013. Arkiverad från originalet 9 december 2013. (obestämd)
↑ 1 2 3 Ray Tracer Language Comparison (riktmärke för programmeringsspråk - ffconsultancy.com/languages/ray_tracer/)
↑ 12 Martin Ward . Språkorienterad programmering . - Datavetenskapliga institutionen, Science Labs, 1994. Arkiverad från originalet den 4 mars 2016.
↑ Paul Hudak. Modulära domänspecifika språk och verktyg. — Institutionen för datavetenskap, Yale University.
↑ Alan Kays definition av objektorienterad programmering (länk inte tillgänglig) . Tillträdesdatum: 5 augusti 2013. Arkiverad från originalet 24 augusti 2013. (obestämd)
↑ Schildt, C++ Theory and Practice, 1996 , sid. 64-67.
↑ 12 Ian Joyner . En kritik av C++ och programmering och språktrender på 1990-talet - 3:e upplagan . - upphovsrätt och publikationslista . Arkiverad från originalet den 25 november 2013.
↑ Paulson, Lawrence C. ML för den arbetande programmeraren, 2:a upplagan. - University of Cambridge: Cambridge University Press, 1996. - ISBN 0-521-57050-6 (inbunden), 0-521-56543-X (pocket). , c. 271-285
↑ Walid Taha. Domänspecifika språk . — Institutionen för datavetenskap, Rice University. Arkiverad från originalet den 24 oktober 2013.
↑ Lugovsky VS Använda en hierarki av domänspecifika språk i design av komplexa mjukvarusystem . - 2008. Arkiverad den 10 augusti 2016.
↑ Andrey Karpov. 20 fallgropar med att porta C++-kod till en 64-bitars plattform . - RSDN Magazine #1-2007, 2007. Arkiverad från originalet den 2 april 2015.
↑ Don Clugston, CSG Solar Pty Ltd (Översatt av Denis Bulichenko). Medlemsfunktionspekare och den snabbaste C++-implementeringen av delegater . — RSDN Magazine #6-2004. Arkiverad från originalet den 19 oktober 2013.
↑ Stroustrup, Programmering: C++ Principles and Practice, 2001
↑ Dave Gottner. Mallar utan koduppblåsning . — Dr. Dobb's Journal , januari 1995. Arkiverad från originalet den 7 juni 2008.
↑ Adrian Stone. Minimera koduppblåsning: Redundant mallinstansering (nedlänk) . Game Angst (22 september 2009). Datum för åtkomst: 19 januari 2010. Arkiverad från originalet den 8 december 2011. (obestämd)
↑ Ört Sutter . C++ Överensstämmelse Roundup . — Dr. Dobb's Journal , januari 2001. Arkiverad från originalet den 15 januari 2009.
↑ Finns det några kompilatorer som implementerar allt detta? (inte tillgänglig länk) . comp.std.c++ vanliga frågor / Språket C++ . Comeau Computing (10 december 2008). Datum för åtkomst: 19 januari 2010. Arkiverad från originalet den 30 april 2009. (obestämd)
↑ Scott Meyers . Code Bloat på grund av mallar . comp.lang.c++.modererad . Usenet (16 maj 2002). Hämtad: 19 januari 2010. (obestämd)
↑ Eric Raymond . Konsten att programmera för Unix = The Art of Unix. - Williams, 2005. - ISBN 5-8459-0791-8 .
↑ Zhanyong Wan och Paul Hudak. Händelsedriven FRP // Institutionen för datavetenskap, Yale University. Arkiverad från originalet den 16 augusti 2011.
↑ Walid Taha (engelska) (länk ej tillgänglig) . School of Engineering Rice University . Hämtad 20 november 2019. Arkiverad från originalet 13 augusti 2013.
↑ MLKit (nedlänk) . Hämtad 30 juli 2013. Arkiverad från originalet 17 september 2013. (obestämd)
↑ Chistyakov Vlad aka VladD2. Syntaktisk socker eller C++ vs. Nemerle :) // RSDN Magazine #1-2006. - 2006-05-24. Arkiverad från originalet den 13 december 2013.
↑ Gå till Google: Language Design in the Service of Software Engineering . talks.golang.org. Hämtad 19 september 2017. Arkiverad från originalet 25 januari 2021. (obestämd)
↑ Catalin Cimpanu. Microsoft för att utforska med Rust . ZDNet (17 juni 2019). Hämtad 26 september 2019. Arkiverad från originalet 15 oktober 2019.

Åsikter

↑ Popularitet för programmeringsspråk (otillgänglig länk) (2009). Tillträdesdatum: 16 januari 2009. Arkiverad från originalet 16 januari 2009. (obestämd)
↑ TIOBE Programming Community Index (länk ej tillgänglig) (2009). Hämtad 6 maj 2009. Arkiverad från originalet 4 maj 2009. (obestämd)
↑ 1 2 Öppna korrespondens gmane.comp.version-control.git daterad 09/06/2007 (otillgänglig länk) . Hämtad 5 augusti 2013. Arkiverad från originalet 9 december 2013. (obestämd)
↑ vanDooren. Dagens C++ nyckelord: export (inte tillgänglig länk) . Blogs@MSMVPs (24 september 2008). "Exportnyckelordet är lite som Higgs-bosonen i C++. Teoretiskt existerar den, den beskrivs av standarden, och ingen har sett den i naturen. … Det finns 1 C++-kompilatorfront-end i världen som faktiskt stöder det.” Tillträdesdatum: 19 januari 2010. Arkiverad från originalet den 6 maj 2009. (obestämd)

Förklaringar

↑ Marknadsförs till exempel Boost.Lambdasom en lambdafunktion, men C++ implementerar inte kyrkans lambdakalkyl i sin helhet; imitation av kombinatorer genom ett mallspråk är för svårt att förvänta sig att de används i praktiken; fortsättningar som ärvts från C anses icke-ideomatiska och farliga, och deras implementering genom mallspråket är omöjligt; dessutom är det inte möjligt att använda λ-lifting för att optimera C++ – så det är faktiskt Boost.Lambda bara en anonym funktion, inte ett objekt i lambdakalkylen.

Litteratur

Björn Stroustrup . C++ programmeringsspråk = C++ programmeringsspråket / Per. från engelska. - 3:e uppl. - St Petersburg. ; M .: Nevskij-dialekt - Binom , 1999. - 991 sid. - 3000 exemplar. — ISBN 5-7940-0031-7 (Nevsky-dialekt), ISBN 5-7989-0127-0 (Binom), ISBN 0-201-88954-4 (engelska).
Björn Stroustrup . C++ programmeringsspråk. Special Edition = Programmeringsspråket C++. specialutgåva. - M. : Binom-Press, 2007. - 1104 sid. — ISBN 5-7989-0223-4 .
Björn Stroustrup . Programmering: Principer och praxis med C++, Reviderad upplaga = Programmering: Principer och praxis med C++. — M .: Williams , 2011. — S. 1248. — ISBN 978-5-8459-1705-8 .
Björn Stroustrup . Design och utveckling av C++ = Designen och utvecklingen av C++. - St Petersburg. : Peter, 2007. - 445 sid. — ISBN 5-469-01217-4 .
Björn Stroustrup . C++ programmeringsspråk. Kort kurs. - 2019. - 320 sid. - ISBN 978-5-907144-12-5 .
Björn Stroustrup . Programmering: principer och praxis med C++. - 2016. - 1328 sid. - ISBN 978-5-8459-1949-6 .

Siddhartha Rao. Teach Yourself C++ in One Hour a Day, 7th Edition (C++11) = Sams Teach Yourself C++ in One Hour a Day, 7th Edition. - M. : "Williams" , 2013. - 688 sid. — ISBN 978-5-8459-1825-3 .
Stephens D.R.C ++. Samling av recept. - KUDITS-PRESS, 2007. - 624 sid. - ISBN 5-91136-030-6 .
Stephen Prata. C++ programmeringsspråk (C++11). Föreläsningar och övningar = C++ Primer Plus, 6:e upplagan (utvecklarens bibliotek). - 6:e uppl. — M. : Williams , 2012. — 1248 sid. - ISBN 978-5-8459-1778-2 .
Stephen Prata. Programmeringsspråk C. Föreläsningar och övningar. — M. : Williams , 2015. — 928 sid. - ISBN 978-5-8459-1950-2 .
Ivor Horton. Visual C ++ 2010: hela kursen = Ivor Horton's Beginning Visual C ++ 2010. - M . : Dialectics , 2010. - S. 1216. - ISBN 978-5-8459-1698-3 .
Herbert Schildt . Den fullständiga referensen till C++ = C++: Den fullständiga referensen. - 4:e uppl. - M .: Williams , 2011. - S. 800. - ISBN 978-5-8459-0489-8 .
Herbert Schildt . Teori och praktik för C++ = Schildts Expert C++. - St Petersburg. : BHV - St. Petersburg, 1996. - ISBN 0-07-882209-2 , 5-7791-0029-2.
PJ Plauger. Gissningsspel för programmeringsspråk - Om C++ är svaret, vad är frågan? // Dr. Dobbs tidning . - Oktober 1993.
Unix-hatarnas handbok (obestämd) . - International Data Group , 1994.
Ian Joyner. En kritik av C++ och programmerings- och språktrender på 1990-talet - 3:e upplagan // copyright och publikationslista . — 1996.
Scott Meyers. Effektivt modernt C++: 42 rekommendationer för användning av C++11 och C++14 = Effektivt modernt C++: 42 specifika sätt att förbättra din användning av C++11 och C++14 / Per. från engelska. - Williams, 2016. - 304 sid. - ISBN 978-5-8459-2000-3 .
Herbert Schildt . C++ The Complete Reference Third Edition. - Osborne McGraw-Hill, 1998. - ISBN 978-0-07-882476-0 .
Jeremy A. Hansen The Rook's Guide to C++ (En Creative Commons-licensierad lärobok) .

Länkar

isocpp.org ( Engelska) - officiell C++-webbplats

arbetsdokument från standardiseringskommittén för år 2009

Björn Stroustrup. CppCoreGuidelines C ++ Core Guidelines är en uppsättning beprövade riktlinjer, regler och bästa praxis om kodning i C++
Björn Stroustrup. Kort översikt av C++ 0x
comp.lang.c++ modererad
Yossi Kreinin. C++ FQA Lite . (obestämd)
Linus Torvalds . Konvertera builin-mailinfo.c för att använda The Better String Library (nedlänk) . Gmane forum (6 september 2007). Arkiverad från originalet den 9 december 2013. (obestämd)

Ordböcker och uppslagsverk

I bibliografiska kataloger
BNE : XX540250 BNF : 12139768z GND : 4193909-8 J9U : 987007539277905171 LCCN : sh87007505 NKC : ph116956 SUDOC : 029859778

Programmeringsspråk
Berättelse Kronologi
Ada ALGOL assemblerare APL GRUNDLÄGGANDE C C++ C# D Delphi COBOL Erlang F# Vidare Fortran gå Haskell Java JavaScript Julia Kotlin Läspa Lua MATLAB Mål-C Ocaml Pascal Perl PL/SQL PHP Pytonorm rubin Rost Scala UNIX-skal Småprat Snabb Visual Basic .NET Zig
Kategori Listor: kronologisk efter kategori

ISO- standarder
Listor: Lista över ISO-standarder Lista över ISO-romaniseringar Lista över IEC-standarder Kategorier: Kategori:ISO-standarder Kategori:OSI-protokoll
1 till 9999	ett 2 3 fyra 5 6 7 9 16 31 -0 -ett -2 -3 -fyra -5 -6 -7 -åtta -9 -tio -elva -12 -13 128 216 217 226 228 233 259 269 296 302 306 428 639 -ett 646 668 690 732 764 796 843 898 1000 1004 1007 1073-1 1413 1538 1745 2014 2015 2022 2108 2145 2146 2281 2709 2711 2788 3029 3103 3166 -ett -2 -3 3297 3307 3602 3864 3901 3977 4031 4157 4217 5218 5775 5776 5964 6166 6344 6346 6425 6429 6438 6523 6709 7001 7002 7098 7185 7388 7498 7736 7810 7811 7812 7813 7816 8000 8217 8571 8583 8601 8632 8652 8691 8807 8820-5 8859 -ett -2 -3 -fyra -5 -6 -7 -åtta -9 -tio -elva -12 -13 -fjorton -femton -16 ) 8879 9000 9075 9126 9241 9362 9407 9506 9529 9564 9594 9660 9897 9945 9984 9985 9995
10 000 till 19999	10006 10118-3 10160 10161 10165 10179 10206 10303 10303-11 10303-21 10303-22 10303-238 10303-28 10383 10487 10585 10589 10646 10664 10746 10861 10957 10962 10967 11073 11170 11179 11404 11544 11783 11784 11785 11801 11898 11940 11941 11941(TR) 11992 12006 12164 12182:1998 12207:1995 12207:2008 12234-2 13211 -ett -2 13216 13250 13399 13406-2 13407 13450 13485 13490 13567 13568 13584 13616 14 000 14031 14396 14443 14496-10 14496-14 ISO 14575 14644 -ett -2 -3 -fyra -5 -6 -7 -åtta -9 14649 14651 14698 14698-2 14750 14882 14971 15022 15189 15288 15291 15292 15408 15444 15445 15438 15504 15511 15686 15693 15706 15706-2 15707 15897 15919 15924 15926 15926 WIP 15930 16023 16262 16750 17024 17025 17369 17799 17987 18 000 18004 18014 18245 18629 18916 19005 19011 19092-1 19092-2 19114 19115 19439 19501:2005 19752 19757 19770 19775-1 19794-5
20 000+	20 000 20022 21 000 21047 21500 21827:2002 22 000 23008-2 23270 23360 24613 24707 25964-1 25178 26 000 26300 26324 27000-serien 27 000 27001 27002 27003 27004 27005 27006 27007 27729 27799 29199-2 29500 31 000 32 000 38500 42010 50001 80 000
Se även: Lista över artiklar vars titlar börjar med "ISO"

C++
C++98 C++03 C++11 C++14 C++17 C++20 C++23
Egenheter	Funktionsöverbelastning Operatör överbelastning Mallar virtuellt arv Länkar Reguladetri POD SFINAE
Vissa bibliotek	Standardbibliotek STL Lyft POCO Qt
Kompilatorer	Borland C++ C++ Builder framför Klang GCC Intel C++ kompilator Visual C++ öppna watcom
påverkas	C# D Java Hanterade C++ Rost Vala
Kategori C++