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

61–70 of 91 posts

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

#61

Post by jesse__ »

ebingdom wrote: post #55
jesse__ wrote: post #32

> All basic types (excluding pointers and references) are const by default and may be marked 'mutable' to allow them to be changed after declaration FWIW, for me, this is an anti-feature, and I would not use this language because of it. The net effect of this would be that I type "mutable" all over the place and get very little for my effort. I've spent a significant amount of time understanding what the high-consequ…

> The net effect of this would be that I type "mutable" all over the place You might want to consider adopting a more modern programming style for the benefit of your coworkers (and possibly yourself). Mutability all over the place is a nightmare, speaking as someone who currently has to work in a large codebase written like that. It's hard to predict what value a variable is going to have at any particular point in…

> You might want to consider adopting a more modern programming style

Just because some people think a particular style is useful doesn't mean everyone does. You might want to consider checking your biases before making comments like this. I understand the (many) arguments for using `const`, and I've concluded (for myself) that it's not a useful construct. Read and internalize the rest of my previous comment for more information.

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

#62

Post by jesse__ »

mjan22640 wrote: post #57
jesse__ wrote: post #32

> All basic types (excluding pointers and references) are const by default and may be marked 'mutable' to allow them to be changed after declaration FWIW, for me, this is an anti-feature, and I would not use this language because of it. The net effect of this would be that I type "mutable" all over the place and get very little for my effort. I've spent a significant amount of time understanding what the high-consequ…

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, I usually do.

> or you should learn to do better

I do just fine without `const`, thank you. Maybe you should learn to have a more open mind.

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

#63

Post by arinlen »

sanxiyn wrote: post #53
arinlen wrote: post #30

Earlier quoted context omitted.

> I think we can start dropping some of the crufty legacy in the C++ language (...) Do you have any concrete example of what you perceive as being "crufty legacy"?

C style casts, already prohibited by this patch, seems to be a good example.

> C style casts (...)

Those are pretty much irrelevant since at least C++98, specially as not only are they used voluntarily but also under the hood they are already handled with explicit casts.

Is this the best argument there is to break backwards compatibility?

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

#64

Post by archi42 »

sanxiyn wrote: post #53
arinlen wrote: post #30

Earlier quoted context omitted.

> I think we can start dropping some of the crufty legacy in the C++ language (...) Do you have any concrete example of what you perceive as being "crufty legacy"?

C style casts, already prohibited by this patch, seems to be a good example.

I hate writing proper C++ casts because C style is just shorter (e.g. (T)(foobar)), and have to force myself to write the whole invocation. So yeah, not even having the lazy option wouldn't be too bad :)

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

#65

Post by archi42 »

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…

Btw, a lot of bad things are already present as compile time warnings. Using -Wall -Werror (or similar) should already the default for new projects for well over a decade.

You probably know that, but "stealing" stuff from there is also a good idea. Plus, iirc, there are several additional warning options that are not contained in -Wall. Maybe you want to add some of these, too.

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

#66

Post by [deleted] »

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,…

[deleted]

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

#69

Post by compiler-devel »

_kst_ wrote: post #46
enedil wrote: post #14

Earlier quoted context omitted.

mutable x = y in my opinion should be allowed. After all the new variable is just a copy of old one. Why shouldn't you be able to modify it?

Agreed, just like mutable x = 42 should be allowed.

Yes, good point, I retract what I said before. Thanks!

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

#70

Post by compiler-devel »

Findecanor wrote: post #37
vlovich123 wrote: post #3

> - All basic types (excluding pointers and references) are const by default and may be marked 'mutable' to allow them to be changed after declaration If you're not changing how const works, then this has limited utility in C++ because C++ const has all sorts of problems (e.g. not transitive). Also, what does the "mutable" annotation for a free function (i.e. main) mean? That just seems weird. > - Lambda capture list…

Just don't fall into the trap of believing that only making constness transitive would make it fool-proof. A non-"pure" const member function with const parameters could still call some other function with access to a "mutable" alias to what you have a const reference to. You would need something more, such as an ownership system to make the compiler make that impossible (as in Rust) or to detect it (the topic of Mas…

Generally speaking a const member function can't call a member function that is non-const or a member function that modifies a member variable that's not declared mutable. If the present const member function has a const reference to something that's marked mutable, then it's effectively a no-op as far as const value qualifications are concerned.
Post reply on HN