BIND 10 #2105: introduce node deleter of new RBTree

[BIND 10 Development]

#2105: introduce node deleter of new RBTree
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  muks
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120731
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  scalable inmemory                  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => muks


Comment:

 Hello

 Replying to [comment:7 jinmei]:
 > - I suspect we need to pass a `MemorySegment` to the deleter's
 >   operator() (or whatever actually deletes the data).  We'll use a
 >   segment when we actually use it for `RdataSet`.

 I'm not sure if it needs to go to the operator, or if we want to pass a
 deleter that already contains the segment to the tree, or something. But
 it is true the segment must get inside somehow.

 > - I'm not sure if it's a good behavior to autoamtically delete
 >   existing data on setData().  I'm also not sure if we can pass NULL
 >   to the deleter.  please discuss this with the reviwer.

 Well, it kind of makes sense to me to delete it. If we automatically
 delete it upon destruction, it means we've taken the responsibility for
 the destruction and we should not say that we take only half of it ‒ then
 someone outside will still need to take care what to delete when and track
 pointers.

 But, that being said, I think we need a way to take the data out somehow
 without destruction ‒ some kind of release method.

 Deleting of NULL is usually a nop (both with delete and free()), so I
 think we can take an consistent approach. But then, I think it should be
 documented that it is required of the deleter.

 Also, why is data_ set in the body of constructor, if it well could be
 done in the initializer list?
 {{{#!c++
      flags_(FLAG_RED | FLAG_SUBTREE_ROOT),
      labels_capacity_(labels_capacity)
  {
 +    data_ = NULL;
  }
 }}}

 And, the template parameter list ‒ I think we usually place a space after
 the comma there, so it should be `DomainTree<T, DT>`, not
 `DomainTree<T,DT>`.

 With regards

-- 
Ticket URL: <https://bind10.isc.org/ticket/2105#comment:10>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development