RE: [GD-General] Compile times

[Paul B. <pa...@mi...>]

> -----Original Message-----
> From: Mick West [mailto:mi...@ne...]=20
> Subject: RE: [GD-General] Compile times
>=20
> So, while you could (maybe) say that the behavior of a=20
> ref-counted smart pointer is completely deterministic,=20
> I think it's a fair comment to say that replacing the=20
> usage of a regular pointer with a smart pointer will
> decrease the amount of determinism in a piece of code=20
> (Brian's code, not the smart pointer code), by making=20
> it reliant on the actions of other loosely coupled=20
> objects about which it knows nothing.

Right.  The one thing that I question is whether it is
"easier" overall (in a large codebase) to mentally manage
the "who-should-delete-this" problem or the similar=20
"is-this-release-going-to-delete-this" problem.

We use refcounted objects a lot (we also use passively
tracked pointers with explicit ownership for other things)
and if there is a place in the code where one *expects*
the release to delete the object we insert something like:

	ASSERT_LAST_REFERENCE(ref_counted_object_pointer);
	RELEASE(ref_counted_object_pointer);

Both of these are macros for the non-smart pointer case.
The smart pointer could support a similar method that could
be asserted.

The key here is that we have an compiled piece of code that
verifies an assumption (that the code in question in fact
the last remaining reference at this point).  It is difficult=20
to have a similar *compiled* artifact for verifying that I=20
should be the one deleting a pointer.  I think this has some=20
benefit.

Like I said, we use both refcounting and explicit lifetime
control (for different systems) as both have their benefits.
We try to maintain a consistent scheme within major systems
so people expend as little mental effort as possible when=20
writing or debugging code.

Paul