Prev: hacking
Next: How get percentage of use of cpu
From: lawrence.jones on 19 Jan 2010 15:14 robertwessel2(a)yahoo.com <robertwessel2(a)yahoo.com> wrote: > > But except in the case of VLAs, sizeof is defined to return a > constant, which allows the value to use used at compile time. A > couple of examples: > > int i; > #if sizeof(i) < 4 > ... > #endif That doesn't work. At preprocessor time, both sizeof and i are interpreted as undefined macro names and thus get replaced with 0. -- Larry Jones What a stupid world. -- Calvin
From: Gene on 19 Jan 2010 17:32 On Jan 17, 11:33 am, Jon Harrop <j...(a)ffconsultancy.com> wrote: > Anyone know of a memory allocator that allows blocks to be allocated in > batches? > > -- > Dr Jon D Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com/?u GNU obstacks are roughly this. Each obstack is a mark-release arena that is automatically freed in toto after the first-allocated block is released. As I recall, it's implemented as a layer on top of malloc (), though, so may not be what you want.
From: BGB / cr88192 on 19 Jan 2010 22:03 "Rod Pemberton" <do_not_have(a)havenone.cmm> wrote in message news:hj3tk9$vbf$1(a)speranza.aioe.org... > "BGB / cr88192" <cr88192(a)hotmail.com> wrote in message > news:hj28p7$na4$1(a)news.albasani.net... >> >> malloc is a function, and not a keyword. > > True... But, that's an entirely different topic: > > for(), while(), return(), switch(), sizeof() could all be implemented as > functions. It might even be possible to do it an be compliant. The > compiler must recognize them as being keywords or operators for proper > parsing, but the implementation could use functions to implement them. > possibly... in my case, they are usually handles as special built-in logic... for/while/switch are handled in the upper-end, and generally expand to labels and conditional jumps. return and sizeof are converted to special opcodes, and handled in the lower-end (which limits some possible optimizations on the constant value of sizeof). if(sizeof(long)==4) { ... } if(sizeof(long)==8) { ... } by the time sizeof is a constant, it is too late to eliminate the if body... >> malloc is a function, and not a keyword. > > I just meant that to recognize malloc without the header, you're parser > will > need to recognize it as some language element, say function or keyword, > when > it wouldn't normally do so, since it's header hasn't been included. > 'types' are the only real thing which need special attention by the parser. most of the rest of the syntax is unambiguous (in plain C at least). >> #define _noinclude //magic define that enables this "magic"... > > Nice. You're just going copy them into your tables/trees as functions as > the compiler would've done with the actual include...? Should work well, > IMO. Ignore my statements on malloc... > not exactly, but close... what happens here is that, upon trying to lookup something, and failing, the compiler may go and instead try to pull an item of matching description from the database, and if found, add the needed entries to the table(s) and pretend like the lookup never failed. "might there per-chance happen to be a function or struct by this name floating around?...". if something turns up, it is used. >> granted, there are certain "compiler built-in functions" (such as sin, > cos, >> ...) but these are different... > > There's no reason why malloc() and free() couldn't have been part of the C > language instead of in the C libraries. It would've made C a better > language, IMO. It's just random history that they aren't. > yes, ok...
From: Jon Harrop on 20 Jan 2010 12:07 Richard Harter wrote: > On Sun, 17 Jan 2010 16:33:22 +0000, Jon Harrop > <jon(a)ffconsultancy.com> wrote: >>Anyone know of a memory allocator that allows blocks to be allocated in >>batches? > > Could you be more specific? Sure. I want a function that accepts an array of sizes of blocks to allocate and returns an array of pointers to allocated blocks. For example (assuming an array notation [.., ...]): mallocs[10, 20, 30] gives a similar result to: [malloc(10), malloc(20), malloc(30)] except that the whole block is allocated atomically, i.e. as contiguously as possible for a given thread. The problem with the latter (which is my current approach) is that the atomic lock in malloc allows the allocations to get multiplexed: Thread Location A 0 B 10 A 20 B 40 A 60 B 90 That destroys locality and can even introduce false sharing. I can just take out a global lock of my own but I suspect it would be far more efficient if malloc could handle bulk allocations all at the same time. For example, it could just allocate a larger block and divvy it up internally so I could still call "free" to free each subblock individually. -- Dr Jon D Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?u
From: Willem on 20 Jan 2010 11:32
Jon Harrop wrote: ) Sure. I want a function that accepts an array of sizes of blocks to allocate ) and returns an array of pointers to allocated blocks. ) ) For example (assuming an array notation [.., ...]): ) ) mallocs[10, 20, 30] ) ) gives a similar result to: ) ) [malloc(10), malloc(20), malloc(30)] ) ) except that the whole block is allocated atomically, i.e. as contiguously as ) possible for a given thread. How would free()ing work ? ) I can just take out a global lock of my own but I suspect it would be far ) more efficient if malloc could handle bulk allocations all at the same ) time. For example, it could just allocate a larger block and divvy it up ) internally so I could still call "free" to free each subblock ) individually. Or you could do that yourself (0-terminated list): void * malloc_m(size_t *sizes) { size_t sz, psz; size_t *sp; void *vp, *tp, *ret; for (sp = sizes, sz = psz = 0; *sp; sp++, psz += sizeof(void *)) { sz += *sp; } ret = malloc(sz + psz); tp = ret + psz; for (sp = sizes, vp = ret; *sp; sp++, vp++) { *vp = tp; tp += *sp; } *vp = NULL; return ret; } Off the top of my head, of course, and untested. Just wanted to get the idea across. This way, you obviously have to only free() the array of pointers. SaSW, Willem -- Disclaimer: I am in no way responsible for any of the statements made in the above text. For all I know I might be drugged or something.. No I'm not paranoid. You all think I'm paranoid, don't you ! #EOT |