3 ms·
Not refuting that c++ can be made safe easily, but this particular error should be blocked by clang-tidy. Assuming you use it and configured it properly, pickin
by Too 6y ago
Not refuting that c++ can be made safe easily, but this particular error should be blocked by clang-tidy. Assuming you use it and configured it properly, picking the right analyzers is an equally witchcraft as writing memory safe code in the first place. https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidelines-pro-type-member-init.html https://clang.llvm.org/extra/clang-tidy/checks/cppcoreguidel...
- saagarjha 6y agoI’m will have to admit that I haven’t tried clang-tidy on it (I will once I get back to a computer), but I am unsure that it would be able to diagnose the issue. I linked to the code in another comment (https://news.ycombinator.com/item?id=23289614 https://news.ycombinator.com/item?id=23289614) but the issue was that I have multiple template specializations of a class, each of which has a constructor that fully initializes that specific specialization’s members. The specific problem was that I used parentheses in a context where I was letting the language deduce which constructor it needed to call based on template arguments but (as far as I understand) this made it deduce the type incorrectly and always call the unspecialized version that had none of the members, but the type system let me coerce that into one of the specialized ones (also not sure how, but presumably some magic along the lines of “they were the same class”) and the non-shared members at that point were not initialized. Oh, and this was in a constexpr context which essentially generated a switch statement on an instruction opcode at compile time. So I’m not confident that an automated tool could pick this up, although if when I try it it finds the issue I will be extremely impressed.