Hacker News Reader

Comment by kwant_kiddo | Hacker News Reader

Once again the comments prove that people are more interested in trash-talking C++ than than solving real problems.

C++20 IS fixing many complaints or design-choices made in the past.

In terms of the article it casually mentions in the end using

'''-Werror -Wall -Wextra''' The unsigned signed comparisons will fail to compile. Most serious projects use these flags anyway.

I wonder if clang-tidy will also catch this?

View on HN

I'm fully aware of pitfalls of c++ (and c), but I keep coming back to them as all the rest alternatives failed to provide the same speed, performance, and small size.

every language has its dark corner, none is perfect, same as C and C++. C and C++ are popular for decades is a fact, like it or not, data does not lie.

As a person working on big C++ telco codebases for a living, I'm fully aware that C++ is solving real problems and that -Weverything makes it somewhat possible to work with the language. At the same time, I'm appalled by the negative consequences of the "let's fix problems with the old and broken comparison operator by introducing a new, better comparison operator, since we need to maintain almost complete backwards compatibility" approach that C++ takes here.

I'm interested in solving real problems, but C++ deserves trash talking for this reason alone.

What's the alternative? Change the semantics of the comparison operator so that code looks cleaner? That means that when you read a comparison in source you have to know how it's going to be compiled in order to tell if the code is correct or not.

You can opt in a new behavior, attribute syntax added in C++11 should make this much more bearable. In fact, I'm honestly surprised that this mode of language evolution didn't seem to be frequently discussed in C++ WG at all; ECMAScript had `use strict` which is very much the same thing and well received, and if ECMAScript can do it with a lot of legacy code, there is no real reason C++ can do the same.

This isn't that, though. C/C++ continue to leave undefined behavior in specifically for performance. It would, AFAICT, be standard-compliant behavior for a compiler to handled mixed-sign comparisons involving negative numbers in the intuitive number-line way, but the language specification doesn't require this because it means another comparison[1]. Because performance, it's the programmer's responsibility to avoid having negative numbers in such comparisons. And woe to they who have bugs in their programs, the compiler may even exploit that UB to assume the code is never reached. The default is all wrong because the priorities are all wrong.

[1] It's non-obvious to me why an implicit conversion with potential UB would ever be a good idea. If a programmer really did want a UB-having single-machine compare between a signed (but non-negative) int and an unsigned int, they could write an explicit static_cast and then compare. Such a static_cast would be the UB-having nop that unlocked a non-UB comparison. You'd get the exact machine code that you wanted, but you had to opt into UB. Bad default that the short, intuitive-looking code has UB.

I don't think this is correct. Comparison operators are defined to perform the usual arithmetic conversions before they are applied, and the usual arithmetic conversions for converting to unsigned integer types are defined like so:

> If the destination type is unsigned, the resulting value is the least unsigned integer congruent to the source integer (modulo 2n where n is the number of bits used to represent the unsigned type). [Note: In a two’s complement representation, this conversion is conceptual and there is no change in the bit pattern (if there is no truncation). ]

Converting a signed negative number to unsigned is UB.

Can you provide a citation? I have above quoted the part of the standard that defines the value of the result of the conversion.

It looks like C++20 updated this so that conversion both ways is defined in a way that preserves two's complement bit-patterns, which you can see here: https://eel.is/c++draft/conv#integral-3

I don't know why they don't do that either. Perhaps because a transition like that will take multiple decades of consistent and steady guidance to succeed, given the nature and size of C++ codebases and nobody will take the responsibility for it?

Welcome to every language that has the balls to say "yeah you know what, that didn't work, here's a revision". Stuff is deprecated all the time.

> Most serious projects use these flags anyway.

Most serious projects are opting in to being unable to compile on future compilers whenever new warnings are added?

Obviously, -Werror shouldn't be enabled by default, only for things like CI tests.

On the contrary, it should be on by default for every build configuration! If you move to a newer compiler version and the compilation breaks, then you just saved yourself valuable debugging time. The alternative is that the new compiler has a new optimization that causes your code to break in runtime. You can always disable specific warnings if you think they're not relevant for your code.

Reply on news.ycombinator.com