From: Rod Pemberton on
"Richard Harter" <cri(a)tiac.net> wrote in message
news:4b53de37.413140546(a)text.giganews.com...
>
> The puzzling thing is that Jon is almost certainly familiar with
> all of these techiques. That implies that he has something else
> in mind.

Yeah, that's what I though about providing links to your "old" c.l.c. memory
allocator, BGET, and dlmalloc. "He's certainly aware of these... Isn't
he?" If not, I'll post links to them upon request, if one can't find one of
my old posts with them.


RP


From: Rod Pemberton on
"BGB / cr88192" <cr88192(a)hotmail.com> wrote in message
news:hj0uhi$ev9$1(a)news.albasani.net...
>
> meanwhile, I am off trying to find a way to get my C compile times maybe
> 10 or 100x faster by making headers optionally optional...

It's a good idea. You just have to remember a few issues might come up:

1) a warning is needed if the library function is used/called without an
include and there isn't a function by that name in the program
2) if a header isn't included and there is a function in the program by the
same name as the library function, then it's a user function and you
shouldn't warn about a missing library include, or link to the C library
function.

I'm just mentioning this, because this could affect how you parse. E.g., if
you decide "malloc" is a keyword since it should reference a C library
function, but the user is using his own malloc() and not using the stdlib.h
header... I "roll-my-own" quite a bit, especially with ctype.h or string.h
functions. I'll use a standard C library function, say strchr(), throughout
the code, and then have define sequence to map it to an internal function if
the string.h include isn't included:

#if 0
#include <string.h>
#else
#define strchr myfunction
#endif


RP



From: Calum on
On Jan 17, 4:33 pm, 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

If using C++, then the boost::pool allocator may be what you need.

http://www.boost.org/doc/libs/1_41_0/libs/pool/doc/index.html

It would be helpful to understand: what language you need it for, what
problem you are trying to solve (e.g. memory management, simple
deallocation, thread safety, multithreaded performance, allocation
speed, memory overhead), what are your intended patterns of object
allocation/deallocation, and perhaps what you are writing.

Calum
From: bartc on
BGB / cr88192 wrote:

> meanwhile, I am off trying to find a way to get my C compile times
> maybe 10 or 100x faster by making headers optionally optional...
> (IOW: optionally switching to a very different scoping model...).

Some of my first compiler attempts used (for good reasons) a memory-resident
program, a sort of combined editor/compiler/runner.

This way, symbol tables stayed resident and were reused on the next
compilation. You just needed a way of clearing the tables relevant to the
module being compiled but keeping header-related ones. This wasn't C so
header stuff was in a higher scope, which helped.

(However if you're talking about your compiler system which, iirc, writes
and rereads XML representations between passes, you might want to look at
some obvious speed-ups first...)

--
Bartc

From: BGB / cr88192 on

"Rod Pemberton" <do_not_have(a)havenone.cmm> wrote in message
news:hj1asv$2rn$1(a)speranza.aioe.org...
> "BGB / cr88192" <cr88192(a)hotmail.com> wrote in message
> news:hj0uhi$ev9$1(a)news.albasani.net...
>>
>> meanwhile, I am off trying to find a way to get my C compile times maybe
>> 10 or 100x faster by making headers optionally optional...
>
> It's a good idea. You just have to remember a few issues might come up:
>
> 1) a warning is needed if the library function is used/called without an
> include and there isn't a function by that name in the program
> 2) if a header isn't included and there is a function in the program by
> the
> same name as the library function, then it's a user function and you
> shouldn't warn about a missing library include, or link to the C library
> function.
>

yeah.

warning about non-existing names will still happen, since in this case there
will be no entry in the database either.

2, well, generally compilers don't warn against this, unless the prototype
differs or there is some other issue.


> I'm just mentioning this, because this could affect how you parse. E.g.,
> if
> you decide "malloc" is a keyword since it should reference a C library
> function, but the user is using his own malloc() and not using the
> stdlib.h
> header... I "roll-my-own" quite a bit, especially with ctype.h or
> string.h
> functions. I'll use a standard C library function, say strchr(),
> throughout
> the code, and then have define sequence to map it to an internal function
> if
> the string.h include isn't included:
>
> #if 0
> #include <string.h>
> #else
> #define strchr myfunction
> #endif
>

malloc is a function, and not a keyword.
actually, pretty much no functions are keywords, as this would be nasty and
a violation of the C standard...
(granted, allowing a magic define to make headers optional is also a
violation, but nevermond this...).

#define _noinclude //magic define that enables this "magic"...


granted, there are certain "compiler built-in functions" (such as sin, cos,
....) but these are different...
also, the parser does not care about built-in functions anyways, rather,
these are noted and handled specially when producing the IL code...



First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: hacking
Next: How get percentage of use of cpu