- Strong typedefs. - 2 Updates
- Mutex with Spin-Count - 9 Updates
- Users needed - 3 Updates
- "C++20: The Advantages of Modules" by Rainer Grimm - 1 Update
- Recursive spinlock - 1 Update
- neoGFX animation is as simple as... - 1 Update
- Rust has the same memory problem as C and C++ - 1 Update
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 18 07:13PM +0100 Hi! When is C++ getting strong typedefs? I want strong typedefs! /Flibble -- "Snakes didn't evolve, instead talking snakes with legs changed into snakes." - Rick C. Hodgin "You won't burn in hell. But be nice anyway." – Ricky Gervais "I see Atheists are fighting and killing each other again, over who doesn't believe in any God the most. Oh, no..wait.. that never happens." – Ricky Gervais "Suppose it's all true, and you walk up to the pearly gates, and are confronted by God," Byrne asked on his show The Meaning of Life. "What will Stephen Fry say to him, her, or it?" "I'd say, bone cancer in children? What's that about?" Fry replied. "How dare you? How dare you create a world to which there is such misery that is not our fault. It's not right, it's utterly, utterly evil." "Why should I respect a capricious, mean-minded, stupid God who creates a world that is so full of injustice and pain. That's what I would say." |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 19 12:32AM +0200 On 18.05.2020 20:13, Mr Flibble wrote: > When is C++ getting strong typedefs? I want strong typedefs! AOL. It will probably be never, because it's something that practitioners actually want and that could be of practical utility. However, if someone can come with some ivory tower reason for it, e.g. grounded in type theory, and expressed in math notation, then, possibly. Meanwhile the Boost Operators sub-library can help generate operators from a few basic ones, to reduce the amount of boilerplate. <url: https://www.boost.org/doc/libs/1_41_0/libs/utility/operators.htm#integer_arithmetic1> - Alf |
| Bonita Montero <Bonita.Montero@gmail.com>: May 13 04:02PM +0200 >> expermental to allow to prove Öö Tiibs assumptions. And for this >> puprose it is completely adequate. > If it doesn't need to be correct it can be arbitrarily simple and fast. It wouldn't be slower if it would be correct. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 13 08:27AM +0200 > Porting your code over to Relacy makes these corrections necessary to > pass a test. It wasn't my idea to add Relacy-code here. The code is trivial and you can see withoud debugging that it is correct for the discussed purpose. that you use this tool here makes me strongly doubt you. > You failed to close the handle to the semaphore, and failed > to handle EINTR. ... I didn't think about EINTR but that doesn't matter in this case. And the other was intenionally. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 11:21PM -0700 On 5/12/2020 11:17 PM, Bonita Montero wrote: >> So anyone who disagrees with you is stupid. Bye bye... *PLONK* > His objections simply have nothing to do with the question discussed, > i.e. whether adaptive mutexes make sense. Porting your code over to Relacy makes these corrections necessary to pass a test. You failed to close the handle to the semaphore, and failed to handle EINTR. Well, shi% happens. |
| red floyd <no.spam.here@its.invalid>: May 17 07:59PM -0700 On 5/17/2020 9:17 AM, Bonita Montero wrote: >> mode *cough*ncurses*cough* > I know when EINTR-handling is appropriate and when not. > You don't. I'm so glad you know that my 38 years of Unix programming experience haven't taught me anything... Screw you. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 18 06:42AM +0200 >> You don't. > I'm so glad you know that my 38 years of Unix programming > experience haven't taught me anything... According what you said there wasn't any real experience. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 18 10:51AM +0200 >>> https://www.kernel.org/doc/Documentation/powerpc/transactional_memory.txt >> 1. That's not about STM but HTM of POWER8/9. > Iirc, several STM's had to handle SIGSEGV's. Yes, it was years I go when I wrote a lockfree structure which was safeguarded via SEH / EXCEPTION_ACCESS_VIOLATION. I think it was you who said that this wasn't portable. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 18 01:40PM -0700 On 5/18/2020 1:51 AM, Bonita Montero wrote: > Yes, it was years I go when I wrote a lockfree structure which > was safeguarded via SEH / EXCEPTION_ACCESS_VIOLATION. I think > it was you who said that this wasn't portable. SEH is a Windows thing, and it works well for these types of scenarios. It can be portable via SIGSEGV. Fwiw, iirc, the Windows lock-free stack uses it in a very clever way for its lock-free stack: https://docs.microsoft.com/en-us/windows/win32/sync/using-singly-linked-lists Iirc, it uses it for the function that removes an item from the list. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 18 01:44PM -0700 On 5/18/2020 1:40 PM, Chris M. Thomasson wrote: > uses it in a very clever way for its lock-free stack: > https://docs.microsoft.com/en-us/windows/win32/sync/using-singly-linked-lists > Iirc, it uses it for the function that removes an item from the list. This is a classic problem with a lock-free stack. Iirc, the IBM freepool documentation says that the memory used for the nodes should not be deallocated. You can get around it using RCU. However, SEH works pretty good. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 18 01:45PM -0700 On 5/18/2020 1:40 PM, Chris M. Thomasson wrote: > uses it in a very clever way for its lock-free stack: > https://docs.microsoft.com/en-us/windows/win32/sync/using-singly-linked-lists > Iirc, it uses it for the function that removes an item from the list. Sorry for all of the posts, but, iirc, the Windows slist's even had special support from the kernel. |
| woodbrian77@gmail.com: May 17 06:54PM -0700 On Wednesday, May 13, 2020 at 12:45:36 PM UTC-5, Real Troll wrote: > github for straight static site as they provide free hosting service. > Alternatively, you can use Google Drive to upload your webpages and use > Fast.IO to render your pages. these are all free and very reliable. Fast.io has a free option. I couldn't tell if their free option has support for email. At any rate, I went with Dreamhost on a monthly basis. Now I'm planning to add a form to my site to help with setting up accounts. What, preferably C++, libs do you suggest I consider? Thanks in advance. Brian Ebenezer Enterprises - In G-d we trust. https://webEbenezer.net |
| Real Troll <real.troll@trolls.com>: May 13 07:50AM -1000 > More info here: http://webEbenezer.net/about.html > . First get rid of Comcast as your webhost as they are not recognised as suitable webhost. Your links rarely work for me and so I decided to dig into this problem further and surprised that you are using Comcast as a webhost for your business. Mind boggles. <https://i.imgur.com/FFNtP9W.png> Use something like Google-Firebase or Microsoft Azure or Netlify or github for straight static site as they provide free hosting service. Alternatively, you can use Google Drive to upload your webpages and use Fast.IO to render your pages. these are all free and very reliable. |
| Real Troll <real.troll@trolls.com>: May 18 12:20AM -0400 > Now I'm planning to add a form to my site to help > with setting up accounts. What, preferably C++, > libs do you suggest I consider? Thanks in advance. C++ is not the solution to "add a form" on a website. You need to use HTML and PHP for that. Your webhost might have tutorials for that or you could use off the shelf CMS packages such as WordPress or Joomla or Drupal which as extensions for that sort of things. Just take one thing at a time. Setup a website first then worry about other things. |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: May 13 03:32PM +0200 On 13.05.2020 04:04, Melzzzzz wrote: >> ugly workarounds." > How they think to implement modules? In this article nothing to be > seen... Visual C++ has for several versions had experimental support for modules. So you can try it out. I haven't tried it though. - Alf |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 12 01:09PM -0700 On 5/12/2020 12:58 AM, Bonita Montero wrote: >> using a race detector, it will find your bugs. Try Relacy..." > Races are absolutely legal in this situation and, if your theory > is right, should be prevented by an appropriate spin-count. Huh? What does the spin-count have to do with a nasty race condition? You do not seem to know what you are talking about. Think of a race condition where the wrong memory barrier was used. > And don't believe what Chris says; he is an underskilled developer > with a lot of ideas which are not thought to the end. lol. |
| Bart <bc@freeuk.com>: May 13 11:47AM +0100 On 13/05/2020 06:27, Christian Gollwitzer wrote: > IOW, to you it may seem simple, to me it is just gibberish. And the > nesting of different braces <({ sprinkled with names reminds me of LISP > code. Isn't this just normal C++ code? Just reams of auto, {}, <>, :: and liberal sprinkling of 'const'. Graphics programming like this really needs a clean scripting language. |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: May 14 08:11AM -0700 > too vague to say anything definite. You said that some code which > is both valid C and valid C++ should be "automatically" compiled > as C. [...] No, I didn't. What I did say is this: What I would like to see is for C++ to define how extern "C" blocks work so that inside extern "C" { ... } what is accepted is C syntax, and for that part of the source uses C semantics. That statement is specific both about what needs to happen and in which situations it does happen. > become 4? Or must the full expression be a valid C expression? The > whole function? The whole extern "C" block? All extern "C" blocks in a > compilation unit? All of those questions are easily answered after referring to my stated description quoted above. (The example seems rather silly, since there is never any reason to need sizeof('A'). But in any case you should have no problem determining the answers. Right?) > code limited to some fixed C version, meaning that I cannot use > compiler extensions even if I explicitly switch them on on command > line? The C++ standard includes one or more normative references to the C standard, including commonality with (parts of?) the C library. So there is some notion that a C++ implementation has a tie to a specific C implementation. As for extensions, a C++ compiler is not required to implement any C extensions for extern "C" {...} blocks; it could if that were desired, but it's not required, and there isn't much incentive to do so. When people are writing interfaces, normally they limit what is in them to be standard C (or C++, depending), and don't use any extensions. The reason is obvious: because we want the code to be acceptable to other compilers that we might not know about, any code in the header should be as standard as possible. > function has been declared extern "C" or not? Does the meaning of code > inside the extern "C" block silently change when I change the > declaration of that other function to extern "C"? Code inside extern "C" { ... } is treated as C code, not C++ code. Note that the braces are an essential ingredient of this rule. Functions defined like so - extern "C" <type> f( <...> ){ <...> } - are C++ code (so the body is regular C++), but with C linkage. That rule also holds for functions that are /declared/ with C linkage but later /defined/ without any explicit extern "C" at the point of definition; it doesn't matter whether the declaration is written with (or without) braces for the extern "C". It seems reasonable to allow code in extern "C" { ... } blocks to call any functions previously declared with C linkage. This is part of a larger question about what symbols declared outside the immediate extern "C" { ... } should be visible within it. Obviously that needs to be nailed down but shouldn't present any substantial problems; at first guess, any symbol previously declared or defined in a way that has the same meaning in C as in C++ should be usable in an extern "C" { ... } block. > recognized as valid C even though it isn't, or vice versa? Does the > meaning of code silently change in the next compiler version where the > bug is fixed? Oh, come on. Compiler bugs are compiler bugs. > These are just first issues coming to mind, and I did not even reach > function overloading yet. Do you think that's a problem? Seriously, if there is some sort of interaction I haven't considered yet I would like to know about it. I don't see any problem with function overloading. > instruction how to name a symbol passed to the linker, the only > difference is that in one case the symbol is defined and in the other > case it is used. [...] At some level what I am saying is that the linker/linkage view doesn't serve this major use case very well. My proposal is an effort to address this shortcoming. |
| 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