- Finest C++ - 7 Updates
- Where's the dangling reference, according to gcc 13? - 1 Update
- "C++23's New Fold Algorithms" by Sy Brand - 1 Update
- An idea and a question - 2 Updates
- bitfields compact packing within a struct or class - 2 Updates
| Muttley@dastardlyhq.com: Apr 17 03:41PM On Mon, 17 Apr 2023 13:11:36 +0200 > ((min = (ct_t)values < min ? (ct_t)values : min), ...); > return min; >} One of the reasons Perl has been comprehensively killed by Python except in a few niche and legacy applications is because people got sick of trying to decipher the barely comprehensible line noise that "gurus" had written in order to show off. Unfortunately C++ seems to be heading in that direction. Sometimes more can be less when it comes to code. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 17 05:50PM +0200 > few niche and legacy applications is because people got sick of trying to > decipher the barely comprehensible line noise that "gurus" had written in order > to show off. Unfortunately C++ seems to be heading in that direction. If you halfweay know C++17 this doesn't look like Swahili. |
| Muttley@dastardlyhq.com: Apr 17 03:58PM On Mon, 17 Apr 2023 17:50:12 +0200 >order >> to show off. Unfortunately C++ seems to be heading in that direction. >If you halfweay know C++17 this doesn't look like Swahili. You're missing the point. There's enough work in trying to figure out the logic of code itself when a problem arises. Thats only made worse by someone doing mental masturbation with meta programming facilities. C++ is a huge language now and just getting bigger and no one person can learn all of its dusty corners so using fold expressions when in 99% of cases a standard loop iterating an array/container would work just as well is assinine. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 17 06:11PM +0200 > You're missing the point. There's enough work in trying to figure out the > logic of code itself when a problem arises. Thats only made worse by someone > doing mental masturbation with meta programming facilities. ... This "mental masturbation" leads to much less code on the side of the caller. The developer using such a function doesn't need to know whats going on with the code but just how to use it, i.e. being able to read the signature. Large parts of the standar library also look like that. |
| Muttley@dastardlyhq.com: Apr 17 04:24PM On Mon, 17 Apr 2023 18:11:56 +0200 >> logic of code itself when a problem arises. Thats only made worse by someone >> doing mental masturbation with meta programming facilities. ... >This "mental masturbation" leads to much less code on the side of the Whooooosh... A regex can save a lot of code but is often unintelligable to anyone except the person who wrote it. |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 17 07:54PM +0200 > Whooooosh... > A regex can save a lot of code but is often unintelligable to anyone except the > person who wrote it. Regex-Matching is straightforward and doesn't need much template aerobatics inside the function. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Apr 17 04:22PM -0700 On 4/17/2023 6:52 AM, Alf P. Steinbach wrote: > -> auto > { return min({ static_cast<<common_type_t<Args...>>( args )... }); } > That editing error was of course Donald Trump's work. LOL! ;^) |
| Sam <sam@email-scan.com>: Apr 17 07:11PM -0400 David Brown writes: >>>> return v; >>>> } > When I am in doubt about this kind of thing, I make a little class with an Actually I have no doubts, I'm fairly certain that this a second gcc bug involving a spurious warning that I found. The first one was recently fixed, sort of. The spurious warning was triggered in std::vector's bowels, in certain situations. As far as I can decipher the bug updates they fixed it by tweaking std::vector's code to avoid triggering the spurious warning; but the warning was bogus. > external constructor and destructor and look at what is called where. It's > easy to be mislead by the behaviour on simple types like "int". That sounds like a reasonable suggestion, so: #include <iostream> struct my_optional { int value{0}; my_optional() { std::cout << "constructor" << std::endl; } ~my_optional() { std::cout << "destructor" << std::endl; } const int &operator*() const { return value; } }; const int &get_my_optional(const my_optional &o) { return *o; } int main() { my_optional opt; const int &value= *opt; std::cout << "value: " << value << std::endl; return 0; } Result: constructor value: 0 destructor UPDATE: I'm now fairly sure that this has nothing to do with any cockamamie temporary returned from any cockamamie function. The following also trips this warning. Replacing the "int &&def_val" parameter with "int defval" fixes this warning: #include <optional> #include <utility> const int &optional_arg_or(std::optional<int> &def, int &&def_val) { def = def_val; return *def; } int gimme() { std::optional<int> def; const int &v=optional_arg_or(def, 0); int bologna=v; return bologna; } int salami() { std::optional<int> def; def = 0; return *def; } gimme() and salami() do the same thing, but gimme() barks, and changing the parameter to "int def_val" shuts it up. Definitely a gcc bug. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Apr 17 04:36PM -0500 "C++23's New Fold Algorithms" by Sy Brand https://devblogs.microsoft.com/cppblog/cpp23s-new-fold-algorithms/ "C++20 added new versions of the standard library algorithms which take ranges as their first argument rather than iterator pairs, alongside other improvements. However, key algorithms like std::accumulate were not updated. This has been done in C++23, with the new std::ranges::fold_* family of algorithms. The standards paper for this is P2322 and was written by Barry Revzin. It been implemented in Visual Studio 2022 version 17.5. In this post I'll explain the benefits of the new "rangified" algorithms, talk you through the new C++23 additions, and explore some of the design space for fold algorithms in C++." Lynn |
| Daniel <danielaparker@gmail.com>: Apr 17 09:19AM -0700 On Monday, April 17, 2023 at 11:40:08 AM UTC-4, Bonita Montero wrote: > Does anyone know some library that does a move-construction or move > -assigment on a foreign type, i.e. not on its own type ? I'm wondering > if this makes sense sometimes. std::optional<T> has a converting move constructor, template < class U > constexpr optional( optional<U>&& other ); with the requirements that T is not constructible from std::optional<U>, and std::optional<U> is not convertible to T. See https://en.cppreference.com/w/cpp/utility/optional/optional. Daniel |
| Bonita Montero <Bonita.Montero@gmail.com>: Apr 17 08:04PM +0200 Am 17.04.2023 um 18:19 schrieb Daniel: > and std::optional<U> is not convertible to T. > See https://en.cppreference.com/w/cpp/utility/optional/optional. > Daniel Cool, thanks. I think an r-value reference also makes sense if the moved of forwared object is later a part of the constructed object; but I never had such code so far. |
| MarioCPPP <NoliMihiFrangereMentulam@libero.it>: Apr 17 06:59PM +0200 On 17/04/23 16:41, James Kuyper wrote: > C++ is a type sensitive language, so you need to be careful about case. > It does have a bitset class template, it doesn't have anything named > BITSET. it is simply a way to stress keywords in a portable way without formatting -- 1) Resistere, resistere, resistere. 2) Se tutti pagano le tasse, le tasse le pagano tutti MarioCPPP |
| "james...@alumni.caltech.edu" <jameskuyper@alumni.caltech.edu>: Apr 17 10:24AM -0700 On Monday, April 17, 2023 at 12:59:43 PM UTC-4, MarioCPPP wrote: > > BITSET. > it is simply a way to stress keywords in a portable way > without formatting bitset is not a keyword, it's an identifier. I recognised what you were trying to do, I'm just telling you that, because C++ is a case sensitive language, it's a bad idea to use case for any purpose other than identifying the correct spelling of a keyword or identifier. |
| 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