3 ms·

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

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?

phoe-krk 4y ago
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.
- rictic 4y ago
  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.
  - lifthrasiir 4y ago
    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.
    - sharikous 4y ago
      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?
    - titzer 4y ago
      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.
      - anonymoushn 4y ago
        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). ]
        titzer 4y ago
        Converting a signed negative number to unsigned is UB.
  - bruce343434 4y ago
    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.
synergy20 4y ago
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.
deleted 4y ago
[deleted]
anonymoushn 4y ago
> 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?
- nwellnhof 4y ago
  Obviously, -Werror shouldn't be enabled by default, only for things like CI tests.
  - tomerv 4y ago
    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.

phoe-krk 4y ago

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.

rictic 4y ago
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.
- lifthrasiir 4y ago
  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.
  - sharikous 4y ago
    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?
  - titzer 4y ago
    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.
    - anonymoushn 4y ago
      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). ]
      - titzer 4y ago
        Converting a signed negative number to unsigned is UB.
- bruce343434 4y ago
  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.

synergy20 4y ago

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.

deleted 4y ago

[deleted]

anonymoushn 4y ago

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

nwellnhof 4y ago
Obviously, -Werror shouldn't be enabled by default, only for things like CI tests.
- tomerv 4y ago
  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.