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