On Mon, 12 Feb 2018 13:15:08 -0800 Paul Vixie <p...@redbarn.org> wrote:
> Ralph Corderoy wrote:
> >
> >> he wanted new(), and methods, and garbage collection.
> >
> > GC as in https://en.wikipedia.org/wiki/Smart_pointer#Features ?
> > So analyse and switch from C pointers to the various C++ kinds?
> i didn't even though about smart/unique/auto pointers. what i was 
> thinking of is that one of the smartest people i ever worked with, was 
> working on incremental generational mostly-copying garbage collection 
> when C++ came out, and in 1989, wrote this:
> www.hpl.hp.com/techreports/Compaq-DEC/WRL-TN-12.pdf

>From that paper:

  An alternative type of garbage collector that one might try
  with C++ is a conservative collector [4]. Unlike the
  mostly-copying collector, such collectors do not put any
  restrictions on pointer use nor do they compact memory. With
  such collectors, objects in the heap need not have valid
  pointers nor have runtime discernible structure. While they
  might place fewer restrictions on programs, the benefits of
  memory compaction provided by the mostly-copying collector
  are worth the restrictions.


  [4] Hans-Juergen Boehm, Mark Weiser. Garbage Collection in
  an Uncooperative Environment.  Software Practice and
  Experience 18(9):807-820, September, 1988.

Bartlett's argument for mostly-copying collector seem to be
for a second order benefit. The first being using GC!

> so while the smart pointers you referenced in wikipedia appear to be a 
> feature of C++11, the GC i was thinking about for C++ happened in 1989.

I haven't used C++ much since 2013 and am not a fan of C++ but
if you have to use C++, these features are an improvement. For
unique_ptrs you still have to free space. shared_ptrs use ref
counting so you have to ensure no cycles. GC just finesses a
whole bunch of such issues. As I showed, the perf loss via
using GC with nmh is tolerable and this is without doing any
cleanup or code improvement based on profiling.

> note: because valgrind finds hundreds of thousands of runtime anomalies 
> in even a trivial libcurl application, and because the suppression file 
> syntax for valgrind doesn't permit me to say "if it comes from libcurl 
> just ignore it", i'm currently at wit's end in verifying my heap memory 
> management in dnsdbq (https://github.com/dnsdb/dnsdbq). any ideas welcomed!

Go to Go? :-)


Reply via email to