I've been going over ROMs loading protocols the last couple days and I've noticed a leak I've not seen reported.

When shops are loaded

void load_shops( FILE *fp )
{
    SHOP_DATA *pShop;

    for ( ; ; )
    {
	MOB_INDEX_DATA *pMobIndex;
	int iTrade;

	pShop			= alloc_perm( sizeof(*pShop) );
	pShop->keeper		= fread_number( fp );
	if ( pShop->keeper == 0 )
	    break;
       …
    }
}

here it allocates a keeper, but if it's a bad number it just breaks and returns. The pShop is just left dangling. I'd suggest holding keeper in a temp variable and after you make sure it's not zeron, then alloc_perm pShop.

Thats a good catch. But by default, isn't the whole alloc_mem/alloc_perm, and free_list system of ROM a leak that nobody reported :P J/K.

Heh, it basically is! However, in this case, one could replace this with malloc, and it'd still leak. It's just bad form.

Yeah, I know. Its why I stick to new/delete, and to my own engine these days. Man I used to be super addicted to ROM. (prods his posted snippets for example)

Resource pools are a useful form of resource management that are usually a better fit for long-running programs. Individual malloc/free/new/delete calls "only" do an acceptable job in a wider range of situations.

That said, memory today is cheap, CPUs are fast, and it's up to each of us to use techniques that we can work with effectively.

Problem with resource pool is it is harder to detect leak. Here if there was a malloc valgrind would detect it pretty easily, and maybe even clang.

It is harder… but not by much. Valgrind already knows how malloc works, but you can tell it how your pool allocator works by sprinkling a couple of macros in the appropriate places, as I understand it.

I was under the impression that memory pools like this where purely for performance and mattered only with the frequency of the calls, and not the longevity of the program. Surely you'd think the OS recycles it's memory at least as efficiently, if not more so than a homegrown memory pool ya? If I were using something that was allocating/deallocating like crazy, I'd probably consider something like this over malloc/calloc. It's definitely not something I'd factor in when considering the life of the program.

It's useful for very specific problems. There's a few other niche areas where you can eek out some gains in speed. It was at one time more useful, many years ago.

Oh, we're talking about custom memory allocation. I was referring to C/+.

Actually, malloc/free are notoriously slow. It's much more efficient to grab the first chunk of memory off a given pool's free list (a constant-time operation, assuming the appropriate pool has an opening) than to send malloc searching through a heterogeneous mass of memory blocks for an unused space of adequate size.

I mention long-running programs because the usage patterns of most programs (lots of ad-hoc malloc and free calls on memory of different sizes) usually fragments the heap as it runs. It is admittedly an assumption on my part that malloc's search complexity increases with fragmentation.