- Strange optimization - 7 Updates
- initial size of a std::vector of std::strings - 2 Updates
- Available C++ Libraries FAQ - 1 Update
- std::unique_lock - Cannot lock twice? - 3 Updates
- Can D simulated by H terminate normally? [Ben Bacarisse] - 7 Updates
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Jun 14 09:46PM +0200 On 2023-06-14 7:56 AM, Bonita Montero wrote: >> an `uint64_t`; that's nonsense. > The reference intitially supplied by the caller is casted from a char > -array. memcpy() is the only legal way in C++ to alias that content. When that function is separately compiled in a different translation unit, how is the compiler to know when compiling calling code that the function uses `memcpy` internally, and when compiling the function, how is the compiler to know that it's generally called with a `*reinterpret_cast<uint64_t*>( p_bytes )` as argument? Answer: it doesn't know, in either case. So generally (let's disregard global optimization with link time compilation) `memcpy` versus `=` can't affect the outcome. So for the separately compiled function it does not matter technically, except possibly for performance, whether it uses clear, concise, safe and guaranteed max efficient `=`, or verbose and unsafe `memcpy`. That means that regarding this matter the common interpretation of the standard is not technical but instead specifies a formal UB that can't happen unless one informs a really perverse compiler that it's there. Even g++'s documentation of `-fstrict-aliasing` says "A character type may alias any other type.". So g++ is /not/ that perverse a compiler, and I believe you won't find any sufficiently perverse compiler. So in practice one can and should not accommodate the common standard interpretation; it's nonsense, built on the assumption of magic effects. Let the committee come up with their COBOL-inspired C++26 formal solution. Let others waste their time trying to write then formally correct COBOL++. I.e. just ignore all that; say no to nonsense. - Alf |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 14 09:53PM +0200 Am 14.06.2023 um 21:46 schrieb Alf P. Steinbach: > When that function is separately compiled in a different translation > unit, how is the compiler to know when compiling calling code that the > function uses `memcpy` internally, It doesn't matter if my function is inlined or not. > So generally (let's disregard global optimization with link > time compilation) `memcpy` versus `=` can't affect the outcome. Thats not safe if you do aliasing. Rest unread. |
| David Brown <david.brown@hesbynett.no>: Jun 14 11:28PM +0200 On 14/06/2023 16:46, Bonita Montero wrote: >>> therefore it's safe to assume that it is partitially intrinsic. >> That's not what "intrinsic" means. <rest unread> > For me it's partitially intrinsic. Please don't use words like that in totally different ways from everyone else. >> for such a simple feature. > Since it's the only way to have safe aliasing in C++ you can silently > rely on that. You said that before - you are still wrong. >> character pointer, ... > In C you can alias anything as a char-array and vise versa, > but not in C++. <https://en.cppreference.com/w/cpp/language/reinterpret_cast#Type_aliasing> <https://en.cppreference.com/w/cpp/types/byte> Look it up in the standards if you prefer. >> You did not check gcc. > I checked it and this trick doesn't work with g++ / RISC-V > _with_ -O2 but I hope this will change, so I check for __GNUC__. Finally you have managed to check it, and found - as I told you at the start - that it does not work for -O2. (Not for RISC-V, and not for any other target that makes a distinction between aligned and unaligned accesses.) While I too hope this will change (that's why I registered it as a bug), the sane thing to do is write the code properly using the correct gcc extension for the purpose - __builtin_assume_aligned - as I suggested. > For me it is because I use systems with flat memory. And in this case > I could even use a char since I only check for the three lower bits to > be zero. No, it is still the wrong type regardless of the memory flatness. It is really very simple. "size_t" is a type used for the size of objects. "uintptr_t" is a type used for converting pointers to unsigned integers. Use the correct type. You have /nothing/ to gain by using the wrong type here other than a reputation for being stubborn in your insistence on writing pointlessly odd code. |
| David Brown <david.brown@hesbynett.no>: Jun 14 11:33PM +0200 On 14/06/2023 17:14, Scott Lurndal wrote: >> wrapper function around a cpu-specific feature or instruction. > FWIW, the HP-3000 MPE operating system interfaces (system calls) were called > "intrinsics". It is not uncommon for system calls to be handled by embedded assembly instructions for software interrupts. You could also argue that the system calls are native to the target but not to the C (or C++) language, just like assembly instructions, and can justifiably be called "intrinsics". "memcpy", on the other hand, is no more "intrinsic" than any other standard library function. |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Jun 14 06:27PM -0400 On 6/14/23 15:46, Alf P. Steinbach wrote: >>> an `uint64_t`; that's nonsense. >> The reference intitially supplied by the caller is casted from a char >> -array. memcpy() is the only legal way in C++ to alias that content. ... > That means that regarding this matter the common interpretation of the > standard is not technical but instead specifies a formal UB that can't > happen unless one informs a really perverse compiler that it's there. All you need is a platform where misaligned pointers do not merely cause the code to be inefficient, but to actually malfunction. On such a platform, if p_bytes is not correctly aligned to store a uint64_t, then the code will malfunction in the reinterpret_cast<>. "When a prvalue v of object pointer type is converted to the object pointer type "pointer to cv T", the result is static_cast<cv T*>(static_cast<cv void*>(v))." (7.6.1.9p7) "A prvalue of type "pointer to cv1 void" can be converted to a prvalue of type "pointer to cv2 T", where T is an object type and cv2 is the same cv-qualification as, or greater cv-qualification than, cv1. If the original pointer value represents the address A of a byte in memory and A does not satisfy the alignment requirement of T, then the resulting pointer value is unspecified." (7.6.1.8p13). In particular, because the pointer value is unspecified, it's not guaranteed to be dereferenceable. A common possibility is that the result of the conversion will be a pointer to the nearest preceding or following correctly aligned location. If p_bytes is correctly aligned, simple assignment will work just as well as memcpy(). > Even g++'s documentation of `-fstrict-aliasing` says "A character type > may alias any other type.". ... True, but that's not what this reinterpret_cast does; it aliases a character type with uint64_t, and that a problem if pbytes is not correctly aligned to hold a uint64_t. The anti-aliasing rules are not symmetric. |
| scott@slp53.sl.home (Scott Lurndal): Jun 14 10:48PM >> "intrinsics". >It is not uncommon for system calls to be handled by embedded assembly >instructions for software interrupts. In this case, it was more generic than that, since: 1) The HP-3000 didn't have an assembler 2) Intrinsic calls were just function calls into a different segment (a stack architecture similar to the Burroughs systems). |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 14 04:01PM -0700 On 6/14/2023 3:27 PM, James Kuyper wrote: > the code to be inefficient, but to actually malfunction. On such a > platform, if p_bytes is not correctly aligned to store a uint64_t, then > the code will malfunction in the reinterpret_cast<>. [...] What about some code that crosses a L2 cache line boundary and causes the damn processor to assert a bus lock... Argh! |
| olcott <polcott2@gmail.com>: Jun 14 05:47PM -0500 On 12/7/2022 8:38 AM, Bonita Montero wrote: > Only MSVC uses 50% increments to satisfy the amortized constant > overhead constraint while inserting. libstdc++ and libc++ use a > 100% increment. So you do have technical competence. -- Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 14 04:00PM -0700 On 6/14/2023 3:47 PM, olcott wrote: >> overhead constraint while inserting. libstdc++ and libc++ use a >> 100% increment. > So you do have technical competence. Bonita Montero is not stupid. |
| Nikki Locke <nikki@trumphurst.com>: Jun 14 10:23PM Available C++ Libraries FAQ URL: http://www.trumphurst.com/cpplibs/ This is a searchable list of libraries and utilities (both free and commercial) available to C++ programmers. If you know of a library which is not in the list, why not fill in the form at http://www.trumphurst.com/cpplibs/cppsub.php Maintainer: Nikki Locke - if you wish to contact me, please use the form on the website. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 14 02:50PM -0700 On 6/14/2023 8:30 AM, Ralf Fassel wrote: > Destroys the lock. If *this has an associated mutex and has acquired > ownership of it, the mutex is unlocked. > Note the conditional on unlocking the mutex in the DTOR. The release can be fairly dangerous. { std::unique_lock<std::mutex> lock(g_mutex); // foo bar baz } The mutex gets locked, and automatically unlocked at the end of the scope, right? Be very careful when using release... |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 14 02:52PM -0700 On 6/9/2023 5:49 PM, Chris M. Thomasson wrote: > ^^^^^^^^^^^^ > The dtor of the damn lock will unlock the mutex. The mutex needs to be > in a locked state before the scope goes out and unlocks it itself! I mistook release() for an unlock(). This can open a can of worms. Actually, not exactly sure why unique_lock would even have a release such that the dtor does not automatically unlock it. Sounds like a nightmare deadlock waiting to happen. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 14 03:02PM -0700 On 6/14/2023 8:30 AM, Ralf Fassel wrote: > Destroys the lock. If *this has an associated mutex and has acquired > ownership of it, the mutex is unlocked. > Note the conditional on unlocking the mutex in the DTOR. Yes. The damn acquire/release vs lock/unlock got me confused. Thanks for the heads up Ralf! Fwiw, I have had to use code where acquire and release actually meant lock and unlock the mutex. Not alter the binding of the RAII object to the underlying mutex itself! ARGH!!!! Sorry. |
| olcott <polcott2@gmail.com>: Jun 14 11:43AM -0500 On 6/14/2023 11:26 AM, Bonita Montero wrote: >> that would have otherwise succeeded when H is presented with the halting >> problem's otherwise "impossible" input: D. > Now I'm 100% confident that you have got a psychosis. That is merely an example of the ad hominem error of reasoning. (Attacking the person): This fallacy occurs when, instead of addressing someone's argument or position, you irrelevantly attack the person or some aspect of the person who is making the argument. https://www.txst.edu/philosophy/resources/fallacy-definitions/Ad-Hominem.html It is not even in the ballpark of showing any error in my claim. -- Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 14 07:03PM +0200 Am 14.06.2023 um 18:43 schrieb olcott: > That is merely an example of the ad hominem error of reasoning. That's not ad homimem. I just wanted to say that you've sth. completely different than a comuter science problem. |
| olcott <polcott2@gmail.com>: Jun 14 12:16PM -0500 On 6/14/2023 12:03 PM, Bonita Montero wrote: >> That is merely an example of the ad hominem error of reasoning. > That's not ad homimem. I just wanted to say that you've > sth. completely different than a comuter science problem. I reframed the problem from a computer science halt decider to a termination analyzer that correctly prevents denial of service attacks from inputs matching the halting problem's input template. Because H does correctly thwart denial of service attacks based on this input then H is necessarily correct from this frame-of-reference. -- Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 14 08:37PM +0200 Am 14.06.2023 um 19:16 schrieb olcott: > from inputs matching the halting problem's input template. > Because H does correctly thwart denial of service attacks based on > this input then H is necessarily correct from this frame-of-reference. I think that others around here understand what I said. But not you. |
| olcott <polcott2@gmail.com>: Jun 14 01:58PM -0500 On 6/14/2023 1:37 PM, Bonita Montero wrote: >> this input then H is necessarily correct from this frame-of-reference. > I think that others around here understand what I said. > But not you. So you do not understand that that termination analyzer H does correctly thwart what would be an otherwise successful denial of service attack by by pathological input D? Are you new to the C++ programming language? A few years ago I beat Herb Sutter's std::string by about 23-fold faster performance. -- Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 14 09:49PM +0200 Am 14.06.2023 um 20:58 schrieb olcott: > So you do not understand that that termination analyzer H does correctly > thwart what would be an otherwise successful denial of service attack by > by pathological input D? *facepalm* The therapist who is a match for you has yet to be born. |
| olcott <polcott2@gmail.com>: Jun 14 04:03PM -0500 On 6/14/2023 2:49 PM, Bonita Montero wrote: >> by pathological input D? > *facepalm* > The therapist who is a match for you has yet to be born. People that insist on staying in rebuttal mode even against the easily verified facts can be spotted when their entire rebuttal is an ad hominem attack. -- Copyright 2023 Olcott "Talent hits a target no one else can hit; Genius hits a target no one else can see." Arthur Schopenhauer |
| 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