Re: safe "struct hack"?
On 14.08.13 19.44, Jonathan Lee wrote:
That's not my understanding of calloc. What (I believe) I've
done is allocated enough space for 20 headers, with the
appropriate alignment. The number 20 is just for the sake
of example. The actual value would depend on how many ints
I want room for.
OK, seems that I did not catch what you are going to achieve at all.
If you are talking about alignment, AFAIK malloc/calloc/realloc always
returns storage that is suitable aligned for any native data type. OK,
it might no always be aligned for the fastest array access on a
particular platform (especially if you work with cache line
prefetching), but at least it would work.
You can't exactly know how many of them are legal. Se above.
I think I can. Basically I have 19 * sizeof(wrap) bytes with
the proper alignment for an int array. Therefore I should have
(19 * sizeof(wrap)) / sizeof(int)
elements. My claim is that this is no different than
int* t = (int*)calloc(19 * sizeof(wrap)/sizeof(int), sizeof(int))
Be careful. The division might cause truncations.
int* q = static_cast<int*>(p);
This works syntactically, as p is void*.
Given the way calloc was called, it should be more than a
syntactic guarantee. I know this is C++, but if this didn't
work, you wouldn't be able to allocate arrays in C...
It depends on what you expect about the resulting pointer.
If you want to have an header and a dynamically sized integer array in
one allocation then write a class with a custom new operator that takes
an additional argument for the size of the array and provide functions
for more or less safe access to the array. At least in debug builds I
would recommend boundary checks.
That's precisely what I'm going to end up with. What I'm proposing is
a safe way of doing that underneath. I can't simply extend the memory
allocated by operator new, because I need the alignment guarantee.
You can have this easier.
size_t header_size = offsetof(wrap,arr);
This will include additional padding for the following arr.
wrap* w = malloc(header_size + n * sizeof(int);
This will be suitable aligned to handle an array of int after the
header, regardless of the headers content.
But you still could use a custom allocator. I have done this in a Java
like, immutable string implementation with strongly thread-safe
reference counting. The header (ref count and length) is followed by the
string content in one allocation. The custom allocator takes the array
size as additional parameter.
I further did the hack in the allocator that the pointers to these
instances point to the start of the array rather than the start of the
header. The header content is then located at this[-1]. This makes
references to string instances binary compatible to const char*, making
commonly used adapter functions so trivial, that no code is generated at
all. (Otherwise always NULL checks have to be done before the offset is
applied.)
Marcel