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

[Lycantrophe]

Jeg pusler litt med et par hjelpemetoder for å tukle med arrays, men har et problem med realloc, eller snarere det jeg tror er en brukket pointer.

 

Jeg har:

 

Defines:

#define expand(TYPE, source, size) \
(TYPE *)expand_array( (void *)(source), (size), sizeof(TYPE) );

 

void* expand_array( void *source, int *size, size_t s ) {
(*size) *= 2;
void *ret = realloc( source, (*size) * s );
if( !ret ) {
	fprintf( stderr, "out of memory or other memory error\n" );
	exit( 1 );
}
source = ret;
return source;
}

 

void append( int *source, int *last, int *size, int elem ) {
++(*last);
if( (*last) == (*size) )
	source = expand( int, source, size );

source[ *last ] = elem;
}

 

Ideen er at jeg skal kunne legge til elementer på slutten av arrayen uten å måtte bekymre meg for bounds.

 

Problemet er dette: Når jeg har appendet så mye at expand() må kalles blir innholdet ødelagt, det vil si jeg får plutselige verdier (0) som ikke var i den opprinnelige arrayen.

 

for( i = 0; i &--#60; size; ++i ) {
	// Skip the chosen pivot
	if( i == pivindex ) { /* do not do anything */ }
	else if( source[ i ] &--#60;= pivot )
		append( less, &lesslast, &lesslen, source[ i ] );
	else
		append( greater, &greatlast, &greatlen, source[ i ] );
}

 

Som mange sikkert ser er det quicksort.

 

Jeg prøvde å skrive ut arrayen før og etter expand() blir kalt (inne i append-metoden), og da fikk jeg en identisk output (som forventet). Problemet er når den returnerer og kommer tilbake til quicksort, akkurat som om pekeren ikke lenger peker til riktig blokk.

 

Er det noen som ser hva jeg gjør feil?

Endret 6. mai 2012 av Lycantrophe

[GeirGrusom]

Du sender inn size som verdi istedet for referanse.

[Lycantrophe]

I append? Den tar inn int *size. Blir det ikke da riktig å sende pekeren (som verdi) videre?

 

Edit: Denne?

source = expand( int, source, size );

Endret 7. mai 2012 av Lycantrophe

[GeirGrusom]

Ah kanskje jeg som var litt trøtt på morgen.

[LostOblivion]

Problemet er at du aldri setter pekeren til arrayet til det nye minneområdet som realloc allokerer. Dette er fordi du gir med pekeren til det første elementet, og ikke en peker til pekeren til arrayet. Pekeren vil derfor etter et kall på realloc peke til et gammelt minneområde, som kan inneholde hva som helst. Du må derfor gi append pekeren til arrayet, dvs følgende.

 

int arr[5];
int last = 0;
int size = 5;
append(&arr, &last, &size, 42);

 

Oppdatert kode. Har ikke testet, men håper du skjønner hva jeg mener.

 

#define expand(T, source, size) \
 expand_array((void **) (source), (size), sizeof(T));

 

void expand_array(void ** source, int * size, size_t element_size) {
 *size = *size * 2
 void * ret = realloc(source, *size * element_size);
 if (ret == NULL) {
   fprintf(stderr, "Out of memory\n");
   exit(1);
 }
 *source = ret;
}

 

void append(int ** source, int * last, int * size, int elem ) {
 *last = *last + 1;
 if (*last == *size)
   expand(int, source, size);
 (*source)[*last] = elem;
}

 

Eventuelt kan du la append returnere en peker til det nye arrayet, så slipper du så mye pekermagi i brukergrensesnittet. Det var dette du gjorde i array_expand, men du glemte det i append.

Endret 7. mai 2012 av LostOblivion

[LonelyMan]

malloc er en del av c++ runtime og er en wrapper for virtualalloc. Har du store arrays, eller forsåvidt, medium store arrays og t.o.m små arrays så anbefaler jeg at du bruker virtualalloc direkte. Så reserverer du en mengde systemminne i programstarten, en mengde som ikke er for liten og heller ikke for stor, den må ha mulighet for å ekspandere litt.

 

For all del unngå å reallokere små biter med minne regelmessig. Om du allokerer 1 KB med minne så allokerer systemet mest sannsynlig 4 KB for deg for det er det mest vanlige størrelsen per page. Aldri alloker mindre enn page size når du arbeider med store arrays, og spesielt ikke hvis du ønsker maksimal ytelse.

 

Om du allokerer bare så lite som 1 byte, så vil operativsystemet gi deg 4096 bytes med minne, bare for å dekke den ene byten din. Allokerer du 30 bytes så får du også 4096 bytes med minne. Allokerer du 690 bytes, så får du også 4096 bytes med minne. Allokerer du 4097 bytes, så får du 8192 bytes fra operativsystemet.

 

Trikset her er å forstå hvordan systemet deler ut minne og granulariteten i systemet. På de fleste windows systemer er page størrelsen 4096 bytes og granulariteten 65536.

 

Når arrayet ditt er gått tom for minne, så utvid det med multipler av pagesize. Styr unna malloc og realloc, det lager et nodesystem som degraderer ytelsen. Bruker du virtualalloc så burde du reservere minne i programstarten og ikke drive å tulle med dette langt ut i programmets levetid. Målet er å forsøke å unngå reallokering, og det gjør du ved å estimere peaken på arrayet ditt. Finn peaken ved å kjøre programmet en stund og mål det høyeste bruksnivået.

 

Hver gang du kjører realloc så kopierer den alle data fra arrayet ditt over til den nye adressen som os'et gir malloc (om den ikke får beholde den nåværende adressen), det er ekstremt belastende da minneoverføringer er tregt.

 

Kutt ut malloc og lær deg å bruke VirtualAlloc, VirtualFree og VirtualLock. Disse er rene minnefunksjoner og gir deg full kontroll.

Endret 20. juni 2012 av LonelyMan

[zotbar1234]

malloc er en del av c++ runtime og er en wrapper for virtualalloc.

 

Kilde for denne påstanden? (spesielt for "virtualalloc").

 

Om du allokerer bare så lite som 1 byte, så vil operativsystemet gi deg 4096 bytes med minne, bare for å dekke den ene byten din. Allokerer du 30 bytes så får du også 4096 bytes med minne. Allokerer du 690 bytes, så får du også 4096 bytes med minne. Allokerer du 4097 bytes, så får du 8192 bytes fra operativsystemet.

 

... kanskje. Og det er virkelig feil ting å bry seg om, med mindre profilering tilsier noe annet. Det er nettopp derfor man har allocators (for å flikke på slikt tøys uten å forstyrre programmet forøvrig).

 

Når arrayet ditt er gått tom for minne,

 

Nå er jeg spent, eksakt hva betyr dette utsagnet? Og hvordan kan et array "gå tom" for minne?

 

Kutt ut malloc og lær deg å bruke VirtualAlloc, VirtualFree og VirtualLock. Disse er rene minnefunksjoner og gir deg full kontroll.

 

Hva med oss som ikke har VirtualAlloc?

[GeirGrusom]

Dette er ihvertfall det malloc gjør i MSVCRT på Wine:

void *ret = HeapAlloc(GetProcessHeap(),0,size);

 

Forøvrig en artikkel på MSDN om dette:

Heap Function

 

Jeg vil påstå at det er bedre å bruke malloc: det funker på alle systemer, og overhead på det funksjonskallet er så og si fraværende, uansett hva det wrapper rundt.

 

edit: Forumet ødela lenken

Endret 21. juni 2012 av GeirGrusom

[LonelyMan]

malloc er en del av c++ runtime og er en wrapper for virtualalloc.

Kilde for denne påstanden? (spesielt for "virtualalloc").

 

hehe, hvorfor tror du at malloc er en selvstendig funksjon? malloc kan ikke tilegne seg minne på egen hånd, det er operativsystemet som deler ut minne, og kun operativsystemet. malloc må først hente minnet fra operativsystemet, og deretter kan den gjøre hva det vil med minnet, den kan lagre pekere til det lokalt og senere dele det ut igjen som det finner for godt, og eventuelt splitte det opp i noder og dele ut biter av det, det er en del av minnebehandlingen internt i malloc. Men malloc MÅ hente minnet gjennom operativsystemet, og det skjer kun gjennom virtualalloc. Om malloc bruker heapalloc, så skjer det også gjennom virtualalloc, heapalloc er også en wrapper for virtualalloc.

Hvis malloc bruker heapalloc, så ser strukturen slik ut:

 

1 kall, malloc

2 kall, heapalloc

3 kall, virtualalloc

 

Det blir til syvende og sist virtualalloc som må kjøre, og det hele blir en lang omvei bare for å nå ut til virtualalloc.

De selger masse bøker om akkurat dette emnet, jeg anbefaler deg at du kjøper en for jeg ser at du stilte et spørsmål som baserer seg på feil forståelse og premisser; Det er et absolutt at malloc må gå gjennom virtualalloc, så at du stilte dette spørsmålet til å begynne med sier meg at du ikke forstår dette.

 

Om du allokerer bare så lite som 1 byte, så vil operativsystemet gi deg 4096 bytes med minne, bare for å dekke den ene byten din. Allokerer du 30 bytes så får du også 4096 bytes med minne. Allokerer du 690 bytes, så får du også 4096 bytes med minne. Allokerer du 4097 bytes, så får du 8192 bytes fra operativsystemet.

 

... kanskje. Og det er virkelig feil ting å bry seg om, med mindre profilering tilsier noe annet. Det er nettopp derfor man har allocators (for å flikke på slikt tøys uten å forstyrre programmet forøvrig).

 

Det er en misforståelse, eller mangel på forståelse det du sier om at man forstyrrer programmet ved å bruke virtualalloc, når malloc gjør akkurat det samme, og mer enn det.

 

Når arrayet ditt er gått tom for minne,

 

Nå er jeg spent, eksakt hva betyr dette utsagnet? Og hvordan kan et array "gå tom" for minne?

 

arrayet er tom for minne når behovet overgår opprinnelig estimert størrelse på minnet, da har du fått en peak som arrayet åpenbart ikke tåler.

 

Kutt ut malloc og lær deg å bruke VirtualAlloc, VirtualFree og VirtualLock. Disse er rene minnefunksjoner og gir deg full kontroll.

 

Hva med oss som ikke har VirtualAlloc?

 

Alle operativsystemer har sine rene minnefunksjoner, om du ikke har virtualalloc, så har den garantert en tilsvarende variant. Jeg ser at du har litt manglende forståelse for hvordan operativsystem fungerer, men nå har du iallefall fått litt info fra meg da.

[LonelyMan]

Når det gjelder malloc så er den designet for å gjøre "smårask" i funksjoner hvor du behøver små biter med minne for å utføre enkle oppgaver, for så å frigjøre det igjen ganske raskt. Når jeg sier "kutt ut malloc", så ikke bruk den som en universell minneallokeringsmetode. Bruk den for smårask, og bruk virtualalloc når du skal lage et seriøst program eller spill.

 

Og det er enkelt å bruke den, her er et eksempel på parameterne, her lager vi en page med minne, og gjør den lesbar og skrivbar. Du kan bruke virtualalloc til å lage kjørbare sider også, om du har dynamisk kode du vil putte inn der, så er det også mulig.

 

VirtualAlloc, NULL, STØRRELSE, MEM_RESERVE or MEM_COMMIT, PAGE_READWRITE

 

Om størrelsen er 1, så får du 1 page som er på 4096 bytes. Husk at det fysiske minnet blir ikke allokert før du faktisk bruker minnet, leser eller skriver til det, først da tilegner operativsystemet fysisk minne til den siden med minne.

 

Du kan finne pagesize på systemet ved å kjøre GetSystemInfo, så finner du pagesize i SYSTEM_INFO strukturen under navnet dwPageSize.

 

Om du ønsker å allokere 1 million bytes, så ser parameterne slik ut:

 

VirtualAlloc, NULL, 1000000, MEM_RESERVE or MEM_COMMIT, PAGE_READWRITE

 

For å finne ut hvor mange faktiske sider med minne du har fått, så kan du dele 1000000/PageSize, om du har en rest etter delingen (bruk modulus) så har du EN ekstra page og du har fått litt mer minne enn du ba om.

 

En av de fine tingene med VirtualAlloc er at du kan selv bestemme foretrukken adresse for minnet, dette kan du ikke bestemme om du bruker malloc. Poenget med å bestemme foretrukken adresse selv kan være mange grunner. Om du ønsker å benytte deg av pipes mellom to programmer kan det lønne seg å ha statisk adresse slik at adressen aldri endrer seg mellom hver gang du avslutter og starter programmet. Eller det kan være optimaliseringsteknikker som opererer på tall som er spesifik til adressen, det kan være mange grunner.

Endret 21. juni 2012 av LonelyMan

[GeirGrusom]

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

Endret 21. juni 2012 av GeirGrusom

[LonelyMan]

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.

Endret 21. juni 2012 av LonelyMan

[zotbar1234]

malloc er en del av c++ runtime og er en wrapper for virtualalloc.

Kilde for denne påstanden? (spesielt for "virtualalloc").

 

hehe, hvorfor tror du at malloc er en selvstendig funksjon?

 

Siden du ikke forstod spørsmålet, la meg gjenta -- på hvilket grunnlag hevder du at "malloc er en del av c++ runtime og er en wrapper for virtualalloc"? (det er spesielt den siste biten jeg er nysgjerrig på, siden virtualalloc ikke eksisterer på en rekke platformer).

 

Men malloc MÅ hente minnet gjennom operativsystemet, og det skjer kun gjennom virtualalloc.

 

Nei, det må det ikke (hint: nå kommer du med en autoritativ referanse som tilsier at det er slik. Husk også at det holder med _ett_ moteksempel for å motbevise dette sinnsvake vrøvlet du serverer, og det moteksempelet heter eksempelvis brk()/sbrk(). Nå, har du lyst til å revidere påstanden din?)

 

Hvis malloc bruker heapalloc (...)

 

Ah, nettopp -- hvis. Og hvis ikke?

 

De selger masse bøker om akkurat dette emnet, jeg anbefaler deg at du kjøper en for jeg ser at du stilte et spørsmål som baserer seg på feil forståelse og premisser;

 

Vis meg hvor standarden sier at malloc() skal bruke virtualalloc før du kommer med flere verdiløse anbefalinger.

 

Det er et absolutt at malloc må gå gjennom virtualalloc, så at du stilte dette spørsmålet til å begynne med sier meg at du ikke forstår dette.

 

Pisspreik, igjen. Det er massevis av implemetnasjoner der dette ikke er tilfellet (jeg skriver dette innlegget i en omgivelse der malloc() ikke er implementert vha virtualalloc). Derimot, det at du hevder at malloc må gjennom virtualalloc tyder på alvorlige kunnskapsgap om portabilitet.

 

Så hva om du viser hvor i språkdefinisjonen det foreligger et krav om hvordan malloc() skal implementeres eller holder opp med å spre feilinformasjon?

 

arrayet er tom for minne når behovet overgår opprinnelig estimert størrelse på minnet, da har du fått en peak som arrayet åpenbart ikke tåler.

 

Interessant. Nå er jeg spent, siden et array ikke er dynamisk utvidbar, hvorda går man "tom for mine" for et array? Når (array)objektet først er allokert (der størrelsen er kjent statisk eller, slik det er tilfellet med f.eks. VLA-er, dynamisk), kan ikke det arrayet utvides. Vær så snill, fortell hvor i ISO/IEC 14882 er det man finner beskrivelsen av hvordan et array kan få en "peak" som det "åpenbart ikke tåler".

 

Alle operativsystemer har sine rene minnefunksjoner, om du ikke har virtualalloc, så har den garantert en tilsvarende variant.

 

Det var ikke det du hevdet opprinnelig. Du skrev:

 

Det er et absolutt at malloc må gå gjennom virtualalloc (...)

 

... noe som er feil.

 

Jeg ser at du har litt manglende forståelse for hvordan operativsystem fungerer, men nå har du iallefall fått litt info fra meg da.

 

Hadde bare denne "infoen" vært korrekt.

 

edit: et par teite trykkfeil

Endret 21. juni 2012 av zotbar1234

[LonelyMan]

Punkt nummer 1.

Når jeg sier at det er et absolutt at malloc må gå gjennom virtualalloc, så er det overveiende sannsynlig at jeg snakker om windows plattformen, at du da velger å tolke dette som om det var snakk om en annen plattform er en feil måte å tolke informasjon på. Jeg nevnte helt klart en windows spesifik funksjonalitet, og da er det naturlig å tolke hva jeg sa i den retningen, når trådstarter ikke nevner plattform så er det naturlig for meg å ta utgangspunkt i den mest utbredte, men på tross av dette, så må du likevel gå en liknende vei i andre plattformer med tilsvarende varianter, så selv om du tolket dette feil så holder det likevel mål for andre plattformer også som jeg sa.

 

Punkt 2.

Jeg har ikke kunnskapsgap om portabilitet. Når vi snakker om c++ og portabilitet så er ikke c++ et portabelt dataspråk. Pseudo-språket c++ derimot, er portabelt og årsaken til at c++ er portabelt er fordi det ikke er et dataspråk til å begynne med, ingenting av det du skriver i editoren din er brukelig for en datamaskin, hver eneste linje du skriver der, er så fremmed for maskinvaren at den ville krasjet bare ved å snuse på det. Når det ikke er et dataspråk til å begynne med så kan du i prinsippet også gjøre det portabelt helt til månen, du kan gjøre det portabelt ned til en ubåt, du kan portere det til et ferieparadis og portere det inn i kjøleskapet også. Men du kan jaggu også portere en pakke med leverpostei i samme retning, (grunnen til at c++ passer så godt overalt og er portabelt er fordi det er helt nøytralt, tolkningsmateriale) for begge disse to ikke har noen verdens ting med datamaskiner å gjøre i det hele tatt. Det du skriver i editoren din er kommandoer til den som har skrevet kompilatoren du bruker, c++ koden din inneholder instruksjoner til forfatteren av kompilatoren. For å ta et lite eksempel, som ikke har med c++ å gjøre, men et pseudo eksempel:

 

Du skriver i editoren "Sett x til å være 10", så tolker kompilatoren (som består av flere deler, inkludert en linker). Så tolker den som skrev kompilatoren dette som en request til han om at du har gitt den et symbol x og at du vil den skal være 10. Men dette har ingen verdens ting med datamaskiner å gjøre.

 

Eller du kan gjøre følgende:

 

"kjør dette 100 ganger" (en loop), så vil tolkningen bli at det blir overført til noe teknisk som datamaskinen kan forstå og du behøver ikke bry deg med hvordan det fungerer.

 

Punkt 3.

Dette med at et array kan gå tom for minne, jeg tror du tenker som så at, "en bil er en bil" og så tenker du bare på den definitive sannheten i øyeblikket, men ser du utenfor denne lite dynamiske filosofien i det hverdagslige hvor arrayer har varierende behov, hvilket i denne tråden det var snakk om (jeg holder meg til trådens emne), hvor vi spesifikt snakker om å ordne opp i en ødelagt array hvor det åpenbart snakkes om og planlegges for utvidelse, så er det jeg sier det mest relevante. Men såklart, "en bil er en bil", men dette er flisespikkeri, og de fleste som driver flisespikkeri de er som regel kunnskapsløse.

 

Min konklusjon om deg er at du ikke har peiling på datamaskiner eller om optimalisering. Jeg har holdt på med dette og har lært meg dette over en lang periode, du er ikke i nærheten av å forstå hva optimalisering innebærer på det jeg leser av deg.

 

Du har ikke peiling på datamaskiner eller maskinvaren eller det som foregår inni der, og ikke om operativsystemer heller.

 

Jeg merker meg dog at du forsøker å lære meg ting, og på tross av at det føles som om en mus skal belære en katt, så setter jeg pris på det, faktisk. Det er underholdende.

Endret 21. juni 2012 av LonelyMan

[Lycantrophe]

Skrev greiene mest for å teste nettopp hvordan sånt fungerte i C, men én bemerkning føler jeg passer inn nå:

 

Jeg sitter ikke på Windows skriver ikke C for Windows, så for min del er Windows-spesifikke ting HELT uinteressant.

[tomsi42]

Hvordan malloc er implementert er helt uinteressant, er jeg enig i. Og dette er vel strengt tatt ikke Windows spesifikt, men Microsoft C/C++ spesifikt.

 

Jeg vil si at en av de viktigste grunnene til å velge et språk som C og C++ er fordi man ønsker å være platform-uavhengig. Det finnes mer egnede språk for effektiv programmering på Windowsplatformen i mine øyne.

 

Jeg ser at du fikk et svar på hvorfor koden din kke virket - håper du fant det innimellom digresjonen.

[Lycantrophe]

LostOblivions var ikke så dumt, og jeg kom ganske langt på vei (før jeg kom på noe annet å gjøre og gjorde det i stedet :>)

[LonelyMan]

Hvordan malloc er implementert er helt uinteressant, er jeg enig i. Og dette er vel strengt tatt ikke Windows spesifikt, men Microsoft C/C++ spesifikt.

 

Jeg vil si at en av de viktigste grunnene til å velge et språk som C og C++ er fordi man ønsker å være platform-uavhengig. Det finnes mer egnede språk for effektiv programmering på Windowsplatformen i mine øyne.

 

Jeg ser at du fikk et svar på hvorfor koden din kke virket - håper du fant det innimellom digresjonen.

 

Jeg har uthevet og understreket den digresjonen du snakker om.

[zotbar1234]

Punkt nummer 1.

Når jeg sier at det er et absolutt at malloc må gå gjennom virtualalloc, så er det overveiende sannsynlig at jeg snakker om windows plattformen, at du da velger å tolke dette som om det var snakk om en annen plattform er en feil måte å tolke informasjon på.

 

Jeg må ingenting utøver å lese det du skriver. La meg gjenta, siden du glemmer dine egne utsagn:

 

Det er et absolutt at malloc må gå gjennom virtualalloc (...)

 

Hadde du skrevet at på noen windowsimplementasjoner så er malloc() implementert via virtualalloc(), ville ingen ha protestert. Men du greide jo å servere det søppelet over uten forbehold.

 

.

Jeg nevnte helt klart en windows spesifik funksjonalitet, og da er det naturlig å tolke hva jeg sa i den retningen, når trådstarter ikke nevner plattform så er det naturlig for meg å ta utgangspunkt i den mest utbredte (...)

 

Det mest naturlige er å ikke gjøre tåpelige platformspesifikke antagelser når man ikke trenger det.

 

men på tross av dette, så må du likevel gå en liknende vei i andre plattformer med tilsvarende varianter,

 

Nei, det må man ikke (dette er en test: hvorfor ikke?)

 

så selv om du tolket dette feil (...)

 

Du satte ingen forbehold på tøyset du serverte. At du senere forsøker å introdusere dem, gjør ikke ditt opprinnelige utsagn mer korrekt.

 

Jeg har ikke kunnskapsgap om portabilitet.

 

That much is obvious. Men hva om du skaffet deg litt innsikt om emnet, før du begynte å dele råd?

 

Når vi snakker om c++ og portabilitet så er ikke c++ et portabelt dataspråk. Pseudo-språket c++ derimot, er portabelt og årsaken til at c++ er portabelt er fordi det ikke er et dataspråk til å begynne med, ingenting av det du skriver i editoren din er brukelig for en datamaskin, hver eneste linje du skriver der, er så fremmed for maskinvaren at den ville krasjet bare ved å snuse på det.

 

Jeg er nysgjerrig på hvordan maskinvare "snuser på det". Antageligvis stammer det fra samme land der C++ arrays har "peaks" og går "tomme for minne".

 

Du skriver i editoren "Sett x til å være 10", så tolker kompilatoren (som består av flere deler, inkludert en linker).

 

Det er underholdende å bli undervist i kompilatorkonstruksjon av en som har misforstått hva et array er i C++. Men for all del, fortsett.

 

Dette med at et array kan gå tom for minne, jeg tror du tenker som så at, "en bil er en bil"

 

Akkurat. Mao. du vet ikke hva et array er.

 

Jeg gjentar, siden mitt spørsmål opplagt unnslapp deg -- fortell hvor i ISO/IEC 14882 er det man finner beskrivelsen av hvordan et array kan få en "peak" som det "åpenbart ikke tåler".

 

og så tenker du bare på den definitive sannheten i øyeblikket, men ser du utenfor denne lite dynamiske filosofien i det hverdagslige hvor arrayer har varierende behov, hvilket i denne tråden det var snakk om

 

Les mitt forrige spørsmål en gang til, er du snill, før du kommer med flere pinlige og malplasserte allegorier.

 

(jeg holder meg til trådens emne)

 

Neppe, windows"optimaliseringstipsene" dine tatt i betraktning.

 

Men såklart, "en bil er en bil", men dette er flisespikkeri, og de fleste som driver flisespikkeri de er som regel kunnskapsløse.

 

Mens du er en utømmelig kilde for kunnskap (om enn med stadig større fravær av begrunnelser). Jeg kan ikke annet enn beundre påståeligheten av en som ikke greier å begrunne en eneste påstand med den autoritative referansen (være det 1998 utgaven eller nyere dato).

 

Min konklusjon om deg er at du ikke har peiling på datamaskiner eller om optimalisering. Jeg har holdt på med dette og har lært meg dette over en lang periode, du er ikke i nærheten av å forstå hva optimalisering innebærer på det jeg leser av deg.

 

Men, altså, fremdeles ingen autoritative referanse til det jeg etterspurte?

[LonelyMan]

ISO definerer hva standarder er, ikke hva problemstillingene kan være, i dette tilfellet er et fullt array et problem, ikke for meg i dette tilfellet, men for enkelte andre. 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.

Endret 22. juni 2012 av LonelyMan