RE: SourceForge Project Approved

Hello

> -----Original Message-----
> From: ext Richard A. O'Keefe [mailto:ok@atlas.otago.ac.nz]
> Sent: 28 May 2001 03:22
> To: Valeri.Atamaniouk@nokia.com; html-tidy@w3.org; 
> ok@atlas.otago.ac.nz
> Subject: RE: SourceForge Project Approved
> 
> 
> The thing is, how is this relevant to HTML Tidy?  The whole 
> point of Tidy
> is to *be* the error handling code.  Well, I exaggerate.  But 
> its job is
> to take sows' ears and turn them into silk purses, from messy input to
> create a clean data structure.
> 
> 	Another approach: you create a memory allocator and 
> start processing. All
> 	functions get their memory from this allocator. If 
> there is a error, an
> 	exception is emulated (longjmp would be fine) to the 
> starting point. Having
> 	it we just release allocator (and all the memory wich 
> was allocated from it
> 	in one operation). This makes unnessesary numerous 
> error checks. Besides
> 	mechanism with preallocation of a chunk of a memory and 
> then distributing it
> 	as needed works faster, than standard 
> malloc/realloc/free. You will be
> 	suprised how much faster.
> 	
> Not really.  I have been allocating memory in great big 
> blocks and running
> a simple suballocator for hmm, the last 20 years.  Anyone who 
> is interested
> will find the technique expounded in Donald Knuth's book "The Stanford
> GraphBase".  For what it's worth, that is a collection of 
> graph algorithms
> with data structure doing very complex things, with no 
> general exception-
> handling machinery in sight.

But that means that you deprecate functions like CheckNodeIntegrity ->
because if you detected problems with tree you can not release memory. That
would definitively lead to memory leak (which is not important for
standalone application, but a fatal bug for server-kind application). But if
all your allocation handled by object, which knows how to free everything
allocated from it -> there would be no problem at all. 
And this allows also easily handle situations when you need to release all
the memory of the session without relying on the standard procedures.
Actually you don't have to preallocate a big blocks. You may just maintain
the list of allocated blocks to release it on demand.
I've attached a sample code with such allocator.

BR
VA