Varför har språk som C och C ++ inte skräpsamling, medan Java gör det? [stängd]

Insamling av skräp kräver datastrukturer för spårningstilldelningar och / eller referensräkning. Dessa skapar overhead i minne, prestanda och språkets komplexitet. C ++ är utformad för att vara ”nära metallen”, med andra ord tar den den högre prestandasidan av avvägningen jämfört med bekvämlighetsfunktionerna. Andra språk gör att avvägningen blir annorlunda. Detta är en av övervägandena när du väljer språk, vilken betoning du föredrar.

Som sagt, det finns många scheman för referensräkning i C ++ som är ganska lätta och performanta, men de finns i bibliotek, både kommersiella och öppen källkod, snarare än en del av själva språket. Referensräkning för att hantera objektets livslängd är inte detsamma som skräpsamling, men det tar upp många av samma slags problem och passar bättre med C ++: s grundläggande strategi.

Kommentarer

• Ett sekundärt problem är att GC är icke-deterministisk. Objektet kanske eller kanske inte finns i minnet långt efter att programmet har " tappat " det. Livscykler för återräkning är deterministiska, när den sista referensen tappas, tappas minnet. Detta har inte bara konsekvenser för minneseffektivitet utan också för felsökning. Ett vanligt programmeringsfel är " zombie " objekt, referensminne som teoretiskt har tappats. GC är mycket mer benägna att maskera denna effekt och producera buggar som är intermittenta och extremt svåra att spåra.
• – moderna gc ' är varken spårallokeringar eller räknar referenser. De bygger en graf från kvällen allting för närvarande på stacken och bara kondensera och torka allt annat (förenklat), och GC resulterar normalt i reducerad språkkomplexitet. Till och med prestationsfördelen är ifrågasatt.
• Er, @kylben, hela poängen med att ha automatisk GC bakad till språket är att det blir omöjligt att referera till zombieobjekt, eftersom GC frigör bara objekt som är omöjliga att referera till! Du får den typ av svåra att spåra buggar som du ' talar om när du gör misstag med manuell minneshantering.
• -1, GC räknas inte referenser. Plus, beroende på din minnesanvändning och tilldelningsschema, kan en GC vara snabbare (med en overhead i minnesanvändningen). Så argumentet om prestanda är också fel. Bara det nära metall är faktiskt en giltig punkt.
• Varken Java eller C # använder referensräkning: GC-scheman baserade på referensräkning är ganska primitiva i jämförelse och fungerar mycket sämre än moderna sopor (främst för att de måste göra minnesskrivningar för att ändra referensräkningarna när du kopierar en referens!)

Strikt taget, det finns ingen minneshantering alls på C-språket. malloc () och free () är inte nyckelord på språket, utan bara funktioner som anropas från ett bibliotek.Denna skillnad kan vara pedantisk nu, eftersom malloc () och gratis () är en del av C-standardbiblioteket och kommer att tillhandahållas av alla standardkompatibla implementeringar av C, men det var inte alltid sant tidigare.

Varför vill du ha ett språk utan standard för minneshantering? Detta går tillbaka till C: s ursprung som ”bärbar montering”. Det finns många fall av hårdvara och algoritmer som kan dra nytta av eller till och med kräva specialiserad minneshanteringsteknik. Såvitt jag vet finns det inget sätt att helt inaktivera Java: s inbyggda minneshantering och ersätta det med ditt eget. Detta är helt enkelt inte acceptabelt i vissa högpresterande / minimala resursituationer. C ger nästan fullständig flexibilitet för att välja exakt vilken infrastruktur. ditt program kommer att användas. Priset som betalas är att C-språket ger väldigt lite hjälp med att skriva korrekt, felfri kod.

Kommentarer

• +1 för det övergripande bra svaret, men också speciellt för " Priset som betalas är att C-språket ger väldigt lite hjälp med att skriva korrekt, felfri kod "
• C har minneshantering – men det fungerar bara, så folk märker det knappt. Det ' s statiska minne, register och stack. Tills du börjar allokera ut ur högen är du ' bra och dandy. Det ' är högtilldelningen som förstör saker . Som för Java kan alla skriva sin egen Java-runtime – det finns ' mycket att välja mellan, inklusive vad som kan kallas " System ' s Java ". .NET kan göra i stort sett allt som C kan – det ligger bara efter C ++ ' s inbyggda funktioner (t.ex. klasser hanteras endast i .NET). Naturligtvis har du också C ++. NET, som har allt som C ++ gör, och allt. NET gör.
• @Luaan I ' d säger att ' en mycket generös definition av att ha " minneshantering " " Tills du börjar allokera ur högen är du ' bra och dandy. Det ' är högtilldelningen som förstör saker ", att ' är som att säga en bil är ett perfekt bra flygplan, det är bara inte ' som inte kan flyga.
• @ CharlesE.Grant Tja, ett rent funktionellt språk kan göra allt med det typ av minneshantering. Bara för att högtilldelning är en bra avvägning i vissa användningsfall betyder inte ' att det ' är riktmärket för alla språk / körtider . Det ' är inte som minneshantering slutar vara " minneshantering " bara för att det ' är enkelt, rakt fram, gömt bakom kulisserna. Att utforma statisk minnestilldelning är fortfarande minneshantering, liksom en bra användning av stacken och allt annat du har tillgängligt.
• " alla standardkompatibla implementeringar " är inte sant, endast för standardkompatibel värdmiljöimplementering. Vissa plattformar / standardbibliotek, mest för 8 eller 16-bitars inbäddad mikrokontroller, tillhandahåller inte malloc() eller free(). (exempel är MLAP-kompilatorer för PIC)

Det verkliga svaret är att det enda sättet att göra en säker och effektiv sopmekanism är att ha språkstöd för ogenomskinliga referenser. (Eller omvänt, brist på språknivå för direktminnesmanipulation.)

Java och C # kan göra det eftersom de har speciella referenstyper som inte kan manipuleras. Detta ger körtiden friheten att göra saker som flytta tilldelade objekt i minnet , vilket är avgörande för en högpresterande GC-implementering .

För ordens skull använder ingen modern GC-implementering referensräkning , så det är helt rött sill. Moderna GC använder generationssamling, där nya allokeringar behandlas väsentligen på samma sätt som stackallokeringar är på ett språk som C ++, och sedan flyttas periodiskt alla nyligen allokerade objekt som fortfarande lever till ett separat ”survivor” -utrymme och en hel generation föremål delas omedelbart.

Detta tillvägagångssätt har fördelar och nackdelar: uppåtriktningen är att högtilldelningar på ett språk som stöder GC är lika snabbt som stackallokeringar på ett språk som inte stöder GC, och nackdelen är att objekt som behöver rengöras innan de förstörs antingen kräver en separat mekanism (t.ex. C #” s using nyckelord) eller så går deras saneringskod icke-deterministiskt.

Observera att en nyckel till en högpresterande GC är att det måste finnas språkstöd för en speciell referensklass. C har inte detta språkstöd och kommer aldrig att göra det; eftersom C ++ har överbelastning av operatören kan det emulera en GC-pekartyp, även om det måste göras noggrant. Faktum är att när Microsoft uppfann sin dialekt av C ++ som skulle köras under CLR (.NET runtime), var de tvungna att uppfinna en ny syntax för ”C # -stil referenser” (t.ex. Foo^) för att skilja dem från ”C ++ – stilreferenser” (t.ex. Foo&).

Vad C ++ har och vad som regelbundet används av C ++ – programmerare är smarta pekare , som egentligen bara är en referensräkningsmekanism. Jag skulle inte betrakta referensräkning som ”sann” GC, men det ger många av samma fördelar, till en kostnad av långsammare prestanda än antingen manuell minneshantering eller sann GC, men med fördelen av deterministisk förstörelse.

I slutet av dagen beror svaret verkligen på en språkdesignfunktion. C gjorde ett val, C ++ gjorde ett val som gjorde att det kunde vara bakåtkompatibelt med C samtidigt som det tillhandahöll alternativ som är tillräckligt bra för de flesta syften, och Java och C # gjorde ett annat val som är oförenligt med C men som också är tillräckligt bra för de flesta ändamål. Tyvärr finns det ingen silverkula, men att vara bekant med de olika alternativen där ute hjälper dig att välja rätt för vilket program du för närvarande försöker bygga.

Kommentarer

• Detta är det faktiska svaret på frågan
• För c ++ -delen, nuförtiden bör du titta på std :: unique_ptr och std :: move 🙂
• inget modernt GC-implem entation använder referensräkning : cPython använder både referensräkning och automatisk samling .
• @ Mike76: På allokeringssidan kommer en GC-fördelare att fungera ungefär lika snabbt som stackallokering, och GC kan omplacera tusentals objekt samtidigt. Oavsett vad du gör med en ref-räkningsimplementering kommer allokering och deallocation aldrig att vara snabbare än malloc och free. Så ja, en GC kan vara väsentligt snabbare. (Observera att jag sa " kan vara " – naturligtvis påverkas varje programs exakta prestanda av många faktorer.)
• ingen modern GC-implementering använder referensräkning Swift använder automatisk referensräkning.

”Allt” som en skräpsamlare är är en process som körs regelbundet för att se om det finns några icke refererade objekt i minnet och om det raderas. (Ja, jag vet att detta är en överdriven förenkling). Detta är inte en egenskap hos språket, utan ramverket.

Det finns skräpsamlare skrivna för C och C ++ – den här till exempel .

En anledning till att man inte har ”lagts” till språket kan bero på den stora volymen av befintlig kod som aldrig skulle använda den eftersom de använder sin egen kod för att hantera minne. En annan anledning kan vara att de typer av applikationer som skrivs i C och C ++ inte behöver omkostnaderna förknippade med en skräpuppsamlingsprocess.

Kommentarer

• Men framtida program skrev skulle börja använda sopuppsamlaren, nej?
• Även om insamling av skräp är teoretiskt oberoende av vilket programmeringsspråk som helst, är det ganska svårt att skriva en användbar GC för C / C ++, och till och med omöjligt att göra en idiotsäker (åtminstone lika idiotsäker som Java div id = ”0f18cfc402″>