While by using .get() method we don't get the full protection offered by std::unique_ptr, given that two bugs were already encountered (http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/9065 and omitted nullptr assignment), using std::unique_ptr seems strictly better than raw pointer for all practical purposes.
Details
Diff Detail
Event Timeline
lib/Analysis/AnalysisDeclContext.cpp | ||
---|---|---|
606 | Why having empty user-defined dtor? This class has no vtbl; deleting the dtor declaration in AnalysisDeclContext.h should work. |
include/clang/Analysis/AnalysisDeclContext.h | ||
---|---|---|
424 | BdyFrm is somewhat cryptic. Maybe Farm, Bodies or something else that is not so weirdly abbreviated? |
include/clang/Analysis/AnalysisDeclContext.h | ||
---|---|---|
424 | But that's just forced on us by the naming convention, isn't it? I think other names are worse though: they don't tell us which class we can look at to figure out what is it doing. |
include/clang/Analysis/AnalysisDeclContext.h | ||
---|---|---|
424 | LLVM Coding Standards doesn't endorse this kind of an abbreviation, on the opposite: If you consider shorter names ("Bodies" or "Farm") non-informative, we can go the other direction, e.g. "FunctionBodyFarm". |
include/clang/Analysis/AnalysisDeclContext.h | ||
---|---|---|
424 | What I've meant to say is that I think a good way to write it would be to use unique_ptr<BodyFarm> bodyFarm, or even better unique_ptr<BodyFarm> m_bodyFarm, which is sadly not allowed. We already have a good informative name: the name of the class, and due to the convention we have to modify it :( |
I agree with Alexander here. The LLVM naming convention is not going to change and we should err on the side of using descriptive names. How about "FunctionBodyFarm"?
BdyFrm is somewhat cryptic. Maybe Farm, Bodies or something else that is not so weirdly abbreviated?