BIND 10 #2371: define dns::MasterLexer class

[BIND 10 Development]

#2371: define dns::MasterLexer class
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20121120
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  libdns++                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  loadzone-ng                        |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:18 muks]:

 > So it was the case that there were protos but no storage allocation for
 it, so a reference could not be made to it. As you say, it looks like the
 compiler's optimizer substitutes it in other places by value.
 >
 > If we already have adopted a way of fixing this by defining it in the
 tests, then that's fine as our code is consistent.
 >
 > Otherwise, I still think it's better to have it defined in the
 `master_lexer_inputsource.cc`. The reason is that while it wastes (sizeof
 (int) + any alignment) of space, we don't have to define it for every
 program that references this storage. A user of this library will also not
 have any surprises. The space wasted should be negligible.
 >
 > But I leave the choice to you, as I merely wanted to discuss this.

 On thinking about it again, I agree with you on this.  Since this is a
 public member variable (although mostly private conceptually in this
 specific case), it wouldn't be safe to assume its address won't be
 needed.

 So I updated the case for END_OF_STREAM with some explanation
 comments.  I think we should update other cases, but that will go to a
 separate cleanup ticket (planning to create one).

 Now this branch depends on #2369, I'll merge it once #2369 is merged.

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