[cfe-dev] cppcoreguidelines-pro-type-member-init

[Alexander Kornienko via cfe-dev]

The author of the check (cc-ed) had plans to work on it further, IIUC.

-- Alex

On Fri, Feb 26, 2016 at 8:49 PM, Michael Miller via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Hi all!
>
> I just finished writing a clang-tidy check to flag uninitialized members
> variables. I was thus very happy to see the
> cppcoreguidelines-pro-type-member-init check land in clang-tidy mainline
> recently! The documentation for this clang-tidy check implies it's
> targeting "Type.6: Always initialize a member variable." It seems like some
> aspects might be missing, though, and I was wondering if there's anyone
> working on adding them or if the plan is to keep the current check as is.
>
> Type.6's enforcement section reads:
> • Issue a diagnostic for any constructor of a non-trivially-constructible
> type that does not initialize all member variables. To fix: Write a data
> member initializer, or mention it in the member initializer list.
> • Issue a diagnostic when constructing an object of a trivially
> constructible type without () or {} to initialize its members. To fix: Add
> () or {}.
>
> Right now, the clang-tidy check only seems to address the first bullet
> point yet only partially. It flags member variables that are built-ins or
> pointers. Based on my reading, it needs to flag any trivially constructible
> typed members, not just built-ins and pointers, excepting fully in-class
> initialized record types. If the second bullet point were addressed, either
> in this check or a separate one, the two together should cover the full
> text.
>
> The other thing I wonder about is whether trivially constructible is too
> narrow. There are types that are not trivially constructible, at least in
> the definition that I know, that still should be flagged:
>
> struct Foo {
>   int Bar;
>   std::string Baz;
> };
>
> Foo is not trivially constructible because Baz has a user defined
> constructor, yet a default initialized Foo will leave Bar in an
> indeterminate state. Therefore, it seems like we need to initialize any
> member that is one of the following:
> A. Built-in or pointer type
> B. Record type without a user-provided default constructor with at least
> one member that needs to be initialized as per these criteria
> C. Array of any type matching these criteria*
>
> Is anyone actively working on these aspects of Type.6 or is that something
> that I should look into?
>
> * One might prefer arrays to be default initialized for performance
> reasons in some cases. Perhaps this should be an option.
>
> Thanks!
> Michael Miller
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20160302/4a3a0b4b/attachment.html>