BIND 10 #2369: InputSource helper class for MasterLexer

[BIND 10 Development]

#2369: InputSource helper class for MasterLexer
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  muks
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20121106
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  libdns++                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  loadzone-ng                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by muks):

 Hi Michal

 I'll address the implementation issues first, the the design bits.

 Replying to [comment:7 vorner]:
 > '''Current code''':
 >
 > In the constructor, the `buffer_` is empty, isn't it? Therefore the
 > `buffer_.size()` is zero. Is there a need to write the zero in that much
 > complicated manner, the?
 > {{{#!c++
 > buffer_pos_(buffer_.size()),
 > }}}

 I have changed it to 0, but it was `buffer_.size()` in the first place to
 make the point to the reader that buffer_pos_ is by default pointing at
 the end of the buffer_ vector.  At construction, the buffer_ vector is
 empty, so both are equivalent.

 >
 > Couldn't `!input_.good()` mean some other error as well?
 > {{{#!c++
 >     int c = buffer_[buffer_pos_++];
 >     if (c == '\n') {
 >         line_++;
 >     }
 > }}}
 >
 > What I mean is, if there's an I/O error, and it happens to be at the end
 of RR,
 > we could load an incomplete zone, which is bad (IMO worse than failing
 to load).

 The code fragment you have pasted seems to be unrelated, so was there
 anything else you wanted to add about this fragment?

 About the EOF vs failure issue, an exception has been added now and we
 separate the two issues.

 > I think most of our exception classes are top-level ones (but I don't
 think
 > there's anything forbidding having them nested). Anyway, there might be
 a
 > better name than `UngetError`. Maybe `BeforeBeginning`?

 Done. :)

 > The relation between `ungetAll()` and `compact()` should be documented
 too.

 Done. :)

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