Re: Strong/weak pointers

lican <>
Mon, 1 Sep 2008 16:45:43 -0700 (PDT)

          From comp.compilers

Related articles
Strong/weak pointers (Michiel Helvensteijn) (2008-09-01)
Re: Strong/weak pointers (lican) (2008-09-01)
Re: Strong/weak pointers (=?ISO-8859-15?Q?Jan_Vorbr=FCggen?=) (2008-09-02)
Re: Strong/weak pointers (Marco van de Voort) (2008-09-02)
Re: Strong/weak pointers (2008-09-02)
Re: Strong/weak pointers (Dmitry A. Kazakov) (2008-09-02)
Re: Strong/weak pointers (Armel) (2008-09-03)
Re: Strong/weak pointers (glen herrmannsfeldt) (2008-09-03)
[3 later articles]
| List of all articles for this month |

From: lican <>
Newsgroups: comp.compilers
Date: Mon, 1 Sep 2008 16:45:43 -0700 (PDT)
Organization: Compilers Central
References: 08-09-004
Keywords: design
Posted-Date: 03 Sep 2008 05:17:26 EDT

Well, to be honest I think if you give a programmer too much power he/
she wouldn't know what to do with it. In this case it would be
something like 'should I use the weak one? no, I have to have at least
one reference... but wait, what will be deleted first?' and such. Try
the strong ones and if you feel something's missing try to add the
weak pointer. Look at Boost library, it has all sorts of smart
pointers. I'll bet half of them is very rarely used. Weak, scoped,
shared, _ptr or _array. I once saw a code that had twice the ptr
types ;) People have to get used to them, read some manuals, know
which type is for what and when not to use some of them. It gets
confusing. Look at C++, one pointer for all things. If you know what
you're doing it can work out. But beware, one mistake and good luck
wasting days on debugging. So I'm guessing it's a trade-off: make it
more general (relatively faster and more error prone) or very
specialized (hard to use and maybe debug). If you can try only the
strong ones first (if it's not that much of a problem of course).
Someone argued that weak pointers are good for things like linked
lists and similar structures. If lists and arrays will be a built-in
type in your language then that problem is solved to some extent.
Maybe some complex composition / inheritance models will need them. On
the other side good planning can solve that too. I once had this
problem with smart pointers in my simple game engine. The base
GameObject class was composed of some other classes i.e.
PhysicsComponent, GraphicsComponent, AIComponent. The thing is that
some components would have to have pointers to the base object so they
could destroy or query it for some reason. I rewrote the whole system
so that either a GameObject HAS a Component or the Component USES the
GameObject. With that the whole pointer problem was resolved.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.