4 ms·

Is C++ capable of deprecating or simplifying anything? Honest question, haven't followed closely. rand() is broken,I;m told unfixable and last I heard still wa

by harry8 2y ago

Is C++ capable of deprecating or simplifying anything? Honest question, haven't followed closely. rand() is broken,I;m told unfixable and last I heard still wasn't deprecated. Is this proposal a test? "Can we even drop support for a solution to a problem literally nobody has?"

epcoa 2y ago
Signed integers did not have to be 2’s complement, there were 3 valid representations: signed mag, 1s and 2s complement. Modern C and C++ dropped this and mandate 2s complement (“as if” but that distinction is moot here, you can do the same for CHAR_BIT). So there is certainly precedence for this sort of thing.
nialv7 2y ago
well they managed to get two's complement requirement into C++20. there is always hope.
- oefrha 2y ago
  Well then someone somewhere with some mainframe got so angry they decided to write a manifesto to condemn kids these days and announced a fork of Qt because Qt committed the cardinal sin of adopting C++20. So don’t say “a problem literally nobody has”, someone always has a use case; although at some point it’s okay to make a decision to ignore them. https://lscs-software.com/LsCs-Manifesto.html https://lscs-software.com/LsCs-Manifesto.html https://news.ycombinator.com/item?id=41614949 https://news.ycombinator.com/item?id=41614949 Edit: Fixed typo pointed out by child.
  - ripe 2y ago
    > because Qt committed the carnal sin of adopting C++20 I do believe you meant to write "cardinal sin," good sir. Unless Qt has not only become sentient but also corporeal when I wasn't looking and gotten close and personal with the C++ standard...
  - epcoa 2y ago
    Wow. https://theminimumyouneedtoknow.com/ https://theminimumyouneedtoknow.com/ https://lscs-software.com/LsCs-Roadmap.html https://lscs-software.com/LsCs-Roadmap.html "Many of us got our first exposure to Qt on OS/2 in or around 1987." Uh huh. > someone always has a use case; No he doesn't. He's just unhinged. The machines this dude bitches about don't even have a modern C++ compiler nor do they support any kind of display system relevant to Qt. They're never going to be a target for Qt. Further irony is this dude proudly proclaims this fork will support nothing but Wayland and Vulkan on Linux. "the smaller processors like those in sensors, are 1's complement for a reason." The "reason" is never explained. "Why? Because nothing is faster when it comes to straight addition and subtraction of financial values in scaled integers. (Possibly packed decimal too, but uncertain on that.)" Is this a justification for using Unisys mainframes, or is the implication that they are fastest because of 1's complement? (not that this is even close to being true - as any dinosaurs are decomissioned they're fucking replaced with capable but not TOL commodity Xeon CPU based hardware running emulation, I don't think Unisys makes any non x86 hardware anymore) Anyway, may need to refresh that CS education. There's some rambling about the justification being data conversion, but what serialization protocols mandate 1's complement anyway, and if those exist someone has already implemented 2's complement supporting libraries for the past 50 years since that has been the overwhelming status quo. We somehow manage to deal with endianness and decimal conversions as well. "Passing 2's complement data to backend systems or front end sensors expecting 1's complement causes catastrophes." 99.999% of every system MIPS, ARM, x86, Power, etc for the last 40 years uses 2's complement, so this has been the normal state of the world since forever. Also the enterpriseist of languages, Java somehow has survived mandating 2's complement. This is all very unhinged. I'm not holding my breath to see this ancient Qt fork fully converted to "modified" Barr spec but that will be a hoot.
    - smaudet 2y ago
      Yeah, I think many of their arguments are not quite up to snuff. I would be quite interested how 1s compliment is faster, it is simpler and thus the hardware could be faster, iff you figure out how to deal with the drawbacks like -0 vs +0 (you could do it in hardware pretty easily...) Buuuut then the Unisys thing. Like you say they dont make processors (for the market) and themselves just use Intel now...and even if they make some special secret processors I don't think the IRS is using top secret processors to crunch our taxes, even in the hundreds of millions of record realm with average hundreds of items per record, modern CPUs run at billions of ops per second...so I suspect we are talking some tens of seconds, and some modest amount of RAM (for a server). The one point he does have is interoperability, which if a lot of (especially medical) equipment uses 1s compliment because its cheaper (in terms of silicon), using "modern" tools is likely to be a bad fit. Compatability is King, and where medical devices are concerned I would be inclined to agree that not changing things is better than "upgrading" - its all well and good to have two systems until a crisis hits and some doctor plus the wrong sensor into the wrong device...
  - __turbobrew__ 2y ago
    This person is unhinged. > It's a desktop on a Linux distro meant to create devices to better/save lives. If you are creating life critical medical devices you should not be using linux.
    - smaudet 2y ago
      > If you are creating life critical medical devices you should not be using linux. Hmm, what do you mean? Like, no you should not adopt some buggy or untested distro, instead choose each component carefully and disable all un-needed updates... But that beats working on an unstable, randomly and capriciously deprecated and broken OS (windows/mac over the years), that you can perform zero practical review, casual or otherwise, legal or otherwise, and that insists upon updating and further breaking itself at regular intervals... Unless you mean to talk maybe about some microkernel with a very simple graphical UI, which, sure yes, much less complexity...
      - __turbobrew__ 2y ago
        I mean you should be building life critical medical devices on top of an operating system like QNX or vxworks which are much more stable and simpler.
        epcoa 2y ago
        Regulations are complex, but not every medical device or part of it is "life critical". There are plenty of regulated medical devices floating around running Linux, often based on Yocto. There is some debate in the industry about the particulars of this SOUP (software of unknown provenance) in general, but the mere idea of Linux in a medical device is old news and isn't crackpot or anything. The goal for this guy seems to be a Linux distro primarily to serve as a reproducible dev environment that must include his own in-progress EDT editor clone, but can include others as long as they're not vim or use Qt. Ironically Qt closed-source targets vxWorks and QNX. Dräger ventilators use it for their frontend. https://www.logikalsolutions.com/wordpress/information-technology/medical-device-developer-linx/ https://www.logikalsolutions.com/wordpress/information-techn... Like the general idea of a medical device linux distros (for both dev host and targets) is not a bad one. But the thinking and execution in this case is totally derailed due to outsized and unfocused reactions to details that don't matter (ancient IRS tax computers), QtQuick having some growing pains over a decade ago, personal hatred of vim, conflating a hatred of Agile with CI/CD.
hyperhello 2y ago
C++ long ago crossed the line where making any change is more work than any benefit it could ever create.
- pjmlp 2y ago
  It is one of my favourite languages, but I think it has already crossed over the complexity threshold PL/I was known for.
- BoringTimesGang 2y ago
  This is such an odd thing to read & compare to how eager my colleagues are to upgrade the compiler to take advantage of new features. There's so much less need to specify types in situations where the information is implicitly available after C++ 20/17. So many boost libraries have been replaced by superior std versions. And this has happened again and again on this enormous codebase that started before it was even called 'C++'.
mrpippy 2y ago
C++17 removed trigraphs
- poincaredisk 2y ago
  Which was quite controversial. Imagine that.
Nevermark 2y ago
I think you are right. Absolutely. Don’t break perfection!! Just accumulate more perfection. What we need is a new C++ symbol that reliably references eight bit bytes, without breaking compatibility, or wasting annnnnny opportunity to expand the kitchen sink once again. I propose “unsigned byte8” and (2’s complement) “signed byte8”. And “byte8” with undefined sign behavior because we can always use some more spice. “unsigned decimal byte8” and “signed decimal byte8”, would limit legal values to 0 to 10 and -10 to +10. For the damn accountants. “unsigned centimal byte8” and “signed centimal byte8”, would limit legal values to 0 to 100 and -100 to +100. For the damn accountants who care about the cost of bytes. Also for a statistically almost valid, good enough for your customer’s alpha, data type for “age” fields in databases. And “float byte8” obviously.
- bastawhiz 2y ago
  > For the damn accountants who care about the cost of bytes. Finally! A language that can calculate my S3 bill
jfbastien 2y ago
As mentioned by others, we've dropped trigraph and deprecated rand (and offer an alternative). I also have: * p2809 Trivial infinite loops are not Undefined Behavior * p1152 Deprecating volatile * p0907 Signed Integers are Two's Complement * p2723 Zero-initialize objects of automatic storage duration * p2186 Removing Garbage Collection Support So it is possible to change things!
mort96 2y ago
How is rand() broken? It seems to produce random-ish values, which is what it's for. It obviously doesn't produce cryptographically secure random values, but that's expected (and reflects other languages' equivalent functions). For a decently random integer that's quick to compute, rand() works just fine.
- akdev1l 2y ago
  > The function rand() is not reentrant or thread-safe, since it uses hidden state that is modified on each call. It cannot be called safely from a multi-threaded application for one
- tntxtnt 2y ago
  RAND_MAX is only guaranteed to be at least 32767. So if you use `rand() % 10000` you'll have real biased towards 0-2767, even `rand() % 1000` is already not uniform (biased towards 0-767). And that assumes rand() is good uniform from 0-RAND_MAX in the first place.
pjmlp 2y ago
GC API from C++11 was removed in C++23, understandibly so, given that it wasn't designed taking into account the needs of Unreal C++ and C++/CLI, the only two major variants that have GC support. Exception specifications have been removed, although some want them back for value type exceptions, if that ever happens. auto_ptr has been removed, given its broken design. Now on the simplying side, not really, as the old ways still need to be understood.
BoringTimesGang 2y ago
>haven't followed closely Don't worry, most people complaining about C++ complexity don't.
- harry8 2y ago
  Hahaha, you're including Bjarne in that sweeping generalization? C++ has long had a culture problem revolving around arrogance an belittling others, maybe it is growing out of it? I would point out that for any language, if one has to follow the standards committee closely to be an effective programmer in that language, complexity is likely to be an issue. Fortunately in this case it probably isn't required. I see garbage collection came in c++11 and has now gone. Would following that debacle make many or most c++ programmers more effective?
112233 2y ago
they do it left and right when it meets their fancy, otherwise it is unconscionable. Like making over "auto". Or adding "start_lifetime_as" and declaring most existing code that uses mmap non-conformant. But then someone asks for a thing that would require to stop pretending that C++ can be parsed top down in a single pass. Immediate rejection!
rty32 2y ago
One obvious example is auto_ptr. And from what I can see it is quite successful -- in a well maintained C++ codebase using C++ 11 or later, you just don't see auto_ptr in the code.
deleted 2y ago
[deleted]

by harry8 2y ago

epcoa 2y ago

Signed integers did not have to be 2’s complement, there were 3 valid representations: signed mag, 1s and 2s complement. Modern C and C++ dropped this and mandate 2s complement (“as if” but that distinction is moot here, you can do the same for CHAR_BIT). So there is certainly precedence for this sort of thing.

nialv7 2y ago

well they managed to get two's complement requirement into C++20. there is always hope.

oefrha 2y ago
Well then someone somewhere with some mainframe got so angry they decided to write a manifesto to condemn kids these days and announced a fork of Qt because Qt committed the cardinal sin of adopting C++20. So don’t say “a problem literally nobody has”, someone always has a use case; although at some point it’s okay to make a decision to ignore them. https://lscs-software.com/LsCs-Manifesto.html https://lscs-software.com/LsCs-Manifesto.html https://news.ycombinator.com/item?id=41614949 https://news.ycombinator.com/item?id=41614949 Edit: Fixed typo pointed out by child.
- ripe 2y ago
  > because Qt committed the carnal sin of adopting C++20 I do believe you meant to write "cardinal sin," good sir. Unless Qt has not only become sentient but also corporeal when I wasn't looking and gotten close and personal with the C++ standard...
- epcoa 2y ago
  Wow. https://theminimumyouneedtoknow.com/ https://theminimumyouneedtoknow.com/ https://lscs-software.com/LsCs-Roadmap.html https://lscs-software.com/LsCs-Roadmap.html "Many of us got our first exposure to Qt on OS/2 in or around 1987." Uh huh. > someone always has a use case; No he doesn't. He's just unhinged. The machines this dude bitches about don't even have a modern C++ compiler nor do they support any kind of display system relevant to Qt. They're never going to be a target for Qt. Further irony is this dude proudly proclaims this fork will support nothing but Wayland and Vulkan on Linux. "the smaller processors like those in sensors, are 1's complement for a reason." The "reason" is never explained. "Why? Because nothing is faster when it comes to straight addition and subtraction of financial values in scaled integers. (Possibly packed decimal too, but uncertain on that.)" Is this a justification for using Unisys mainframes, or is the implication that they are fastest because of 1's complement? (not that this is even close to being true - as any dinosaurs are decomissioned they're fucking replaced with capable but not TOL commodity Xeon CPU based hardware running emulation, I don't think Unisys makes any non x86 hardware anymore) Anyway, may need to refresh that CS education. There's some rambling about the justification being data conversion, but what serialization protocols mandate 1's complement anyway, and if those exist someone has already implemented 2's complement supporting libraries for the past 50 years since that has been the overwhelming status quo. We somehow manage to deal with endianness and decimal conversions as well. "Passing 2's complement data to backend systems or front end sensors expecting 1's complement causes catastrophes." 99.999% of every system MIPS, ARM, x86, Power, etc for the last 40 years uses 2's complement, so this has been the normal state of the world since forever. Also the enterpriseist of languages, Java somehow has survived mandating 2's complement. This is all very unhinged. I'm not holding my breath to see this ancient Qt fork fully converted to "modified" Barr spec but that will be a hoot.
  - smaudet 2y ago
    Yeah, I think many of their arguments are not quite up to snuff. I would be quite interested how 1s compliment is faster, it is simpler and thus the hardware could be faster, iff you figure out how to deal with the drawbacks like -0 vs +0 (you could do it in hardware pretty easily...) Buuuut then the Unisys thing. Like you say they dont make processors (for the market) and themselves just use Intel now...and even if they make some special secret processors I don't think the IRS is using top secret processors to crunch our taxes, even in the hundreds of millions of record realm with average hundreds of items per record, modern CPUs run at billions of ops per second...so I suspect we are talking some tens of seconds, and some modest amount of RAM (for a server). The one point he does have is interoperability, which if a lot of (especially medical) equipment uses 1s compliment because its cheaper (in terms of silicon), using "modern" tools is likely to be a bad fit. Compatability is King, and where medical devices are concerned I would be inclined to agree that not changing things is better than "upgrading" - its all well and good to have two systems until a crisis hits and some doctor plus the wrong sensor into the wrong device...
- __turbobrew__ 2y ago
  This person is unhinged. > It's a desktop on a Linux distro meant to create devices to better/save lives. If you are creating life critical medical devices you should not be using linux.
  - smaudet 2y ago
    > If you are creating life critical medical devices you should not be using linux. Hmm, what do you mean? Like, no you should not adopt some buggy or untested distro, instead choose each component carefully and disable all un-needed updates... But that beats working on an unstable, randomly and capriciously deprecated and broken OS (windows/mac over the years), that you can perform zero practical review, casual or otherwise, legal or otherwise, and that insists upon updating and further breaking itself at regular intervals... Unless you mean to talk maybe about some microkernel with a very simple graphical UI, which, sure yes, much less complexity...
    - __turbobrew__ 2y ago
      I mean you should be building life critical medical devices on top of an operating system like QNX or vxworks which are much more stable and simpler.
      - epcoa 2y ago
        Regulations are complex, but not every medical device or part of it is "life critical". There are plenty of regulated medical devices floating around running Linux, often based on Yocto. There is some debate in the industry about the particulars of this SOUP (software of unknown provenance) in general, but the mere idea of Linux in a medical device is old news and isn't crackpot or anything. The goal for this guy seems to be a Linux distro primarily to serve as a reproducible dev environment that must include his own in-progress EDT editor clone, but can include others as long as they're not vim or use Qt. Ironically Qt closed-source targets vxWorks and QNX. Dräger ventilators use it for their frontend. https://www.logikalsolutions.com/wordpress/information-technology/medical-device-developer-linx/ https://www.logikalsolutions.com/wordpress/information-techn... Like the general idea of a medical device linux distros (for both dev host and targets) is not a bad one. But the thinking and execution in this case is totally derailed due to outsized and unfocused reactions to details that don't matter (ancient IRS tax computers), QtQuick having some growing pains over a decade ago, personal hatred of vim, conflating a hatred of Agile with CI/CD.

hyperhello 2y ago

C++ long ago crossed the line where making any change is more work than any benefit it could ever create.

pjmlp 2y ago
It is one of my favourite languages, but I think it has already crossed over the complexity threshold PL/I was known for.
BoringTimesGang 2y ago
This is such an odd thing to read & compare to how eager my colleagues are to upgrade the compiler to take advantage of new features. There's so much less need to specify types in situations where the information is implicitly available after C++ 20/17. So many boost libraries have been replaced by superior std versions. And this has happened again and again on this enormous codebase that started before it was even called 'C++'.

mrpippy 2y ago

C++17 removed trigraphs

poincaredisk 2y ago
Which was quite controversial. Imagine that.

Nevermark 2y ago

I think you are right. Absolutely. Don’t break perfection!! Just accumulate more perfection. What we need is a new C++ symbol that reliably references eight bit bytes, without breaking compatibility, or wasting annnnnny opportunity to expand the kitchen sink once again. I propose “unsigned byte8” and (2’s complement) “signed byte8”. And “byte8” with undefined sign behavior because we can always use some more spice. “unsigned decimal byte8” and “signed decimal byte8”, would limit legal values to 0 to 10 and -10 to +10. For the damn accountants. “unsigned centimal byte8” and “signed centimal byte8”, would limit legal values to 0 to 100 and -100 to +100. For the damn accountants who care about the cost of bytes. Also for a statistically almost valid, good enough for your customer’s alpha, data type for “age” fields in databases. And “float byte8” obviously.

bastawhiz 2y ago
> For the damn accountants who care about the cost of bytes. Finally! A language that can calculate my S3 bill

jfbastien 2y ago

As mentioned by others, we've dropped trigraph and deprecated rand (and offer an alternative). I also have: * p2809 Trivial infinite loops are not Undefined Behavior * p1152 Deprecating volatile * p0907 Signed Integers are Two's Complement * p2723 Zero-initialize objects of automatic storage duration * p2186 Removing Garbage Collection Support So it is possible to change things!

mort96 2y ago

How is rand() broken? It seems to produce random-ish values, which is what it's for. It obviously doesn't produce cryptographically secure random values, but that's expected (and reflects other languages' equivalent functions). For a decently random integer that's quick to compute, rand() works just fine.

akdev1l 2y ago
> The function rand() is not reentrant or thread-safe, since it uses hidden state that is modified on each call. It cannot be called safely from a multi-threaded application for one
tntxtnt 2y ago
RAND_MAX is only guaranteed to be at least 32767. So if you use `rand() % 10000` you'll have real biased towards 0-2767, even `rand() % 1000` is already not uniform (biased towards 0-767). And that assumes rand() is good uniform from 0-RAND_MAX in the first place.

pjmlp 2y ago

GC API from C++11 was removed in C++23, understandibly so, given that it wasn't designed taking into account the needs of Unreal C++ and C++/CLI, the only two major variants that have GC support. Exception specifications have been removed, although some want them back for value type exceptions, if that ever happens. auto_ptr has been removed, given its broken design. Now on the simplying side, not really, as the old ways still need to be understood.

BoringTimesGang 2y ago

>haven't followed closely Don't worry, most people complaining about C++ complexity don't.

harry8 2y ago
Hahaha, you're including Bjarne in that sweeping generalization? C++ has long had a culture problem revolving around arrogance an belittling others, maybe it is growing out of it? I would point out that for any language, if one has to follow the standards committee closely to be an effective programmer in that language, complexity is likely to be an issue. Fortunately in this case it probably isn't required. I see garbage collection came in c++11 and has now gone. Would following that debacle make many or most c++ programmers more effective?

112233 2y ago

they do it left and right when it meets their fancy, otherwise it is unconscionable. Like making over "auto". Or adding "start_lifetime_as" and declaring most existing code that uses mmap non-conformant. But then someone asks for a thing that would require to stop pretending that C++ can be parsed top down in a single pass. Immediate rejection!

rty32 2y ago

One obvious example is auto_ptr. And from what I can see it is quite successful -- in a well maintained C++ codebase using C++ 11 or later, you just don't see auto_ptr in the code.

deleted 2y ago

[deleted]