- Thread-safe initialization of static objects - 5 Updates
- How to concat two constexpr c-string? - 1 Update
| James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 24 05:19PM -0400 On 9/24/23 14:17, Richard Damon wrote: > On 9/24/23 12:17 PM, James Kuyper wrote: >> On 9/24/23 08:04, Richard Damon wrote: ... > Note the emphasis on the word YOU. > The fact THEY don't see how to do it, even after it has been > demonstrated that it CAN be done, is what is unprofessional. The problem is that Bonita has not recognized those demonstrations as valid and relevant. That might be because she's misunderstood the situation (which would be my guess), it might be because she's right, it might be because you all have explained things to her poorly. However, unless and until she's been convinced that the specification can be met, it's entirely appropriate for her to complain about the "fact" that it can't. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Sep 24 02:32PM -0700 On 9/24/2023 2:19 PM, James Kuyper wrote: > unless and until she's been convinced that the specification can be met, > it's entirely appropriate for her to complain about the "fact" that it > can't. A mutex that has to jump through atomic hoops during a contended lock with any "delayed" resource allocation from the kernel is a no go. Bad design, no good at all. |
| Richard Damon <Richard@Damon-Family.org>: Sep 24 07:00PM -0400 On 9/24/23 5:19 PM, James Kuyper wrote: > unless and until she's been convinced that the specification can be met, > it's entirely appropriate for her to complain about the "fact" that it > can't. Refusing to accept Truth just puts her in the same league as Peter Olcott and Flat Earthers. Someone asserting that something that has been demonstrated isn't true has the burden of proof to actually show their claim. We have implementations that fully claim to be compliant in this, and zero cases even hinting that they are in this aspect. Arguing about it is the same as arguing about Russel's Teapot. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 25 01:06AM +0200 Am 24.09.2023 um 19:10 schrieb Pavel: > so? everyone has been telling you initialization of simple mutices > does not fail. After few hundred posts, you decided to agree? lock() and unlock() might throw system_error. |
| Bonita Montero <Bonita.Montero@gmail.com>: Sep 25 01:10AM +0200 Am 24.09.2023 um 18:47 schrieb Pavel: > Bonita Montero wrote: > Name one platform for which it is not guaranteed and that targets a > compliant C++11+ implementation. Any platform since lock() and unlock() might throw system_error() as documented. |
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Sep 25 12:08AM +0200 On 2023-09-24 10:55 AM, JiiPee wrote: >> Easy peasy. :-) >> - Alf > But isnt it that many recommend not to use define's? Yes. But with proper prefixes it's quite clean. Unfortunately the standard language doesn't yet support pushing/popping macro definitions, though individual implementations do as language extensions. If you really want to avoid macros, /and/ want that compile time concatenation really bad, consider something like --- namespace my { template< class Type > using in_ = const Type&; template< class Type > using ref_ = Type&; template< int n, class Item > struct Wrapped_array_ { using Raw = Item[n]; Raw items; constexpr auto raw() const -> ref_<const Raw> { return items; } }; template< int size_a, int size_b > constexpr auto adjoined( in_<const char[size_a]> a, in_<const char[size_b]> b ) -> Wrapped_array_<size_a + size_b - 1, char> { const int len_a = size_a - 1; const int len_b = size_b - 1; const int n = len_a + len_b + 1; Wrapped_array_<n, char> result{}; for( int i = 0; i < len_a; ++i ) { result.items[i] = a[i]; } for( int i = 0; i < len_b; ++i ) { result.items[i + len_a] = b[i]; } result.items[n - 1] = '\0'; return result; } } // namespace my #include <stdio.h> auto main() -> int { constexpr auto& a = "abc"; constexpr auto& b = "def"; static constexpr auto c_wrapped = my::adjoined( a, b ); constexpr auto& c = c_wrapped.raw(); puts( c ); } --- - Alf |
| 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