Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.forth > #26944

Re: Reclaiming Allocated Memory

From Paul Rubin <no.email@nospam.invalid>
Newsgroups comp.lang.forth
Subject Re: Reclaiming Allocated Memory
Date 2013-11-25 09:03 -0800
Organization Nightsong/Fort GNOX
Message-ID <7xmwksv2f5.fsf@ruckus.brouhaha.com> (permalink)
References <5293458b$0$296$14726298@news.sunsite.dk> <7x1u24o749.fsf@ruckus.brouhaha.com> <529377f6$0$1658$e4fe514c@dreader35.news.xs4all.nl>

Show all headers | View raw


albert@spenarnc.xs4all.nl (Albert van der Horst) writes:
>>C++ ...automatic reference counting (the STL shared_ptr template)
> Forth can do better than C++ IMO for a very principal reason.
> C++ has this dynamic memory allocation built in. It must be there
> and it must work in all C++ ever to be invented.

I don't understand what you mean there.  shared_ptr is a template
defined in a library.  It's not part of the underlying C++ language.
C++ itself has an operator loading feature which means an object can
have some code that gets called when any given operation (including
assigment like a=b) gets called on the object, and a "~" operation
that gets called when an object goes out of scope.  So you can say

  int func(shared_ptr<Foo> x) {
     shared_ptr<Foo> y = x;
     ...
     otherfunc(y); ...
  }

The assignment "y = x" makes y and x point to the same object, and
increments the reference count in the object.  y gets passed to
otherfunc, which might or might not create further references to the
object.  Then func finishes, and y goes out of scope, automatically
decrementing the reference.  Or if func throws an exception, the
exception unwinding also decrements the reference.  Finally, if the
refcount goes to 0, the object is freed.  The programmer doesn't have to
track stuff at all, other than avoiding reference cycles.  It's almost
like GC.

I don't see how to do that in Forth, which doesn't have any notion of
types or scopes.  It takes a fair amount of compiler hair.

> The discipline about using strings is not a complicated one-size-fits-all
> but it is part of the application. In the above there where three
> different classes of strings.

Sure, fair enough, you can get a bit more performance by not gc'ing
everything.

> This may also be the reason that general string packages have not
> caught on in Forth.

It could also just be that Forth applications tend to not do much with
strings.

> Now if I work with current objects I can fill in
>    ^object !
> at the dots.

One of these days I'd like to figure out how to use a Forth object
package.  But, that still doesn't address the storage reclamation issue.

Back to comp.lang.forth | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-11-25 07:41 -0500
  Re: Reclaiming Allocated Memory Paul Rubin <no.email@nospam.invalid> - 2013-11-25 07:04 -0800
    Re: Reclaiming Allocated Memory albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-11-25 16:16 +0000
      Re: Reclaiming Allocated Memory Paul Rubin <no.email@nospam.invalid> - 2013-11-25 09:03 -0800
        Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-11-26 06:30 -0500
          Re: Reclaiming Allocated Memory AKK <akk@nospam.org> - 2013-11-26 13:07 +0100
    Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-11-26 05:11 -0500
  Re: Reclaiming Allocated Memory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-04 16:46 +0000
    Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-12-05 06:43 -0500
      Re: Reclaiming Allocated Memory Paul Rubin <no.email@nospam.invalid> - 2013-12-05 06:30 -0800
        Re: Reclaiming Allocated Memory albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-05 14:37 +0000
          Re: Reclaiming Allocated Memory Paul Rubin <no.email@nospam.invalid> - 2013-12-05 07:21 -0800
        Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-12-06 04:57 -0500
          Re: Reclaiming Allocated Memory Paul Rubin <no.email@nospam.invalid> - 2013-12-06 07:38 -0800
            Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-12-07 06:14 -0500
      Re: Reclaiming Allocated Memory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-05 18:14 +0000
        Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-12-06 04:58 -0500
          Re: Reclaiming Allocated Memory Bernd Paysan <bernd.paysan@gmx.de> - 2013-12-06 17:30 +0100
            Re: Reclaiming Allocated Memory Doug Hoffman <glidedog@gmail.com> - 2013-12-07 05:59 -0500
              Re: Reclaiming Allocated Memory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-07 11:57 +0000
                Re: Reclaiming Allocated Memory albert@spenarnc.xs4all.nl (Albert van der Horst) - 2013-12-07 17:48 +0000
                Re: Reclaiming Allocated Memory Bernd Paysan <bernd.paysan@gmx.de> - 2013-12-07 19:15 +0100
                Re: Reclaiming Allocated Memory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-09 13:45 +0000
          Re: Reclaiming Allocated Memory anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2013-12-06 17:42 +0000

csiph-web