Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #14750
| From | Aleksej Saushev <asau@inbox.ru> |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: heap implementation |
| Date | 2012-08-06 01:43 +0400 |
| Organization | A noiseless patient Spider |
| Message-ID | <87obmpaubg.fsf@inbox.ru> (permalink) |
| References | <32efd358-5119-44a2-83fd-2a2967d81d32@y1g2000vbx.googlegroups.com> <jvevq7$r0f$1@speranza.aioe.org> <a80emiF5f6U1@mid.individual.net> |
vandys@vsta.org writes:
> Rod Pemberton <do_not_have@notemailnot.cmm> wrote:
>>> It doesn't have ALLOCATION for one thing (a function
>>> that returns the amount of memory in a node given the
>>> node's address).
>> That sounds _alot_ like C's sizeof()... on a node... at least to me. So,
>> why don't you just implement C's SIZEOF for Forth? ;-)
>
> No, sizeof() is an operator which compiles to a constant based on looking at
> the (compile time) types. This sounds more like a runtime thing. malloc()
> records the size of the allocated object, so that free() can return its
> storage. I don't think there's ever been an API to find out an allocated
> node's size--if you care, you have to keep it somewhere (usually in the
> allocate memory) for yourself.
In some cases there exists API to find it, the only problem is that it
isn't exported for "hysterical raisins." "You have to keep it somewhere"
not because it is hard or it is impossible, it is due to the long
standing tradition of using lowest common denominator in C and records
of fixed size in other languages of Algol family. Some allocators may
require some refactoring, but at least if you look at jemalloc source,
you can easily find the relevant function. It is not hard to remove one
word ("static") and introduce function prototype. The only problem here
is change resistance.
--
HE CE3OH...
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
heap implementation Hugh Aguilar <hughaguilar96@nospicedham.yahoo.com> - 2012-08-02 00:25 -0700
Re: heap implementation Alex McDonald <blog@nospicedham.rivadpm.com> - 2012-08-02 02:51 -0700
Re: heap implementation Andrew Haley <andrew29@littlepinkcloud.invalid> - 2012-08-02 05:23 -0500
Re: heap implementation Alex McDonald <blog@rivadpm.com> - 2012-08-02 13:57 -0700
Re: heap implementation "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-02 18:45 -0400
Re: heap implementation vandys@vsta.org - 2012-08-02 22:53 +0000
Re: heap implementation Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-08-02 21:53 -0700
Re: heap implementation "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-03 07:23 -0400
Re: heap implementation anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2012-08-03 12:12 +0000
Re: heap implementation Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-08-05 23:08 -0700
Re: heap implementation Alex McDonald <blog@rivadpm.com> - 2012-08-03 08:41 -0700
Re: heap implementation "Rod Pemberton" <do_not_have@notemailnot.cmm> - 2012-08-03 06:58 -0400
Re: heap implementation Alex McDonald <blog@rivadpm.com> - 2012-08-03 05:36 -0700
Re: heap implementation Hugh Aguilar <hughaguilar96@yahoo.com> - 2012-08-05 23:28 -0700
Re: heap implementation Aleksej Saushev <asau@inbox.ru> - 2012-08-06 01:43 +0400
Re: heap implementation "wolfgang kern" <nowhere@never.at> - 2012-08-17 19:57 +0200
csiph-web