Duncan P. N. Exon Smith
2014-Mar-02 01:59 UTC
[LLVMdev] [RFC] The coding standard for "struct" should be relaxed or removed
The current guidelines [1] on the use of the struct keyword are too restrictive and apparently ignored. They limit the use of struct to PODs, citing broken compilers. The guidelines are out-of-date and should be relaxed. Here’s why: 1. Our updated list of supported compilers should all deal correctly with non-POD structs. 2. A quick grep of the source suggests that no one paid attention anyway. I’ve attached a patch that removes the guideline entirely (matching the apparent current practice), but does anyone feel a new explicit guideline is in order? [1]: http://llvm.org/docs/CodingStandards.html#use-of-class-and-struct-keywords -------------- next part -------------- A non-text attachment was scrubbed... Name: remove-struct-guidelines.patch Type: application/octet-stream Size: 1221 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140301/6208807f/attachment.obj>
Chandler Carruth
2014-Mar-02 03:15 UTC
[LLVMdev] [RFC] The coding standard for "struct" should be relaxed or removed
On Sat, Mar 1, 2014 at 5:59 PM, Duncan P. N. Exon Smith < dexonsmith at apple.com> wrote:> The current guidelines [1] on the use of the struct keyword are too > restrictive and apparently ignored. They limit the use of struct to > PODs, citing broken compilers. > > The guidelines are out-of-date and should be relaxed. Here’s why: > > 1. Our updated list of supported compilers should all deal correctly > with non-POD structs. > > 2. A quick grep of the source suggests that no one paid attention > anyway. > > I’ve attached a patch that removes the guideline entirely (matching > the apparent current practice), but does anyone feel a new explicit > guideline is in order? >We should at least remove it, the rule is nonsense as you point out. I would be happy to have a soft rule along the lines of "use struct for types which are intended to be aggregate types, or to behave like aggregate types". IE, types which are suitable for use with list-initialization in C++11. I also don't feel terribly strongly about such things other than that I would prefer *some* guidance to lessen the inconsistency. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140301/0e4b8ba7/attachment.html>
Chris Lattner
2014-Mar-02 06:33 UTC
[LLVMdev] [RFC] The coding standard for "struct" should be relaxed or removed
On Mar 1, 2014, at 7:15 PM, Chandler Carruth <chandlerc at google.com> wrote:> On Sat, Mar 1, 2014 at 5:59 PM, Duncan P. N. Exon Smith <dexonsmith at apple.com> wrote: > The current guidelines [1] on the use of the struct keyword are too > restrictive and apparently ignored. They limit the use of struct to > PODs, citing broken compilers. > > The guidelines are out-of-date and should be relaxed. Here’s why: > > 1. Our updated list of supported compilers should all deal correctly > with non-POD structs. > > 2. A quick grep of the source suggests that no one paid attention > anyway. > > I’ve attached a patch that removes the guideline entirely (matching > the apparent current practice), but does anyone feel a new explicit > guideline is in order? > > We should at least remove it, the rule is nonsense as you point out.This rule was specifically about brokenness with some version of MSVC. That version (I have no idea which, or if it still does that) mangled classes and structs differently. If this isn't the case for the currently supported version of MSVC, we should definitely remove this guideline. -Chris -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140301/a850de0a/attachment.html>
Maybe Matching Threads
- [LLVMdev] [RFC] The coding standard for "struct" should be relaxed or removed
- [LLVMdev] SparseBitVector compile warning
- [LLVMdev] [PATCH]: Add SparseBitmap implementation
- [LLVMdev] [PATCH]: Add SparseBitmap implementation
- [LLVMdev] df_ext_iterator in LiveIntervalAnalysis