RFR (2nd round) 8071627: Code refactoring to override == operator of Symbol*
Erik Helin
erik.helin at oracle.com
Thu May 28 11:12:10 UTC 2015
On 2015-05-28, John Rose wrote:
> On May 27, 2015, at 10:02 AM, Coleen Phillimore <coleen.phillimore at oracle.com> wrote:
> >
> > One note about methodHandles. Since they have nontrivial copy constructors, they should be passed as const references to prevent copy constructor calls.
>
> I would love to have a robust enough C++ linter to be able to issue and check for rules like, "this type should not implicitly call its copy constructor". I know some of those "gotchas" can be defended against using new C++11 features ("explicit"), but by no means all of them. Linting for Symbol*::operator== is one of them that will never (?) be supported by the core language.
What about clang-tidy [0]? I haven't used it myself but it certainly
looks powerful enough, see some examples regarding contructors in the
slides at [1]. You could also probably implement a
RecursiveASTVisitor [2] using the clang framework to do the analysis.
We should use clang + llvm more :)
Thanks,
Erik
[0]: http://clang.llvm.org/extra/clang-tidy.html
[1]: http://llvm.org/devmtg/2014-04/PDFs/Talks/clang-tidy%20LLVM%20Euro%202014.pdf
[2]: http://clang.llvm.org/docs/RAVFrontendAction.html
> — John
More information about the hotspot-dev
mailing list