On Mon, Mar 21, 2016 at 6:19 PM, Jeff Law <l...@redhat.com> wrote: > On 03/21/2016 11:16 AM, David Malcolm wrote: >> >> On Mon, 2016-03-21 at 11:13 -0600, Jeff Law wrote: >>> >>> On 03/21/2016 11:15 AM, Trevor Saunders wrote: >>>> >>>> >>>>> I'll resist the urge for now to apply RAII principles in this >>>>> code, but >>>>> that'd probably a much cleaner way to think about the problem in >>>>> general. >>>> >>>> >>>> I worked on a couple attempts to c++ify bitmaps a while back, but >>>> never >>>> finished any of them, but I could probably publish what I did in >>>> case >>>> someone wants to pick that up for gcc 7. >>> >>> Can't hurt. >>> >>> FWIW, bitmaps are low level and independent of trees, rtl, etc that >>> we >>> ought to (in theory) be able to class-ify them and build a real unit >>> testing framework for them. >> >> >> Something like: >> https://gcc.gnu.org/ml/gcc-patches/2015-11/msg02371.html > > Like that, or complete instantiation outside GCC.
I don't like more C++-ification just for the sake of it. Like the alloc-pool C++ification caused more issues than it fixed. I'd happily approve sth like an auto_bitmap class though (bah, we can't have auto <X> as auto is already taken!). Notice that using bitmap_initialize is a micro-optimization to avoid one indirection. I doubt it matters for REE. Also keep in mind bitmap statistics - leaving bitmaps to GC only like REE seems to do will mess them up. Bitmaps that have used bitmap_initialize and allocating from GC need to call bitmap_clear on them. In fact REE should simply use &bitmap_default_obstack, I think that it uses GC is an oversight... Richard. > jeff
