- Is this undefined behavior? - 14 Updates
- DCAS-atomic - 4 Updates
- "C++20: The Unspoken Features" By Michele Caini - 6 Updates
| Ralf Goertz <me@myprovider.invalid>: Jun 19 09:19AM +0200 Am Thu, 18 Jun 2020 15:45:08 -0400 > periodically tried and failed to send those messages. It didn't > actually succeed until nearly a day after the problem first happened. > What I don't know is why sending of those messages failed. Speeking of this, might that also be the reason why the paragraph characters § you quoted from Chris' message ended up as �? That seemed odd given that the header of your message said "charset=utf-8". Or did only I see the wrong character? One message downthread that particular quote was restored correctly. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 19 07:31AM On Thu, 2020-06-18, Chris Vine wrote: ... > discussing with C++17. With C++, you have the worry that the committee > is going to saw your low-level code off at the knees again when the next > standard comes out. Why not just use C++14, then? Compiler writers seem to rarely remove support for older standards. The way C++ changes these days bothers me too, but I'm not going to go back to the Stone Age just to spite the ISO committee. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Juha Nieminen <nospam@thanks.invalid>: Jun 19 09:25AM > implementation is under no obligation to generate the same machine code > that you naively expect it to, so long as the code it actually generates > has the required observable behavior One of the defenses I have seen several times for the C language over other languages (including C++) is the claim that you know exactly what kind of machine code every C statement produces. I think this just goes to show how so many old-school C coders still seem to live in the early 90's. In the 80's and well into the 90's it might have indeed been so: Most C compilers were extremely straightforward, and did a very simplistic and rudimentary direct C-to-asm conversion (in the worst cases you could hardly even call it a C "compiler", more like a "C to asm transpiler"). Many compilers didn't do even the most rudimentary optimizations (like converting a division by 2 of an unsigned int into a right-shift.) However, rather obviously this hasn't been the case for like two decades now. C compilers (like gcc, clang, icc and even MSVC) do all kinds of optimizations that can make the result asm not resemble the original C source code at all. They will unroll loops, they will optimize things away, they will do as many calculations at compile time as possible, and especially nowadays they are becoming better and better at autovectorization (ie. creating SIMD opcodes that operate on more than one value at a time). What looked like a simple loop that does some arithmetic on some array may end up in asm as a series of SSE opcodes that operate on 8 or even 16 values at a time and have very little resemblance to the original C code. |
| Juha Nieminen <nospam@thanks.invalid>: Jun 19 09:32AM >>I don't agree. C is too simplistic for large complex projects (mainly > Linus Torvalds would disagree with you. I have read his famous anti-C++ rant. It makes absolutely no sense, is full of errors, and proves that he still thinks we live in 1992. It is *possible* to create enormous projects in C. However, the code pretty much invariably ends up being a lot more complicated and following needless coding conventions than it would have to be, for little to no benefit (eg. in terms of efficiency or features). |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 19 10:36AM On Fri, 2020-06-19, Juha Nieminen wrote: > In the 80's and well into the 90's it might have indeed been so: > Most C compilers were extremely straightforward, and did a very > simplistic and rudimentary direct C-to-asm conversion It was also more common IME that you saw your code as tied to one OS and one CPU -- e.g. the 68000 or x86. I didn't stop thinking that way until I began doing more Unix work. That world was more diverse, and came with weird RISC CPUs which you weren't supposed to know in detail. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| boltar@nowhere.co.uk: Jun 19 11:01AM On Fri, 19 Jun 2020 09:32:45 +0000 (UTC) >> Linus Torvalds would disagree with you. >I have read his famous anti-C++ rant. It makes absolutely no sense, >is full of errors, and proves that he still thinks we live in 1992. His rant was a long time ago when frankly C++ was an awful language. >pretty much invariably ends up being a lot more complicated and >following needless coding conventions than it would have to be, >for little to no benefit (eg. in terms of efficiency or features). The point you are apparently unaware of is that a lot of the nice features in modern C++ can't be used at the bare metal level because the flow of control and memory/stack allocation has to be absolutely explicit. For the same reason you won't find malloc() or free() in kernel code you wouldn't find any of the STL or shared pointers or virtual functions or frankly anything that makes C++ useful. |
| "Öö Tiib" <ootiib@hot.ee>: Jun 19 06:00AM -0700 > you won't find malloc() or free() in kernel code you wouldn't find any of the > STL or shared pointers or virtual functions or frankly anything that makes C++ > useful. Several things in every sentence wrong. Nothing needs to be absolutely explicit. The whole point of structured programming is to abstract away the uninteresting details that are always same every time. Even all assemblers have macros to get rid of how tediously repetitive absolutely explicit garbage is. std::pair, std::tuple, std::array, std::string_view, std::variant, std::initializer_list etc do not do any dynamic allocations if the elements don't. C++20 aims to add std::vector and std::string to those. Where there are no malloc nor free needed in C there also are no dynamic allocations in C++ are needed, so what is the difference? The std::shared_ptr is typical in newbie code anyway, someone from Java world attempting to write C++. In actual C++ I see it rarely. Virtual functions are about as common in embedded C++ as function pointers in embedded C. |
| Paavo Helde <eesnimi@osa.pri.ee>: Jun 19 04:35PM +0300 > you won't find malloc() or free() in kernel code you wouldn't find any of the > STL or shared pointers or virtual functions or frankly anything that makes C++ > useful. There is no rule that for OS programming everything must be explicit. One just has to know what happens when one writes a line of code. But this is not specific to kernel, it's just the consequences are nastier with OS code when you do write a line which you don't understand what it does. In kernel code you do not indeed call malloc. Instead of it there is kmalloc with lots of additional options. But in principle there is nothing which would prohibit one to use STL containers with memory allocators using kmalloc and having the same options. RAII classes might indeed not work well in situations like thread context switch. But such code constitutes only a little piece of kernel. In a similar fashion, in a normal user-space C++ program one has to be extremely careful what one writes in a signal handler or between fork() and exec() (hint: a malloc call or a std::string construction is a big no-no!). You will not decide to switch your multi-million line C++ program over to C just because occasionally you want to launch child processes via fork and exec. |
| boltar@nowhere.co.uk: Jun 19 02:52PM On Fri, 19 Jun 2020 06:00:13 -0700 (PDT) >Several things in every sentence wrong. >Nothing needs to be absolutely explicit. The whole point of >structured programming is to abstract away the uninteresting details You can't abstract away when writing kernel code, you need to know whats going on. >that are always same every time. Even all assemblers have macros >to get rid of how tediously repetitive absolutely explicit garbage is. Macro != container. >The std::shared_ptr is typical in newbie code anyway, someone from >Java world attempting to write C++. In actual C++ I see it rarely. You don't see much modern C++ then. |
| Manfred <noname@add.invalid>: Jun 19 05:21PM +0200 On 6/19/2020 9:31 AM, Jorgen Grahn wrote: > support for older standards. > The way C++ changes these days bothers me too, but I'm not going to go > back to the Stone Age just to spite the ISO committee. True, but still I find this a weak argument. If the committee broke some feature (in the sense that made it UB) in C++17, as of today you can still do with C++14, especially since the delta between C++14 and C++17 is limited, however hopefully new useful features will be added in the future, which you won't be able to use unless you drop malloc() for POD objects, for example. I may add that the use of malloc() might not seem a big deal, but it seems to me that the same issues apply more generally to manipulating raw memory, which is a big deal in systems programming. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 19 04:11PM On Fri, 2020-06-19, Manfred wrote: >> The way C++ changes these days bothers me too, but I'm not going to go >> back to the Stone Age just to spite the ISO committee. > True, but still I find this a weak argument. Well, it wasn't meant as an argument for the committee to break stuff. I just meant, let's not overreact by going back to the 1970s. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: Jun 19 04:44PM > On Fri, 19 Jun 2020 06:00:13 -0700 (PDT) <ootiib@hot.ee> wrote: ... >>The std::shared_ptr is typical in newbie code anyway, someone from >>Java world attempting to write C++. In actual C++ I see it rarely. > You don't see much modern C++ then. Stroustrup: "... does make the lifetime of the shared object hard to predict. Use shared_ptr only if you actually need shared ownership." That's after he warns against pointers of all kinds and complains that people use 'new' too much. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| "Öö Tiib" <ootiib@hot.ee>: Jun 19 02:08PM -0700 > >structured programming is to abstract away the uninteresting details > You can't abstract away when writing kernel code, you need to know whats > going on. When writing whatever code we need to know what is going on. Kernel is not different in any way. Abstracting away is not for to lose awareness about what is going on but for to lose pointless need to address every of well-known details explicitly. > >that are always same every time. Even all assemblers have macros > >to get rid of how tediously repetitive absolutely explicit garbage is. > Macro != container. Writing pointless truisms? Are you confused in dark and trying to understand what is what? Similarly template is not container and pointer is not function. I gave partial list of standard library containers that do not even involve dynamic allocations that you snipped. > >The std::shared_ptr is typical in newbie code anyway, someone from > >Java world attempting to write C++. In actual C++ I see it rarely. > You don't see much modern C++ then. Newbie C++ does not mean that it is modern but that it is clumsy, naive, defective and inefficient. Most C++ I see is relatively modern. Big parts of it won't compile on C++11 compiler as there are C++14 or even C++17 features used. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jun 20 12:02AM +0200 On 19.06.2020 11:25, Juha Nieminen wrote: > One of the defenses I have seen several times for the C language over > other languages (including C++) is the claim that you know exactly > what kind of machine code every C statement produces. No, not the exact kind of machine code, but knowing that no support machinery is added, such as * C++ dynamic initialization of global lifetime variables. * C++ exception support. * C++ hidden array size prefix increasing allocation size. There is one major case of not knowing the kind of machine code in C++, discussed a number of times in this group: * C++ permission to implement an iterative function as recursive. While I'm happy that there is a language that has the tree first C++ features (one can always use C for critical parts where those features are undesired), I'm very unhappy about the lunacy in the standard that formally permits this last point, that the /compiler/ is permitted to /introduce/ undefined behavior. From a pedantically theoretical perspective that means that /every/ C++ program has UB, and thus, that the compiler can do whatever the hark it wants and still be formally correct. Of course, that possibility is also there by just silently omitting to blink the NumLock indicator, as a diagnostic about language extension, after which again the compiler can do pretty much whatever it wants and still be formally correct. But. > I think this just goes to show how so many old-school C coders still > seem to live in the early 90's. I don't think /any/ C coders believe they know the exact kind of machine code, except that possibly the C standard requires source code loops to be machine code loops. Essentially a requirement that O(1) resource usage in the source code is not translated to O(n) resource usage in the machine code. I don't know if C does, indeed I suspect it's as lunatic as C++ here, but it would be really nice if one could rely on C. Original Jensen & Wirth Pascal was designed to support manual compilation by students, it was a design goal. But then, J&W Pascal didn't even have dynamic length arrays. [snip] - Alf |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 19 07:21AM +0200 > atomic_thread_fence in the right places. Remember, the acquire membar > goes _after_ the atomic RMW for acquire semantics. The release membar > goes _before_ the atomic RMW for release semantics. That's not necessary with my code. |
| Bonita Montero <Bonita.Montero@gmail.com>: Jun 19 07:22AM +0200 > That's fine, but its not ideal. Its like creating an algorithm where > everything is seq_cst. Yes it works, but its not ideal wrt performance. You're talking stupid stuff. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 19 02:52PM -0700 On 6/18/2020 10:21 PM, Bonita Montero wrote: >> membar goes _after_ the atomic RMW for acquire semantics. The release >> membar goes _before_ the atomic RMW for release semantics. > That's not necessary with my code. Well, its still nice to learn. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Jun 19 02:55PM -0700 On 6/18/2020 10:22 PM, Bonita Montero wrote: >> That's fine, but its not ideal. Its like creating an algorithm where >> everything is seq_cst. Yes it works, but its not ideal wrt performance. > You're talking stupid stuff. Wrong! For instance, if RCU was forced to execute a full memory barrier for every operation, it would basically be useless. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Jun 18 09:02PM -0500 "C++20: The Unspoken Features" By Michele Caini https://humanreadablemag.com/issues/3/articles/cpp20-the-unspoken-features "C++20 is coming. As of this writing, the new revision of the language isn't a thing yet, but by the time you are reading this, it may be published." "The C++ community is really excited about C++20. It looks like a groundbreaking update similar to C++11. Some major features are finding their way in the standard: modules, coroutines, concepts, and ranges. These are the big four, and almost everybody is giving a talk or a presentation on these topics." "But let's be honest, modules will take a while before they are widely adopted, coroutines aren't something you use daily, and concepts are mainly dedicated to those who write libraries rather than end-users; it's unlikely they'll be used extensively in a medium-sized application." "Of the big four, ranges seem to be the one candidate that most people will be using daily; but C++20 is not just that. This revision of the standard also contains many small changes that will help us as developers." "We'll be taking a look at some of these unspoken features in this article." Lynn |
| "Öö Tiib" <ootiib@hot.ee>: Jun 19 01:28AM -0700 On Friday, 19 June 2020 05:02:31 UTC+3, Lynn McGuire wrote: > will be using daily; but C++20 is not just that. This revision of the > standard also contains many small changes that will help us as developers." > "We'll be taking a look at some of these unspoken features in this article." Thanks for sharing what people think. Basically spaceship and designated initialisers are likely useful. I would also likely love constexpr vector and string. Since the constexpr is IMHO defective after C++17 the implementations have perhaps to add some non-standard magic (that I would possibly like to use). Also standard algorithms becoming constexpr means I can perhaps erase constexpr raw arrays and some hand-rolled algorithms that process those around 2022 or so. :D Rest seems all syntax sugar that I do not need (like variadic argument lambda templates) that can make the language even worse IMHO (like more ways to add obfuscation garbage into if, for and switch statements). |
| Juha Nieminen <nospam@thanks.invalid>: Jun 19 09:41AM > Basically spaceship and designated initialisers are likely useful. I just wish you could specify designated initializers in any order you wanted, just like in C. (There are very good reasons why I would want this.) I don't care if in C++ initializing members is more complicated, especially if the initialization has side-effects. They could just state something like "if the designated initializers are not listed in the same order as the member variables, the order in which they are evaluated is implementation-defined". I would be fully content with that. |
| Daniel P <danielaparker@gmail.com>: Jun 19 06:22AM -0700 On Friday, June 19, 2020 at 4:28:25 AM UTC-4, Öö Tiib wrote: > On Friday, 19 June 2020 05:02:31 UTC+3, Lynn McGuire wrote: > > "The C++ community is really excited about C++20. > Thanks for sharing what people think. I'm trying to picture a C++ programmer being "really excited" over a feature of the language. I've never seen that. Daniel |
| "Öö Tiib" <ootiib@hot.ee>: Jun 19 07:14AM -0700 On Friday, 19 June 2020 12:42:08 UTC+3, Juha Nieminen wrote: > in the same order as the member variables, the order in which they > are evaluated is implementation-defined". I would be fully content > with that. I think it is issue for programmer to solve that is new to C++. Basically ... optimal order for minimal padding can be different from optimal order for initialising the members ... and C syntax is not designed with that issue in mind. |
| Paavo Helde <eesnimi@osa.pri.ee>: Jun 19 09:09PM +0300 19.06.2020 16:22 Daniel P kirjutas: >> Thanks for sharing what people think. > I'm trying to picture a C++ programmer being "really excited" over a feature of > the language. I've never seen that. I feel "really excited" over the RAII feature, especially because many younger languages have (IMO foolishly) failed to adopt the idea. In addition to making the object lifetime self-contained it also makes object lifetime explicit in the source code so that any violations can be detected as compile errors. A new language feature which I would be excited over would be similar, but for multithreading. It would produce a compile-time error for a race condition (missing MT locking) or for invalid duplicate/recursive locking. Alexandrescu tried to develop something like that a long time ago, but this did not quite work out. As a bonus it could detect at compile time if there is a danger of a deadlock (yeah, this would be NP-hard I guess, so not much hope in this regard). |
| 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