[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