BIND 10 #1773: build failure with clang++ on MacOS Lion

[BIND 10 Development]

#1773: build failure with clang++ on MacOS Lion
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:         |             Milestone:
  defect                             |  Sprint-20120417
                   Priority:         |            Resolution:
  medium                             |             Sensitive:  0
                  Component:  build  |           Sub-Project:  Core
  system                             |  Estimated Difficulty:  2
                   Keywords:         |           Total Hours:  0.73
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:11 vorner]:
 > Replying to [comment:9 jinmei]:
 > > If we re-enabled the commented-out constructor, it should compile, and
 > > the second one should always be chosen because that's the only legal
 > > choice.
 >
 > Hmm, then it would have to be called as:
 > {{{#!c++
 >       int i(10);
 >       Foo(i);
 > }}}
 > Which is longer.

 Right, and the second constructor that takes a reference in case the
 redundant setup is acceptable in favor of avoiding the copy.  But in
 the benchmark cases I believe conciseness would be much more
 preferred.

 > > this cannot be a solution.   Using `const T& target` instead of
 > > `T target` would avoid this particular issue, but we cannot declare
 > > target as const because we need to be able to call non const member
 > > function of it (`run()`).
 >
 > Thinking about it, `C++` warnings and rules here are a terrible mess.
 Why keeping a const reference should be safer than keeping a non-`const`
 one is a mystery. Anyway, if the goal is to be able to just call the
 `BenchMark` like a function on something where the `run()` is non-const,
 then your solution is probably the way to go.
 >
 > So if changing the `run()` to `const` or calling it with pre-creating
 the variable is not an (better) option, then I think it should be merged.

 Okay.  Pre-creating the variable *could be* an option, but I suspect
 it's less preferred as commented above.  I'm afraid changing run to
 const cannot be an option since it'd be more reasonable to assume
 type T contains some mutable state and run() could modify it (which is
 the case for some of our benchmark test code).

 So I'm going to merge the current branch.  After all, this is a helper
 internal tool, and we can quite freely revisit the design if we come
 up with a better approach.

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