[c++] new voor geheugen met grootte - Softwareontwikkeling

vrijdag 18 oktober 2002 17:15

Acties:

Verwijderd

Topicstarter

De operator "new" alloceerd dus geheugen voor een bepaald type. Nu wil ik hem gebruiken om een stukje te alloceren met een bepaalde grootte (vb: 8 bytes).

Ik heb een functie (heeel erg versimpelt) die ongeveer dit doet:

code:

void mem_alloc(void *&var, const int size)
{
  var = (void *)unsigned char[size];
}

Mijn theory is dan:
Een "unsigned char" is 1 byte. Hij alloceerd dus een stukje van "size" bytes. Dit wordt gecast naar "void", zodat het overal voor te gebruiken is (die cast kan ik ook weglaten, maar ff voor het verhaal).

Als ik nou dit doe:

code:

  ...
  char *bla = 0;
  mem_alloc((void *&)bla, 3);
  str.copy(bla, "12345678");  // deze werkt, echt waar :-)
  printf(bla);
  ...

laat de printf-regel ook echt "12345678" zien !!

Dit zou niet mogen, er zijn 3 bytes gealloceerd, maar heeft er 8 (+1 voor de \0) nodig... Ook als ik "bla" weer vrijgeef en het proggie afsluit, gaat alles goed !! Hij zou volgens mij een access-violation moeten geven...

kan iemand mij dit uitleggen ?? $_/-\o_$

vrijdag 18 oktober 2002 17:24

Acties:

cameodski

Je zou haast gaan denken dat de copy functie (indien nodig?) zelf geheugen gaat alloceren.

Never underestimate the power of

vrijdag 18 oktober 2002 17:26

Acties:

Verwijderd

Dat heet een buffer overflow. Je schrijft in geheugen waar je niet mag zijn. Aangezien je 3 bytes alloceert, zou je maar een (null terminated) string van 2 karakters mogen wegschrijven. Echter als je wat alloceert met mem_alloc wordt er meestal wel een redelijk stuk gealloceerd, bijvoorbeeld veelvouden van 1kb of meer, dus crasht je systeem niet meteen doordat je een buffer overflow genereert hiero.
Maar dit is echt helemaal geen C++ code, dit is typisch C en oerlelijk om in C++ te gebruiken....

vrijdag 18 oktober 2002 17:29

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

geheugen management routines alloceren meestal niet per byte, maar in blokken van 8 of 16 bytes (of een andere grootte, meestal macht van 2). Bovendien hoeft het eind van je buffer nog niet per se het eind van je heap te zijn, dus je overschrijft vrolijk alles wat erachter staat, met alle gevolgen van dien

waarom wil je trouwens memory alloceren met een eigen functie?

.edit: note to self: niet irc'en tijdens het posten

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

vrijdag 18 oktober 2002 17:30

Acties:

Verwijderd

Verwijderd schreef op 18 oktober 2002 @ 17:26:
Dat heet een buffer overflow. Je schrijft in geheugen waar je niet mag zijn. Aangezien je 3 bytes alloceert, zou je maar een (null terminated) string van 2 karakters mogen wegschrijven. Echter als je wat alloceert met mem_alloc wordt er meestal wel een redelijk stuk gealloceerd, bijvoorbeeld veelvouden van 1kb of meer, dus crasht je systeem niet meteen doordat je een buffer overflow genereert hiero.
Maar dit is echt helemaal geen C++ code, dit is typisch C en oerlelijk om in C++ te gebruiken....

veelvouden van 1kilobyte zou me verbazen, maar het is inderdaad zo dat er niet echt 3 bytes gealloceerd worden. Theoretisch wel, maar in de praktijk sowiezo in veelvouden van 4. En daar komt bij dat er door het OS niet per byte de access rights worden bijgehouden. Dus het kan best zijn dat er een heel stuk geheugen na die drie bytes zonder problemen overschreven KAN worden (je local heap). Het mag natuurlijk niet maar het kan.
En kijk nog eens naar naar je mem_alloc, ik weet jappie dat ie er niet ZO uitziet als je hier laat zien.

offtopic:
jappie, moet jij geen huiswerk maken?

vrijdag 18 oktober 2002 17:41

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op 18 oktober 2002 @ 17:15:
code:
1
2
3
4
void mem_alloc(void *&var, const int size)
{
  var = (void *)unsigned char[size];
}

C++:

void mem_alloc (void *& var, size_t size)
{
    var = operator new (size);
}

das al wat beter

maar goed, vanwaar die reference? kun je net zo goed dit doen

C++:

void * mem_alloc (size_t size)
{
    return operator new (size);
}

maar ja, dan kun je in je code in plaats van mem_alloc ook gewoon operator new gebruiken

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

vrijdag 18 oktober 2002 17:48

Acties:

Verwijderd

.oisyn schreef op 18 oktober 2002 @ 17:41:
maar ja, dan kun je in je code in plaats van mem_alloc ook gewoon operator new gebruiken

wat jappie waarschijnlijk wil (wil ik ook altijd) is op elk moment weten hoeveel geheugen er gealloceerd is in je programma. En in die new wrapper dus een log functie bouwen die precies opslaat hoeveel geheugen er in bezit is. Heel handig voor debug doeleinden. Aan het eind van je programma moet dan altijd gelden: LOG_ALLOC - LOG_FREE = 0.

Als dat zo is weet je dat het waarschijnlijk wel goed zit met je geheugen beheer.

vrijdag 18 oktober 2002 18:00

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op 18 oktober 2002 @ 17:48:
[...]

wat jappie waarschijnlijk wil (wil ik ook altijd) is op elk moment weten hoeveel geheugen er gealloceerd is in je programma. En in die new wrapper dus een log functie bouwen die precies opslaat hoeveel geheugen er in bezit is. Heel handig voor debug doeleinden. Aan het eind van je programma moet dan altijd gelden: LOG_ALLOC - LOG_FREE = 0.

Als dat zo is weet je dat het waarschijnlijk wel goed zit met je geheugen beheer.

het lullige is dat zo'n wrapper niet compatible is met de rest van de allocaties in je programma, dus het beste kun je gewoon operator new (en new[], delete en delete[]) overriden

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

vrijdag 18 oktober 2002 19:14

Acties:

LordLarry

Aut disce aut discede

Verwijderd schreef op 18 oktober 2002 @ 17:48:
[...]

wat jappie waarschijnlijk wil (wil ik ook altijd) is op elk moment weten hoeveel geheugen er gealloceerd is in je programma. En in die new wrapper dus een log functie bouwen die precies opslaat hoeveel geheugen er in bezit is. Heel handig voor debug doeleinden. Aan het eind van je programma moet dan altijd gelden: LOG_ALLOC - LOG_FREE = 0.

Als dat zo is weet je dat het waarschijnlijk wel goed zit met je geheugen beheer.

Je hebt programma's die dat voor je doen (en meer). Ze melden dan op welke regel het mis ging.

Een gratis versie voor Borland compilers (BCB/Delphi) kan je vinden op
http://www.automatedqa.com/products/memproof.asp

We adore chaos because we like to restore order - M.C. Escher

vrijdag 18 oktober 2002 19:20

Acties:

whoami

Nog een kleine opmerking,
afaik is een char niet noodzakelijk op ieder platform 1 byte.

https://fgheysels.github.io/

vrijdag 18 oktober 2002 19:34

Acties:

Verwijderd

*&var

pointer naar een refference ???? heeeeeeeeeeeeel vreemd !

vrijdag 18 oktober 2002 20:04

Acties:

Soultaker

Verwijderd schreef op 18 oktober 2002 @ 19:34:
*&var
pointer naar een refference ???? heeeeeeeeeeeeel vreemd !

Nee, reference naar een pointer-variabele (feitelijk een dubbele pointer).

vrijdag 18 oktober 2002 20:22

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

whoami schreef op 18 oktober 2002 @ 19:20:
Nog een kleine opmerking,
afaik is een char niet noodzakelijk op ieder platform 1 byte.

sizeof (char) == 1
aangezien sizeof eigenlijk de grootte van een type is ten opzichte van een char

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

vrijdag 18 oktober 2002 21:54

Acties:

MSalters

.oisyn schreef op 18 oktober 2002 @ 20:22:
sizeof (char) == 1
aangezien sizeof eigenlijk de grootte van een type is ten opzichte van een char

[vieze dingen met insecten]
ISO: Een byte is een deel van het geheugen ter grootte van een char

[/vieze dingen met insecten]

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

vrijdag 18 oktober 2002 22:38

Acties:

curry684

left part of the evil twins

Verwijderd schreef op 18 oktober 2002 @ 19:34:
pointer naar een refference ???? heeeeeeeeeeeeel vreemd !

Wa's daar vreemd aan afgezien van dat het een reference naar een pointer is?

Een van de belangrijke voordelen van references is dat je ze als output- en als input/output parameters kunt gebruiken, en of je nu toevallig een int, een byte of een pointer ergens naar by reference meegeeft maakt dus geen hol uit.

Daarnaast zijn ze natuurlijk botweg leesbaarder

Professionele website nodig?

zaterdag 19 oktober 2002 02:29

Acties:

Verwijderd

curry : wat skizmo bedoelt is dat je geen pointer naar een reference mag maken. Daarom is hij verbaasd. Reference naar een pointer kan wel natuurlijk.

zaterdag 19 oktober 2002 03:33

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

MSalters schreef op 18 oktober 2002 @ 21:54:
[...]

[vieze dingen met insecten]
ISO: Een byte is een deel van het geheugen ter grootte van een char
[/vieze dingen met insecten]

ja, das natuurlijk ook weer zo

maar voor mij blijft een byte gewoon 8 bits, dan weet iedereen tenminste waarover je het hebt

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

zaterdag 19 oktober 2002 12:04

Acties:

MSalters

.oisyn schreef op 19 oktober 2002 @ 03:33:

[...]

ja, das natuurlijk ook weer zo
maar voor mij blijft een byte gewoon 8 bits, dan weet iedereen tenminste waarover je het hebt

Daar heeft ISO het woord octet voor. Een byte heeft CHAR_BIT bits.
DSPs maar ook sommige GSM chipsets weken met afwijkende groottes.

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

zaterdag 19 oktober 2002 20:06

Acties:

curry684

left part of the evil twins

Verwijderd schreef op 19 oktober 2002 @ 02:29:
curry : wat skizmo bedoelt is dat je geen pointer naar een reference mag maken. Daarom is hij verbaasd. Reference naar een pointer kan wel natuurlijk.

Dat bedoelt hij niet, want de grammaticale constructie waar ie zo verbaasd over doet is een reference naar een pointer (hij schrikt van *&var). Dus oftewel hij las extreem verkeerd-om of hij kende de constructie niet, in beide gevallen is m'n uitleg gerechtvaardigd

Professionele website nodig?

zaterdag 19 oktober 2002 23:56

Acties:

^Mo^

Verwijderd schreef op 19 oktober 2002 @ 23:40:
[...]

Wat je bedoelt is dat er programmeer-omgevingen zijn (zoals die van borland) die inderdaat aangeven waar wat fout gaat. Maar dit geldt alleen voor compiler-fouten...

Als jij meer geheugen alloceerd dan dat je vrijgeeft, vind de compiler dat prima... Alleen je OS gaat op een gegeven moment zeuren dat je geen geheugen hebt, of er niet aan mag komen

't gaat niet om compiler fouten, maar om memory leaks. De programmeeromgeving geeft niet echt aan waar het fout gaat, dat doet de compiler, de IDE geeft dit alleen mooi weer. Een compiler zal echter nooit memory leaks (kunnen) weergeven, en daar is dat ene programma voor .. 't zal waarschijnlijk aangeven, in geval van een leak, waar het stukje was gealloceerd.

"There are 10 kinds of people in the world, those who understand binary and those who don't" | Werkbak specs

zondag 20 oktober 2002 00:20

Acties:

Verwijderd

Topicstarter

_Mo_ schreef op 19 oktober 2002 @ 23:56:
't gaat niet om compiler fouten, maar om memory leaks. De programmeeromgeving geeft niet echt aan waar het fout gaat, dat doet de compiler, de IDE geeft dit alleen mooi weer. Een compiler zal echter nooit memory leaks (kunnen) weergeven, en daar is dat ene programma voor .. 't zal waarschijnlijk aangeven, in geval van een leak, waar het stukje was gealloceerd.

errr.... dat bedoel ik...

zondag 20 oktober 2002 12:40

Acties:

LordLarry

Aut disce aut discede

Inderdaad, maar niet alleen memory leaks, maar ook gebruik van niet geinitialiseerde pointers, Geheugen Access buiten het gereserveerde gebied, Dubbel vrijmaken en wat al niet meer.

En BCB heeft sinds v5 zo'n programma ingebouwd!

We adore chaos because we like to restore order - M.C. Escher

zondag 20 oktober 2002 12:47

Acties:

mulder

ik spuug op het trottoir

LordLarry schreef op 20 oktober 2002 @ 12:40:
Inderdaad, maar niet alleen memory leaks, maar ook gebruik van niet geinitialiseerde pointers, Geheugen Access buiten het gereserveerde gebied, Dubbel vrijmaken en wat al niet meer.

En BCB heeft sinds v5 zo'n programma ingebouwd!

[offtopic]
Typisch een programmeur: veel woorden met hoofdletters, declareert variabelen.

oogjes open, snaveltjes dicht

zondag 20 oktober 2002 12:59

Acties:

LordLarry

Aut disce aut discede

hehe, dankje

We adore chaos because we like to restore order - M.C. Escher

zondag 20 oktober 2002 13:05

Acties:

Verwijderd

LordLarry schreef op 18 oktober 2002 @ 19:14:
Je hebt programma's die dat voor je doen (en meer). Ze melden dan op welke regel het mis ging.

Een gratis versie voor Borland compilers (BCB/Delphi) kan je vinden op
http://www.automatedqa.com/products/memproof.asp

Je noemt hier weliswaar een gratis versie, maar dan wel voor een duur pakket. Wat omslachtig als je met je gcc/g++ compiler bezig bent. En zo'n wrapper is een kleine moeite en geeft een goed beeld van je geheugen gebruik.

Althans, ik schrijf c en geen c++, en malloc wrappen is geen probleem, new is wellicht wat lastiger.

edit:
ik kna inet tpyen

zondag 20 oktober 2002 14:47

Acties:

Verwijderd

Topicstarter

ohh... err... wist niet dat ze daar ook al tool-tjes voor hadden... (let dus ook niet op m"n vorige post

)
maarja... om weer ff terug te komen op waar het over ging:

ik begrijp dat je in je heap kan alloceren, lezen, schrijven en vrijgeven wat je wil, het is je eigen probleem als je daarmee data verneukt...
maar waarom geeft malloc/free (bijna) altijd accass-violations, en new/delete (bijna) nooit ??

maandag 21 oktober 2002 00:07

Acties:

MSalters

Verwijderd schreef op 20 oktober 2002 @ 14:47:
ik begrijp dat je in je heap kan alloceren, lezen, schrijven en vrijgeven wat je wil, het is je eigen probleem als je daarmee data verneukt...
maar waarom geeft malloc/free (bijna) altijd accass-violations, en new/delete (bijna) nooit ??

Misschien omdat jouw malloc implementatie z'n boekhoud informatie achter de data opslaat, en jouw operator-new implementatie z'n boekhoud informatie voor het vrije blok opslaat. Als je dan aan de achterkant overschrijft, mol je met operator new een ander geheugenblok (wat dus 2 uur later een crash kan opleveren, dus een echt voordeel is het niet. Snelle craches zijn beter.)

Man hopes. Genius creates. Ralph Waldo Emerson
Never worry about theory as long as the machinery does what it's supposed to do. R. A. Heinlein

dinsdag 22 oktober 2002 01:45

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op 19 oktober 2002 @ 21:47:
[...]

en mag ik weten hoe JIJ weet wat er in MIJN programma allemaal compatible is ??

hahaha, grapjas, je weet het zelf nog niet eens (tenzij je een een of andere embedded programma of kernel of iets dergelijks schrijft waarbij je niet met de standaard libraries linkt)

Bovendien sprak ik in het algemeen, niet zozeer over jouw app specifiek

Wat ik bedoel is dat de standaar lib ook allocaties en frees doet, zonder dat jij daar ergen in hebt. Als je dus fijn een allocatie wrapper schrijft die het geheugen bijhoudt dan zal die alleen die dingen bijhouden die jij zelf alloceert, en niet die dingen die de stdlib voor jouw doet. Daarom kun je new en delete in zo'n geval beter overriden (Hoewel je dan wel zelf je geheugen allocatie en deallocatie routines moet schrijven, omdat de oude niet meer aanroepbaar zijn. Maar daar zijn meestal ook wel OS specifieke functies voor)

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

dinsdag 22 oktober 2002 16:57

Acties:

Verwijderd

Topicstarter

.oisyn schreef op 22 oktober 2002 @ 01:45:
hahaha, grapjas, je weet het zelf nog niet eens (tenzij je een een of andere embedded programma of kernel of iets dergelijks schrijft waarbij je niet met de standaard libraries linkt)
Bovendien sprak ik in het algemeen, niet zozeer over jouw app specifiek

je kan ook geen standaard libraries gebruiken

nou is dat niet helemaal waar... dan zou ik ook allocatie-libraries moeten maken

dus die wrap ik...
Verder gebruik ik geen libraries (niet nodig), dus werkt alles prima...

Wat ik bedoel is dat de standaar lib ook allocaties en frees doet, zonder dat jij daar ergen in hebt. Als je dus fijn een allocatie wrapper schrijft die het geheugen bijhoudt dan zal die alleen die dingen bijhouden die jij zelf alloceert, en niet die dingen die de stdlib voor jouw doet. Daarom kun je new en delete in zo'n geval beter overriden (Hoewel je dan wel zelf je geheugen allocatie en deallocatie routines moet schrijven, omdat de oude niet meer aanroepbaar zijn. Maar daar zijn meestal ook wel OS specifieke functies voor)

Ik heb geen ervaring met die dingen overloaden, is vast ook veel handiger maar weet niet precies hoe het werkt... daar zal ik inderdaat binnenkort eens wat over lezen

Vandaar dat ik het nu wrap...
De reden dat ik het wrap (oid) is omdat ook die "new" fout kan gaan (in vorm van NULL-return en/of exception). Dus dat moet fatsoenlijk afgevangen worden. Ik zie het niet zo zitten om bij elke alloc die ik doe er een try-catch omheen te moeten zetten: dus in een functie

Je zou kunnen zeggen dat als die "new" flipt, dat eigenlijk alleen maar is als je niet genoeg geheugen hebt, dus toch weinig meer kan doen... Dit is waar, maar weinig is niet niets...
vb: in geval van een database-proggie, zou je die interface kunnen dumpen en heb je weer genoeg geheugen om een file-dumpje van de database zelf te maken...

dinsdag 22 oktober 2002 17:26

Acties:

Verwijderd

Je kunt in de standard lib toch ook gewoon een allocator meegeven? met "vector<int, myOwnAllocator>" zeg maar...

Eneh, om "fatsoenlijk af te vangen" is toch juist het hele exceptiegebeuren in C++ zo ideaal

Als jij niet overal try..catch om heen wil zette, doe je dat toch alleen op het hoogste nivo?! Je hoeft niet overal try..catch omheen te zetten...

Trouwens, hou je er wel rekening mee dat als jouw "new" een exceptie zou geven, dat er dan misschien ook niet genoeg geheugen beschikbaar is om jouw alternatieve afvangmechanisme te draaien? Om in dat geval bijvoorbeeld een interface te kunnen dumpen, heb je toch echt het e.e.a. nodig aan geheugen... En als je zeer beperkt geheugen hebt kun je je beter richten op C of RTTI, en virtuals zien te vermijden e.d.

dinsdag 22 oktober 2002 17:58

Acties:

Verwijderd

Topicstarter

Verwijderd schreef op 22 oktober 2002 @ 17:26:
Eneh, om "fatsoenlijk af te vangen" is toch juist het hele exceptiegebeuren in C++ zo ideaal Als jij niet overal try..catch om heen wil zette, doe je dat toch alleen op het hoogste nivo?! Je hoeft niet overal try..catch omheen te zetten...

ik doe dit dus ook op het hoogste niveau

Trouwens, hou je er wel rekening mee dat als jouw "new" een exceptie zou geven, dat er dan misschien ook niet genoeg geheugen beschikbaar is om jouw alternatieve afvangmechanisme te draaien? Om in dat geval bijvoorbeeld een interface te kunnen dumpen, heb je toch echt het e.e.a. nodig aan geheugen... En als je zeer beperkt geheugen hebt kun je je beter richten op C of RTTI, en virtuals zien te vermijden e.d.

met "interface dumpen" bedoel ik dus weggooien, zodat geheugen dat ervoor gebruikt werd, vrij komt, dat je dan weer kan gebruiken voor.....
nou heb ik dit in practijk nog nooit gedaan. ik vind het meer netjes dat je er gewoon ff rekening mee houd dat alloceren fout kan gaan.
wat ik wel doe is op zo"n moment de rest van het geheugen dat in het proggie gebruikt wordt vrijgeven, zodat er geen troep meer inhangt als je proggie crashed...

dinsdag 22 oktober 2002 18:13

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

kijk eens naar set_new_handler (), daarmee kun je precies doen wat jij wilt (gewoon een eigen handler implementeren, die wordt aangeroepen als er geen geheugen meer te alloceren is)

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

woensdag 23 oktober 2002 15:46

Acties:

Verwijderd

.oisyn schreef op 22 oktober 2002 @ 01:45:
Wat ik bedoel is dat de standaar lib ook allocaties en frees doet, zonder dat jij daar ergen in hebt. Als je dus fijn een allocatie wrapper schrijft die het geheugen bijhoudt dan zal die alleen die dingen bijhouden die jij zelf alloceert, en niet die dingen die de stdlib voor jouw doet. Daarom kun je new en delete in zo'n geval beter overriden (Hoewel je dan wel zelf je geheugen allocatie en deallocatie routines moet schrijven, omdat de oude niet meer aanroepbaar zijn. Maar daar zijn meestal ook wel OS specifieke functies voor)

Indien je geen (of nauwelijks) standaard libraries gebruikt is dit niet erg interessant. En wat je natuurlijk kan doen is alles wat JIJ moet vrijgeven, wat een call naar een standard functie heeft gealloceerd niet met jouw wrapper vrijgeeft maar met de standaard delete. Zo log je dus alleen je zelf geschreven functies. klaar.

offtopic:
En wat ik van jouw (.oisyn) niet snap is, dat jij nooit echt antwoord geeft op iemand vraag, maar je alleen bemoeid met de stijl en dat jij het totaal anders zou doen (wat jij over doet komen als 'beter'). Gedrag wat ik van een moderator eigenlijk niet zou verwachten.

woensdag 23 oktober 2002 16:07

Acties:

curry684

left part of the evil twins

Verwijderd schreef op 23 oktober 2002 @ 15:46:

offtopic:
En wat ik van jouw (.oisyn) niet snap is, dat jij nooit echt antwoord geeft op iemand vraag, maar je alleen bemoeid met de stijl en dat jij het totaal anders zou doen (wat jij over doet komen als 'beter'). Gedrag wat ik van een moderator eigenlijk niet zou verwachten.

Bliep, lees de reactie van Oisyn eens boven deze van jou, da's een antwoord op een vraag. Tevens: klik eens op z'n naam voor een autosearch in z'n 5000+ postings, grotendeels technisch goed onderbouwd.

_{Volgens mij stond er in de FAQ ergens iets over 'profiles lezen voordat je mensen aanvalt'...}

Professionele website nodig?

woensdag 23 oktober 2002 16:18

Acties:

styno

Koffie? Hmmm, ja, lekkerrr

MSalters schreef op 21 oktober 2002 @ 00:07:
Snelle craches zijn beter.

Ik heb liever helemaal geen crashes.

Climatechange is a super-wicked problem, but:
"The stone age came to an end not for lack of stones. And the oil age will come to an end not for lack of oil." -- Sheikh Yamani, Saudi oil minister
8xLG Neon MonoX 290Wp SMA SB2100TL / MY SR '22

woensdag 23 oktober 2002 16:50

Acties:

Verwijderd

curry684 schreef op 23 oktober 2002 @ 16:07:
[...]

Bliep, lees de reactie van Oisyn eens boven deze van jou, da's een antwoord op een vraag. Tevens: klik eens op z'n naam voor een autosearch in z'n 5000+ postings, grotendeels technisch goed onderbouwd.

_{Volgens mij stond er in de FAQ ergens iets over 'profiles lezen voordat je mensen aanvalt'...}

Ik zie de relevantie van deze opmerking niet in.
Technisch goed onderbouwd idd, maar daar had ik het dus niet over.

woensdag 23 oktober 2002 17:50

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op 23 oktober 2002 @ 15:46:
[...]

Indien je geen (of nauwelijks) standaard libraries gebruikt is dit niet erg interessant. En wat je natuurlijk kan doen is alles wat JIJ moet vrijgeven, wat een call naar een standard functie heeft gealloceerd niet met jouw wrapper vrijgeeft maar met de standaard delete. Zo log je dus alleen je zelf geschreven functies. klaar.

daar heb je idd gelijk in, je mag er wel vanuit gaan dat libraries die je gebruikt niet lekken. Toch kun je op die manier niet de totale hoeveelheid aan gealloceerd geheugen bijhouden

En wat ik van jouw (.oisyn) niet snap is, dat jij nooit echt antwoord geeft op iemand vraag, maar je alleen bemoeid met de stijl en dat jij het totaal anders zou doen (wat jij over doet komen als 'beter'). Gedrag wat ik van een moderator eigenlijk niet zou verwachten.

klopt, ik ben geen vragen-beantwoord-machine, en ik zal dus ook nooit met een kant en klare oplossing komen. Iets wat meer mensen zouden moeten doen imho, GoT is immers geen helpdesk (bovendien is dat juist de taak van een mod, imho)

Wat dat 'beter' betreft, als ik mijn methode niet ervaar als beter dan ga ik het natuurlijk ook niet posten, want waarom zou je met een slechtere aanpak komen? En dat ik ze beter vindt wil natuurlijk niet zeggen dat ze dan ook werkelijk beter zijn. Het mooie van een forum is dat je weer een reactie op mijn reactie kunt geven, om jouw mening te geven over mijn methode en mij zo nodig te verbeteren (iets wat gelukkig ook vaak genoeg gebeurd

)

Als ik jou moet geloven dan moeten we dus maar alleen maar oplossingen posten en verder niets (potentieel) interessants vermelden. Een helpdesk dus.

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

woensdag 23 oktober 2002 17:50

Acties:

Verwijderd

Topicstarter

curry684 schreef op 23 oktober 2002 @ 16:07:
Bliep, lees de reactie van Oisyn eens boven deze van jou, da's een antwoord op een vraag. Tevens: klik eens op z'n naam voor een autosearch in z'n 5000+ postings, grotendeels technisch goed onderbouwd.

_{Volgens mij stond er in de FAQ ergens iets over 'profiles lezen voordat je mensen aanvalt'...}

het gaat er niet alleen om of het technisch goed onderbouwd is, maar ook (misschien meer) of het relevant is voor de topic-starter (diegene met het probleem).

ik vroeg dus waarom "malloc"/"free" (bijna) altijd flipt bij onjuist gebruik, en "new"/"delete" (bijna) niet.
dan krijg ik replies over dat ik niet moet wrappen, de stijl lelijk is, het geen c++ is, etc... allemaal volledig niet relevant !!

verder is hij degene die mensen aanvalt:
beweert dat hij beter weet wat er in mijn programma"s gebeurt dan hijzelf. ik geloof best dat hij veel weet op dit gebied, maar dat betekend niet dat andere mensen niets weten, en dat hoeft hij zeker niet op zo"n arogante manier over te brengen...
ik neem aan dat ook voor moderators geld dat ze respect moeten hebben voor anderen en hun werk.

woensdag 23 oktober 2002 17:56

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

[nohtml]

Verwijderd schreef op 23 oktober 2002 @ 17:50:
ik vroeg dus waarom "malloc"/"free" (bijna) altijd flipt bij onjuist gebruik, en "new"/"delete" (bijna) niet.
dan krijg ik replies over dat ik niet moet wrappen, de stijl lelijk is, het geen c++ is, etc... allemaal volledig niet relevant !!

lees even mijn eerste reactie in deze thread... is al een antwoord op je vraag

verder is hij degene die mensen aanvalt:

oh, val ik mensen aan

beweert dat hij beter weet wat er in mijn programma"s gebeurt dan hijzelf.

sorry, maar ik neem aan dat dit slaat op deze post?

.oisyn schreef op 18 oktober 2002 @ 18:00:
het lullige is dat zo'n wrapper niet compatible is met de rest van de allocaties in je programma, dus het beste kun je gewoon operator new (en new[], delete en delete[]) overriden

Ik sprak hier tegen unteraarsch, en bovendien in het algemeen. Toch ben je ervan overtuigd dat ik het over jouw programma heb, en dat ik beweer dat ik alles van jouw programma afweet en jijzelf niet? Ik vind dat behoorlijk egocentrisch eerlijk gezegd

en dat hoeft hij zeker niet op zo"n arogante manier over te brengen...

kun je eens een stukje quoten waarvan jij vindt dat ik arrogant ben?

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

woensdag 23 oktober 2002 18:05

Acties:

Verwijderd

Topicstarter

.oisyn schreef op 22 oktober 2002 @ 01:45:
hahaha, grapjas, je weet het zelf nog niet eens (tenzij je een een of andere embedded programma of kernel of iets dergelijks schrijft waarbij je niet met de standaard libraries linkt)
...

deze post viel mij dus aardig verkeerd...

woensdag 23 oktober 2002 18:12

Acties:

.oisyn

Moderator Devschuur®

Demotivational Speaker

Verwijderd schreef op 23 oktober 2002 @ 18:05:

deze post viel mij dus aardig verkeerd...

Ok, mijn excuses daarvoor, ik kan me voorstellen dat die verkeerd over kon komen. Maar het is wel een reactie op een felle reactie van jouw kant omdat jij ineens begint over het feit hoe ik in hemelsnaam kan weten wat er in jouw programma gebeurt. Dat weet ik niet en dat heb ik ook nooit beweerd, dus we hebben beide schuld in dit geval

en hop, nu weer ontopic

Give a man a game and he'll have fun for a day. Teach a man to make games and he'll never have fun again.

woensdag 23 oktober 2002 18:20

Acties:

Verwijderd

Topicstarter

ik begreep achteraf wel dat je het niet over mijn app specifiek had, maar toen de bovenstaande post dus langs kwam, kwam het toch weer over alsof je echt tegen mij had...

maar blij dat we eruit zijn...
hier kan wel een slotje op, ik ben er wel uit

woensdag 23 oktober 2002 18:33

Acties:

D2k

en als hier nog geen slotje op kon kwam het er alsnog
ik wil de heren Jappie en unteraarsch verzoeken om met tips en hints blij te zijn
alle suggesties van .oisyn zijn nuttig. Misschien niet allemaal voor dit probleem maar iig zinniger dan nix. Als je dan het modbeleid in P&W wil aanvallen doe je dat per mail aan .oisyn (en cc aan ACM/Tom/Janoz/D2k ofzow) en niet IN een thread

Doet iets met Cloud (MS/IBM)