- P.1: Express ideas directly in code - 1 Update
- Christmas Quiz... - 7 Updates
- "C++ 23 Standard Won't Have a Key Parallelism Feature" - 1 Update
- g++ -c -Werror -Weverything exercise_2_17.cpp - 2 Updates
| "Alf P. Steinbach" <alf.p.steinbach@gmail.com>: Dec 27 11:31PM +0100 On 25 Dec 2022 15:40, Stefan Ram wrote: > with them. To learn how to use "Month" takes me at least one > additional lookup. It could be even more lookups if even > "Month" then redirects me to more opaque types. Hm, I don't buy that argument. But I would declare the function as auto month() const -> Month::Enum; Say no to the newfangled enum classes, they're Just Wrong. Define the enum like this: struct Month{ enum Enum{ january = 1, february, ... }; }; > Would there be a "var", it would tell me clearly that > - the function may change the object state, it is > not to be considered "const". I guess the keyword `mutable` is a little underused and could be set to work, like they did with `auto`. However it's not possible to change the defaults, so it would be a matter of just adding verbosity to express explicitly what would otherwise be expressed implicitly. - Alf |
| Bonita Montero <Bonita.Montero@gmail.com>: Dec 27 04:59AM +0100 Am 26.12.2022 um 22:22 schrieb Chris M. Thomasson: > B: MEMBAR #StoreLoad | #LoadLoad > C: MEMBAR #LoadStore | #StoreStore > D: MEMBAR #StoreLoad | #StoreStore 1. I use proper C++ barriers so I won't have to care for that. 2. SPARC is dead. |
| Michael S <already5chosen@yahoo.com>: Dec 27 03:38AM -0800 On Monday, December 26, 2022 at 11:23:06 PM UTC+2, Chris M. Thomasson wrote: |
| Michael S <already5chosen@yahoo.com>: Dec 27 03:42AM -0800 On Monday, December 26, 2022 at 11:23:06 PM UTC+2, Chris M. Thomasson wrote: > Imagine you are on a SPARC in RMO mode, you are programming in assembly > language. If I am not mistaken, SPARC RMO is paper spec that was never implemented in hardware. Which does not mean that it is impossible to imagine that I am programming it in assembler, but it takes stronger imagination than I posses. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 27 01:29PM -0800 On 12/26/2022 7:59 PM, Bonita Montero wrote: >> D: MEMBAR #StoreLoad | #StoreStore > 1. I use proper C++ barriers so I won't have to care for that. > 2. SPARC is dead. Well, suppose you were tasked with creating the guts for C++ membars for the SPARC. Imvvho, the SPARC in RMO mode is a good place to learn. The MEMBAR instruction is pretty damn diverse! :^) |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 27 01:31PM -0800 On 12/27/2022 3:42 AM, Michael S wrote: > If I am not mistaken, SPARC RMO is paper spec that was never implemented > in hardware. Which does not mean that it is impossible to imagine that I am > programming it in assembler, but it takes stronger imagination than I posses. SPARC RMO is a real thing. https://www.linuxjournal.com/article/8212 "Solaris on SPARC uses total-store order (TSO); however, Linux runs SPARC in relaxed-memory order (RMO) mode." |
| Michael S <already5chosen@yahoo.com>: Dec 27 02:09PM -0800 On Tuesday, December 27, 2022 at 11:31:33 PM UTC+2, Chris M. Thomasson wrote: > https://www.linuxjournal.com/article/8212 > "Solaris on SPARC uses total-store order (TSO); however, Linux runs > SPARC in relaxed-memory order (RMO) mode." I am pretty sure that the article got it wrong. OS can set control bits in register to any value it wishes, but the underlying hardware will still behave as TSO. At least, if the hardware is made by Sun/Oracle or Fujitsu, but all other SPARC CPU vendors became irrelevant since ~1996, anyway. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Dec 27 02:17PM -0800 On 12/27/2022 2:09 PM, Michael S wrote: > hardware will still behave as TSO. > At least, if the hardware is made by Sun/Oracle or Fujitsu, but all other SPARC > CPU vendors became irrelevant since ~1996, anyway. [...] Are you telling me that SPARC RMO mode was run as if it was TSO in the hardware? I need to ask Paul. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Dec 27 03:52PM -0600 "C++ 23 Standard Won't Have a Key Parallelism Feature" https://thenewstack.io/c-23-standard-wont-have-a-key-parallelism-feature/ The C++ 2023 standard won't have an asynchronous algorithm feature called senders and receivers. Lynn |
| "gdo...@gmail.com" <gdotone@gmail.com>: Dec 27 01:22AM -0800 compiling a simple program, including <iostream> using: g++ -c -Werror -Weverything exercise_2_17.cpp -Weverything is producing this: g++ -c -Werror -Weverything exercise_2_17.cpp error: include location '/usr/local/include' is unsafe for cross-compilation [-Werror,-Wpoison-system-directories] 1 error generated. if I don't use -Weverything source compiles fine, no errors or warning messages. what does that mean? using an intel based Mac, clang++ gives the same message. Apple clang version 14.0.0 (clang-1400.0.29.202) Target: x86_64-apple-darwin22.1.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin apparently g++ uses the clang++ compiler. g++ -v Apple clang version 14.0.0 (clang-1400.0.29.202) Target: x86_64-apple-darwin22.1.0 Thread model: posix InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin adding -Wsystem-headers gives so many warnings the it stops at its default limit. |
| "Öö Tiib" <ootiib@hot.ee>: Dec 27 02:50AM -0800 > 1 error generated. > if I don't use -Weverything source compiles fine, no errors or warning messages. > what does that mean? The -Weverything of clang produces all kinds of silly warnings some of what you might want to disable. If you want to disable only that warning then use -Wno-poison-system-directories > Thread model: posix > InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin > adding -Wsystem-headers gives so many warnings the it stops at its default limit. Yes, there are no gcc installed on Apple by default. You need to install it yourself if you want real gcc and of course there are artificial difficulties made by Apple to that. But without challenges ... life is boring. ;-) |
| 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