From: John Max Skaller (skaller_at_[hidden])
Date: 2001-05-11 10:26:52
Larry Evans wrote:
> OOPS. I forgot to tell you to read the README file, 3ird paragraph
> from bottom. The above errors are caused by CR in the Makefile.
AH! Thanks. Oh dear, if there is one thing worse
than STUPID MS-Windows tools that can't read unix files,
it is STUPID Unix tools that can't read Windows ones. :-)
> The following should work:
> < typename SubjTop
> , off_root OffRoot=root_prox
OK. Now, pick just the sp_zomsafe case,
explaining that this is a choice, and put the rest
into the 'USER GUIDE'. Reformat the example
using a more conventional layout. It is OK for your
library code to be in your privately prefered format
during development, but examples should reflect the format
clients would use. If the library ever makes it into
a proposal to the Standards committee, it will have to
use the format used in the Standard: the editor
has standard to follow too.
you should also consider: it is bad style to mix
identifier styles like:
off_root OffRoot = ...
Use the committee prefered style everywhere:
off_root_t off_root = ...
[Using STL map]
> That uses less memory (after all, there are fewer pointee's than pointers);
> however, wouldn't this require an O(log(V.size)) lookup each time the
> root_handle is assigned?
So what? There is a cost to ensuring uniqueness.
If the client wants the system to do this work, that is their
I'm MUCH more concerned that the size of my frame_headers
has now grown to 4 pointers, a long, and two flags. That cost is paid
for every allocated object, even if
a) only collection is used
b) only ref counting is used
c) only explicit deletion is used
This breaks the principle 'the client only pays for
what they use'.
Even worse: the system isn't thread safe. I'm concerned
at the cost of making it thread safe: I'd prefer a single
solution (perhaps with a tiny amount of conditional
> 1) Decide which garbage collection method, i.e. which subjtop class)
> you want, say subjtop_mine.
So put this into the USER_GUIDE.
> Of course I'd appreciate any suggestions for making these
> instructions clearer.
Like I said, the first step is to put them into the
USER_GUIDE. Keep a discussion of the underlying
technical decisions made separate.
If the doco isn't clear, you'll get people commenting,
and you can fix it.
Note that my own Felix doco doesn't necessarily
follow these guidelines ... so this would be a fault
in my stuff too.
The one thing people _really_ need is a premade
'Hello World' type of example file that they
can just compile and run _without making any decisions_.
For something as difficult as your system, you
probably want several of these, but you can add
In the case of Felix gc, I now have several example
techniques merged in a single test file, and it
is getting close to the time to split up
-- John (Max) Skaller, mailto:skaller_at_[hidden] 10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850 checkout Vyper http://Vyper.sourceforge.net download Interscript http://Interscript.sourceforge.net
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk