- bard on trig.... - 5 Updates
- Lambda type not isolated within function - 1 Update
- "Functional exception-less error handling with C++23 - 12 Updates
- "Windows 11 Version Detection" by Shao Voon Wong - 2 Updates
- What's your cost of throwing an exception ? - 5 Updates
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 21 05:35PM -0700 Humm... It tried to tell me that cos(0) does not equal sin(pi/2)... This is bad: https://i.ibb.co/DgtknZS/image.png Humm... |
| Manu Raju <MR@invalid.invalid>: Apr 22 03:56AM +0100 On 22/04/2023 01:35, Chris M. Thomasson wrote: > This is bad: > https://i.ibb.co/DgtknZS/image.png > Humm... Try this: <https://i.imgur.com/6fDbiId.png> |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 22 11:09AM +0200 Am 22.04.2023 um 02:35 schrieb Chris M. Thomasson: > is bad: > https://i.ibb.co/DgtknZS/image.png > Humm... Depending on the implementation bit_cast<int64_t>( sin( M_PI / 2 ) ) may be not equal to bit_cast<int64_t>( cos( 0 ) ). |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 22 12:45PM -0700 On 4/21/2023 7:56 PM, Manu Raju wrote: >> Humm... > Try this: > <https://i.imgur.com/6fDbiId.png> It learned! Nice. :^D |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 22 12:50PM -0700 On 4/22/2023 2:09 AM, Bonita Montero wrote: > bit_cast<int64_t>( sin( M_PI / 2 ) ) > may be not equal to > bit_cast<int64_t>( cos( 0 ) ). I was mostly interested in the mathematical truth that cos(0) = sin(pi/2)... ;^) Wrt degrees, pi/2 = 90 degrees. So, I was not really interested in precision issues. |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Apr 22 11:20AM -0700 On 04/20/23 3:06 AM, Frederick Virchanza Gotham wrote: > auto mylambda = [](void)->int { return 27u; }; > return *decltype(&mylambda)(nullptr); > } A lot of things became trivially "non-isolated" in C++ the moment the language started to support `auto` return types and `decltype` (primarily the former). Local types, `private` types... Yes, this is how it is intended to work. Get used to it. -- Best regards, Andrey |
| Muttley@dastardlyhq.com: Apr 22 09:19AM On Fri, 21 Apr 2023 19:31:30 +0200 >> I don't expect to have to spend a lot of my time googling obscure C++ >> semantics when working on code. ... >Use a different language if you'd like to program like with C++98. When you ever work in a corporate enviroment where code has to be clear and maintainable by people of varying abilities then maybe you'll get a clue. In the meantime enjoy life in your academic ivory tower. |
| Mr Flibble <flibble2@reddwarf.jmc.corp>: Apr 22 11:55AM +0100 > When you ever work in a corporate enviroment where code has to be clear and > maintainable by people of varying abilities then maybe you'll get a clue. In > the meantime enjoy life in your academic ivory tower. std::optional is great and move semantics means returning by value need not be more expensive than using an out parameter, there is RVO/NRVO also; additionally, out parameters can be problematic for the optimiser. /Flibble |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 22 01:17PM +0200 > When you ever work in a corporate enviroment where code has to be clear and > maintainable by people of varying abilities then maybe you'll get a clue. ... If you're relaxed and reasonably intelligent, you can learn additional things on the side. My employer currently has two vacancies that require C++17 and Boost. I think you're saying the same thing about Boost that you're saying about more modern C++ features: too complex and unnecessary. Using modern language usually results in less code and sometimes just more portable code. |
| Muttley@dastardlyhq.com: Apr 22 02:41PM On Sat, 22 Apr 2023 11:55:54 +0100 >> the meantime enjoy life in your academic ivory tower. >std::optional is great and move semantics means returning by value need >not be more expensive than using an out parameter, there is RVO/NRVO That depends on what you're doing. If you create a local object/array then set up its values thats already more expensive that just updating a reference without the create. Then you have to add the cost of doing the move upon return. Despite what some people seem to think, move isn't costless. >also; additionally, out parameters can be problematic for the optimiser. Optimisers are a black box. The only way you can know which approach is faster is try both. |
| Muttley@dastardlyhq.com: Apr 22 02:44PM On Sat, 22 Apr 2023 13:17:51 +0200 >> maintainable by people of varying abilities then maybe you'll get a clue. ... >If you're relaxed and reasonably intelligent, you can learn >additional things on the side. My employer currently has two Sure you can ,but if you have a deadline you really don't want to have to dig into some obtuse syntax to figure out what its doing. >vacancies that require C++17 and Boost. I think you're saying >the same thing about Boost that you're saying about more modern >C++ features: too complex and unnecessary. Its more a case of use where appropriate, not simply because you want to look like a rockstar coder. >Using modern language usually results in less code and sometimes >just more portable code. As I've already said, a regex can in theory dispense with a huge amount of code. But sometimes that code would be more intelligable not to mention flexible. |
| Mr Flibble <flibble2@reddwarf.jmc.corp>: Apr 22 04:20PM +0100 > set up its values thats already more expensive that just updating a > reference without the create. Then you have to add the cost of doing the > move upon return. Despite what some people seem to think, move isn't costless. With NRVO you might think you are creating the local object/array in the stack frame of the current function but with NRVO you are actually creating it in the caller's stack frame, so zero cost. >> also; additionally, out parameters can be problematic for the optimiser. > Optimisers are a black box. The only way you can know which approach is faster > is try both. It is well known that out parameters can be problematic for optimisers. /Flibble |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 22 05:27PM +0200 > Sure you can ,but if you have a deadline you really don't want to > have to dig into some obtuse syntax to figure out what its doing. If you have a deadline it's good to learn things which save time. > Its more a case of use where appropriate, not simply because you > want to look like a rockstar coder. Demanding C++17 skills isn't like looking for a rockstar coder. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 22 05:47PM +0200 And you're overburdened with std::expected, which is rather a variant<> with two variables. You can check it from cpppreference in 5min. And you're saying that needs a "rockstar developer" ? I guess you're not developing software at all. |
| Muttley@dastardlyhq.com: Apr 22 04:15PM On Sat, 22 Apr 2023 16:20:24 +0100 >With NRVO you might think you are creating the local object/array in the >stack frame of the current function but with NRVO you are actually >creating it in the caller's stack frame, so zero cost. That depends on whether the compiler does it and if you're writing code for some system where optimisation is low or switched off for some reason (usually odd compiler bugs in edge cases) then it won't happen anyway. |
| Muttley@dastardlyhq.com: Apr 22 04:18PM On Sat, 22 Apr 2023 17:27:29 +0200 >> Its more a case of use where appropriate, not simply because you >> want to look like a rockstar coder. >Demanding C++17 skills isn't like looking for a rockstar coder. There are many useful things in C++ 17 such as shared_mutex so C++ threads could finally manage 3 level locking (decades after pthreads), conditional compilation of constexprs etc, but some of the stuff you post up is just obfuscation for its own sake. |
| Mr Flibble <flibble2@reddwarf.jmc.corp>: Apr 22 05:23PM +0100 > That depends on whether the compiler does it and if you're writing code for > some system where optimisation is low or switched off for some reason (usually > odd compiler bugs in edge cases) then it won't happen anyway. We should primarily be concerned with the general case, not the obscure edge case. /Flibble |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 22 06:38PM +0200 > could finally manage 3 level locking (decades after pthreads), conditional > compilation of constexprs etc, but some of the stuff you post up is just > obfuscation for its own sake. Everything you're not familiar with is obfuscation. std::expected<> is that simple and you didn't take 5min to look the doc. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Apr 21 09:04PM -0500 "Windows 11 Version Detection" by Shao Voon Wong https://www.codeproject.com/Articles/5336372/Windows-11-Version-Detection "In this article, you will see how to detect Windows 11 Version by using C# and C++." Cool. There are some nuances there. Lynn |
| gazelle@shell.xmission.com (Kenny McCormack): Apr 22 03:06PM In article <u1vfb4$33k92$2@dont-email.me>, >"Windows 11 Version Detection" by Shao Voon Wong Off topic. Keith will explain it to you. OT in both groups, but even moreso in CLC (where I am reading it). -- The people who were, are, and always will be, wrong about everything, are still calling *us* "libtards"... (John Fugelsang) |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 22 04:39AM +0200 Am 21.04.2023 um 22:30 schrieb Mr Flibble: > The cost of throwing an exception is not important as exceptions are > supposed to be rare (exceptional - the clue is in the name) events; ... I know that, but Muttley@... suggested in another posting always to use exceptions instead of error return values. I've shown that this doesn't make sense. |
| Mr Flibble <flibble2@reddwarf.jmc.corp>: Apr 22 05:44AM +0100 On 22/04/2023 3:39 am, Bonita Montero wrote: > I know that, but Muttley@... suggested in another posting always > to use exceptions instead of error return values. I've shown that > this doesn't make sense. Wrong. Always using exceptions instead of ERROR return values is perfectly fine because ERRORS, like exceptions, should be rare (exceptional) events. /Flibble |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 22 08:16AM +0200 Am 22.04.2023 um 06:44 schrieb Mr Flibble: > Wrong. Always using exceptions instead of ERROR return values is > perfectly fine because ERRORS, like exceptions, should be rare > (exceptional) events. Look at how Java uses exceptions where in C++ you'd use return-values. That's while exceptions in Java are magnitudes faster (the language itsef aint't faster). If you would do that in C++, like Muttley sug- gested, you'd sometimes have performance problems. |
| Muttley@dastardlyhq.com: Apr 22 09:18AM On Fri, 21 Apr 2023 19:30:42 +0200 >Am 21.04.2023 um 15:45 schrieb Muttley@dastardlyhq.com: >> No muttley didn't think that. ... >You suggested to use exceptions for return-values. No, I suggested them for errors. Learn to read. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 22 01:13PM +0200 > No, I suggested them for errors. Learn to read. That's what I said or didn't mean, that using exceptions for return values should be obvious anyway. But using exceptions to inform the immediate caller doesn't make sense. |
| 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