Suljettu . Tämä kysymys on kohdistettava tarkemmin . Se ei tällä hetkellä hyväksy vastauksia.

Kommentit

  • Olemme ' saaneet moduulin iPhonen kehityksestä tänä lukukautena. Kun olet koodannut Android-sovelluksia 2 vuoden ajan, tämä kysymys iski suurinta osaa luokasta melko kovasti. Vasta nyt näemme, kuinka monta tuntia Java on tosiasiallisesti pelastanut meidät, koska meidän ei tarvitse jäljittää ikäviä muistinhallintavirheitä eikä tarvitse kirjoittaa kattilakoodia.
  • @NullUserException, koska se ei ole ' t määritä tapa palauttaa muisti, joka tarkoittaa melko paljon GC: tä.
  • @ bizso09: Katsoitko vielä ARC: tä? Ei tarvita hidasta / rasvaa / ei-determinististä GC: tä, kun ' on järjestelmätuki viitteiden laskemiseen: developer.apple. com / technologies / ios5
  • Vastaukset tähän melko hyvään kysymykseen ovat täynnä uskonnollisia passeja.
  • C- ja C ++ -järjestelmissä on mahdollista ottaa osoitin, heittää se int ja lisää siihen numero. Vähennä myöhemmin numero int: stä ja heitä tulos takaisin osoittimeen. Saat saman osoittimen kuin aiemmin. Onnea sellaisen GC: n toteuttamisessa, joka EI kerää muistia, kun taas sen osoite on tallennettu vain muuttujaan, jolla on myös toinen arvo. Tiedän, että esimerkki on typerä, mutta XOR-linkitetty luettelo käyttää jotain vastaavaa. Lähetän tämän vastaukseksi, mutta kysymys on suljettu.

Vastaus

Jätteiden kerääminen vaatii tietorakenteita kohdistusten ja / tai viitteiden laskemisen seuranta. Nämä luovat yleiskustannuksia muistissa, suorituskyvyssä ja kielen monimutkaisuudessa. C ++ on suunniteltu olemaan ”lähellä metallia”, toisin sanoen se vie kompromissin korkeamman suorituskyvyn puolen verrattuna mukavuusominaisuuksiin. Muut kielet tekevät siitä kompromissin eri tavalla. Tämä on yksi huomioitavista kielistä, jota painotat.

Siitä huolimatta C ++: ssa on paljon viitteiden laskentamenetelmiä, jotka ovat melko kevyitä ja suorituskykyisiä, mutta ne ovat kirjastoissa, sekä kaupallisissa että avoimissa lähdekoodeissa, eivätkä osa itse kieltä. Viitteiden laskenta objektin käyttöiän hallitsemiseksi ei ole sama kuin roskien keruu, mutta se ratkaisee monia samanlaisia asioita ja sopii paremmin C ++: n peruslähestymistapaan.

Kommentit

  • Toissijainen ongelma on, että GC ei ole deterministinen. Kohde saattaa olla tai olla edelleen muistissa kauan sen jälkeen, kun ohjelma on " pudonnut " it. Refcount-elinkaaret ovat deterministisiä, kun viimeinen viite pudotetaan, muisti pudotetaan. Tällä ei ole merkitystä vain muistin tehokkuudelle, vaan myös virheenkorjaukselle. Yleinen ohjelmointivirhe on " zombie " -objekti, teoreettisesti pudonnut viitemuisti. GC peittää paljon todennäköisemmin tämän vaikutuksen ja tuottaa virheitä, jotka ovat ajoittaisia ja erittäin vaikeasti jäljitettäviä.
  • – nykyaikaiset gc ' eivät kumpikaan kappaleen allokointeja tai viitteitä. He rakentavat kaavion aattista Pinoa tällä hetkellä ja vain tiivistyy ja pyyhi kaikki muu (yksinkertaistettu), ja GC johtaa yleensä vähentyneeseen kielen monimutkaisuuteen. Jopa suorituskyvyn hyöty on kyseenalainen.
  • Eee, @kylben, automaattisen GC: n paistaminen kieleen on siinä mielessä, että zombi-esineiden viittaaminen mahdottomaksi on, koska GC vapauttaa vain esineet, joihin on mahdotonta viitata! Saat sellaisia vaikeasti seurattavia vikoja, joista ' puhut, kun teet virheitä manuaalisen muistinhallinnan kanssa.
  • -1, GC ei lasketa viitteet. Lisäksi muistin käytöstä ja allokointijärjestelmästä riippuen GC voi olla nopeampi (muistin käytön yläpuolella). Joten argumentti suorituskyvystä on myös harhaa. Ainoastaan lähellä metallia on kelvollinen piste.
  • Java tai C # eivät käytä viitelaskentaa: vertailulaskentaan perustuvat GC-mallit ovat melko alkeellisia ja toimivat paljon huonommin kuin nykyaikaiset roskakeräimet (lähinnä siksi täytyy tehdä muistikirjoituksia muuttaaksesi viitteiden määrää aina, kun kopioit viitteen!)

Vastaa

Tarkkaan ottaen C-kielellä ei ole lainkaan muistinhallintaa. malloc () ja free () eivät ole kielen avainsanoja, vaan vain funktiot, joita kutsutaan kirjastosta.Tämä ero voi olla pedanttinen nyt, koska malloc () ja free () ovat osa C-standardikirjastoa, ja ne tarjoavat kaikki standardin mukaiset C-toteutukset, mutta tämä ei ollut aina totta aikaisemmin.

Miksi haluaisit kielen, jolla ei ole standardia muistinhallinnalle? Tämä johtuu C: n alkuperästä ”kannettava kokoonpano”. Monissa laitteisto- ja algoritmitapauksissa voidaan hyötyä erikoistuneista muistinhallintatekniikoista tai jopa vaatia niitä. Sikäli kuin tiedän, ei ole mitään tapaa poistaa Javan natiivimuistin hallintaa kokonaan käytöstä ja korvata se omalla. Tätä ei yksinkertaisesti voida hyväksyä joissakin korkean suorituskyvyn ja vähäisen resurssin tilanteissa. C tarjoaa melkein täydellisen joustavuuden valita tarkalleen mikä infrastruktuuri ohjelmasi käyttää. Maksettu hinta on, että C-kieli tarjoaa hyvin vähän apua oikean, virheettömän koodin kirjoittamisessa.

Kommentit

  • + 1 +1 yleisestä hyvästä vastauksesta, mutta myös erityisesti " -maksusta. Maksettu hinta on se, että C-kieli tarjoaa hyvin vähän apua oikean, virheettömän koodin kirjoittamisessa "
  • C: llä on muistinhallinta – mutta se vain toimii, joten ihmiset tuskin huomaavat sitä. Siellä ' on staattinen muisti, rekisterit ja pino. Kunnes aloitat varaamisen kasasta, ' on hieno ja hieno. Se ' s kasan allokointi, joka sekoittaa asiat. . Kuten Java-versiota varten kuka tahansa voi kirjoittaa oman Java-ajonsa – siellä on paljon valittavia vaihtoehtoja, mukaan lukien mitä voidaan kutsua " Järjestelmä ' s Java ". .NET voi tehdä melkein kaiken, mitä C voi – se on vain jäljessä C ++ ' natiivista ominaisuudesta (esim. Luokkia hallitaan vain .NET: ssä). Tietysti sinulla on myös C ++. NET, jolla on kaikki C ++: n ja kaikki .NET: n tehtävät.
  • @Luaan I ' d sanon, että ' on erittäin antelias määritelmä " muistinhallinnasta " " Kunnes aloitat varaamisen ulos kasasta, ' on hieno ja hieno. Se ' s kasan allokoinnin, joka sekoittaa asiat ", Se ' haluaa sanoa auto on erittäin hyvä lentokone, se ei vain ' pysty lentämään.
  • @ CharlesE.Grant No, puhtaasti toiminnallinen kieli voi tehdä kaiken sen kanssa eräänlainen muistinhallinta. Pelkästään siksi, että kasan allokointi on hyvä kompromissi joissakin käyttötapauksissa, se ei tarkoita, että se ' on vertailukohde kaikille kielille / ajonaikaisille . Se ' ei pidä siitä, että muistinhallinta lopettaa " muistinhallinnan " vain siksi, että se ' s yksinkertainen, suoraviivainen, piilotettu kulissien taakse. Staattisen muistin allokoinnin suunnittelu on edelleen muistinhallintaa, samoin kuin pinon ja kaiken muun käytettävissä olevan käyttö.
  • " mikä tahansa standardin mukainen toteutus " ei ole totta, vain standardin mukaisessa isäntäympäristössä. Jotkin käyttöympäristöt / vakiokirjastot, useimmat 8 tai 16-bittiselle upotetulle mikrokontrollerille, eivät tarjoa malloc() tai free(). (esimerkkejä ovat PIC: n MLAP-kääntäjät)

Vastaus

Todellinen vastaus on, että ainoa tapa tehdä turvallisella ja tehokkaalla roskien keräysmekanismilla on oltava kielitason tuki läpinäkymättömille viitteille. (Tai päinvastoin, kielitason tuen puute suorasta muistin manipuloinnista.)

Java ja C # voivat tehdä sen, koska niillä on erityisiä viitetyyppejä, joita ei voida manipuloida. Tämä antaa ajonaikalle vapauden tehdä asioita, kuten siirtää allokoituja objekteja muistissa , mikä on ratkaisevan tärkeää korkean suorituskyvyn GC-toteutuksessa .

Tietueeksi yksikään nykyaikainen GC-toteutus ei käytä viitelaskentaa , joten se on täysin punainen silli. Nykyaikaiset GC: t käyttävät sukupolvien kokoelmaa, jossa uusia allokaatioita käsitellään olennaisesti samalla tavalla kuin pinon allokaatiot ovat kielellä, kuten C ++, ja sitten kaikki elossa olevat uudet allokoidut objektit siirretään säännöllisesti erilliseen ”selviytyjä” -tilaan ja koko sukupolvi esineitä jaetaan kerralla. ”>

kielellä, joka ei tue GC: tä, ja haittapuoli on, että objektit, jotka on puhdistettava ennen tuhoutumista, vaativat joko erillisen mekanismin (esim. C #” s using avainsana) tai muuten heidän siivouskoodinsa toimii ei-deterministisesti.

Huomaa, että yksi avain korkean suorituskyvyn GC: hen on, että erityiselle viiteluokalle on oltava kielituki. C: llä ei ole tätä kielitukea eikä koskaan tule; koska C ++: lla on käyttäjän ylikuormitusta, se voisi jäljitellä GC ”d-osoittimen tyyppiä, vaikka se olisi tehtävä huolellisesti. Itse asiassa, kun Microsoft keksi CLR: n (.NET-ajonaikaisen) alla toimivan C ++ -murrteensa, heidän oli keksittävä uusi syntaksia ”C # -tyyppisille viitteille” (esim. Foo^) erottaakseen ne C ++ – tyyliviitteistä (esim. Foo&).

Mitä C ++: lla on ja mitä C ++ -ohjelmoijat käyttävät säännöllisesti, on älykkäät osoittimet , jotka ovat oikeastaan vain viitteiden laskentamekanismi. En pidä viitteiden laskemista ”tosi” GC: ksi, mutta se tarjoaa monia samoja etuja hitaamman suorituskyvyn kustannuksella kuin joko manuaalinen muistinhallinta tai tosi GC, mutta deterministisen tuhon etuna.

Päivän lopussa vastaus on todellakin kielen suunnitteluominaisuus: C teki yhden valinnan, C ++ teki valinnan, joka mahdollisti sen yhteensopivuuden taaksepäin C: n kanssa tarjoten silti riittävän hyviä vaihtoehtoja useimpiin tarkoituksiin, ja Java ja C # tekivät toisen vaihtoehdon, joka ei ole yhteensopiva C: n kanssa, mutta on myös tarpeeksi hyvä useimpiin tarkoituksiin. Valitettavasti ei ole hopeamerkkiä, mutta tuntemalla eri vaihtoehdot siellä voit auttaa valitsemaan oikean mistä tahansa ohjelmasta, jota yrität parhaillaan rakentaa.

Kommentit

  • Tämä on varsinainen vastaus kysymykseen
  • c ++ osa, nykyään kannattaa tarkastella std :: unique_ptr ja std :: move 🙂
  • ei modernia GC implemiä entationointi käyttää viittauslaskentaa : cPython käyttää sekä viitteiden laskemista että automaattista keräämistä .
  • @ Mike76: Kohdistuspuolella GC-allokaattori toimii suunnilleen yhtä nopeasti kuin pinon allokointi, ja GC voi jakaa tuhansia objekteja samanaikaisesti. Riippumatta siitä, mitä teet uudelleenlaskennan toteuttamisen kanssa, allokointi ja jakautuminen eivät koskaan ole nopeampia kuin malloc ja free. Joten kyllä, GC voi olla huomattavasti nopeampi. (Huomaa, että sanoin, että " voi olla " – tietysti monet tekijät vaikuttavat kunkin ohjelman tarkkaan suorituskykyyn.)
  • mikään nykyaikainen GC-toteutus ei käytä viitelaskentaa Swift käyttää automaattista viitelaskentaa.

Vastaa

Koska C ++: n tehoa käytettäessä ei ole tarvetta.

Herb Sutter:” En ole kirjoittanut vuosien kuluessa kirjallista poistoa. ”

katso Modernin C ++ -koodin kirjoittaminen: miten C ++ on kehittynyt vuosien varrella 21:10

Se voi yllättää monia kokeneet C ++ – ohjelmoijat.

Kommentit

  • Mielenkiintoista. Luentomateriaalini tänään.
  • Bah, video. Mutta silti mielenkiintoinen.
  • mielenkiintoinen video. 21 minuuttia sisään ja 55 minuuttia sisään olivat parhaat palat. Harmi, että WinRT-puhelut näyttivät edelleen olevan C ++ / CLI-törmäyksiä.
  • @ dan04: Se ' on totta. Mutta sitten, jos kirjoitat C-muodossa, saat mitä pyydät.
  • Älykkäiden osoittimien hallinta ei ole vaativampaa kuin varmistaa, että et ' t sinulla on tarpeettomia viitteitä roskakorissa. Koska GC ei voi ' lukea mieltäsi, se ' ei myöskään ole taikaa.

Vastaus

”Kaikki” roskakorin kerääjä on prosessi, joka suorittaa ajoittain tarkistusta, onko muistissa viitteettömiä objekteja ja onko niitä. (Kyllä, tiedän, että tämä on karkea yksinkertaistaminen). Tämä ei ole kielen, vaan kehyksen ominaisuus.

Esimerkiksi C: lle ja C ++: lle on kirjoitettu roskien keräilijöitä – tämä .

Yksi syy siihen, miksi kieltä ei ole ”lisätty”, voi johtua olemassa olevan koodin suuresta määrästä, joka ei koskaan käytä sitä, koska he käyttävät omaa koodiaan muistin hallintaan. Toinen syy voisi olla C- ja C ++ -lajilla kirjoitetut sovellustyypit eivät tarvitse roskien keräysprosessiin liittyviä yleiskustannuksia.

Kommentit

  • Mutta tulevat ohjelmat kirjoitettu alkaisi käyttää roskien keräilijää, eikö?
  • Vaikka roskien keräys on teoreettisesti riippumaton ohjelmointikielistä, on melko vaikea kirjoittaa hyödyllistä GC: tä C / C ++: lle, ja jopa mahdotonta tehdä tyhjästä (ainakin yhtä hämmentävä kuin Java ' s) – syy Java voi vetää sen pois, koska se toimii kontrolloidussa virtualisoidussa ympäristössä. Ja päinvastoin, Java-kieli on suunniteltu GC: lle, ja ' ll on vaikea kirjoittaa Java-kääntäjää, joka ei tee ' t .
  • @tdammers: Olen samaa mieltä siitä, että jätteiden keräystä on tuettava kielellä, jotta se olisi mahdollista. Pääasia ei kuitenkaan ole virtualisointi ja hallittu ympäristö, vaan tiukka kirjoittaminen. C ja C ++ ovat heikosti kirjoitettuja, joten ne sallivat esimerkiksi osoittimen tallentamisen kokonaislukumuuttujaan, osoittimien rekonstruoinnin offsetista ja sellaiset asiat, jotka estävät keräilijää kertomasta luotettavasti saavutettavissa olevaa (C ++ 11 kieltää myöhemmän sallimasta ainakin konservatiiviset keräilijät). Java-tiedostossa tiedät aina mikä on viite, joten voit kerätä sen tarkasti, vaikka se olisi käännetty alkuperäiskieleksi.
  • @Thorbj ø rnRavnAndersen: Voin kirjoittaa kelvollinen C-ohjelma, joka tallentaa osoittimia siten, että kukaan roskakorin vastaanottaja ei koskaan löydä niitä. Jos kytket sitten roskakorin malloc ja free, rikkoa oikea ohjelmani.
  • @Thorbj ø rnRavnAndersen: Ei, en soita ' soittamaan free, kunnes olen valmis siihen . Ehdotettu roskien keräilijä, joka ' ei vapauta muistia, kunnes kutsun nimenomaisesti free isn ' ta roskien kerääjä.

Vastaus

C suunniteltiin aikakaudella, jolloin roskien keräys oli tuskin vaihtoehto. Se oli tarkoitettu myös käyttötarkoituksiin, joissa roskien keräys ei yleensä toimi – paljaat metallit, reaaliaikaiset ympäristöt, joissa on vähän muistia ja minimaalinen ajonaikainen tuki. Muista, että C oli ensimmäisen unixin toteutuskieltä, joka juoksi pdp-11: llä 64 * K * tavua muistia. C ++ oli alun perin jatke C: lle – valinta oli jo tehty, ja roskien keräystä on hyvin vaikea oksastaa olemassa olevalle kielelle. Se on sellainen asia, joka on rakennettava sisään pohjakerroksesta.

Vastaa

Minulla ei ole tarkkoja lainauksia, mutta sekä Bjarne että Herb Sutter sanovat jotain samansuuntaisesti:

C ++ ei tarvitse roskien keräilijää, koska siinä ei ole roskia.

Moderni C ++ käytät älykkäitä osoittimia, joten sinulla ei ole roskia.

Kommentit

  • mitkä ovat älykkäitä osoittimia?
  • jos se oli niin Yksinkertainen, kukaan ei olisi toteuttanut mitään GC: tä.
  • @deadalnix: Oikein, koska kukaan ei koskaan toteuta mitään liian monimutkaista, hidasta, paisunutta tai tarpeetonta. Kaikki ohjelmistot ovat 100% tehokkaita koko ajan, eikö niin?
  • @deadalnix – C ++ -menetelmä muistinhallinnassa on uudempi kuin roskien keräilijät. RAII: n keksi Bjarne Stroustrup C ++: lle. Destructor-puhdistus on vanhempi idea, mutta säännöt poikkeusturvallisuuden varmistamiseksi ovat avainasemassa. En tiedä ' en, milloin tarkalleen kun idea itse kuvattiin, mutta ensimmäinen C ++ -standardi valmistui vuonna 1998, ja Stroustrups " Suunnittelu ja C ++: n evoluutio " ei ollut ' t julkaistu vuoteen 1994 asti, ja poikkeukset olivat suhteellisen uusi lisäys C ++: iin – julkaisun jälkeen div id = ”ed65bc2ef6″>

Kommentoitu C ++ -käyttöopas " vuonna 1990, uskon. GC keksittiin vuonna 1959 Lisp: lle.

  • @deadalnix – tiedätkö, että ainakin yksi Java VM käytti viitteitä laskevaa GC: tä, joka voitaisiin (melkein) toteuttaa käyttämällä C ++ -tyyppistä RAII: ta älykäs osoitinluokka – tarkalleen koska se oli tehokkaampi monisäikeiselle koodille kuin olemassa olevat virtuaalikoneet? Katso www.research.ibm.com/people/d/dfb/papers/Bacon01Concurrent.pdf. Yksi syy siihen, ettet näe ' tätä käytännössä C ++: ssa, on tavallinen GC-kokoelma – se voi kerätä jaksoja, mutta ei ' valita turvallinen tuhoajajärjestys syklien läsnä ollessa, eikä siten voi varmistaa luotettavaa tuhoajan puhdistamista.

    • Vastaa

    Sinä kysy, miksi näitä kieliä ei ole päivitetty sisällyttämään valinnaista roskien keräilijää.

    Valinnaisen roskakorin ongelma on, että et voi sekoittaa eri malleja käyttävää koodia. Toisin sanoen, jos kirjoitan koodin, joka olettaa käyttävänsi roskakorin, et voi käyttää sitä ohjelmassasi, jonka roskien keräys on kytketty pois päältä. Jos teet niin, se vuotaa kaikkialle.

    Vastaa

    Siellä on useita ongelmia, kuten …

    • Vaikka GC keksittiin ennen C ++: ta ja mahdollisesti ennen C: tä, sekä C että C ++ otettiin käyttöön ennen kuin GC: t hyväksyttiin yleisesti käytännölliseksi.
    • Et voi helposti toteuttaa GC-kieli ja -alusta ilman taustalla olevaa muuta kuin GC-kieltä.
    • Vaikka GC on todistettavasti tehokkaampi kuin muu kuin GC tyypillisissä aikatauluissa kehitetyissä tyypillisissä sovelluskoodeissa, on asioita, joissa enemmän kehitystyötä on hyvä kauppa – Pois päältä ja erikoistunut muistinhallinta ylittää yleiskäyttöisen GC: n. Lisäksi C ++ on tyypillisesti todistettavasti tehokkaampi kuin useimmat GC-kielet, ilman ylimääräistä kehitystyötä.
    • GC ei ole yleisesti turvallisempi kuin C ++ -tyyppinen RAII RAII mahdollistaa muiden resurssien kuin muistin automaattisen puhdistamisen, lähinnä siksi, että se tukee luotettavia ja oikea-aikaisia tuhoajia. Näitä ei voida yhdistää perinteisiin GC-menetelmiin referenssisykleistä johtuvien ongelmien vuoksi.
    • GC-kielillä on omat ominaisuutensa eräänlainen muisti vuotoja, erityisesti muistiin liittyen, jota ei enää käytetä koskaan uudelleen, mutta joissa on olemassa viitteitä, joita ei ole koskaan mitätöity tai korvattu. Tarve tehdä tämä nimenomaisesti ei ole periaatteessa erilainen kuin tarve delete tai free nimenomaisesti. GC-lähestymistavalla on edelleen etu – ei roikkuvia viitteitä – ja staattinen analyysi voi saada kiinni joistakin tapauksista, mutta jälleen kerran ei ole olemassa yhtä täydellistä ratkaisua kaikkiin tapauksiin.

    Pohjimmiltaan osittain se ” noin kielten iästä, mutta muille kuin GC-kielille löytyy aina paikka – vaikka se olisikin vähän nichey-paikka. Ja vakavasti, C ++: ssa GC: n puute ei ole iso juttu – muistiasi hallitaan eri tavalla, mutta sitä ei hallita.

    Mikrosoftilla hallinnoidulla C ++: lla on ainakin jonkin verran kyky sekoittaa GC: tä ja muuta GC samassa sovelluksessa, mikä sallii molempien etujen yhdistämisen, mutta minulla ei ole kokemusta sanoa, kuinka tämä toimii käytännössä.

    Toissijaiset linkit vastaaviin vastauksiin minun …

    vastaus

    Voitteko kuvitella kirjoittavasi laitekäsittelijän kielellä, jolla on roskakoria? Kuinka monta bittiä voisi tulla alas rivi GC: n ollessa käynnissä?

    Tai käyttöjärjestelmä? Kuinka voit aloittaa roskakorin käynnissä ennen kuin edes käynnistät ytimen?

    C on suunniteltu matalalle tasolle lähellä laitteistotehtäviä. Ongelma? onko se niin mukava kieli, että se on hyvä valinta myös moniin ylemmän tason tehtäviin. Kielitsaarit ovat tietoisia näistä käyttötavoista, mutta heidän on tuettava ensisijaisesti laiteajurien, sulautettujen koodien ja käyttöjärjestelmien vaatimuksia.

    kommentit

    • C hyvä korkealle tasolle? Nuuskasin juomani koko näppäimistössäni.
    • No, hän sanoi: " monia korkeamman tason tehtäviä ". Hän voisi laskea peikkoja (yksi, kaksi, monet …). Ja hän ei sanonut ' ei oikeastaan sanonut mitä korkeampi. Vitsit syrjään, mutta se ' on totta – todisteet siitä, että monia merkittäviä korkeamman tason projekteja on kehitetty onnistuneesti C: ssä. Voi olla parempia valintoja nyt monille näistä projekteista, mutta toimiva projekti on vahvempi todiste kuin spekulaatio siitä, mitä on voinut olla.
    • Siellä ' on joitain hallittuja käyttöjärjestelmiä, ja ne toimivat melko hyvin. Itse asiassa, kun teet koko järjestelmän hallittavaksi, hallitun koodin käytöstä johtuva suorituskyky laskee vielä pienemmäksi, jopa nopeammin kuin hallitsematon koodi tosielämän tilanteissa. Tietenkin nämä kaikki ovat " tutkimuskäyttöjärjestelmiä " – siellä ' ei melkein ole tapa tehdä niistä yhteensopivia olemassa olevan hallitsemattoman koodin kanssa sen lisäksi, että tehdään täysin virtualisoitu hallitsematon käyttöjärjestelmä hallitussa käyttöjärjestelmässä. Microsoft ehdotti jossain vaiheessa, että ne saattavat korvata Windows Serverin yhdellä näistä, koska yhä useampi palvelinkoodi on kirjoitettu .NET-verkkoon.

    Vastaa

    Lyhyt ja tylsä vastaus tähän kysymykseen on, että roskat kerääville ihmisille on oltava muu kuin roskat kerätty kieli. Ei ole käsitteellisesti helppoa olla kieli, joka samalla mahdollistaa erittäin tarkan hallinnan muistin asetteluista ja GC on päällä.

    Toinen kysymys on miksi C: llä ja C ++: lla ei ole roskien keräilijöitä.Tiedän, että C ++: lla on pari heistä, mutta he eivät ole kovin suosittuja, koska heidän on pakko käsitellä kieltä, jota ei ole suunniteltu ensisijaisesti GC: lle, ja ihmisille, jotka käyttävät edelleen C ++: ta tämä ikä ei todellakaan ole sellainen, joka kaipaa GC: tä.

    Sen lisäksi, että GC lisätään vanhaan muuhun kuin GC: n muokkaamaan kieleen, on itse asiassa helpompaa luoda uusi kieli, jolla on suurin osa sama syntakse samalla kun tuet GC: tä. Java ja C # ovat hyviä esimerkkejä tästä.

    Kommentit

    • Jossain osoitteessa programmers.se tai SO, siellä ' sa väittää, että joku sanoi minulle, että joku työskenteli itsestään käynnistyvän roskakorin kanssa – IIRC toteuttaa virtuaalikoneen pohjimmiltaan GC-kielellä ja käynnistyslohko-osajoukon, jota käytetään itse GC: n toteuttamiseen. . Unohdan nimen. Kun tutkin sitä, kävi ilmi, että he ' eivät periaatteessa koskaan saavuttaneet harppausta osajoukosta ilman GC: tä toimivaan GC-tasoon. on periaatteessa mahdollista, mutta AFAIK: ta ei ole koskaan saavutettu käytännössä – se ' on varmasti tapaus tehdä asioita vaikeasti.
    • @ Steve314: I ' Rakastan nähdä, että jos muistat koskaan, mistä löysit sen!
    • löysit sen! Katso kommentit osoitteeseen stackoverflow.com/questions/3317329/… , jotka viittaavat Kleinin virtuaalikoneeseen. Osa ongelmasta sen löytämisessä – kysymys suljettiin.
    • BTW – En näytä pystyvän aloittamaan kommenttejani @missingno – mitä antaa?
    • @ steve314: Olen kirjoittanut vastauksen tähän ketju on liitetty, saan jo ilmoituksen kaikista kommenteista. @ -Postin tekeminen tässä tapauksessa olisi turhaa eikä SE salli sitä (älä ' kysy minulta miksi tosin). (Todellinen syy on kuitenkin se, että numeroni puuttuu)

    Vastaus

    Jätteiden kerääminen on periaatteessa yhteensopimaton järjestelmäkieli, jota käytetään ajureiden kehittämiseen DMA-yhteensopiville laitteistoille.

    On täysin mahdollista, että kohteen ainoa osoitin tallennetaan laitteistorekisteriin jossakin oheislaitteessa. Koska roskien kerääjä ei tiedä tästä se luulisi objektin olevan tavoitettavissa ja keräisi sen.

    Tämä argumentti on kaksinkertainen GC: n tiivistämiseen. Vaikka olisitkin varovainen ylläpitää muistissa olevia viitteitä laitteisto-oheislaitteiden käyttämiin objekteihin, kun GC siirtää objektin uudelleen, se ei tiedä, miten päivittää oheislaitteiden määritysrekisterissä oleva osoitin.

    Joten nyt tarvitset sekoituksen liikkumattomista DMA-puskureista ja GC-hallituista objekteista, mikä tarkoittaa, että sinulla on molempien haitat.

    Kommentit

    • Molempien epäilemättä kaikki haitat, mutta vähemmän haittoja, ja edut ovat samat. On selvää, että on monimutkaisempaa käsitellä monenlaisia muistinhallintaa, mutta monimutkaisuutta voidaan välttää myös valitsemalla oikea hevonen kullekin kurssille koodissasi. Kuvittelin epätodennäköistä, mutta ' siinä on teoreettinen aukko. Olen ' spekuloinut aiemmin GC: n ja muun kuin GC: n sekoittamisesta samalla kielellä, muttei laiteohjaimille – enemmänkin enimmäkseen GC-sovelluksen saamiseksi, mutta joidenkin manuaalisesti muistiohjattujen tietorakenteen kirjastotasot.
    • @ Steve314: Etkö ' sanoisi, että muistaa, mitkä objektit on vapautettava manuaalisesti, on yhtä hankalaa kuin muistaa vapauttaa kaikki? (Tietysti älykkäät osoittimet voivat auttaa kummassakin, joten kumpikaan niistä ei ole valtava ongelma.) Ja tarvitset erilaisia altaita manuaalisesti hallinnoiduille objekteille verrattuna kerättyihin / pakattaviin kohteisiin, koska tiivistäminen ei ' t toimivat hyvin, kun kiinteitä esineitä on hajallaan. Joten paljon ylimääräistä monimutkaisuutta turhaan.
    • Ei, jos ' on selvä jako korkean tason koodin, joka on kaikki GC, ja matalan tason välillä. koodi, joka valitsee GC: n. Kehitin idean lähinnä tarkastellessani muutama vuosi sitten D: tä, jonka avulla voit kieltäytyä GC: stä, mutta ' ei salli sinun palata takaisin. Otetaan esimerkiksi B + -puukirjasto . Säiliön kokonaisuudessaan tulisi olla GC, mutta tietorakenteen solmut eivät todennäköisesti ole – se on ' tehokkaampaa tehdä räätälöity skannaus vain lehtisolmujen kautta kuin saada GC tekemään rekursiivinen haku haarasolmujen kautta. Tämän tarkistuksen on kuitenkin raportoitava sisältämät kohteet GC: lle.
    • Asia on, että ' on sisällytetty toiminto. B + -puusolmujen kohtelu erityisenä WRT-muistinhallintana ei ole erilaista kuin niiden käsitteleminen erityisinä WRT- olennoina B + puupalmuina. Se ' on kapseloitu kirjasto, ja sovelluskoodin ei tarvitse tietää ', että GC-käyttäytyminen on ohitettu / erityiskoteloitu.Paitsi, että ainakin tuolloin se oli mahdotonta D: ssä – kuten sanoin, ei ole mitään tapaa valita takaisin ja ilmoittaa sisältämät tuotteet GC: lle mahdollisina GC-juurina.

    vastaus

    Koska C & C ++ ovat suhteellisen matalan tason kieliä, jotka on tarkoitettu yleiskäyttöön, jopa esimerkiksi suorittaa 16-bittisellä prosessorilla, jossa on 1 Mt muistia sulautetussa järjestelmässä, jolla ei ole varaa tuhlata muistia gc: llä.

    Kommentit

    • " Sulautettu järjestelmä "? Kun C standardoitiin (1989), sen oli pystyttävä käsittelemään tietokoneita 1 Mt muistia.
    • Olen samaa mieltä, mainitsin ajankohtaisemman esimerkin.
    • 1 Mt ??? Holy schmoley, joka tarvitsisi koskaan niin paljon RAM-muistia? < / billGates >

    vastaus

    C ++: ssa ja C: ssä on roskien keräilijöitä. Etkö ole varma, miten tämä toimii C: ssä, mutta C ++: ssa voit hyödyntää RTTI -toimintoa löytääksesi dynaamisesti objektikaavion ja käyttää sitä roskien keräykseen.

    Tietojeni mukaan et voi kirjoittaa Java-tiedostoa ilman roskien keräilijää. Pieni haku osoitti tämän .

    Tärkein ero Java- ja C / C ++: n välillä on se, että C / C ++: ssa valinta on aina sinun. , kun taas Java-ohjelmassa jätät usein ilman vaihtoehtoja suunnittelun perusteella.

    Kommentit

    • Ja myös, että omistetut roskien keräilijät toteutetaan paremmin, tehokkaammin ja sopivat paremmin kieleen. 🙂
    • Ei, et ' et voi käyttää RTTI: tä etsimään objektikaavio dynaamisesti C / C ++: It ' s tavalliset vanhat dataobjektit, jotka pilaavat kaiken. Tavalliseen vanhaan dataobjektiin ei yksinkertaisesti ole tallennettu RTTI-tietoja, joiden avulla roskien keräilijä voisi erottaa osoittimet ja ei-osoittimet kyseisen objektin sisällä. Vielä pahempaa on, että osoittimia ei tarvitse kohdistaa täydellisesti kaikkiin laitteistoihin, joten 16-tavuisen objektin vuoksi 64-bittinen osoitin voidaan tallentaa 9 mahdollisesta sijainnista, joista vain kaksi don ' t ovat päällekkäisiä.

    Vastaa

    Se vaihtelee suorituskyvyn ja turvallisuuden välillä.

    Ei ole takeita siitä, että roskat kerätään Java-järjestelmään, joten se voi roikkua tyhjentämällä tilaa pitkään, kun taas viittaamattomien esineiden (eli roskien) skannaus kestää myös kauemmin kuin käyttämättömän kohteen nimenomainen poisto tai vapauttaminen.

    Etuna on tietysti, että voidaan rakentaa kieli ilman viitteitä tai ilman muistivuotoja, joten on todennäköisempää tuottaa oikea koodi.

    Näissä keskusteluissa voi joskus olla pieni ”uskonnollinen” reuna – varoita!

    vastaus

    Tässä on luettelo GC: n luontaisista ongelmista, jotka tekevät siitä käyttökelvottoman järjestelmäkielellä kuten C:

    • GC: n on suoritettava sen koodin tason alapuolella, jonka objekteja se hallinnoi. Ytimessä ei yksinkertaisesti ole tällaista tasoa.

    • GC: n on lopetettava hallittu koodi ajoittain. Ajattele nyt, mitä tapahtuisi, jos se tekisi niin ytimellesi. Kaikki koneesi käsittely pysähtyy esimerkiksi millisekunniksi, kun taas GC skannaa kaikki olemassa olevat muistijaotukset. Tämä tappaisi kaikki yritykset luoda järjestelmiä, jotka toimivat tiukkojen reaaliaikaisten vaatimusten mukaisesti.

    • GC: n on kyettävä erottamaan osoittimet ja muut osoittimet. Toisin sanoen sen on kyettävä tarkastelemaan kaikkia olemassa olevia muistikohteita ja pystyttävä tuottamaan luettelo siirtymistä, joista sen osoittimet löytyvät.

      Tämän löydön on oltava täydellinen: GC: n on kyettävä jahtaamaan kaikkia löytämiään viitteitä. Jos se viittaa väärään positiiviseen, se todennäköisesti kaatuu. Jos se ei löytänyt väärää negatiivista, se todennäköisesti tuhoaisi objektin, joka on edelleen käytössä, kaatuu hallittu koodi tai vahingoittaisi sen tietoja hiljaa.

      Tämä edellyttää ehdottomasti, että tyyppitiedot tallennetaan jokaiseen yksittäiseen Olemassa oleva objekti. Sekä C että C ++ sallivat kuitenkin tavalliset vanhat dataobjektit, jotka eivät sisällä tyyppitietoja.

    • GC on luonnostaan hidas liiketoiminta. ei ehkä ymmärrä tätä, mutta ohjelmat voivat olla suuruusluokkaa nopeammin, kun niitä ei toteuteta Javassa. Ja yksi tekijöistä, jotka tekevät Javasta hitaan, on GC. Tämä estää Java-kaltaisia GCed-kieliä käyttämästä supertietokoneita. Jos koneesi maksaa miljoona vuodessa virrankulutusta, et halua maksaa edes 10 prosenttia roskakorista.

    C ja C ++ ovat kieliä, jotka on luotu tukemaan kaikki mahdolliset käyttötapaukset. Ja kuten näette, roskien keräys estää monet näistä käyttötapauksista. Joten näiden käyttötapausten tukemiseksi C / C ++: ta ei voida kerätä roskiin.

    Vastaa

    Sähköpostiosoitettasi ei julkaista. Pakolliset kentät on merkitty *