Live data from Hacker News

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

github.com

81–90 of 91 posts

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

#81
post #65
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.

Great suggestion.

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

#82
post #67

Without an Issue tracker on the GH fork it will be hard to add ideas. I would add: removing Unicode identifiers, because identifiers are meant to be identifiable.

Great suggestion, I'll set up an issue tracker. A few people have ventured into the code to leave some comments inline, I welcome that.

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

#83

I'm not sure about explicit braces for cases in `switch`. I think what Swift does is pretty neat: each case breaks by default, so you don't have to write `break;`, instead you have to write `fallthrough` to explicitly allow them falling through.

That is neat, I'll look further into it.

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

#84
post #27

const-by-default is definitely nice. Does this extend to both sides of a pointer type? Does int * refer to int const * const? There is nothing wrong with [&] for short-lifetime lambdas. Lambdas passed to std algorithms or immediately invoked lambdas come to mind. edit: Are data members also const by default? How do I declare a non-const data member that is const when accessed within a const member function? (so non-c…

In my first release I didn't address pointers or references and need to think on them further. I'll release updates over time that address these as well as many of the great ideas that I've received from other commenters.

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

#85

IMO it would help adoption if you supply a clang-powered rewriter into and out of your language variant. It allays the fear of losing your codebase if the compiler project dies. Reverse the default for typename. Currently some_class ::thing is assumed to be an expression where 'thing' is a variable, when we don't know which template pattern to use because there may be an explicit specialization on the T that the user…

break and continue with an integer argument, how many times to break. "break" breaks out of nearest loop, "break 2" breaks out of two. "continue 2" breaks out of one loop and then performs "continue" on the loop outside that.

This is a neat idea but I'm afraid it's fraught in that the resulting code could be as hard to maintain as the same written with goto.

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

#86

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: D…

So we don't really have strong coding standards (kind of tricky when you inherit a 10 million LOC codebase written over ~20 years), we just try to be pragmatic and improve the code where we can.

So we have a collection of plugins, see here: https://cgit.freedesktop.org/libreoffice/core/tree/compilerp...

Which verify a variety of things.

We focus on 2 things: finding dodgy code and using APIs correctly. We don't try to modify the C++ language, just restrict accidentally straying into some of the really nasty corners.

But I like to keep an eye on experiments like yours for ideas :-)

e.g.

no c-style casts: https://cgit.freedesktop.org/libreoffice/core/tree/compilerp...

use the comma-operator sparingly: https://cgit.freedesktop.org/libreoffice/core/tree/compilerp...

is your loop variable really big enough: https://cgit.freedesktop.org/libreoffice/core/tree/compilerp...

calling virtual methods from destructors is dodgy: https://cgit.freedesktop.org/libreoffice/core/tree/compilerp...

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

#87

Earlier quoted context omitted.

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

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

C++ is quite literally meant for use cases where Java (or Python or C# or Go or pretty much any other language) is not "just fine". And as I mentioned above, you CAN get by without goto. You just have to go through (go to?) contortions in certain cases without it that make the situation worse rather than better. (And there is no reason to believe such use cases are equally common across all languages, so keep that in mind. For example hardware contexts require dealing with explicit state machines a lot more than software contexts do, and C/C++ are used more in those contexts—to name just one example.) Remember Java was doing "just fine" without lambdas, and it's still doing "just fine" without templates, value types, manual memory management, and a million other things you find in C++. Even C was also doing "just fine" without generics and destructors, but then they realized they're missing out and finally added it.

You have to realize, goto is basically a religion nowadays. People want to believe goto has no legitimate use cases, because (I can only assume) they're scared someone will use it as an excuse to utilize it irresponsibly outside those contexts. Kind of like why some drugs require prescriptions, I guess. I can't stop people from believing what they want, but as far as facts go, it does have use cases that many people simply don't encounter, and I tried to list some of them in my comments above.

> Minor nit: you can't use static_cast to cast away constness.

You actually can! Check this out:

  int const b = 1;
  int const *p = &b;
  **static_cast(static_cast(static_cast(&p))) = 2;
  assert(p == &b && *p == 2);
If this is surprising... I would take it as an indication that it's difficult to foresee what can be done even with the commonplace features in the language (in both good and bad directions), let alone the rare ones (like goto).

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

#88
post #61

Earlier quoted context omitted.

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

It's not about biases. Using immutability is not just some personal preference. It's common knowledge that mutability everywhere is a bad practice. That's why there's a trend toward immutability by default in newer languages.

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

#89

Earlier quoted context omitted.

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

> Java does just fine without goto (or have they added that since 2010?). C++ is quite literally meant for use cases where Java (or Python or C# or Go or pretty much any other language) is not "just fine". And as I mentioned above, you CAN get by without goto. You just have to go through (go to?) contortions in certain cases without it that make the situation worse rather than better. (And there is no reason to belie…

Can you cast away const with a single static_cast? Your static_cast chain is analogous to my example of serializing/deserializing across TUs because the memory is treated as a pointer to storage (your second static_cast). As I understand, the original question you asked pertained to using one of the C++ cast operators in place of a single C style cast.

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

#90

Earlier quoted context omitted.

> Java does just fine without goto (or have they added that since 2010?). C++ is quite literally meant for use cases where Java (or Python or C# or Go or pretty much any other language) is not "just fine". And as I mentioned above, you CAN get by without goto. You just have to go through (go to?) contortions in certain cases without it that make the situation worse rather than better. (And there is no reason to belie…

Can you cast away const with a single static_cast? Your static_cast chain is analogous to my example of serializing/deserializing across TUs because the memory is treated as a pointer to storage (your second static_cast ). As I understand, the original question you asked pertained to using one of the C++ cast operators in place of a single C style cast.

Oh shoot I'm sorry, I misunderstood your comment. Yeah you're right, the const_cast isn't important for casting away const, so it's not important for that rule as far as that goes, good point! This is why I also need to sit down and think about these before I can be confident in them :)
Post reply on HN