The pseudo code also confirms what I guessed by doing failed memory allocation tests (real or simulated) with or without the operator New overload coded:- There is no test on the nullity of the returned pointer ('tmp') and it seems that the code always tries to build even from zero memory address and obviously crashes in that case.- Is there a reason for this choice?

Regarding the update of the documentation (for 'New' and 'Delete' that I prefer to do first), I think the work is similar to what I did in 2016 to cut the old single page 'Cast' in 2 separate pages 'Cast' and 'Operator Cast' (after saving the old text edit and the page links, by using page cloning, then cleaning/rewording on each new page).

I think to treat the page 'Placement New' after, in a second step.

About the 4 pages for 'New' and 'Delete', I propose that:- each page has as title the long version of the name that you specified (viewtopic.php?p=251133#p251133),- as usually, a first short sentence introduces roughly the function, but also defines the short-cut for the name (only this short-cut will be used after in the text to be cleaned/reworded),- one thing bugs me a little, because for example by cloning the page 'KeyPgOpNew' to 'KeyPgNew', the revision history will remain attached to the page 'New Overload' (the page a priori the shortest) and not to the page 'New Expression',- finally, previous links to be readjusted according to the new cutting.

fxm wrote:... the code always tries to build even from zero memory address and obviously crashes in that case.- Is there a reason for this choice?

I don't think it was a choice; it just happened. Older fbc called stdc++ and new/delete operators could throw a bas_alloc error. When stdc++ dependency was removed, nothing was added to handle the the error condition. We should probably check for the null pointer. And throw our own error when compiling with '-e'

fxm wrote:- one thing bugs me a little, because for example by cloning the page 'KeyPgOpNew' to 'KeyPgNew', the revision history will remain attached to the page 'New Overload' (the page a priori the shortest) and not to the page 'New Expression',

I was thinking about this after, but for a different reason:- new/delete is an operator. It is implemented that way in the compiler. And that is what we are calling it.- "KeyPgOp" wiki page name prefix would be correct for all contexts- KeyPgOpNew, KeyPgOpPlacementNew, KeyPgOpNewOverload- Side benefit is this naming keeps most revision history. And KeyPgNew could still be added later if desired as disambiguation page.

If I well understood, you propose this page mapping.Consistent with the name of the links, I propose to change the order of the terms for the full names of the page titles (being also the full names of the operators).

In the literature, one can find examples of these operators overloading, but most are obvious and without any interest (almost like 'Return Allocate(size)' for New and 'Deallocate buf' for Delete), irrelevant or even bugged. :-(

"Dynamic allocation manager for UDT, by using the member operators "New[] Overload" and "Delete[] Overload":- Monitoring of memory allocations/deallocations: addresses, sizes and total memory used.- Detection of abnormal deallocation requests.- Detection of a failed allocation (Allocate() returning null pointer).- Detection of total allocated memory size exceeding a threshold.- The last two detection cases induces an automatic memory freeing before forcing the program to end.

The principle is to manage a dynamic list of successful allocations, but not yet freed, containing the allocated addresses with their requested sizes:

In the literature, one can find examples of these operators overloading, but most are obvious and without any interest (almost like 'Return Allocate(size)' for New and 'Deallocate buf' for Delete)

I think that this type of ultra-simple examples that do not show the interest in overloading such operators (showing only how to use the parameters of the operators), although (and even because) we see a lot of them in the literature, are useless in our documentation, but that's my personal opinion.

Yes, for something like overloading new[]/delete[], we can probably assume that the reader can make sense of the syntax and usage, and they will benefit from a more complex usage. In comparison, for some simple examples, I think we are only trying to help the reader to see how it would be used. Like after the definition of a word, showing how it is used in a sentence.

I added a few days ago a very simple first example to my 2 previous "more interesting" examples, mainly to simply highlight the user interfacing with the parameters of the 2 overload operators:KeyPgOpNewOverload → fxm [Added much simpler example before others (only for syntax usage)]

In order to secure the usage of overload New([])/Delete([]), the compiler could return a warning if the operators are not overload by valid couples as New/Delete or/and New[]/Delete[] (not New([]) or Delete([]) alone)?