- Worst thing about 2020 C++ - 11 Updates
- Avoid excessive write cycles to block - 1 Update
| Sam <sam@email-scan.com>: Aug 15 10:25PM -0400 Jorgen Grahn writes: > > Gee, that's neat. Almost as neat as throw specifications. Oh, wait=E2=80=A6 > With that reasoning, you could argue that C++ should have stopped > evolving with "C with classes" around 1980 ... You might not be aware of this, but throw specifications have been deprecated, and are completely gone in C++20. They turned out to be quite a dumpster fire. This was a completely blown, golden opportunity to add strong exception correctness checking to the core language, simply by aping what Java does. Instead throw specification became weak-ass nothing-burgers, that brought absolutely nothing value-added to to the table. All they did was force a runtime abort when the specification was violated. As Benny Hill would've said: biiiiiiiiiiiiiiiiig ...deal. Wouldn't it be nice to be able to prove, at /compile time/, that all exceptions get caught and handled properly? Simply by making main automatically be throw(), and thus forcing all the knuckleheads to catch their exceptions /or the code won't compile/? Oh, well, it's just a nice dream now… But the bottom line is just because something's been added to the core language doesn't mean it's the greatest thing since sliced bread. The bumpy road of C++'s evolution has its share of piles of flaming crap, still smoldering, in the rear-view mirror. I predict the co-routines will turn out to be another pile. |
| Paavo Helde <eesnimi@osa.pri.ee>: Aug 16 10:37AM +0300 16.08.2020 05:25 Sam kirjutas: > brought absolutely nothing value-added to to the table. All they did was > force a runtime abort when the specification was violated. As Benny Hill > would've said: biiiiiiiiiiiiiiiiig ...deal. Agreed, C++ throw specifications were a disaster. However, strong exception correctness would have been even worse. Maintenance nightmare for very little gain, and cannot be properly applied to templates, virtual functions and shared libraries, so it would have remained half-baked anyway. > automatically be throw(), and thus forcing all the knuckleheads to catch > their exceptions /or the code won't compile/? Oh, well, it's just a nice > dream now… It's very easy to prove at compile time (or even before compile time) that all exceptions are caught and handled, just add catch(...) to main(). > bumpy road of C++'s evolution has its share of piles of flaming crap, > still smoldering, in the rear-view mirror. I predict the co-routines > will turn out to be another pile. Unlike throw specifications, co-routines do not interfere with other code which doesn't use them, so they really cannot become such a smoldering pile. At worst they could become a small unused pile similar to trigraphs. |
| Sam <sam@email-scan.com>: Aug 16 08:36AM -0400 Paavo Helde writes: > correctness would have been even worse. Maintenance nightmare for very > little gain, and cannot be properly applied to templates, virtual functions > and shared libraries, so it would have remained half-baked anyway. I'm not sure why they would be a maintenance nightmare. It's not like existing code somehow decides to throw exceptions that it didn't before, all the time. And I do not see why strong exception checking would have a problem with templates, or virtual functions, or shared libraries. After all, the sole remaining survivor of that epic fail, the noexcept keyword, is perfectly happy keeping them all company. Ignoring the fact that you can still stick a throw inside a noexcept, and it compiles, the noexcept keyword works just fine. With templates or without them. With virtual functions or without them. >> dream now… > It's very easy to prove at compile time (or even before compile time) that > all exceptions are caught and handled, just add catch(...) to main(). Not if one gets thrown inside a noexcept function. Now you've got an aborted program, instead of a nicely caught exception. |
| Paavo Helde <eesnimi@osa.pri.ee>: Aug 16 04:24PM +0300 16.08.2020 15:36 Sam kirjutas: > I'm not sure why they would be a maintenance nightmare. It's not like > existing code somehow decides to throw exceptions that it didn't before, > all the time. But they do. Third-party libraries get new versions which might throw new exceptions. Or what happens more often, I add a new class overriding some virtual function which is throwing a new exception which is not listed in the base class contract. > still stick a throw inside a noexcept, and it compiles, the noexcept > keyword works just fine. With templates or without them. With virtual > functions or without them. Knowing that a function cannot throw at all is a useful piece of information and indeed needed in some circumstances. However, this need appears only rarely and what's more important, it does not require to decorate the rest of the codebase with useless throw specifications. >> main(). > Not if one gets thrown inside a noexcept function. Now you've got an > aborted program, instead of a nicely caught exception. That's one more reason to keep the usage of noexcept at minimum and tightly controlled. A compile-time error would be better indeed in this case. |
| boltar@nowhere.co.uk: Aug 16 06:21PM On Sun, 16 Aug 2020 10:37:20 +0300 >code which doesn't use them, so they really cannot become such a >smoldering pile. At worst they could become a small unused pile similar >to trigraphs. As of the latest MacOS 10.15.6 Clang still doesn't support co-routines properly and gcc (whatever version, didn't check) in the latest debbie update of Linux Mint doesn't either though AFAIK VC++ does so a win for MS there for once. However it means co-routines still can't be used for any portable code so perhaps they'll die before ever becoming mainstream. |
| Sam <sam@email-scan.com>: Aug 16 04:06PM -0400 Paavo Helde writes: >> the time. > But they do. Third-party libraries get new versions which might throw new > exceptions. And then the existing code will not recompile. So you know that you need to fix it. I don't see how that's any different from any other API change. In fact, I would /like it very much/ if it were to happen. As compared to the current situation, where I"m catching the exceptions that are documented by the API. So, everything goes along swimmingly well. Until the new version of this "third party library" starts throwing a different exception, and I missed the memo. So now I'm boned. abort(). I would /very much prefer/ to have the compiler tell me: yo, dude, new exception, you have no handler for it, so no soup for you. So, I very much /like/ having this kind of maintenance foisted on me, where I /know/ I need to do some maintenance, in order to have things continue to work. |
| Sam <sam@email-scan.com>: Aug 16 04:15PM -0400 > update of Linux Mint doesn't either though AFAIK VC++ does so a win for MS > there for once. However it means co-routines still can't be used for any > portable code so perhaps they'll die before ever becoming mainstream. I hope so. This thread finally gave me sufficient motivation to chase down where the co-routine idiocy originated. I strongly suspected it was more Microsoft-lobbied crap. I was right. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/n4775.pdf So, it shouldn't be surprising to see that Microsoft's compiler already implements this garbage. Which is more supporting evidence that it's crap, and will always be crap. I wouldn't lose any sleep if gcc never implements co-routines. But it probably will, at some point. gcc currently lacks support for some C++ library functionality that I sorely miss. Hopefully those gaps will be priority, then this nosense. |
| Vir Campestris <vir.campestris@invalid.invalid>: Aug 16 09:41PM +0100 On 14/08/2020 05:52, Alf P. Steinbach wrote: > structured Cobol programming. I remember that some years ago it was > already very difficult to convince Mr. Google to find anything about it, > but at one time just about every corporate developer knew about it. Actually it _was_ after Michael Jackson. Just not the one normal people have heard of... https://en.wikipedia.org/wiki/Jackson_structured_programming Andy |
| boltar@nowhere.co.uk: Aug 16 08:50PM On Sun, 16 Aug 2020 16:15:51 -0400 >I hope so. This thread finally gave me sufficient motivation to chase down >where the co-routine idiocy originated. I strongly suspected it was more >Microsoft-lobbied crap. Yeah, I can't say I'm a fan either. They have a use case but so does setjmp/ longjmp and I wouldn't use them either unless I absolutely had no other choice (not happened yet). >But it probably will, at some point. gcc currently lacks support for some >C++ library functionality that I sorely miss. Hopefully those gaps will be >priority, then this nosense. Clang hasn't even implemented <=> yet which should be trivial. Not sure about gcc. |
| Brian Wood <woodbrian77@gmail.com>: Aug 16 03:01PM -0700 On Sunday, August 16, 2020 at 8:25:03 AM UTC-5, Paavo Helde wrote: > That's one more reason to keep the usage of noexcept at minimum and > tightly controlled. A compile-time error would be better indeed in this > case. Yeah, whether it's auto, std::string, etc., it's easy to overdo it. Brian Ebenezer Enterprises - Life is fragile; handle with prayer. https://github.com/Ebenezer-group/onwards |
| Brian Wood <woodbrian77@gmail.com>: Aug 16 03:08PM -0700 On Saturday, August 15, 2020 at 4:35:25 PM UTC-5, Jorgen Grahn wrote: > C - Fringe features, easy to ignore. > I haven't investigated coroutines yet; I hope they are in class A. > /Jorgen I've not investigated them a lot, but from what I can tell so far, they aren't going to be useful to me in this program: https://github.com/Ebenezer-group/onwards/blob/master/src/cmw/tiers/cmwA.cc Brian Ebenezer Enterprises - In G-d we trust. |
| "Öö Tiib" <ootiib@hot.ee>: Aug 16 05:23AM -0700 On Friday, 14 August 2020 00:19:19 UTC+3, Frederick Gotham wrote: > Data will be written to the file "data.bin" byte after byte after byte, and then when the file is full, it will start again writing at the beginning of the file. > The "current write position" will be a 64-Bit number stored in the file "position.bin". Of course this file only needs to be 8 bytes in size, however I've chosen to make it 1 megabyte for the following reason: > I need to read up on this more, but I think SDcards are written to in 512-byte blocks at a time. In order to avoid wearing out the first block on the SDcard, I will initially store the "current write position" at Byte #0 in the file "position.bin", and then the next time I'll move it to Byte #512, and then next time I'll move it to Byte #1024, then Byte #1536, then Byte #2048. The multi-gigabyte SD cards have usually 1024 byte sectors. Also SD card is removable storage so your software can not know now what type will be entered 2 years from now. But why you worry? SD card is tiny computer with flash memory that was usually programmed (usually in C) by relatively bright guys. You for some reason assume that they were rather dumb? > Does this sound like a good strategy to get as much longevity as possible out of the SDcard? > I won't increment the "current write position" 1 byte at a time, probably more like one megabyte at a time (so the position marker could be 32-Bit). What you describe is way more primitive and inefficient version of wear leveling technology (to even out the sectors used) already in SD and CF cards. IOW it is already there. By magic. If you program your own file system for flash that you directly access then you may want to do something like that. But if I would be your boss I would buy that code instead of letting you to invent some kind of ugly hack on that case as well. |
| You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment