[llvm-dev] [cfe-dev] Modernizing LLVM Coding Style Guide and enforcing Clang-tidy
Mehdi Amini via llvm-dev
llvm-dev at lists.llvm.org
Mon Jan 9 10:25:33 PST 2017
> On Jan 9, 2017, at 10:20 AM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> On Mon, Jan 9, 2017 at 7:25 AM, Piotr Padlewski via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
> 2017-01-09 16:15 GMT+01:00 Renato Golin <renato.golin at linaro.org <mailto:renato.golin at linaro.org>>:
> On 9 January 2017 at 14:17, Piotr Padlewski via cfe-dev
> <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> > - prefer "using' instead of "typedef"
> > - use default member initialization
> > - use default, override, delete
> > - skip "virtual" with override
>
> I thought we had all of those already...
>
> Nope, some people use it, but I still see a lot of new code with typedefs.
> I would like to have it written in style guide so it will be easier to convince to change in review.
>
> The last two are enforced by compiler warnings now. The second is hard because of bitfields.
>
> I object to the first. If you need a new type name, use a typedef. It's time honored and everyone, including C programmers, will know what you're doing. I don't understand why people push the new thing just for the sake of new-ness.
`using` handles strictly more cases than `typedef`, in particular partial specialization of templates. So because we’ll end up with `using` anyway, uniformity can be valuable. So that could be a motivation: since `using` is needed anyway, might be better to just use it always (I’m not saying it is a “strong” motivation though, just some piece of rational).
(I also find that typedef of function pointers in particular are terrible, and `using` is much better for these, but that can be a matter of taste).
—
Mehdi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170109/ea8f21a8/attachment.html>
More information about the llvm-dev
mailing list