BIND 10 #2768: C++ part of #2676
BIND 10 Development
do-not-reply at isc.org
Thu Mar 7 16:59:58 UTC 2013
#2768: C++ part of #2676
-------------------------------------+-------------------------------------
Reporter: vorner | Owner: muks
Type: enhancement | Status:
Priority: medium | reviewing
Component: Inter-module | Milestone:
communication | Sprint-20130319
Keywords: | Resolution:
Sensitive: 0 | CVSS Scoring:
Sub-Project: DNS | Defect Severity: N/A
Estimated Difficulty: 2.5 | Feature Depending on Ticket:
Total Hours: 0 | Add Hours to Ticket: 0
| Internal?: 0
-------------------------------------+-------------------------------------
Comment (by jinmei):
Replying to [comment:7 vorner]:
> > Can you explain what these occasions are when the object is held
alive,
> > so I can review whether it is applicable to this situation? Is it a
> > standard C++ behavior, or implementation dependent?
>
> Sorry, I don't remember exactly, only what I already wrote in the last
comment. Jinmei may remember where he looked that up.
>
> It should be standard C++ (at least what Jinmei quoted looked like a
standard). But I guess this is a place where compilers could make bugs
often.
It's in the standard C++ specification. See
http://bind10.isc.org/ticket/2436#comment:10
In this specific case, though, the overhead is just to copy a shared
pointer, so the advantage of using a reference may be marginal.
The case of 26401e4e861462c03f689c32f97f49d582a64a5b is different. It
(= the code changed by 2640...) was wrong just like this code is
wrong:
{{{#!cpp
const generic::SSHFP* rdf =
dynamic_cast<const generic::SSHFP*>
(rdataFactoryFromFile(RRType("SSHFP"), RRClass("IN"),
"rdata_sshfp_fromWire12").get());
}}}
--
Ticket URL: <http://bind10.isc.org/ticket/2768#comment:8>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list