C++ | |
---|---|
Semantik | multi- paradigme : objektorienteret , generisk , proceduremæssig , metaprogrammering |
Sprog klasse | objektorienteret programmeringssprog , multi-paradigme programmeringssprog , proceduremæssigt programmeringssprog , funktionelt programmeringssprog , generisk programmeringssprog , programmeringssprog , frit-formsprog [d] og kompileret programmeringssprog |
Udførelsestype | kompileret |
Dukkede op i | 1983 |
Forfatter | Stroustrup, Bjørn |
Filtypenavn _ | .cc, .cpp, .cxx, .c, .c++, .h, .hpp, eller .hh_.hxx.h++ |
Frigøre | |
Type system | statisk |
Større implementeringer | GNU C++ , Microsoft Visual C++ , Intel C++ compiler , Open64 C++ Compiler , Clang , Comeau C/C++ , Embarcadero C++ Builder , Watcom C++ compiler , Digital Mars C++, Oracle Solaris Studio C++ compiler, Turbo C++ |
Dialekter | ISO/IEC 14882 C++ |
Blev påvirket | C , Simula , Algol 68 , Clu , ML og Ada |
Internet side | isocpp.org _ |
Mediefiler på Wikimedia Commons |
C ++ (udtales c-plus-plus [2] [3] ) er et kompileret , statisk skrevet programmeringssprog til generelle formål
Understøtter programmeringsparadigmer som proceduremæssig programmering , objektorienteret programmering , generisk programmering . Sproget har et rigt standardbibliotek, der inkluderer almindelige containere og algoritmer , I/O, regulære udtryk, multithreading -understøttelse og mere. C++ kombinerer funktioner fra både højt niveau og lavt niveau sprog [4] [5] . I sammenligning med dets forgænger - C -sproget - er der lagt størst vægt på understøttelse af objektorienteret og generisk programmering [5] .
C++ er meget brugt til softwareudvikling og er et af de mest populære programmeringssprog [opinions 1] [opinions 2] . Dens omfang omfatter oprettelse af operativsystemer , en række applikationsprogrammer, enhedsdrivere , applikationer til indlejrede systemer, højtydende servere og computerspil. Der er mange implementeringer af C++ sproget, både gratis og kommercielt, og til forskellige platforme. For eksempel på x86 -platformen er disse GCC , Visual C++ , Intel C++ Compiler , Embarcadero (Borland) C++ Builder og andre. C++ har haft en enorm indflydelse på andre programmeringssprog, især Java og C# .
C++-syntaksen er nedarvet fra C -sproget . Et af de oprindelige designprincipper var at opretholde kompatibilitet med C. C++ er dog strengt taget ikke et supersæt af C; Sættet af programmer, der kan oversættes lige godt af både C- og C++-kompilere, er ret stort, men inkluderer ikke alle mulige C-programmer .
Historisk udviklingsstadium [6] | År |
---|---|
BCPL sprog | 1966 |
B -sproget ( oprindelig udvikling af Thompson under UNIX ) | 1969 |
C sprog | 1972 |
C med klasser | 1980 |
C84 | 1984 |
Cfront (Edition E) | 1984 |
cfront (release 1.0) | 1985 |
Multipel/virtuel arv | 1988 |
Generisk programmering ( skabeloner ) | 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 |
Sproget opstod i begyndelsen af 1980'erne , da Bell Labs- medarbejder Björn Stroustrup kom med en række forbedringer af C -sproget til sine egne behov [7] . Da Stroustrup begyndte at arbejde hos Bell Labs i slutningen af 1970'erne med problemer i køteori (som anvendt til modellering af telefonopkald), fandt han ud af, at forsøg på at bruge eksisterende modelleringssprog på det tidspunkt var ineffektive, og brugen af højeffektive maskinsprog var for svært på grund af deres begrænsede udtryksevne. For eksempel har Simula -sproget funktioner, der ville være meget nyttige til udvikling af stor software, men som er for langsomt, og BCPL -sproget er hurtigt nok, men for tæt på sprog på lavt niveau, og er ikke egnet til at udvikle stor software.
I minde om oplevelsen af sin afhandling besluttede Stroustrup at supplere C-sproget (efterfølgeren til BCPL) med de muligheder, der er tilgængelige i Simula-sproget. C-sproget, som er basissproget i UNIX -systemet , som Bell-computerne kørte på, er hurtigt, funktionsrigt og bærbart. Stroustrup tilføjede til det evnen til at arbejde med klasser og objekter. Som et resultat viste praktiske modelleringsproblemer sig at være tilgængelige både med hensyn til udviklingstid (på grund af brugen af Simula-lignende klasser) og med hensyn til beregningstid (på grund af hastigheden af C). De første tilføjelser til C var klasser (med indkapsling ), klassearv, streng typekontrol, inline-funktioner og standardargumenter . Tidlige versioner af sproget, oprindeligt kaldet "C med klasser", har været tilgængelige siden 1980'erne .
Mens han udviklede C med klasser , skrev Stroustrup programmet cfront , en compiler , der omarbejder C-kildekode med klasser til almindelig C-kildekode. Dette gav os mulighed for at arbejde på et nyt sprog og bruge det i praksis ved at bruge den infrastruktur, der allerede er tilgængelig i UNIX til udvikling i C. Et nyt sprog, uventet for forfatteren, opnåede han stor popularitet blandt kolleger og snart kunne Stroustrup ikke længere personligt støtte ham, idet han besvarede tusindvis af spørgsmål.
I 1983 blev der tilføjet nye funktioner til sproget, såsom virtuelle funktioner, funktions- og operatøroverbelastning, referencer, konstanter, brugerkontrol over fri hukommelsesstyring, forbedret typekontrol og en ny kommentarstil ( //). Det resulterende sprog er ikke længere kun en udvidet version af klassisk C og er blevet omdøbt fra C med klasser til "C++". Dens første kommercielle udgivelse fandt sted i oktober 1985 .
Forud for starten af den officielle standardisering blev sproget primært udviklet af Stroustrup som svar på anmodninger fra programmeringsfællesskabet. Funktionen af standardsprogbeskrivelser blev udført af Stroustrups trykte værker på C ++ (en beskrivelse af sproget, en referencemanual, og så videre). Det var først i 1998, at den internationale standard for C++-sproget blev ratificeret: ISO/IEC 14882:1998 "Standard for C++-programmeringssproget"; efter vedtagelsen af tekniske rettelser til standarden i 2003, er den næste version af denne standard ISO/IEC 14882:2003 [8] .
I 1985 udkom den første udgave af The C++ Programming Language , som gav den første beskrivelse af sproget, hvilket var ekstremt vigtigt på grund af manglen på en officiel standard. I 1989 blev C++ version 2.0 udgivet. Dens nye funktioner inkluderede multipel arv, abstrakte klasser, statiske medlemsfunktioner, konstante funktioner og beskyttede medlemmer. I 1990 udkom "Commented Reference Guide to C++", som senere blev grundlaget for standarden. De seneste opdateringer har inkluderet skabeloner, undtagelser, navnerum, nye casts og den booleske type. Standard Template Library (STL) udviklet af Alexander Stepanov og Meng Li blev valgt som grundlag for lagring og adgang til generiske algoritmer .
C++ Standardbiblioteket har også udviklet sig sammen med det. Den første tilføjelse til C++-standardbiblioteket var I/O-streams, der gav et middel til at erstatte traditionelle C printfog scanf. Senere var den mest betydningsfulde udvikling af standardbiblioteket inddragelsen af Standard Template Library .
C++ fortsætter med at udvikle sig for at opfylde moderne krav. En af de grupper, der udvikler C++-sproget og sender forslag til forbedring af det til C++-standardiseringsudvalget, er Boost , som blandt andet beskæftiger sig med at forbedre sprogets muligheder ved at tilføje metaprogrammeringsfunktioner til det .
Ingen ejer rettighederne til C++ sproget, det er gratis. Selve sprogstandarddokumentet (med undtagelse af udkast) er dog ikke frit tilgængeligt [10] . Som en del af standardiseringsprocessen producerer ISO flere typer publikationer. Specielt udgives tekniske rapporter og tekniske specifikationer, når "fremtiden er i sigte, men der ikke umiddelbart er mulighed for aftale om offentliggørelse af en international standard." Indtil 2011 blev der udgivet tre tekniske rapporter om C++: TR 19768: 2007 (også kendt som C++ Technical Report 1) for biblioteksudvidelser hovedsageligt integreret i C++11, TR 29124: 2010 for specielle matematiske funktioner og TR 24733 for 20113: decimal aritmetik med flydende komma. Teknisk specifikation DTS 18822:. 2014 (af filsystem) blev godkendt i begyndelsen af 2015, og resten af specifikationerne er under udvikling og afventer godkendelse [11] .
I marts 2016 blev arbejdsgruppen WG21 C++ oprettet i Rusland . Gruppen blev organiseret for at indsamle forslag til C++-standarden, forelægge dem for udvalget og forsvare dem på generalforsamlinger i International Organization for Standardization (ISO) [12] .
Det resulterende sprognavn kommer fra C unær postfix -increment-++ operatoren (forøger værdien af en variabel med én). Navnet C+ blev ikke brugt, fordi det er en syntaksfejl i C og desuden er navnet taget af et andet sprog. Sproget blev heller ikke navngivet D, fordi "det er en udvidelse af C og ikke forsøger at løse problemer ved at fjerne C-elementer " [7] .
I The Design and Evolution of C++ [13] beskriver Bjørn Stroustrup de principper, han fulgte ved design af C++. Disse principper forklarer, hvorfor C++ er, som det er. Nogle af dem:
C++-standarden består af to hoveddele: en beskrivelse af kernesproget og en beskrivelse af standardbiblioteket.
Til at begynde med udviklede sproget sig uden for de formelle rammer, spontant i overensstemmelse med de opgaver, det stod over for. Udviklingen af sproget blev ledsaget af udviklingen af cfront cross compileren . Innovationer i sproget blev afspejlet i ændringen i versionsnummeret på krydskompileren. Disse cross-compiler versionsnumre udvides til selve sproget, men C++ versioner diskuteres ikke i øjeblikket. Det var først i 1998, at sproget blev standardiseret.
Et unavngivet navneområde er et specialtilfælde. Alle navne beskrevet i den er kun tilgængelige i den aktuelle oversættelsesenhed og har lokal binding. Navnerummet stdindeholder standard C++-biblioteker.
Følgende indbyggede typer er tilgængelige i C++. C++-typer er næsten identiske med C-datatyper :
Sammenligningsoperatørers returtype bool. Udtryk i parentes efter if, while konverteres til type bool[14] .
Sproget introducerede begrebet referencer, og fra C++11 - standarden rvalues - referencer og videresendelsesreferencer . (se link (C++) )
C++ tilføjer objektorienterede funktioner til C. Den introducerer klasser, der giver OOP 's tre vigtigste egenskaber : indkapsling , nedarvning og polymorfi .
I C++-standarden er en klasse en brugerdefineret type, der er erklæret ved hjælp af et af nøgleordene class, eller , structen unionstruktur er en klasse defineret af struct, og en union er en klasse defineret af union. Afhængigt af det anvendte søgeord ændres nogle egenskaber for selve klassen også. For eksempel, i en klasse erklæret med struct, vil medlemmer uden en manuelt tildelt adgangsmodifikator som standard være offentlig frem for privat.
I brødteksten i en klassedefinition kan du angive både funktionserklæringer og deres definition. I sidstnævnte tilfælde er funktionen inline ( inline). Ikke-statiske medlemsfunktioner kan have constog qualifiers volatile, samt en reference qualifier ( &eller &&).
C++ understøtter multipel nedarvning . Basisklasser (forfaderklasser) angives i hovedet på klasseerklæringen, eventuelt med adgangsspecifikationer. Arv fra hver klasse kan være offentlig, beskyttet eller privat:
Basisklassemedlemsadgang/arvtilstand | privat medlem | beskyttet medlem | offentligt medlem |
---|---|---|---|
privat arv | ikke tilgængelig | privat | privat |
fredet-arv | ikke tilgængelig | beskyttet | beskyttet |
offentlig arv | ikke tilgængelig | beskyttet | offentlig |
Som standard nedarves basisklassen som privat.
Som følge af arv modtager barneklassen alle forfædreklassernes felter og alle deres metoder; vi kan sige, at hver instans af efterkommerklassen indeholder en underinstans af hver af forfaderklasserne. Hvis en forfaderklasse nedarves flere gange (dette er muligt, hvis det er stamfaderen til flere basisklasser af den klasse, der oprettes), så vil forekomster af efterkommerklassen inkludere lige så mange underforekomster af denne forfaderklasse. For at undgå denne effekt, hvis det ikke er ønsket, understøtter C++ konceptet virtuel arv . Ved nedarvning kan basisklassen erklæres virtuel; for alle virtuelle forekomster af stamfaderklassen i efterkommerklassens arvetræ, oprettes der kun én underinstans i efterkommerklassen.
C++ understøtter dynamisk polymorfi og parametrisk polymorfi .
Parametrisk polymorfi er repræsenteret ved:
Dynamisk polymorfi implementeres ved hjælp af virtuelle metoder og et arvehierarki. I C++ er en type polymorf, hvis den har mindst én virtuel metode. Hierarki eksempel:
klassefigur _ { offentligt : virtuel void Tegn () = 0 ; // ren virtuel metode virtuel ~ Figur (); // hvis der er mindst én virtuel metode, skal destruktoren gøres virtuel }; klasse Square : offentlig figur { offentligt : void Tegn () tilsidesætte ; }; klasse Cirkel : offentlig figur { offentligt : void Tegn () tilsidesætte ; };Her er figurklassen abstrakt (og endda grænsefladeklassen ), da Draw-metoden ikke er defineret. Objekter af denne klasse kan ikke oprettes, men referencer eller pointere med typen Figur kan bruges. Valget af implementering af Draw-metoden vil blive foretaget på kørselstidspunktet baseret på den faktiske type af objektet.
Indkapsling i C++ implementeres ved at specificere niveauet for adgang til klassemedlemmer: de er offentlige (offentlige, public), beskyttede ( protected) og private (private, private). I C++ adskiller strukturer sig formelt kun fra klasser ved, at adgangsniveauet til klassemedlemmer og typen af arv for en struktur som standard er offentlige, mens de for en klasse er private.
Adgang | privat | beskyttet | offentlig |
---|---|---|---|
Selve klassen | Ja | Ja | Ja |
Venner | Ja | Ja | Ja |
arvinger | Ingen | Ja | Ja |
Udefra | Ingen | Ingen | Ja |
Adgangskontrol finder sted på kompileringstidspunktet, forsøg på at få adgang til et utilgængeligt klassemedlem vil forårsage en kompileringsfejl.
VennerVennefunktioner er funktioner, der ikke er medlemsfunktioner og alligevel har adgang til beskyttede og private medlemmer af klassen. De skal erklæres i klassens brødtekst som friend. For eksempel:
klasse Matrix { ven Matrix Multiply ( Matrix m1 , Matrix m2 ); };Her kan funktionen Multiplyfå adgang til alle felter og medlemsfunktioner i Matrix.
Både hele klassen og en medlemsfunktion i klassen kan erklæres som ven. Fire vigtige begrænsninger for venneforhold i C++ er:
Generelt kan denne regel formuleres som følger: "Venlighedsforholdet eksisterer kun mellem de klasser (klasse og funktion), for hvilke det er udtrykkeligt erklæret i koden, og handler kun i den retning, hvori det er deklareret."
En standardklasse kan have seks specielle funktioner: standardkonstruktør, kopikonstruktør, flyttekonstruktør, destruktor, kopitildelingsoperator, flyttetildelingsoperator. Det er også muligt eksplicit at definere dem alle (se regel om tre ).
klasse Array { offentligt : Array ( ) = standard // kompilatoren vil oprette en standardkonstruktør af Array selv ( size_t _len ) : len ( _len ) { val = ny dobbelt [ _len ]; } Array ( const Array & a ) = delete ; // kopikonstruktør fjernede eksplicit Array ( Array && a ); // flyt konstruktør ~ Array () { slette [] val ; } Array & operator = ( const Array & rhs ); // copy assignment operator Array & operator = ( Array && rhs ); // flyt tildelingsoperator dobbelt & operator []( size_t i ) { returværdi [ i ] ; } const double & operator []( size_t i ) const { returværdi [ i ] ; } beskyttet : std :: size_t len = 0 ; // feltinitialisering dobbelt * val { nullptr }; };Konstruktøren kaldes til at initialisere objektet (af den passende type), når det oprettes, og destruktoren kaldes for at ødelægge objektet. En klasse kan have flere konstruktører, men en destruktor kan kun have én. Konstruktører i C++ kan ikke erklæres virtuelle, men destruktorer kan, og er normalt erklæret for alle polymorfe typer, for at sikre, at et refereret eller pointer-tilgængeligt objekt er korrekt ødelagt, uanset hvilken type referencen eller pointeren er. Hvis mindst én af basisklasserne har en virtuel destruktor, bliver underklassens destruktor automatisk virtuel.
Skabeloner giver dig mulighed for at generere funktioner og klasser, der er parametriseret med en bestemt type eller værdi. For eksempel kunne den forrige klasse implementere et array for enhver datatype:
skabelon < typenameT > _ klasse Array { ... T & operator []( size_t i ) { returværdi [ i ] ; } beskyttet : std :: size_t len { 0 }; // feltinitialisering T * val { nullptr }; };C++ Standardbiblioteket indeholder et sæt værktøjer, der bør være tilgængelige for enhver implementering af sproget for at give programmører en behagelig brug af sprogfunktioner og give grundlag for udvikling af både en bred vifte af applikationsapplikationer og specialiserede biblioteker. C++ Standard Library inkluderer en del af C Standard Library C++ Standarden indeholder en normativ reference til 1990 C Standard og definerer ikke selvstændigt de standard biblioteksfunktioner, der er lånt fra C Standard Library.
#includeAdgang til funktionerne i C++ standardbiblioteket gives ved at inkludere de passende standard header-filer i programmet (via direktivet ). I alt er 79 sådanne filer defineret i C++11-standarden. Standard biblioteksfaciliteter er erklæret som en del af std-navnerummet. Header-filer, hvis navne matcher mønsteret "cX", hvor X er header-filnavnet på C Standard Library uden udvidelse (cstdlib, cstring, cstdio osv.), indeholder erklæringer, der svarer til den del af C Standard Library. standard biblioteksfunktioner findes også i namespace std.
Standardbiblioteket indeholder følgende sektioner:
Containere, strenge, algoritmer, iteratorer og grundlæggende hjælpeprogrammer, med undtagelse af lån fra C-biblioteket, kaldes tilsammen STL (Standard Template Library - standard template library). Oprindeligt var dette bibliotek et separat produkt, og dets forkortelse blev dechifreret anderledes, men derefter kom det ind i C++ standardbiblioteket som et integreret element. Navnet afspejler det faktum, at generaliserede programmeringsmekanismer (C++ skabeloner - skabelon) bruges til at implementere generelle værktøjer (containere, strenge, algoritmer). Stroustrups skrifter uddyber årsagerne til, at dette valg blev truffet. De vigtigste er den større universalitet af den valgte løsning (skabelonbeholdere, i modsætning til objektbeholdere, kan nemt bruges til ikke-objekttyper og kræver ikke en fælles forfader for elementtyper) og dens tekniske effektivitet (som regel skabelonbeholder operationer kræver ikke virtuelle funktionskald og kan nemt indlejres (inline), hvilket i sidste ende giver en præstationsgevinst.
Fra og med C++11-standarden er følgende funktioner blevet tilføjet:
STL'en, før den blev inkluderet i C++-standarden, var en tredjepartsudvikling, først af HP og derefter af SGI . Sprogstandarden kalder det ikke "STL", da dette bibliotek er blevet en integreret del af sproget, men mange mennesker bruger stadig dette navn for at skelne det fra resten af standardbiblioteket (I/O-streams ( iostream ), underafsnit C og andre).
Et projekt kaldet STLport [15] baseret på SGI STL holder STL-, IOstream- og strengklasserne ajour. Flere andre projekter udvikler også private anvendelser af standardbiblioteket.
Valget af C som grundlag for at skabe et nyt programmeringssprog forklares ved, at C-sproget:
På trods af en række velkendte mangler ved C-sproget, valgte Stroustrup at bruge det som base, fordi "C har sine problemer, men et sprog designet fra bunden ville have dem, og vi kender problemerne med C." Derudover gav dette os mulighed for hurtigt at få en compilerprototype ( cfront ), der kun oversatte de tilføjede syntakselementer til det originale C-sprog.
Efterhånden som C++ udviklede sig, blev andre funktioner inkluderet, der tilsidesætter C-konstruktionernes muligheder, og spørgsmålet om at opgive sprogkompatibilitet ved at fjerne forældede konstruktioner blev gentagne gange rejst. Men kompatibiliteten er blevet opretholdt af følgende årsager:
Nye C++-funktioner omfatter udtrykserklæringer, funktionstypekonverteringer, operatorer newog delete, type bool, referencer, udvidet konstans, inline-funktioner, standardargumenter, tilsidesættelser, navnerum, klasser (inklusive alle klasserelaterede funktioner såsom arv, medlemsfunktioner, virtuelle funktioner, abstrakt klasser og konstruktører ), operatørtilsidesættelser, skabeloner, operatør ::, undtagelseshåndtering, dynamisk identifikation og mere. C++-sproget er også i mange tilfælde mere strikt med hensyn til typekontrol end C.
C++ introducerede kommentarer med dobbelt skråstreg ( //), der var i C's forgænger, BCPL .
constNogle funktioner i C++ blev senere overført til C, såsom nøgleordene og , loop inline-deklarationer forog kommentarer i C++-stil ( //). Senere implementeringer af C introducerede også funktioner, der ikke findes i C++, såsom makroer va_argog forbedret array-parameterhåndtering.
Mens de fleste C-koder også vil være gyldige for C++, er C++ ikke et supersæt af C og inkluderer det ikke. Der er også noget kode, der er sandt for C, men ikke sandt for C++. Dette adskiller det fra Objective C , en anden C-forbedring til OOP , som blot er et supersæt af C.
Der er også andre forskelle. For eksempel tillader C++ ikke at kalde en funktion main()inde i et program, mens det i C er lovligt. C++ er også mere streng i nogle henseender; for eksempel tillader den ikke implicit casting mellem ikke-relaterede pointertyper og tillader ikke funktioner, der endnu ikke er deklareret.
Desuden kan kode, der er gyldig for begge sprog, give forskellige resultater afhængigt af hvilket sprogs compiler den er oversat til. På de fleste platforme udskriver følgende program f.eks. "C", hvis det er kompileret af en C-compiler og "C++", hvis det kompileres af en C++-kompiler. Dette skyldes, at tegnkonstanter i C (for eksempel 'a') er af typen int, men i C++ er de af typen char, og størrelserne på disse typer er normalt forskellige.
#include <stdio.h> int main () { printf ( "%s \n " , ( størrelse på ( 'a' ) == størrelse på ( char )) ? "C++" : "C" ); returnere 0 ; }Som Stroustrup bemærker, "Jo bedre du kender C, jo sværere vil det være for dig at undgå C++-programmering i C-stilen, mens du mister de potentielle fordele ved C++." Til det formål fremsætter han følgende sæt anbefalinger til C-programmører for at få fuld fordel af C++:
Den nuværende ISO/IEC 14882:2017 sprogstandard blev offentliggjort i december 2017 . Det er uofficielt omtalt som C++17 . Den næste version af standarden, der er planlagt til 2020, har den uofficielle betegnelse C++20 .
Ifølge sprogets forfatter, Björn Stroustrup [19] [20] [21] , der taler om sprogets videre udvikling og perspektiver, kan der skelnes mellem følgende:
Dette er et eksempelprogram Hej, verden! , som udskriver en besked til konsollen ved hjælp af standardbiblioteket og afslutter.
#include <iostream> bruger navneområde std ; int main () { cout << "Hej verden!" << endl ; returnere 0 ; }Moderne C++ giver dig mulighed for at løse mere komplekse problemer på en enkel måde. Dette eksempel demonstrerer blandt andet brugen af Standard Template Library ( STL ) containere.
#include <iostream> // for at bruge std::cout #include <vektor> // indeholder et dynamisk array #include <map> // indeholder ordbogsdatatype #inkluder <streng> int main () { // Importer alle erklæringer i "std"-navneområdet til det globale navneområde. bruger navneområde std ; // Vi erklærer en associativ beholder med strengnøgler og data som strengvektorer. map < streng , vektor < streng > > elementer ; // Tilføj et par personer til denne associative beholder og giv dem nogle genstande. genstande [ "Anya" ]. push_back ( "tørklæde" ); genstande [ "Dmitry" ]. push_back ( "billetter" ); genstande [ "Anya" ]. push_back ( "hvalp" ); // Loop gennem alle objekterne i containeren for ( const auto & person : items ) { // person er et par af to objekter: person.first er dens navn, // person.second er en liste over dens elementer (vektor af strenge) cout << person . første << " bærer " << person . sekund . størrelse () << "varer" << endl ; } }Dette eksempel importerer alle navne fra std-navneområdet for nemheds skyld. I et rigtigt program anbefales dette ikke, da du kan støde på navnekollisioner. Sproget giver dig mulighed for at importere individuelle objekter:
#inkluder <vektor> int main () { ved hjælp af std :: vektor ; vektor < int > min_vektor ; }I C++ (som i C), hvis programudførelse når slutningen af funktionen main(), så svarer dette til return 0;. Dette gælder ikke for nogen anden funktion end main().
Der kendes adskillige undersøgelser, hvor man forsøgte mere eller mindre objektivt at sammenligne flere programmeringssprog, hvoraf det ene er C++. I særdeleshed:
Ada-sproget er tæt på C++ med hensyn til dets sæt funktioner og anvendelsesområder: det er et kompileret struktursprog med en Simula-lignende objektorienteret tilføjelse (den samme "Algol med klasser"-model som i C++), statisk skrivning , generiske programmeringsværktøjer, designet til udvikling af store og komplekse softwaresystemer. Samtidig er det fundamentalt anderledes i ideologien: Ada er i modsætning til C++ bygget på baggrund af tidligere omhyggeligt gennemarbejdede forhold fra komplekse softwareproducenter med øgede krav til pålidelighed, hvilket satte aftryk på syntaksen og semantikken i Sprog.
Der er få direkte sammenligninger af Ada og C++ kodningseffektivitet. I artiklen [22] nævnt ovenfor resulterede løsningen af modelproblemet i Ada i en kode, der var cirka 30 % mindre i størrelse (i linjer) end i C++. Sammenligning af sprogenes egenskaber er givet i mange kilder, for eksempel opregner Jim Rogers' artikel om AdaHome [28] mere end 50 punkter med forskelle i disse sprogs egenskaber, hvoraf de fleste er til fordel for Ada (flere funktioner, mere fleksibel adfærd, mindre chance for fejl). Selvom mange af udtalelserne fra Ada-tilhængerne er kontroversielle, og nogle af dem er klart forældede, kan det generelt konkluderes:
I en artikel af Stephen Zeiger fra Rational Software Corporation [29] hævdes det, at udvikling i Ada generelt er 60 % billigere og resulterer i kode med 9 gange færre defekter end i C. Selvom disse resultater ikke kan overføres direkte til C++, er de stadig interessante, da mange af manglerne ved C++ er nedarvet fra C.
Java kan ikke betragtes som en fuld erstatning for C++, det er designet som et sikkert sprog med en lav indgangstærskel til udvikling af brugerdefinerede applikationer med høj portabilitet [30] og er grundlæggende uegnet til nogle typer applikationer, der er udviklet i C++. Inden for sit omfang er Java dog en meget reel konkurrent til C++. Fordelene ved Java nævnes almindeligvis som:
Samtidig skaber brugen af skraldeopsamleren og den virtuelle maskine begrænsninger, som er svære at overkomme. Java-programmer har en tendens til at være langsommere, kræver betydeligt mere hukommelse, og den virtuelle maskine isolerer programmet fra operativsystemet, hvilket gør programmering på lavt niveau umulig.
En empirisk undersøgelse [24] fandt ingen signifikant forskel i udviklingshastigheden i C++ og Java. Undersøgelsen [26] viste også, at ideen om en signifikant forskel i hastigheden af programmer på disse sprog ikke altid er korrekt: i to ud af tre tests viste hastigheden af applikationer i Java og C++ sig at være sammenlignelig. Samtidig er Java mere kortfattet - forskellen i mængden af kode var omkring 10-15%.
Det originale C fortsætter med at udvikle sig, mange store projekter udvikles i det: det er hovedsproget til udvikling af operativsystemer, spilmotorerne i mange dynamiske spil og et stort antal applikationsapplikationer er skrevet i det. En række eksperter hævder, at udskiftning af C med C++ ikke øger udviklingseffektiviteten, men fører til unødvendig komplikation af projektet, reduceret pålidelighed og øgede vedligeholdelsesomkostninger. I særdeleshed:
Der er ingen overbevisende beviser for, at C++ er C overlegen, hverken med hensyn til programmørproduktivitet eller programegenskaber. Selvom der er undersøgelser [32] , der fastslår, at C-programmører bruger omkring 30-40% af den samlede udviklingstid (eksklusive fejlretning) på hukommelsesstyring, når man sammenligner den overordnede produktivitet af udviklere [22] , er C og C++ tæt på.
I programmering på lavt niveau bliver mange af de nye funktioner i C++ gjort uanvendelige på grund af øget overhead: virtuelle funktioner kræver dynamisk real-adresseberegning (RVA), skabeloner fører til kode-bloat og dårlige optimeringsmuligheder, run-time library (RTL) er meget stor, og afvisningen af den fratager de fleste funktioner i C ++ (om så kun på grund af utilgængeligheden af new/ operations delete). Som et resultat bliver programmøren nødt til at begrænse sig til den funktionalitet, der er arvet fra C, hvilket gør det meningsløst at bruge C ++:
… den eneste måde at få et godt, effektivt, lavt niveau, bærbart C++ på er at begrænse dig til alle de ting, der er trivielt tilgængelige i C. Og at begrænse projektet til C vil betyde, at folk ikke smider det væk, og at der vil være en masse programmører til rådighed, som virkelig forstår de lave funktioner godt og ikke forlader dem på grund af den idiotiske "objektmodel" nonsens.
… når effektiviteten er i højsædet, vil "fordelene" ved C++ være en stor fejltagelse.
I et eksperiment [22] viste scripting og funktionelle sprog, især Haskell , en 2-3-dobbelt gevinst i programmeringstid og kodestørrelse sammenlignet med C++-programmer. På den anden side viste C++ programmer sig at være lige så meget hurtigere. Forfatterne anerkender, at deres data ikke udgør et repræsentativt udsnit og afholder sig fra at drage kategoriske konklusioner.
I et andet eksperiment [34] viste strenge funktionelle sprog ( Standard ML , OCaml ) en generel udviklingsacceleration med en faktor på 10 (hovedsageligt på grund af tidlig detektering af fejl) med omtrent lige ydelsesindikatorer (mange compilere i flere tilstande var Brugt).
I en undersøgelse af Lutz Prehelt [24] baseret på resultaterne af behandlingen af omkring 80 løsninger skrevet af frivillige, blev følgende konklusioner opnået, især:
Oftest er kritikere ikke imod C++ til noget andet specifikt sprog, men argumenterer for, at afvisningen af at bruge et enkelt sprog, der har adskillige fejl, til fordel for at nedbryde et projekt i underopgaver, der kan løses på forskellige sprog, der er bedst egnede til de gør udviklingen væsentligt mindre tidskrævende, mens de forbedrer programmeringskvalitetsindikatorerne [35] [36] . Af samme grund kritiseres opretholdelsen af kompatibilitet med C: Hvis en del af opgaven kræver funktioner på lavt niveau, er det mere rimeligt at adskille denne del i et separat undersystem og skrive det i C.
Tilhængere af C++ hævder til gengæld, at elimineringen af tekniske og organisatoriske problemer med intersproginteraktion gennem brugen af et universelt sprog i stedet for flere specialiserede sprog er vigtigere end tabene fra dette universelle sprogs ufuldkommenhed, dvs. meget bredde i C++-funktionssættet er en undskyldning for manglerne ved hver enkelt funktion; herunder ulemperne nedarvet fra C er begrundet i fordelene ved kompatibilitet (se ovenfor ).
Således betragtes de samme egenskaber ved C ++ - volumen, kompleksitet, eklekticisme og mangel på en specifik målniche for anvendelse - af tilhængere som "den største fordel ", og af kritikere - som " den største ulempe ".
Sprogets ideologi forveksler " adfærdskontrol " med " effektivitetskontrol ": princippet " du betaler ikke for det, du ikke bruger " antyder, at det giver programmøren fuldstændig kontrol over alle aspekter af programudførelse på et ret lavt niveau er en nødvendig og tilstrækkelig betingelse for at opnå høj kodeeffektivitet. Faktisk er dette ikke sandt for nogen store programmer: at pålægge programmøren optimering på lavt niveau, som en domænespecifik sprogkompiler af høj kvalitet åbenbart er i stand til at udføre mere effektivt, fører kun til en stigning i mængden af kode, en stigning i programmeringsarbejdsintensitet og et fald i kodeforståelighed og testbarhed. Princippet om "ikke betal for det, der ikke bliver brugt" giver således ikke rigtig de ønskede fordele i effektiviteten, men påvirker kvaliteten negativt.
Komponent- og objektorienteret programmeringIfølge Alan Kay er " Algol med klasser" -objektmodellen brugt i C++ ringere end "alt er et objekt"-modellen [37] brugt i Objective-C med hensyn til overordnet omfang, genbrug af kode , forståelighed, modificerbarhed og testbarhed .
C++ arvemodellen er kompleks, svær at implementere og fremkalder samtidig skabelsen af komplekse hierarkier med unaturlige relationer mellem klasser (f.eks. arv i stedet for nesting). Resultatet er oprettelsen af tæt koblede klasser med vagt adskilt funktionalitet. For eksempel er der i [38] givet et pædagogisk og anbefalende eksempel på implementeringen af "liste"-klassen som en underklasse af "listeelement"-klassen, som igen indeholder adgangsfunktioner for andre listeelementer. Denne typeforhold er matematisk absurd og irreproducerbar i mere stringente sprog. Ideologien i nogle biblioteker kræver manuel typekastning op og ned i klassehierarkiet ( static_castog dynamic_cast), hvilket krænker sprogets typesikkerhed . Den høje viskositet af C++-løsninger kan kræve, at store dele af projektet re-udvikles med minimale ændringer senere i udviklingsprocessen. Et levende eksempel på sådanne problemer kan findes i [35]
Som Ian Joyner [39] påpeger , sætter C++ fejlagtigt lighedstegn mellem indkapsling (det vil sige at lægge data inde i objekter og adskille implementering fra grænseflade) og implementeringsskjul. Dette komplicerer adgangen til klassedataene og kræver, at dens grænseflade næsten udelukkende implementeres gennem accessorfunktioner (hvilket igen øger mængden af kode og komplicerer den).
Typematching i C++ er defineret på niveauet af identifikatorer, ikke signaturer. Dette gør det umuligt at erstatte komponenter baseret på interface-matching, hvorfor inddragelsen af ny funktionalitet implementeret på biblioteksniveau i systemet kræver manuel modifikation af eksisterende kode [40] . Som Linus Torvalds [33] påpeger i C++, "Kode virker kun abstrakt, så længe den ikke skal ændres."
Kritik af C++ fra OOPs synspunkt er givet i [39] .
MetaprogrammeringC++'s generative metaprogrammering er skabelon- og præprocessor -baseret, arbejdskrævende og begrænset i omfang. C++-skabelonsystemet er faktisk en kompileringstidsvariant af det primitive funktionelle programmeringssprog . Dette sprog har næsten ingen overlapning med selve C++, hvorfor potentialet for vækst i kompleksiteten af abstraktioner er begrænset. Programmer, der bruger C++-skabeloner, har ekstremt dårlig forståelighed og testbarhed, og skabelonudpakning genererer i sig selv ineffektiv kode, da skabelonsproget ikke giver nogen midler til optimering (se også afsnittet #Computational efficiency ). Indlejrede domænespecifikke sprog implementeret på denne måde kræver stadig viden om selve C++, hvilket ikke giver en fuldgyldig arbejdsdeling. Således er C++'s evne til at udvide C++'s egenskaber ret begrænset [41] [42] .
Cross-platformAt skrive bærbar C++-kode kræver stor dygtighed og erfaring, og "sjusket" C++-kode er højst sandsynligt ikke-bærbar [43] . Ifølge Linus Torvalds , for at opnå C++-portabilitet svarende til C, skal programmøren begrænse sig til de C++-funktioner, der er arvet fra C [33] . Standarden indeholder mange elementer, der er defineret som "implementation-defined" (for eksempel varierer størrelsen af pointere til klassemetoder i forskellige compilere fra 4 til 20 bytes [44] ), hvilket forværrer overførbarheden af programmer, der bruger dem.
Den direktivmæssige karakter af sprogstandardiseringen , ufuldstændig bagudkompatibilitet og inkonsistens af kravene i forskellige versioner af standarden fører til problemer med at overføre programmer mellem forskellige compilere og endda versioner af de samme compilere.
Sproget indeholder værktøjer, der gør det muligt for programmøren at overtræde programmeringsdisciplinen givet i et bestemt tilfælde. For eksempel constindstiller en modifikator egenskaben for tilstands-uforanderlighed for et objekt, men modifikatoren mutableer designet specifikt til at tvinge tilladelse til at ændre tilstanden inde i et const-objekt, det vil sige at overtræde constness-begrænsningen. Desuden er det tilladt dynamisk at fjerne en attribut constfra et konstant objekt, hvilket gør det til en L-værdi. Tilstedeværelsen af sådanne funktioner i sproget gør forsøg på formelt at verificere koden meningsløse, og brugen af restriktioner til optimering er umulig.
Ukontrolleret makrosubstitutionC-makrosubstitutionsfaciliteterne ( #define) er lige så kraftfulde, som de er farlige. De bibeholdes i C++ på trods af, at C++ for alle de opgaver, de blev leveret til i C, gav mere strenge og specialiserede faciliteter - skabeloner, funktionsoverbelastning, inline-funktioner, navnerum, mere avanceret indtastning, udvidelse af applikationen const modifier osv. Der er mange potentielt farlige makroer i standardbibliotekerne arvet fra C [45] . Skabelon metaprogrammering er også nogle gange kombineret med brugen af makro substitution for at give såkaldte. " syntaktisk sukker ".
OverbelastningsproblemerC++-principperne for funktion og operatøroverbelastning fører til betydelig kodeduplikering. Oprindeligt beregnet til at introducere såkaldt " syntaktisk sukker ", opmuntrer operatøroverbelastning i C++ den ukontrollerede adfærd hos elementære operatører for forskellige typer. Dette øger dramatisk risikoen for fejl, især da det er umuligt at indføre en ny syntaks og ændre den eksisterende (for eksempel oprette nye operatorer eller ændre prioriteter eller associativitet), selvom syntaksen for standard C++ operatorer er tilstrækkelig til at semantik af langt fra alle typer, som måske skal introduceres i programmet. Nogle problemer skabes af muligheden for let overbelastning af operatørerne / , hvilket kan generere ekstremt lumske og svære at finde fejl. Samtidig udføres nogle intuitivt forventede operationer (oprydning af dynamiske objekter i tilfælde af at kaste undtagelser) ikke i C++, og en betydelig del af overbelastede funktioner og operatører kaldes implicit (typecasting, oprettelse af midlertidige forekomster af klasser osv. .). Som følge heraf bliver værktøjer, der oprindeligt var beregnet til at gøre programmer klarere og forbedre udvikling og vedligeholdelse, endnu en kilde til unødvendigt kompliceret og upålidelig kode. newdelete
Brugen af C++ skabeloner er parametrisk polymorfi på kildekodeniveau, men når den oversættes, bliver den til ad hoc polymorfi (dvs. funktionsoverbelastning), hvilket fører til en betydelig stigning i mængden af maskinkode sammenlignet med sprog, der har et ægte polymorfisk type system (efterkommere af ML ). For at reducere størrelsen af maskinkoden forsøger de automatisk at behandle kildekoden før stadiet med at afvikle skabeloner [46] [47] . En anden løsning kunne være muligheden for at eksportere skabeloner, som blev standardiseret tilbage i 1998, men den er ikke tilgængelig i alle compilere, da det er vanskeligt at implementere [48] [49] [udtalelser 4] og at importere C++ skabelonbiblioteker i sprog med en væsentlig anden C++ semantik ville det stadig være ubrugeligt. Tilhængere af C++ bestrider omfanget af kodeblæst som overdrevet [50] og ignorerer endda det faktum, at parametrisk polymorfi i C oversættes direkte, det vil sige uden at duplikere funktionslegemer overhovedet. Samtidig mener tilhængere af C++, at parametrisk polymorfi i C er farlig – altså farligere end overgangen fra C til C++ (modstandere af C++ argumenterer for det modsatte – se ovenfor).
OptimeringspotentialePå grund af det svage typesystem og overfloden af bivirkninger , bliver det ekstremt vanskeligt at konvertere programmer tilsvarende, og derfor indlejre mange optimeringsalgoritmer i compileren, såsom automatisk parallelisering af programmer , fjernelse af almindelige underudtryk , λ-løft, opkald til procedurer med fortsættelsesbeståelse , superkompilering osv. Som et resultat er den faktiske effektivitet af C++ programmer begrænset af programmørernes færdigheder og den indsats, der investeres i et bestemt projekt, og en "sjusket" implementering kan være væsentligt ringere i effektivitet end "sjusket" ”implementeringer på sprog på højere niveau, hvilket bekræftes af sammenlignende test af sprog [34] . Dette er en væsentlig barriere mod brugen af C++ i dataminingindustrien .
Effektiv hukommelsesstyringAnsvaret for effektiv hukommelsesstyring falder på udviklerens skuldre og afhænger af udviklerens færdigheder. Til automatisk hukommelsesstyring i C++, den såkaldte. "smarte pointers", manuel hukommelsesstyring reducerer effektiviteten af programmørerne selv (se afsnittet Effektivitet ) . Adskillige implementeringer af affaldsindsamling , såsom statisk inferens af regioner , er ikke anvendelige for C++-programmer (mere præcist kræver dette implementering af en ny sprogfortolker oven på C++-sproget, som er meget forskelligt fra C++ både i de fleste objektive egenskaber og generelt ideologi) på grund af behovet for direkte adgang til AST .
Korrelationen af præstationsfaktorer med udviklingsomkostninger, såvel som den generelle disciplin og programmeringskultur, der dyrkes i programmeringsfællesskabet, er vigtige for kunder, der vælger et sprog (og derfor foretrækker dette udviklersprog) til gennemførelsen af deres projekter, såvel som for folk, der begynder at lære programmering, især med den hensigt at programmere til dine egne behov.
Programmeringskvalitet og kulturPrincippet om C++ " ikke at påtvinge en" god "programmeringsstil " er i modstrid med den industrielle tilgang til programmering, hvor den ledende rolle spilles af softwarens kvalitet og muligheden for at vedligeholde koden, ikke kun af forfatteren , og for hvilke sprog, der minimerer indflydelsen fra den menneskelige faktor , foretrækkes , det vil sige blot at " påtvinge en 'god' programmeringsstil ", selvom sådanne sprog kan have en højere adgangstærskel.
Der er en opfattelse af, at præferencen for at bruge C++ (med mulighed for at vælge alternative sprog) negativt karakteriserer en programmørs professionelle kvaliteter. Specifikt siger Linus Torvalds , at han bruger kandidaternes positive meninger om C++ som et frafaldskriterium [udtalelser 3] :
C++ er et forfærdeligt sprog. Det, der gør det endnu mere forfærdeligt, er det faktum, at mange underkendte programmører bruger det... Helt ærligt, selvom der ikke er nogen grund til at vælge C ud over at holde C++ programmører væk, ville det alene være en god nok grund til at bruge C.
…Jeg er kommet til den konklusion, at jeg virkelig foretrækker at sparke alle, der foretrækker at udvikle et projekt i C++ frem for i C, så denne person ikke ødelægger det projekt, jeg er involveret i.
Den kontinuerlige udvikling af sproget tilskynder (og tvinger nogle gange) programmører til at ændre allerede fejlrettet kode igen og igen - dette øger ikke kun omkostningerne ved udviklingen, men medfører også risikoen for at introducere nye fejl i den debuggede kode. Især selvom bagudkompatibilitet med C oprindeligt var et af kerneprincipperne i C++, er C siden 1999 ophørt med at være en delmængde af C++, således at fejlrettet C-kode ikke længere kan bruges i et C++-projekt uden ændringer.
Kompleksitet for sin egen skyldC++ defineres af dets apologeter som "den mest magtfulde" , netop fordi den er fyldt med farlige, gensidigt modstridende træk. Ifølge Eric Raymond gør dette sproget i sig selv til et grundlag for personlig selvbekræftelse af programmører, hvilket gør udviklingsprocessen til et mål i sig selv:
Programmører er ofte flamboyante individer, der er stolte af … deres evne til at håndtere kompleksitet og håndtere abstraktioner med fingerfærdighed. Ofte konkurrerer de med hinanden og forsøger at finde ud af, hvem der kan skabe "de mest indviklede og smukke kompleksiteter." ... rivaler mener, at de skal konkurrere med andres "pynt" ved at tilføje deres egne. Snart bliver "massiv tumor" industristandarden, og alle kører store buggy-programmer, som selv deres skabere ikke kan tilfredsstille.
…
… denne tilgang kan komme i problemer, hvis programmører gør simple ting på komplekse måder, simpelthen fordi de kender disse måder og ved, hvordan de skal bruge dem.
Der er blevet bemærket tilfælde, hvor skødesløse programmører, ved at bruge den stærke kontekstafhængighed af C++ og manglen på evnen til at spore makrodefinitioner af compileren, bremsede udviklingen af projektet ved at skrive en eller to ekstra, korrekt fra compilerens punkt. linjer med kode, men indføre en svært at opdage spontant manifesteret fejl på deres bekostning. For eksempel:
#define if(a) if(rand())På sprog med dokumenteret korrekthed , selv med avancerede makrofaciliteter, er det umuligt at gøre skade på denne måde.
Upålideligt produktEn urimelig overflod af bivirkninger, kombineret med manglende kontrol fra sprogets runtime-system og et svagt typesystem, gør C++-programmer tilbøjelige til uforudsigelige fatale nedbrud (de velkendte nedbrud med beskeder som "Access violation", "Ren virtuel funktion call" eller "Programmet udførte en ulovlig handling og vil blive lukket"), hvilket udelukker brugen af C++ med høje krav til fejltolerance. Derudover øger det varigheden af selve udviklingsprocessen [34] .
ProjektledelseFaktorerne nævnt ovenfor gør kompleksiteten af C++ projektledelse til en af de højeste i softwareudviklingsindustrien.
James Coggins, en fireårig klummeskribent for The C++ Report , forklarer:
Problemet er, at OOP-programmører har eksperimenteret med incestuøse applikationer og sigtet efter et lavt abstraktionsniveau. For eksempel byggede de klasser som "linked list" i stedet for "brugergrænseflade" eller "strålingsstråle" eller "finite element model". Desværre gør stærk typekontrol, som hjælper C++-programmører med at undgå fejl, det også sværere at bygge store objekter fra små.
Den eneste direkte efterkommer af C++ er D-sproget , beregnet til at være en omarbejdning af C++ for at løse dets mest åbenlyse problemer. Forfatterne opgav kompatibiliteten med C, beholdt syntaksen og mange af de grundlæggende principper i C++ og introducerede funktioner i sproget, der er karakteristiske for nye sprog. D har ingen præprocessor, ingen header-filer, ingen multiple arv, men et modulsystem, interfaces, associative arrays, understøttelse af unicode i strenge, garbage collection (samtidig med at muligheden for manuel hukommelseshåndtering bevares), indbygget multithreading, type-inferens , eksplicit erklæring om rene funktioner og uforanderlige værdier. Brugen af D er meget begrænset, den kan ikke betragtes som en reel konkurrent til C++.
Den ældste konkurrent til C++ i opgaver på lavt niveau er Objective-C , også bygget på princippet om at kombinere C med en objektmodel, kun objektmodellen er nedarvet fra Smalltalk . Objective-C er, ligesom dets efterkommer Swift , meget brugt til softwareudvikling til macOS og iOS.
Et af de første alternativer til C++ i applikationsprogrammering var Java-sproget . Det betragtes ofte fejlagtigt som en direkte efterkommer af C++; faktisk er Javas semantik arvet fra Modula-2 sproget , og den grundlæggende semantik i C++ kan ikke spores i Java. I betragtning af dette og sprogs genealogi (Modula-2 er en efterkommer af Simula , ligesom C++, men det er ikke C), kaldes Java mere korrekt " anden fætter " af C++, snarere end " arvingen ". Det samme kan siges om C# -sproget , selvom procentdelen af affinitet med C++ er lidt højere end Java.
Et forsøg på at kombinere sikkerheden og udviklingshastigheden i Java og C# med funktionerne i C++ var Managed C++ dialekten (senere C++/CLI ). Det blev udviklet af Microsoft primært til at overføre eksisterende C++-projekter til Microsoft .NET-platformen. Programmer kører under CLR og kan bruge hele rækken af .NET-biblioteker, men der er en række begrænsninger for brugen af C++-funktioner, som effektivt reducerer C++ til C#. Denne dialekt har ikke modtaget bred anerkendelse og bruges hovedsageligt til at forbinde biblioteker skrevet i ren C++ med C #-applikationer.
En alternativ måde at udvikle C-sproget på er at kombinere det ikke med objektorienteret programmering, men med applikativ programmering , det vil sige at forbedre abstraktionen, stringens og modulariteten af programmer på lavt niveau ved at give forudsigelig adfærd og referentiel gennemsigtighed . Eksempler på arbejde i denne ånd er sprogene BitC , Cyclone og Limbo . Selvom der også er vellykkede forsøg på at bruge FP i realtidsproblemer uden integration med C-værktøjer [52] [53] [54] , er der stadig i øjeblikket (2013) i lav-niveau udvikling, brugen af C-værktøjer til en vis grad har et bedre forhold mellem arbejdsintensitet og effektivitet. Python og Lua -udviklerne har lagt en stor indsats i Python og Lua for at sikre, at disse sprog bliver brugt af C++-programmører, så af alle de sprog, der er tæt beslægtet med FP, er de de oftest noteret til at blive brugt i forbindelse med C++ i samme projekt. De vigtigste berøringspunkter mellem C++ og FP er bindingerne af wxWidgets og Qt -biblioteker udviklet i C++ med en C++-specifik ideologi til Lisp , Haskell og Python (i de fleste tilfælde laves bindinger til funktionelle sprog for biblioteker skrevet i C eller andre funktionelle sprog).
Et andet sprog, der betragtes som en konkurrent til C++, er Nemerle , som er resultatet af et forsøg på at kombinere Hindley-Milner- typemodellen og en makroundergruppe af Common Lisp med C# [55] . På samme måde er Microsofts F# , en dialekt af ML tilpasset til .NET-miljøet.
Et forsøg på at skabe en industriel erstatning for C/C++ var Go -programmeringssproget udviklet af Google i 2009 . Forfatterne af sproget påpeger direkte, at motivet for dets oprettelse var manglerne i udviklingsprocessen forårsaget af de særlige kendetegn ved C- og C++-sprogene [56] . Go er et kompakt, ukompliceret imperativt sprog med C-lignende syntaks, ingen præprocessor, statisk indtastning, stærk indtastning, pakkesystem, automatisk hukommelsesstyring, nogle funktionelle funktioner, økonomisk bygget OOP-undersystem uden understøttelse af implementeringsarv, men med grænseflader og duck -type , indbygget multithreading baseret på coroutiner og rør (a-la Occam ). Sproget er placeret som et alternativ til C++, det vil sige først og fremmest et middel til gruppeudvikling af meget komplekse meget komplekse computersystemer, herunder distribuerede, som om nødvendigt tillader lav-niveau programmering.
I den samme økologiske niche med C/C++ er Rust, udviklet i 2010 og vedligeholdt af Mozilla Corporation , med fokus på sikker hukommelseshåndtering uden brug af en skraldeopsamler . Især planer om delvist at erstatte C/C++ med Rust blev annonceret i 2019 af Microsoft [57] .
Ordbøger og encyklopædier | ||||
---|---|---|---|---|
|
Programmeringssprog | |
---|---|
|
ISO standarder | |
---|---|
| |
1 til 9999 |
|
10000 til 19999 |
|
20000+ | |
Se også: Liste over artikler, hvis titler begynder med "ISO" |
C++ | |
---|---|
Ejendommeligheder | |
Nogle biblioteker | |
Kompilere | |
påvirket | |
|