| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Oct 29 02:55PM -0700 On 10/28/2018 6:24 AM, Paul wrote: > else ++numZeros; > return *this; > } [...] I like it. Did something "kind of" similar wrt fractal iteration that hit a zero, well, I just chose another root to follow. Counting the zeros that destroy information is nice. I did another thing wrt avoiding a division my zero. Just avoided it by setting the zero to a small epsilon, and setting a bit to reflect that this special scenario has actually occurred. The caller can detect this bit and act accordingly if needed. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 29 03:26PM -0700 On Sunday, 28 October 2018 15:24:16 UTC+2, Paul wrote: > for(int i = 0; i < vec.size(); ++i) > x *= vec[i]; When you iterate over whole container then use range-based for. for (int e : vec) x *= e; It is easier to read that way. Or if you are after speed then use std::reduce of C++17 instead of those loops. |
| boltar@cylonhq.com: Oct 29 09:34AM On Fri, 26 Oct 2018 14:57:31 -0400 >>> Get a load of this cat. >> Did you just step out of a 1970s B movie? >Were you upset when they canceled Galactica 1980? Gutted mate. Still, at least I now had free time to upgrade the Cylons control system to C++. The old FORTRAN version had quite a few bugs. |
| "Chris M. Thomasson" <invalid_chris_thomasson@invalid.invalid>: Oct 29 02:21PM -0700 >> Were you upset when they canceled Galactica 1980? > Gutted mate. Still, at least I now had free time to upgrade the Cylons control > system to C++. The old FORTRAN version had quite a few bugs. lol. :^) |
| bitrex <user@example.net>: Oct 28 08:48PM -0400 On 10/27/2018 09:11 AM, Jorgen Grahn wrote: > On the other hand, fixing bugs in terrible code without rewriting it > from scratch is a useful skill to have. > /Jorgen the problem is as far as I can tell the task the example code is trying to accomplish doesn't actually require heap allocation but they're shoe-horning in some heap allocations anyway and then intentionally screwing it up so the student "learns"....what, exactly. The example is ill-motivated. |
| Juha Nieminen <nospam@thanks.invalid>: Oct 29 08:50AM >> Adding a destructor that has a delete[] is not enough. Google >> "C++ rule of three". > I'm sure Öö will say "and then rule of five" - see upthread. Wasn't it so that if you follow the "rule of three" even in C++11, nothing breaks. You can follow the "rule of five" if you want more efficiency (essentially, copying temporaries around becomes much more efficient). |
| "Öö Tiib" <ootiib@hot.ee>: Oct 29 06:09AM -0700 On Monday, 29 October 2018 10:50:48 UTC+2, Juha Nieminen wrote: > Wasn't it so that if you follow the "rule of three" even in C++11, nothing > breaks. You can follow the "rule of five" if you want more efficiency > (essentially, copying temporaries around becomes much more efficient). Yes. Compiler won't implicitly define move constructors and assignments when one of other four is user-declared. So when we want to use move then we either have to declare those or to declare none of the five. Also implicitly declared copy constructors and copy assignments when one of other two is user-defined is deprecated. However compilers do not issue any diagnostics about that deprecation so it has no effects in practice. |
| 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