BIND 10 #2565: Refactor RR param parsing code in MasterLoader

[BIND 10 Development]

#2565: Refactor RR param parsing code in MasterLoader
-------------------------------------+-------------------------------------
            Reporter:  muks          |                        Owner:
                Type:  enhancement   |  jinmei
            Priority:  medium        |                       Status:
           Component:  libdns++      |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130108
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  0             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:4 muks]:

 > I have prepared the branch using `boost::optional` as you have
 recommended, but I think it is not necessary in this case.

 > * The bare version (returning `NULL` instead of `MaybeRRClass()`) that
 we talked about on Jabber seems to be enough for this particular case.

 How can we avoid allocating memory every time then?

 > * Even in the RRTTL case, using `MaybeRRTTL` may not need additional
 allocation but does the caller not do an object copy which seems to defeat
 this optimization? Is introducing `boost::optional` required?

 I don't understand this.  Is this about the overhead of copying an
 RRTTL object?  If so, I believe it should be very cheap because it
 only contains a trivial uint32_t member and we only need to copy it in
 a trivial way.

 > * Our use of `boost::optional` does not seem to match the purpose it was
 written for (i.e., to represent a return value that does not lie in the
 range of the return type). In this case, we don't have this problem as
 `NULL` serves this purpose.

 I thought we already covered this topic, so I'm not sure why we are
 repeating...  Yes, NULL suffices, but that would require either
 memory allocation or breaking class integrity.  I wanted avoid these,
 and boost::optional was a tool for that.

 Is there anything still not clear enough?

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