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

BIND 10 Development do-not-reply at isc.org
Wed Apr 4 08:13:03 UTC 2012


#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
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 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.

 > 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.

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


More information about the bind10-tickets mailing list