- Why does string.replace not return an iterator? - 3 Updates
- "The pool of talented C++ developers is running dry" - 6 Updates
- Trying to manipulate dynamic_cast - 2 Updates
- What is this header good for ? - 3 Updates
- why use static_cast ? - 2 Updates
- CHAR_BIT is not eight - 1 Update
| David LaRue <huey.dll@tampabay.rr.com>: Nov 02 11:38PM Marcel Mueller <news.5.maazl@spamgourmet.org> wrote in > badly readable to apply multiple replacements to a string. > Why this asymmetry? > Marcel Perhaps you could create one and submit it for ratification. At the very least it would help your coding. |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: Nov 03 10:22PM +0100 Am 03.11.22 um 00:38 schrieb David LaRue: >> badly readable to apply multiple replacements to a string. >> Why this asymmetry? > Perhaps you could create one and submit it for ratification. No idea how to do so. And since it is a potentially breaking change for existing code, it probably cannot be done easily. > At the very least it would help your coding. In fact I already wrote my own function with pointer arithmetic to come around this restriction. I just wondered because replacing string parts not recursively is a not that uncommon requirement. Marcel |
| Andrey Tarasevich <andreytarasevich@hotmail.com>: Nov 03 03:21PM -0700 On 11/2/2022 2:32 PM, Marcel Mueller wrote: > string.replace does not. This makes it more complicated and badly > readable to apply multiple replacements to a string. > Why this asymmetry? Um... On the one hand, `std::string::replace`'s return value is not vacant. It returns a reference to `*this`. So, it is natural to assume that the opportunity to return an iterator wasn't simply ignored, but it simply lost the debate against the idea to return `*this`. The latter allows one to make chained call to `replace`, which was probably considered more valuable. On the other hand, there are several such "asymmetries" in the design of standard containers. The same applies to various `push_back/push_front` methods. In their case the return value is `void`, i.e. the opportunity to return an iterator (or a reference?) was there all the time without any other contenders. `emplace_back/emplace_front` took that opportunity, except that they return references, not iterators. -- Best regards, Andrey. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Nov 03 02:30PM -0500 "The pool of talented C++ developers is running dry" https://www.efinancialcareers.com/news/2022/11/why-is-there-a-drought-in-the-talent-pool-for-c-developers Huh, maybe I can get one of those vaunted C++ $500,000/year developer jobs even at my age of 62. Hat tip to: https://www.codeproject.com/script/Mailouts/View.aspx?mlid=16845 Lynn |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 03 01:04PM -0700 On 11/3/2022 1:03 PM, Chris M. Thomasson wrote: >> jobs even at my age of 62. > Make sure to include the experience of porting a 700,000+ line legacy > Fortran 77 program into C++ Lynn. :^) Just another aspect of your resume... |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 03 01:03PM -0700 On 11/3/2022 12:30 PM, Lynn McGuire wrote: > https://www.efinancialcareers.com/news/2022/11/why-is-there-a-drought-in-the-talent-pool-for-c-developers > Huh, maybe I can get one of those vaunted C++ $500,000/year developer > jobs even at my age of 62. Make sure to include the experience of porting a 700,000+ line legacy Fortran 77 program into C++ Lynn. :^) |
| Lynn McGuire <lynnmcguire5@gmail.com>: Nov 03 04:05PM -0500 On 11/3/2022 3:03 PM, Chris M. Thomasson wrote: > Fortran 77 program into C++ Lynn. :^) >> Hat tip to: >> https://www.codeproject.com/script/Mailouts/View.aspx?mlid=16845 I've gotta finish the experience first. It is a monster. Lynn |
| Lynn McGuire <lynnmcguire5@gmail.com>: Nov 03 04:07PM -0500 On 11/3/2022 3:04 PM, Chris M. Thomasson wrote: >> Make sure to include the experience of porting a 700,000+ line legacy >> Fortran 77 program into C++ Lynn. :^) > Just another aspect of your resume... I turned down a job offer from Microsoft in 1987 and Google in 2004. Wait, that might not look good on my resume. Lynn |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 03 02:25PM -0700 On 11/3/2022 2:05 PM, Lynn McGuire wrote: >>> Hat tip to: >>> https://www.codeproject.com/script/Mailouts/View.aspx?mlid=16845 > I've gotta finish the experience first. It is a monster. Heck, add current experience. Like a log in a resume. Include a link in the "short" version to a longer version that records your journey in the porting process. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 03 02:49AM -0700 On Thursday, 3 November 2022 at 01:12:23 UTC+2, Frederick Virchanza Gotham wrote: > > program is undefined if it compiles. That is not just pedantry, outcome can > > actually behave in rather confusing manner. > The Standard says that identifiers containing a double underscore are reserved. The Standard also tells all about integer promotion, and lots of other stuff too such as an array decaying to a pointer to its first element. The people taking the quiz are expected to be fairly familiar with the Standard, and they can read it while taking the quiz. Still to copy-paste that code is bad idea regardless of deepness of knowledge of standard and years of experience with C++. > I am strongly adverse to spelling standardisation as it curbs creativity. For example if I'm in a happy mood, I will spell 'sheep' with an I instead of an E, as follows: > "Today I am so happi, not to be following everyone in the crowd like a mindless shiip, and instead to inject my creativitii into my spelling" > During the festive season I use camel case. I had one lecturer in college who could do mirror writing. Of course it is OK, if your goal is not to express thoughts and to make a point but just to produce immature sheep noises. But it is not innovative as 95% of internet content seems to be such animal noises expressed in more or less defective human grammar. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Nov 03 12:22PM -0700 On 10/30/2022 2:09 AM, David Brown wrote: >> with the GNU compiler 'g++'. > I don't know what you are trying to do here, but it certainly sounds > like a bad idea... [...] Nasal demons are having a party right now! |
| "Öö Tiib" <ootiib@hot.ee>: Nov 03 08:22AM -0700 On Wednesday, 2 November 2022 at 19:45:33 UTC+2, Bonita Montero wrote: > That might save a lot of CPU-time if you grow a large vector in one > step so that you can omit the initialization if you do it yourself > anyway. How it "might"? IMHO not with what vector is required to do. We grow by your example a vector like vec.resize(large_size). That calls void std::vector<T,A>::resize(size_type count, T value = T()); That function is required to copy construct each element that we did grow using that "value" as argument. On our case that T is supposed to be ndi_t<Something>. Therefore resize() will use compiler-generated constructors ndi_t<Something>::ndi_t( ndit_t const &init ) and those are required to diligently copy that uninitalized Something value from inside of that T() object. So what you expect a compiler can "save" here compared to std::vector<Something> ? |
| Bonita Montero <Bonita.Montero@gmail.com>: Nov 03 04:43PM +0100 Am 03.11.2022 um 16:22 schrieb Öö Tiib: > That calls void std::vector<T,A>::resize(size_type count, T value = T()); > That function is required to copy construct each element that we > did grow using that "value" as argument. The default-constructor of my ndi_t<> is empty so that the loop initia- lizing the new elements is optimized away. My ndi_t<> is a union so the member m_value isn't initialized by default but needs explicit initali- zation with the constructor of my union and I omit that. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 03 09:06AM -0700 On Thursday, 3 November 2022 at 17:43:54 UTC+2, Bonita Montero wrote: > lizing the new elements is optimized away. My ndi_t<> is a union so the > member m_value isn't initialized by default but needs explicit initali- > zation with the constructor of my union and I omit that. What? The resize() is required to copy construct new elements from "value" parameter, not default construct new elements. What default constructor of ndi_t does does not matter in context where it is not called. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 02 05:54PM -0700 > char[8]. > Otherwise it's UB unless your compiler says otherwise (although it > probably Just Works on any of them, in practice.) If a construct is described by the standard as being undefined behavior, said construct is still undefined behavior no matter what the implementation does. The condition of being undefined behavior is only a statement of what is mandated (or not) by the standard; it has nothing to do with whether something "defines" the behavior. |
| "Öö Tiib" <ootiib@hot.ee>: Nov 03 08:51AM -0700 On Thursday, 3 November 2022 at 02:54:58 UTC+2, Tim Rentsch wrote: > behavior is only a statement of what is mandated (or not) by > the standard; it has nothing to do with whether something > "defines" the behavior. The effect of undefined behavior is that compilers are allowed to do whatever these please when running a program that contains it as far C++ standard is concerned. However if particular compiler documents outcome of particular situation (described as undefined behavior by standard) more narrowly then that compiler can't anymore do whatever it pleases without contradicting its documentation. So the effect is gone ... whatever words one uses about it does not matter. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Nov 02 05:46PM -0700 > 3) microcontroller Arduino sam3x8e > If I include "cstdint", then it doesn't have "uint8_t" on the Texas > Instruments compiler. So I'm using "uint_least8_t" in the code. Easier just to use unsigned char. |
| 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