"Malcolm McLean" <> wrote in message
news:...
> "Chris M. Thomasson" <> wrote in message
>>
>> Anyway, do you have any suggestions on how to improve the code?
>>
>> Thanks, and I hope somebody might find this useful...
>>
> You very cleverly fight the C language to get alignments out of a buffer.
;^)
Yeah, it does seem as if it will work pretty darn good as long as
`sizeof(size_t) == sizeof(void*)'. Humm... Perhaps I should add a macro that
the user can pre-define in order to setup a custom integral type that can be
freely converted to a void* in the cast that `sizeof(size_t) !=
sizeof(void*)'. Something simple like this:
__________________________________________________ _________
#if ! defined (CUSTOM_UINTPTR_TYPE)
typedef size_t uintptr_type;
#else
typedef CUSTOM_UINTPTR_TYPE uintptr_type;
#endif
typedef char static_assert[
sizeof(uintptr_type) == sizeof(void*) ? 1 : -1
];
__________________________________________________ _________
That way, if the user knows that size_t is not sufficient, they can simply
define `CUSTOM_UINTPTR_TYPE' to a type that is sufficient. Also, I should
probably try to detect if the user is compiling on a C99 compiler, and just
use the types from <stdint.h> (e.g., uintptr_t). However, I would have to
check to see if its under a XSI conformant system. AFAICT, the types
`intptr_t/uintptr_t' are optional. Well, I guess I could just see if the
`UINTPTR_MAX' macro is defined.
> One suggestion I would make is to change the interface so that
> region_alloc_type() takes a count as well as a type. In practise people
> are going to want to allocate short arrays with this, most of the time.
Completely agreed; here is the mutated code:
http://pastebin.com/f207f6232
> I'd also consider changing the name to rgalloc_type(). The rule of two.
I defined an alternative "condensed" API as follows:
__________________________________________________ ____
#define rinit region_init
#define ralloc region_alloc
#define ralloct region_alloc_type
#define rallocex region_alloc_ex
#define rflush region_flush
__________________________________________________ ____
It certainly reduces the amount of typing...
;^)
> I'd strip out all the debugging code, for the release version. People
> don't want clutter in code they're trying to read.
You mean remove it completely from the posted code? The preprocessor already
removes it when `NDEBUG' is defined. I must be totally misunderstanding you.
> The strategy of assert failing on out of memory I'm not happy about. I
> think maybe have two constructors, the default one which assert fails on
> out of meory conditions, another one which returns NULL. This is easily
> implemented by having a flag in region.
Where are you seeing this condition? Humm... Well, if the current state of a
region cannot satisfy the requested allocation, it does indeed return NULL,
and no assertion is tripped. For instance, the following program with the
current region code as-is does not barf up an assertion failure:
__________________________________________________ ____
int main(void) {
struct region region;
unsigned char buffer[128] = { '\0' };
rinit(®ion, buffer, sizeof(buffer));
ralloc(®ion, 10000);
return 0;
}
__________________________________________________ ____
What am I missing?
Similar Threads
