Gus Koppel wrote:
Too much
ardour for that might let some people end up one terrible day by writing
x = g_math_add (g_math_sub (a, g_math_mul (b, c)), d);
instead of just
x = a - b * c + d;
You mean of course
g_math_assign(&x, g_math_add (g_math_sub (a, g_math_mul (b, c)), d));
Stefan
Olivier Sessink wrote:
> Gus Koppel wrote:
> > What sort of 4 byte information is to be stored, if I may ask? Is it
> > to be referenced mainly by entry numbers (1st, 2nd, 3rd, ... atom)
> > or by contents, i.e. locating atoms that contain particular values?
> > Possibly for your app GMemChunks ar
Gus Koppel wrote:
> Using such a feature like GMemChunk makes sense only if the size of the
> objects (atoms) isn't too small (less than about 16 bytes as a rule of
> thumb). Your atoms appear to be the smallest ones possible at all.
> GMemChunks are especially helpful for linked lists of any sort.
Olivier Sessink wrote:
> I was considering to use the GMemChunk infrastructure for some of my
> code, where often 50 till 5000 structs of 4 bytes are allocated. I
> will use the G_ALLOC_AND_FREE mode, because many items are not used
> after a while, but not all.
>
> I am, however, wondering if GM
Hi all,
I was considering to use the GMemChunk infrastructure for some of my
code, where often 50 till 5000 structs of 4 bytes are allocated. I will
use the G_ALLOC_AND_FREE mode, because many items are not used after a
while, but not all.
I am, however, wondering if GMemChunk has much overhead.
