[C]: Ødelagt array etter 'dynamisk' realloc()

[GeirGrusom]

HeapAlloc kaller ikke nødvendigvis VirtualAlloc. Kun hvis det er behov for det. VirtualAlloc allokerer minimum 4KB minne.

"ikke nødvendigvis" er ikke relevant, poenget er at virtualalloc må kjøre minst en gang for enhver wrapper. Og om du trekker fra denne ene gangen for å få det til å se ut som om det kan unngås, så trekker du i feil snorer. Om du kjører malloc, så må du kjøre virtualalloc EN gang. Kjører du virtualalloc, så behøver du kun å kjøre den EN gang det også, så det er ikke slik at du kan slippe å gjøre dette flere ganger enn om du kjørte virtualalloc direkte. Det er akkurat samme kostnad, men i tillegg så har malloc en overhead som har tillegskostnader som virtualalloc ikke har. Som jeg sa, den allokerer i de fleste tilfeller 4096 bytes, avhengig av hvor stor page size er på systemet. Disse 4 KB vil bli allokert EN gang og etter det behøver du ikke allokere det flere ganger om du bruker virtualalloc. Om du bruker malloc, så vil den også allokere 4 KB, og straks du utvider allokeringen og det er mangel på virtuell plass, så vil malloc flytte minnet til en annen adresse, kopiere alle dataene over til den nye adressen og så vil den måtte kjøre VirtualFree og VirtualAlloc på nytt igjen. Om du bruker VirtualAlloc rent og alene, så behøver du aldri flytte på det igjen, om du bare planlegger adressen og størrelsen godt. malloc egner seg som sagt godt til smårask fordi den allerede har allokert en eller flere pages med minne, og så kan den enkelt og greit bare dele ut en peker til en liten bit av kaka fra begynnelsen, i midten eller mot slutten istedet for å kjøre virtualalloc på nytt. Men fragmenteringen og overhead gjør at malloc ikke egner seg til medium eller store bufre som hvor kontinuitet, hastighet, aligning, fast minneadresse er viktig. Malloc fungerer effektivt til smårask pga at den kan dele ut pekere fra biter direkte fra en allerede allokert page. Derfor egner malloc seg til å bruke inni funksjoner hvor du har behov for små minne deler som du gir slipp på rett etter før du returnerer. Men denne funksjonaliteten kan også gjøres med virtualalloc direkte om det er ønskelig, det kan implementeres meget kjapt og mer effektivt enn malloc. Du kan simpelt hen allokere 10 eller flere pages i programstarten, så har du en roterende variabel, for hver gang en rutine krever minne, så kan du rotere denne variabelen slik at programmet benytter ulike deler av allokeringene for hver gang. Dette er mer effektivt enn å bruke malloc. I tillegg har du full kontroll. Du kan også bruke copyonwrite som er en tillegsfunksjonalitet. For de som er uvant med dette vil sikkert ikke ha lyst til å anstrenge seg for god minnestyring i programmet sitt, (det viktigste som er i et program). Om du har funksjoner som krever stor hastighet så for all del unngå å kjøre malloc i funksjonen, det er ikke bare tregt, men det er elendig fremgangsmåte, helt elendig mtp hva som foregår under panelet, og hva som KAN foregå i enkelte omstendigheter under panelet når du kjører malloc. Ikke bruk det om hastighet er et mål. Når man allokerer en liten bit minne med malloc så er sjansen stor for at malloc allerede har allokert nok minne og bare gi deg pekeren til det, men overheaden til dette er likevel tilstede, denne overheaden er ikke tilstede om du bruker ren virtualalloc, da har du pekeren allerede, og du kan bruke den umiddelbart. "Ja, men jeg har jo pekeren som malloc returnerte også" sier du kanskje, men sannheten er at du kjører likevel malloc flere plasser i programmet ditt allerede, på tross av det du sier. Det er normalt å kjøre malloc på flere titalls plasser. Så man kommer ikke utenom det.

Det å sitte og leke med en minneisde selv med VirtualAlloc får du bare gjøre, men å anbefale folk å benytte seg av VirtualAlloc istedet for malloc er ganske tullete.

Her er et par referanser:

Wine RtlAllocateHeap.

ReactOS RtlAlloateHeap

ReactOS malloc

VirtualAlloc erstatter ikke malloc på noen som helst måte. Kanskje det i noen programmer er greit å bruke det, men du kan ikke bruke VirtualAlloc som en generell ertsatning for malloc, fordi det er ikke det samme. I praksis kommer man til å implementere en heap-algoritme dersom en ønsker heterogen allokering av objekter, og da er det like greit å bruke malloc.

Endret 22. juni 2012 av GeirGrusom

[zotbar1234]

ISO definerer hva standarder er

 

Den spesifikke standarden, hvis referanse jeg etterspurte, definerer språket C++. Så enten har du belegg for dine påstander og da med henvisninger til de aktuelle standardene, eller lyver du.

 

Jeg spør igjen -- har du referanser til de autoritative kildene for påstandene dine?

 

Ikke sleng flere bemerkninger til meg, du er ikke halvveis opp på stigen å forstå noenting som er i nærheten av verdig å gå inn på. Det sier jeg fullt bevisst, du er bare en kranglefant som ikke forstår mer enn hva en annen typisk forstår. Du er bare et gjennomsnitt.

 

Men altså, det å diskutere sak greier du ikke? KTHX, BYE.

Endret 22. juni 2012 av zotbar1234

[LostOblivion]

LonelyMan, du presenterer mye interessant informasjon som jeg har glede av å lese.

 

*Yawn.* Zotbar, du har et kvalmende talent til å rett og slett ikke bidra til noe som helst nyttig.

[zotbar1234]

Zotbar, du har et kvalmende talent til å rett og slett ikke bidra til noe som helst nyttig.

 

Mens du med dette innlegget bidro med noe (i motsetning til ditt første svar)?

 

Dette er ikke "Samfunn"->"Foreldre og barn", men et forum for tekniske diskusjoner. Det å servere opplagt feilaktige svar gagner overhodet ingen uansett hvor nyttig disse svarene måtte være i en begrenset kontekst.

Endret 22. juni 2012 av zotbar1234

[etse]

LonelyMan, du presenterer mye interessant informasjon som jeg har glede av å lese.

 

*Yawn.* Zotbar, du har et kvalmende talent til å rett og slett ikke bidra til noe som helst nyttig.

I denne saken må jeg nok ta zotbar sin side litt; når man kommer med slike utatelser og begynner å rette på folk på en såpass detalj nivå - som egentlig i de fleste tilfeller er helt uvesentlig. (Jeg har enda igjen å se et bruktområde hvor en eventuell overhead man får ved å bruke malloc i stede for andre allokeringer er betydelige - gitt at man bruker malloc riktig that is).

 

I tillegg kommer han med påstander som ikke er helt sanne - kun om du tar visse antagelser - og kommer med disse som om de var universelle. Dette blir da feil; om han skal rette på noen må han i det minste sørge for å komme med med riktige påstander og forklare under hvilke primisser dette gjelder.

 

Han har heller ikke klart å dokumentere påstandene sine, på tross av at folk har etterspurt det.

[Zeph]

Pass på tonen her inne. Me vil vel ikkje har personangrep og dårleg stemning?

[LostOblivion]

Zotbar, du har et kvalmende talent til å rett og slett ikke bidra til noe som helst nyttig.

 

Mens du med dette innlegget bidro med noe (i motsetning til ditt første svar)?

 

Dette er ikke "Samfunn"->"Foreldre og barn", men et forum for tekniske diskusjoner. Det å servere opplagt feilaktige svar gagner overhodet ingen uansett hvor nyttig disse svarene måtte være i en begrenset kontekst.

 

Jeg snakker opplagt nok ikke om minneallokering her.

 

Poenget mitt var at dere to har en tendens til å nesten alltid pirke i det den andre sier, i denne tråden og i svært mange andre, noe som er ganske frustrerende og tar oppmerksomhet bort fra poenget med tråden. Det jeg skrev var frekt og en glipp, og det beklager jeg personlig, men vær så snill og slutte å pirke kun fordi dere har en del generelle uenigheter.

 

Å peke med fingeren på småting som hva betydningen av at et array går tom for minne er, synes jeg nå er tøysete. Formelle definisjoner trengs ikke i hverdagssammenheng, og går soleklart ut ifra kontekst.

 

Begge dere to har utrolig mange gode poenger, og jeg setter alltid pris på å lese det dere skriver, men ofte blir jeg irritert når halvparten av postene går ut på personlig sverting og motargumentering som ofte ser ut til å kun være motivert av å få kverrulert.

 

Prøv å hold det inne neste gang, og prøv å begrens dere litt med krangelen.

[zotbar1234]

Poenget mitt var at dere to har en tendens til å nesten alltid pirke i det den andre sier (...)

 

... kun når den andre serverer løgner (alternativt tar jeg feil, og da unnskylder jeg meg for det, når de rette referansene er gitt).

 

Det jeg skrev var frekt og en glipp, og det beklager jeg personlig

 

Ikke beklag, bare ikke gnål. Fremragende første innlegg.

 

(..) men vær så snill og slutte å pirke kun fordi dere har en del generelle uenigheter.

 

"Generelle uenigheter"? Den var frisk. LonelyMan serverer opplagte utilslørte løgner, basert på antagelser som hverken er nødvendige eller etterspurte; det er ikke snakk om "å pirke". Det er nettopp slik myter om 8 bits / byte, null-referanser og lignende tøys blir født (og så bruker man 1 arbeidsdag for å lete etter en feil fordi en eller annen _tosk_ tenkte "ooo, men det er jo bare å konvertere en char* til en int*, fordi at, gud, hva kan muligens gå galt med _den_ konverteringen og derefereringen av pekeren etterpå).

 

Å peke med fingeren på småting som hva betydningen av at et array går tom for minne er, synes jeg nå er tøysete.

 

Å påstå at et array "går tom for minne" er sinnsvakt tøys i C og C++. Det betyr bare en ting -- at vedkommende ikke har en fjerneste ide om hva et array er i språket.

 

Formelle definisjoner trengs ikke i hverdagssammenheng, og går soleklart ut ifra kontekst.

 

Fortell meg hvordan et array kan få en "peak" som det "åpenbart ikke tåler". Hvordan kan en person som vet hva et array er serverer slikt vås?

 

Begge dere to har utrolig mange gode poenger

 

Jeg venter fremdeles på begrunnelsen til "poengene" til LonelyMan. Dog, jeg holder ikke pusten, siden manglende standardreferanser fortalte meg alt jeg trengte å vite.

 

Prøv å hold det inne neste gang, og prøv å begrens dere litt med krangelen.

 

Ja, hva om vi alle holdt oss til utelukkende den tekniske siden (tja, f.eks. språket slik det er definert)? Du kan begynne med deg selv (og ta evt. problemer med min fremføringsmåte med meg personlig, heller enn å selv spore av i det som skulle ha vært en teknisk tråd).

[tomsi42]

Det var spåass mye usaklig tøys i denne tråden at jeg hadde lovet meg selv å holde kjeft. Men det holdt jo ikke.

 

Å peke med fingeren på småting som hva betydningen av at et array går tom for minne er, synes jeg nå er tøysete.

 

Å påstå at et array "går tom for minne" er sinnsvakt tøys i C og C++. Det betyr bare en ting -- at vedkommende ikke har en fjerneste ide om hva et array er i språket.

Du er inne på noe her. Men det finnes jo en del språk hvor arrayene er dynamiske; f.eks. gode gamle basic; der går man ikke tom for minne før det ikke er minne igjen. I dag styres det av OS; men i gode gamle dager, når vi f.eks. hadde en ABC-80 tilgjengelig; så er vel "OS" å skryte på seg for mye...

 

Men går vi over på kompilerte språk, så håndteres arrays på en helt annen måte. I dette tilfelle, C (og C++) så er det så enkelt at minne til arrays allokeres enten ved program-oppstart eller når en funksjon kalles*. Så lenge det er minne nok til å sette av plass til arrayet; så vil man få arrayet. Eller så vil programmet krasje med en ufin melding. Men så lenge du har fått arrayet, så er det tilgjengelig. Det er ingenting, utenom bugs, som stikker av med det minnet.

 

*) I de tilfellene vi kaller malloc (& venner) så er de minneområden våre til vi frigjør de.

Endret 22. juni 2012 av tomsi42

[zotbar1234]

Men det finnes jo en del språk hvor arrayene er dynamiske;

 

... og hadde bare tråden startet med et spørsmål om slike språk.

 

Utsagnet om arrays som har "peaks" som de "åpenbart ikke tåler" er vrøvl i C og C++. At det kan gi mening i andre språk er i dette tilfellet uvesentlig.

Endret 23. juni 2012 av zotbar1234

[LostOblivion]

Jeg skjønner poenget ditt med at det ikke er en veldig god formulering. Det betyr nærmest minnet går tomt for minne, som ikke gir mening, men kun i en runtime-sammenheng for implementasjonen av språket. I en ren språklig sammenheng, gir det perfekt mening at et array går tomt for minne. Du blander sammen de to sidene av saken, og avviser det derfor som en merkelig formulering og vrøvel. Jeg har allikevel god forståelse for at du gjør denne feilaktige observasjonen, ettersom C/C++ er språk som er svært intimt knyttet til implementasjonen, særlig i forhold til andre språk.

 

Uansett kunne det kanskje blitt formulert som bruken overstiger minnet allokert til arrayet, men det er fortsatt opplagt hva det er snakk om--derfor unødvendig pirking og bais-verdt kommentarer, likt mye av den andre argumentasjonen din.

 

Om du ikke klarer å la vær å kverrulere i det du kaller en "teknisk diskusjon", synes jeg du skal gå tilbake til universitetet og lære hva kandidater til teknisk diskusjon faktisk er, før du latterliggjør deg selv. I "tekniske" problemstillinger verdt å diskutere, kverrulerer man ikke om slike småting overlatt til definisjonene, men faktisk prøver å legge fram argumenter som bidrar til en løsning på problemstillingen.

 

Bare så det er klart: Jeg påklager ikke dine andre påstander ang. malloc og OS-spesifikke prosedyrer for allokering av minne.

Endret 23. juni 2012 av LostOblivion

[zotbar1234]

I en ren språklig sammenheng, gir det perfekt mening at et array går tomt for minne.

 

Vis meg hvor i ISO 9899 eller ISO 14882 denne formuleringen finner sted.

 

Uansett kunne det kanskje blitt formulert som bruken overstiger minnet allokert til arrayet, men det er fortsatt opplagt hva det er snakk om (...)

 

Nei, det er ikke opplagt hva det å få en "peak" for et array betyr, eller hvordan arrayet "åpenbart ikke tåler" det.

 

Jeg er også nysgjerrig på hva "bruken overstiger minnet allokert til arrayet" betyr, forutsatt at man holder seg innen grenser som en implementasjon må respektere for å være i tråd med standarden. Enten er arrayobjektet allokert, eller ikke -- det finnes intet forbehold for fremtidig bruk i forhold til allokert plass. Iallfall ikke slik jeg leser standarden (men korriger meg gjerne, hvis du ser en annen tolkning).

 

Om du ikke klarer å la vær å kverrulere (...)

 

Must... resist...

 

I "tekniske" problemstillinger verdt å diskutere, kverrulerer man ikke om slike småting overlatt til definisjonene, men faktisk prøver å legge fram argumenter som bidrar til en løsning på problemstillingen.

 

Enhver teknisk diskusjon begynner med definisjoner og problemområdeinnsnevring, som man siden holder seg til. LonelyMan feilet spektakulært, der også.

 

edit: trykkfeil

Endret 23. juni 2012 av zotbar1234

[LostOblivion]

Vis meg hvor i ISO 9899 eller ISO 14882 denne formuleringen finner sted.

Herregud da, mann, det er ikke vanskelig å forstå. Det er ikke en gitt mening annet enn den gitt ut fra sammenhengen, navngitt, sammenhengen med resten av det LonelyMan skriver. Er alt du skriver sitert fra en standardization definition paper?

 

Nei, det er ikke opplagt hva det å få en "peak" for et array betyr, eller hvordan arrayet "åpenbart ikke tåler" det.

Nei, men det er det ut ifra sammenhengen. Du er et menneske, ikke en kontekst-fri maskin, du burde være i stand til å se mening ut ifra kontekst, men tydeligvis er dette vanskelig for deg.

 

Jeg er også nysgjerrig på hva "bruken overstiger minnet allokert til arrayet" betyr, forutsatt at man holder seg innen grenser som en implementasjon må respektere for å være i tråd med standarden. Enten er arrayobjektet allokert, eller ikke -- det finnes intet forbehold for fremtidig bruk i forhold til allokert plass. Iallfall ikke slik jeg leser standarden (men korriger meg gjerne, hvis du ser en annen tolkning).

Når du har allokert plass til et array, bruker du det ikke? Dvs, bruker du ikke arrayet ved å skrive til det med egne, fornuftige data? Det er dette som er essensen i det vi snakker om her. Stipulerer denne bruken et krav om mer minne enn det som er allokert for arrayet, kan man påstå at arrayet begynner å "peake".

 

Must... resist...

Du feilet.

Endret 23. juni 2012 av LostOblivion

[zotbar1234]

Herregud da, mann, det er ikke vanskelig å forstå.

 

Jo, det er det. Et array kan ikke "gå tomt for minne" -- plassallokeringen enten lykkes, eller ikke. Det er ikke slik at arrayet utvides dynamisk og en utvidelsesallokering senere kan feile. Så, med bakgrunn i hva (i de respektive standardene) skulle det være lett å forstå hvordan et array kan gå tomt for minne?

 

Er alt du skriver sitert fra en standardization definition paper?

 

Standardization definition paper?

 

Det til side -- ja, jeg prøver å uttale meg på bakgrunn av det som står i standarden. Den definerer språket, ikke nissevås spesifikt for en windowsimplementasjon.

 

Nei, men det er det ut ifra sammenhengen. Du er et menneske, ikke en kontekst-fri maskin, du burde være i stand til å se mening ut ifra kontekst, men tydeligvis er dette vanskelig for deg.

 

Siden det er opplagt for deg, hvordan er det et array får en "peak" som det "åpenbart ikke tåler"?

 

Jeg er også nysgjerrig på hva "bruken overstiger minnet allokert til arrayet" betyr, forutsatt at man holder seg innen grenser som en implementasjon må respektere for å være i tråd med standarden. Enten er arrayobjektet allokert, eller ikke -- det finnes intet forbehold for fremtidig bruk i forhold til allokert plass. Iallfall ikke slik jeg leser standarden (men korriger meg gjerne, hvis du ser en annen tolkning).

 

Når du har allokert plass til et array, bruker du det ikke?

 

Det er uvesentlig. I det kontrollen går forbi ";" for arraydefinisjonen, finnes objektet i sin helhet (gitt at man allokerer et objekt som er innad minstekravet til implementasjonen) -- det er betydningen av en "sequence point". Det er umulig å få noen allokeringsproblemer etter det (det er fullt mulig å ikke få plass til andre objekter, men det spesifikke objektet finnes og kan ikke "gå tomt for minne"), eller før det, men ikke med det aktuelle arrayobjektet, etter at det er definert. Hvordan et array skal "tåle" noe er også en gåte for meg. Hvordan i alle dager "tåler" et array noe som helst? Gjelder det enums? structs? Finnes det toleransegrenser?

 

Hvor i alle dager graver folk fram slikt tøys?

 

edit: har visst glemt litt

Endret 24. juni 2012 av zotbar1234