Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Modifying Clang for a Safer, More Explicit C++

github.com

Post reply on HN
Print view View original

71–80 of 91 posts

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#71

Post by compiler-devel »

dataflow wrote: post #28
compiler-devel wrote: post #22

Earlier quoted context omitted.

Thank you for your thoughtful response. vector wouldn't work because copy semantics wouldn't apply for a constant type, so mutable would be needed (as you rightly pointed out). I'm not sure that vector should work unless the vector container was updated to move its elements by default (another commenter suggested move-by-default rather than copy-by-default as well). I've used RxCpp in the past and know what nightmare…

> I'm not sure that vector should work Well, I think it "should" work in the sense that I shouldn't have to type "vector " just to get a vector of mutable ints. It's just too much typing for zero benefit. How exactly you make that work is a separate question; you can do it at both the the language and library level. A compromise might be to make 'mutable' be a storage class (like 'register', or like how it already is…

Wow, thank you for this rich and thorough follow up. Interestingly, in the present C++ standard, 'mutable' indeed is a storage class like 'register' while 'const' is a CV-qualifier. I thought it quite odd that 'mutable' isn't a CV-qualifier (the standard leaves this gap open) and for nonmember variables, my patch makes it a CV-qualifier; otherwise it remains a storage class specifier.

WRT lambda changes, I have no particular timeline for this project as it's something I took up on the side. Pointers kinda break any data flow analysis that could be done. For example, imagine an object that serializes itself in one translation unit and is deserialized in another using a different class (this is somewhat common in telecommunications code. Imagine a struct Header { ..., void end[0]; }; which is used to handle messages of variable length but with the same Header types).

Java does just fine without goto (or have they added that since 2010?).

I think code that is intentional is more effective than code that is accidental. That said, I'd rather suppress the unused parameter warning with the '#pragma diagnostic ignored' mechanism than use a cast mechanic that just happens to address a compiler issue.

Thank you for the great list of rules! I agree with them all. Minor nit: you can't use static_cast to cast away constness.

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#72

Post by compiler-devel »

jesse__ wrote: post #62
mjan22640 wrote: post #57

Earlier quoted context omitted.

You would only type 'mutable' at the handful places that really need to be mutable. You would also likely delete the 'const' that are already all over the place. If you really use mutation all over the place, then either you work on something unusual or you should learn to do better.

> You would also likely delete the 'const' I never type `const` in the first place. I don't find it useful, which was the point of my original comment. > then either you work on something unusual In C++, I've been working on game engines, compilers, interpreters and occasionally some reverse engineering. Not sure if that counts as unusual. I'm always thinking about perf, so if I can safely modify something in-place,…

const can serve to mark invariants in your code as well as provide the compiler with information that it can use for optimizations. I highly recommend Scott Meyers' "Effective C++" wherein Item #3 is to 'Use const whenever possible'.

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#73

Post by compiler-devel »

cweagans wrote: post #41
compiler-devel wrote: post #6

Earlier quoted context omitted.

Yes, some (maybe most) could be implemented in a plugin. I wanted to make these changes in part to better understand the clang internals and also show that rather than use external tooling, the language itself can (should?) be changed.

I would submit that C++ has enough inertia (as a language and as an ecosystem) that changing the language itself would be difficult. However, C++ is a huge language and if there's a way to enforce safety by using only a subset of the language + tooling to help you do that, your improvements could be adopted piecemeal by teams looking to level up their codebase a bit. Many languages have a way to opt in to e.g. strict…

Thank you, this indeed is the approach that I'd like to take. Like I mentioned in the commit message on the patch, one of my goals is to show that we can iterate the language (and our codebases) gradually. I'll add a feature flag to my patch to selectively enable and disable these changes.

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#75

Post by compiler-devel »

nextaccountic wrote: post #31

This is a really great idea, specially if you can write a transpiler from general C++ into modified C++ (it can error out on corner cases and ask for manual intervention, but trivial stuff like adding missing braces can and should be done by an automatic tool, like rustfix is used to migrate between Rust editions https://github.com/rust-lang/rustfix ) But here you didn't tackle the main thing: a plan to make simple b…

Great suggestions all around. UB is a beast of a problem and compilers take advantage of UB for optimizations (some going so far as to break programmers' code).

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#76

Post by compiler-devel »

mxmlnkn wrote: post #59
nextaccountic wrote: post #31

This is a really great idea, specially if you can write a transpiler from general C++ into modified C++ (it can error out on corner cases and ask for manual intervention, but trivial stuff like adding missing braces can and should be done by an automatic tool, like rustfix is used to migrate between Rust editions https://github.com/rust-lang/rustfix ) But here you didn't tackle the main thing: a plan to make simple b…

Clang-tidy can detect some of the "Modified C++" constraints like no implicit conversions to bool and can even suggest automatic fixes and also apply them with clang-apply-replacements. Clang-tidy is already a transpiler for "Modified C++".

Indeed. I conceded in my commit message that a linter or checker (such as clang-tidy) could be used to implement some or most of what I suggested (but not the mutable/const change of course). Aside from learning more about how clang works, I wanted to show that we can (and should?) modify the language. There appears to be inertia to drop legacy at the committee level. C++ needs a Snow Leopard release to do some of what I've done here.

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#77

Post by compiler-devel »

grandinj wrote: post #68

In the libreoffice project, we have implemented some of this eg. no c style casts, using clang plugins, which avoids needing a custom build of clang. But always good to see people experimenting in this space!

That's great to hear! I'm sure I could find it, but are the libreoffice coding standards written down (and could you send them my way)?

On the topic of coding standards, there's an excellent github repo https://github.com/isocpp/CppCoreGuidelines which even quotes Bjarne Stroustrup as saying "Within C++ is a smaller, simpler, safer language struggling to get out." There are hundreds of recommendations, like 'ES.31: Don't use macros for constants or "functions"'.

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#78

Post by compiler-devel »

wjko21 wrote: post #24

what's the motivation for removing `goto`, is this something that you find being abused? I code in c++ for work, and I almost never see anyone using it without a good reason.

> I almost never see anyone using it without a good reason

In any of those cases, could the code have been rewritten without goto?

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#79

Post by compiler-devel »

Findecanor wrote: post #29
wjko21 wrote: post #24

what's the motivation for removing `goto`, is this something that you find being abused? I code in c++ for work, and I almost never see anyone using it without a good reason.

My personal opinion is that a programming language should instead of 'goto', have explicit constructs for those things that 'goto' is most often used to emulate: • Breaking out of nested loops • Clause after loop that has run to its end-condition without a break, return or throw. Python allows an 'else'-clause after a loop, but IMHO "default" would be a better keyword. • Error handling (C++ has exception handling alr…

This is interesting, are there languages in use today with these constructs?

Re: Show HN: Modifying Clang for a Safer, More Explicit C++

#80

Post by compiler-devel »

archi42 wrote: post #38

- define the evaluation order for function parameters, e.g. f(a(), b()) [or is that well defined in modern C++?] - allow for named arguments. E.g. let's say for the definition f(int a = 12, int b = 42), one might call f(b: 1337) or f(12, 1337). Not allowing mixing of named & positional is probably a good idea. - take a look at static verification and remove language features that make static verification more difficu…

Completely agree! Thank you for these suggestions.
Post reply on HN