- 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.
Show HN: Modifying Clang for a Safer, More Explicit C++
81–90 of 91 posts
Re: Show HN: Modifying Clang for a Safer, More Explicit C++
#82Without 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.
Re: Show HN: Modifying Clang for a Safer, More Explicit C++
#83I'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.
Re: Show HN: Modifying Clang for a Safer, More Explicit C++
#84const-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…
Re: Show HN: Modifying Clang for a Safer, More Explicit C++
#85IMO 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.
Re: Show HN: Modifying Clang for a Safer, More Explicit C++
#86In 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 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++
#87Earlier 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…
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++
#88Earlier 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…
Re: Show HN: Modifying Clang for a Safer, More Explicit C++
#89Earlier 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…
Re: Show HN: Modifying Clang for a Safer, More Explicit C++
#90Earlier 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.