[c++] new aanpassen?

[kvdveer]

Ik ben bezig met een php extension. Ik wil een class irc gaan maken, maar ik zit met een groot dilemma. In php is irc gewoon een class, en het liefst zou ik 'm dus ook in C++ maken. Nu kun je op de website van PHP dat je in php-extensions malloc niet mag gebruiken, daarvoor moet je emalloc gebruiken.

Het probleem dat je met c++ natuurlijk hebt, is dat new automagisch malloc aanroept. Is dat op een of andere manier op te lossen, of moet ik zelf maar een soort pseudo-oop aanpak gaan verzinnen in C?

[curry684]

C++:

void* operator new(size_t p_Size)
{
return InternalAllocateNewMemory(p_Size);
}

void operator delete(void *p_Block)
{
InternalReleaseNewMemory(p_Block);
}

void* operator new [](size_t p_Size)
{
return InternalAllocateNewMemory(p_Size);
}

void operator delete [](void *p_Block)
{
InternalReleaseNewMemory(p_Block);
}

[ Voor 2% gewijzigd door curry684 op 23-02-2003 15:46 . Reden: Kleine oeps ]

[kvdveer]

* kvdveer knuffelt curry
Het werkt...

[SWfreak]

Kan iemand mij dan even uitleggen wat die functie InternalAllocateNewMemory precies doet (behalve kennelijk geheugen alloceren) . Google geeft namelijk 0 hits. Een undocumented function??

[Rataplan]

* zoekt mee *

Ik begin nou ook wel benieuwd te worden. MSDN en usenet leveren ook 0 hits op

[kvdveer]

Het is een fictieve functie die je zelf zult moeten implementeren. Je kunt 'm ook vervangen door alloc en free...

Het volgende is nodig om veilig te kunnen werken met de zend-API.

C++:

void* operator new(size_t p_Size) 
{ 
    return emalloc(p_Size); 
} 
void operator delete(void *p_Block) 
{ 
    efree(p_Block); 
} 
void* operator new [](size_t p_Size) 
{ 
    return emalloc(p_Size); 
} 
void operator delete [](void *p_Block) 
{ 
    efree(p_Block); 
}

[ Voor 9% gewijzigd door kvdveer op 23-02-2003 16:37 ]

[MSalters]

PS. het is wel zo netjes om die operator new en operator delete in class irc te definieren; dan gebruik je die emalloc alleen voor die class en derived classes. Om nou alle strings enzo in je code ook via emalloc te new'en is overkill, gok ik

[kvdveer]

MSalters schreef op 23 February 2003 @ 18:03:
PS. het is wel zo netjes om die operator new en operator delete in class irc te definieren; dan gebruik je die emalloc alleen voor die class en derived classes. Om nou alle strings enzo in je code ook via emalloc te new'en is overkill, gok ik

Niet eens overkill: verplicht zelfs. Het heeft er mee te maken dat mijn scripts op een totaal willekeurig moment afgebroken kan worden, en ik dan niet meer free of delete aan kan roepen. Oftewel: iedere byte die gealoceerd wordt, moet bekend zijn bij de zend engine.

[MSalters]

Whoops. Dat is niet helemaal compatible met C++; je wilt niet alleen bytes reclaimen maar ook de destructors draaien.
Verder denk ik dat je ook std::allocator wil gaan vervangen, voor de STL.

[Soultaker]

MSalters schreef op 23 februari 2003 @ 21:40:
Whoops. Dat is niet helemaal compatible met C++; je wilt niet alleen bytes reclaimen maar ook de destructors draaien.

Ik denk dat die automatisch 'draaien', net als de constructors. Je kunt uit uitsluitend een grootte bij bijvoorbeeld delete[] niet afleiden hoeveel (en welke) objecten je moet destructen.

Verder denk ik dat je ook std::allocator wil gaan vervangen, voor de STL.

Niet als die uitgedrukt is in termen van new/delete, zoals waarschijnlijk is, natuurlijk.

Geen garanties trouwens; ik weet van beide onderwerpen vrij weinig af, dus ik kan hier niet overtuigd op antwoorden. edit: ...maar een beetje Googlen bevestigt mijn vermoedens.

[ Voor 19% gewijzigd door Soultaker op 23-02-2003 21:56 ]

[.oisyn]

kvdveer schreef op 23 February 2003 @ 18:16:
Niet eens overkill: verplicht zelfs. Het heeft er mee te maken dat mijn scripts op een totaal willekeurig moment afgebroken kan worden, en ik dan niet meer free of delete aan kan roepen. Oftewel: iedere byte die gealoceerd wordt, moet bekend zijn bij de zend engine.

op zich niet nodig zolang je gewoon zelf verantwoordelijk blijft voor het vrijgeven van het geheugen (en dus ook zelf de destructors aanroept)

Je zou bijvoorbeeld prima een std::string kunnen gebruiken zonder aanpassingen aan het geheugenmanagement. Maar een string alloceren die in het php-script gebruikt moet worden is natuurlijk weer een ander verhaal

Bovendien staat php nou niet bepaald bekend om z'n goede geheugenmanagement

[MSalters]

Soultaker schreef op 23 February 2003 @ 21:53:
[std::allocator]

Niet als die uitgedrukt is in termen van new/delete, zoals waarschijnlijk is, natuurlijk.

Behalve dan dat de implementatie vaak lazy is, en je het geheugen waarschijnlijk acuut terug wil opruimen. Als je zelf efree( ) aanroept, en std::allocator op een of andere manier later ook een delete doet, dan ben je alsnog gepakt.