- #ifdef with enum member - 2 Updates
- Mutex when returning by value - 2 Updates
| "Öö Tiib" <ootiib@hot.ee>: Jul 22 04:33PM -0700 On Wednesday, 22 July 2020 23:19:42 UTC+3, Alf P. Steinbach wrote: > while C++14 and earlier just had unspecified. > Not sure where I got the notion that the introduction of std::byte > encountered the problem so they had to fix it. Oh it happens ... my memory is also far from what it was say 25 years ago. But C++17 must be is worst standard of C++. Doing even byte wrongly? If it wasn't standard about one of my favorite tools I would consider it comical. Being annoyed somehow helps me to remember. :D > for an enum with fixed underlying types are the underlying type values... > Essentially, for this purpose the underlying type of an enum with > unspecified underlying type is assumed to be a minimum bit field. Such bit-field would make perfect sense if C++ indicated any desire to support architectures with arbitrary bit widths / single bit addressing. Typical 64 bits can precisely address 2 exabytes at singe bit granularity so it is conceivable. Also LLVM actually contains developments in direction of supporting arbitrary bit widths, perhaps for FPGAs or the like. But on any case it feels like pointless pessimization as implementation has to select some concrete underlying type in its ABI also for enum without user-specified underlying type. So why not just say that there is implementation-specified underlying type? |
| Daniel P <danielaparker@gmail.com>: Jul 23 07:07AM -0700 On Wednesday, July 22, 2020 at 10:53:52 AM UTC-4, Öö Tiib wrote: > C++17 itself added borken std::byte into language. C++20 is > supposed to fix it. C++ already had two byte types too many - char, signed char, and unsigned char. For what reason then did we need another non-integral one? We can't even write std::vector<std::byte> v = {0x66,0x6f,0x6f}; It has to be std::vector<std::byte> v = {std::byte{0x66},std::byte{0x6f}, std::byte{0x6f}}; Daniel |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jul 22 08:09PM -0700 On 7/22/2020 2:52 AM, Frederick Gotham wrote: > bool const temp = g_is_on; > return temp; > } I remember a long time ago about something like this. Would the lock be released before the return value is committed! Its been a while, but some settled on something like: <pseudo-code> bool Is_On(void) { bool ret = false; { std::lock_guard<std::mutex> guard(g_mtx_is_on); ret = g_is_on; } return ret; } |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Jul 23 06:50AM -0700 On Thursday, July 23, 2020 at 4:09:26 AM UTC+1, Chris M. Thomasson wrote: > } > return ret; > } If I was writing supremely-portable code that I know might make its way to a less-than-perfect compiler, I might do something like this. I found an alignment error in a PIC compiler a few years ago -- compilers aren't perfect. |
| 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