<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p><br>
</p>
<div class="moz-cite-prefix">On 20/06/2020 08:21, Ray Zhang via
cfe-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEv7QpydhcV8hoY6w7CVw=7vLjQDzBF7FrG8SSf7ODV=21LMig@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hi all,
<div><br>
</div>
<div>I'm currently implementing a clang tool to replace C style
casts to C++ style casts, i.e. const/static/reinterpret_casts.
I'm almost done, but I've ran into a collection of
issues/questions that I'd like to raise here to make sure it's
not a misunderstanding on my part. My solutions are included
in each bullet point:</div>
<div><br>
</div>
<div>1. (Question) For dependent types, it is unknown whether
static_cast or reinterpret_cast is appropriate for the
situation, so I would like to leave that as a C-style cast in
the refactor tool. Example below:</div>
<div><br>
</div>
<div><span style="color:rgb(28,30,33);font-family:monospace;font-size:15px;white-space:pre-wrap;background-color:rgb(253,245,212)">template <typename T>
void foo() {
int* ptr;
(T*) ptr;
}
</span><br>
</div>
<div>If we call foo<int>, it can be a const_cast, but if
we call foo<double>, it has to be a reinterpret_cast. In
a situation where the user is writing library code, it won't
only be relevant to the current translation unit but also for
future purposes. Therefore, I propose that we leave dependent
type c-style casts as they are.</div>
</div>
</blockquote>
<p><br>
</p>
<p>Makes sense. You shouldn't be trying to transform instantiations
of templates. Perhaps issuing a warning as Arthur wrote makes
sense though.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CAEv7QpydhcV8hoY6w7CVw=7vLjQDzBF7FrG8SSf7ODV=21LMig@mail.gmail.com">
<div dir="ltr">3. (Question) In general, should this tool for C++
also support OpenCL and Objective C++? Technically,
const/static/reinterpret_casts exist in those languages (see <a
href="https://godbolt.org/z/DEz8Rs" moz-do-not-send="true">https://godbolt.org/z/DEz8Rs</a> for
example). In my opinion, I think the casting tool should
strictly adhere to C++ as the language of support and nothing
more for the first iteration because different coding standards
may be held for different languages(and I only have ample
experience with C++). As a result, I propose that the first
iteration of the casting tool be placed outside of clang-tidy as
clang-tidy also supports Objective C (but not OpenCL), as seen
here: <a href="https://clang.llvm.org/extra/clang-tidy/#id2"
moz-do-not-send="true">https://clang.llvm.org/extra/clang-tidy/#id2</a>.
In the main driver I will explicitly check whether the program
is in C++.</div>
</blockquote>
<p><br>
</p>
<p>Clang-tidy has plenty of checks which are C++-specific.</p>
<p>You can make your check c++-specific too:</p>
<p><br>
bool isLanguageVersionSupported(const LangOptions &LangOpts)
const override {<br>
return LangOpts.CPlusPlus;<br>
}<br>
</p>
<p>clang-tidy is still an appropriate place for your check.</p>
<p>Thanks,</p>
<p>Stephen.<br>
</p>
<p><br>
</p>
</body>
</html>