- Custom allocator not working with gcc - 9 Updates
- Recursive spinlock - 10 Updates
- Rust has the same memory problem as C and C++ - 1 Update
- C passes Java and becomes number 1 programming language - 3 Updates
- So Alf P. Steinbach's shitty little "C++ Enthusiasts" Facebook group... - 2 Updates
| boltar@nowhere.co.uk: May 11 08:45AM On 10 May 2020 09:41:07 GMT >Still, it's not pedagogical to include unnecessary Unixisms with >questions to comp.lang.c++ because everyone will comment on it and it >will draw attention away from the actual question. Only pedants desperate to score points would comment on something so trivial instead of the issue at hand. > Re: the actual question, I have no clue. Sorry. I've never used > custom allocators; they seem painful and useful only in rare > circumstances. Clang makes them easy , it turns out using them with gcc is a PITA. Oh well. |
| boltar@nowhere.co.uk: May 11 08:45AM On Sun, 10 May 2020 02:45:27 -0700 >>>Be less rude. >> I'll pose that question again. >Bye. I didn't think you'd be able to answer. |
| boltar@nowhere.co.uk: May 11 08:46AM On Sun, 10 May 2020 12:28:16 +0200 >> Plenty of old systems in companies have old compilers. A company I worked for >> until 2019 was still on C++ 2003. Calls to upgrade fell on deaf ears. >Are you writing code for them? If not, why do you care? C++11 is a I care for the same reason I keep my C skills up to date - you never know what a future job may require and I hedge my bets. I'm not going to turn down work simply because they use an old version of C++. >> Each to their own. unsigned long is long winded, u_long is short and to the >> point and standard on unix. >It is not "standard" - common on *nix, but not standard (neither POSIX De facto standard then. |
| boltar@nowhere.co.uk: May 11 08:47AM On Sun, 10 May 2020 12:51:54 +0200 >> that operating system and its tools are. >You mean unlike other systems where long and long long are the exact >same size? Long should always be the size of a CPU word. Long long is implementation dependent. In a sane world anyway. |
| boltar@nowhere.co.uk: May 11 08:48AM On Sun, 10 May 2020 14:09:35 -0000 (UTC) >> clearer? >*What* is the point? I don't get it. >What's with this obsession that beginners have with shorter code? Do try and improve your patronisation techniques. I think the dinosaurs were using that one. >Either way, if you want people *here* to help you, you should post >code that actually compiles. Using non-standard code is a way to >make sure that it won't compile and people will be less helpful. As I've said, it compiled on 4 different systems. If thats not enough then too bad. |
| Ian Collins <ian-news@hotmail.com>: May 11 08:57PM +1200 >> custom allocators; they seem painful and useful only in rare >> circumstances. > Clang makes them easy , it turns out using them with gcc is a PITA. Oh well. There's no difference in this case between the two compilers (or any other assuming the code meets the standard's requirements). -- Ian. |
| boltar@nowhere.co.uk: May 11 09:45AM On Mon, 11 May 2020 20:57:08 +1200 >> Clang makes them easy , it turns out using them with gcc is a PITA. Oh well. >There's no difference in this case between the two compilers (or any >other assuming the code meets the standard's requirements). Apart from the code works in Clang but not gcc. And if I don't inherit from allocator it doesn't even compile in gcc never mind work. So no, no difference at all. |
| Ian Collins <ian-news@hotmail.com>: May 11 09:56PM +1200 > Apart from the code works in Clang but not gcc. And if I don't inherit from > allocator it doesn't even compile in gcc never mind work. So no, no difference > at all. Because it meets the standard's requirements, your code with the three changes I posted compiles and runs correctly with both clang and gcc. Your original code fails on both. -- Ian. |
| Bo Persson <bo@bo-persson.se>: May 11 11:59AM +0200 >> same size? > Long should always be the size of a CPU word. Long long is implementation > dependent. In a sane world anyway. But the world isn't sane. The type was named long because it was 32 bits already when an int was only 16. And then we got long long for even larger values. Then making long the same as long long isn't immediately obvious. What's the advantage of changing it to be the same as something else we already introduced? |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 10 10:48PM -0700 On 5/10/2020 1:36 PM, Chris M. Thomasson wrote: > kind of like them: > https://docs.microsoft.com/en-us/windows/win32/api/synchapi/nf-synchapi-waitonaddress > I have used futexs, but never WaitOnAddress. Trying to avoid the kernel is usually a good thing. A simple example is using an atomic to try to avoid calling into a "presumably slow" OS function. We can break things down into fast-paths, and slow-paths. For this simple example, a slow-path would be a system call, like a futex or something. A fast-path avoids expensive sys calls by using atomic operations. Heck Bonita, would you use a raw semaphore on Windows: https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-createsemaphorea I think not? ;^) Or build a faster one on top of it, processes aside for a moment? Basically, a version that only calls into the slow-paths when it, ideally, _really_ needs to. So, imvho, trying to "efficiently" maximize the fast-paths in sync algorithms can be beneficial, indeed. For some reason, it kind of sounds like you are arguing against trying to avoid the slow-path? An adaptive mutex can be beneficial. Fwiw, a long time ago, 20 years'ish, remember counting how many spins it took for a mutex to hit a fast-path vs- slow.path. Every slow path meant that the lock spinned in failure up to its current threshold. I would experiment with dynamically adjusting said threshold during run time. Fun graphs and data dumped out... Then there is another way to create an adaptive scheme, one of my old experiments. Iirc, might of posted about it in comp.programming.threads. Good ol try_lock can be nice, assuming try lock is not always a slow-path. For now, assume try lock uses an atomic. Failing to acquire the lock means the slow paths are rising! Iirc, this was the first basic crude scheme of the experiment: while (! try_lock()) { // okay, the lock is busy... // try to perform some other work? // Humm... Other work, can be something // unrelated to the reason why we are locking. // humm... if (! try_perform_other_work_under_contention()) { // we found that we cannot perform // other work right now... // spin on try_lock one more time? // not yet, lets test this as-is. // SLOW-PATH!!!!! ALERT! lock(); // a potentially blocking lock break; } } ///// // we are locked! //// unlock(); Instead of spinning doing nothing, a thread tries to perform other work on each spin, before it finally hits a slow path and blocks. Iirc, depending on the nature of the "work", this scheme can be made to work... ;^) A failed try_lock can be a possible opportunity to check for and even execute other work... If it fails, we actually block on the lock. The basic concept: is why spin, when other work might be able to be accomplished? |
| Bonita Montero <Bonita.Montero@gmail.com>: May 11 07:54AM +0200 > You said something like that if lock is needed very frequently for ^^^^^^^^^^^^^^^^^^^^^^^ ... > very short time then there is very low likelihood of collision. Try to really understand it. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 11 07:56AM +0200 > An adaptive mutex is a good idea. Any kernel calls that can be avoided > is great! Btw, you should tell the Linux guys that they made a big > mistake. ;^) Yes, they made a mistake. Try to argue against that: if a lock is held a so small time that spinning might succeed there's such a low likehood of a collision that spinning isn't necessary. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 10 11:48PM -0700 On 5/10/2020 10:56 PM, Bonita Montero wrote: > Try to argue against that: if a lock is held a so small time that > spinning might succeed there's such a low likehood of a collision > that spinning isn't necessary. Its almost as if you do not understand why they were created in the first place? To avoid the slow-path! |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 10 11:54PM -0700 On 5/10/2020 10:56 PM, Bonita Montero wrote: > Try to argue against that: if a lock is held a so small time that > spinning might succeed there's such a low likehood of a collision > that spinning isn't necessary. There are situations where a lock can get "hot", not matter what happens when the lock is held. Its held for a small amount of time, yet can experience periods of load. Trying to avoid slow-paths is a good thing. |
| "Öö Tiib" <ootiib@hot.ee>: May 10 11:57PM -0700 On Monday, 11 May 2020 08:54:42 UTC+3, Bonita Montero wrote: > ^^^^^^^^^^^^^^^^^^^^^^^ ... > > very short time then there is very low likelihood of collision. > Try to really understand it. Try to think yourself instead of shooting nonsense from hip. Adaptive lock is for very short but aggressively contended sections and plain futex can't outperform it there. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 11 12:00AM -0700 On 5/10/2020 10:54 PM, Bonita Montero wrote: >> You said something like that if lock is needed very frequently for > ^^^^^^^^^^^^^^^^^^^^^^^ ... >> very short time then there is very low likelihood of collision. Why do you assume that? Please keep in mind that the complexity of the work performed under the protection of the lock is completely different that how this lock is going to be actually used in a system. Okay, lets say the critical section is short and sweet, however, the usage of the lock can experience periods of load, this means contention, and slow paths are in store... Well, trying to avoid the slow paths is a good thing. We are talking about general purpose locks, and one cannot necessarily predict the usage patterns. Having the ability to use an adaptive lock can be beneficial. [...] |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 11 12:01AM -0700 On 5/10/2020 11:57 PM, Öö Tiib wrote: > Try to think yourself instead of shooting nonsense from hip. > Adaptive lock is for very short but aggressively contended sections > and plain futex can't outperform it there. You beat me to this! :^) The usage of the lock, and the actual work performed under its protected region, are different things. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 11 10:24AM +0200 >> that spinning isn't necessary. > Its almost as if you do not understand why they were created in the > first place? To avoid the slow-path! But as I said the slow path is very unlikely to happen if you're in the situation where locks are only held a very short time. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 11 10:29AM +0200 >> Try to really understand it. > Try to think yourself instead of shooting nonsense from hip. Write me a benchmark to prove your assumptions. |
| Paavo Helde <eesnimi@osa.pri.ee>: May 11 10:58AM +0300 09.05.2020 13:22 Tim Rentsch kirjutas: > Is this hyperbole, or overreaction? Surely potential problems > could be identified and worked out within a normal 3-year C++ > revision cycle. And C evolves more slowly than C++. Yes, a hyperbole, but I'm not sure how large. Your proposal was 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. That's vary vague, plus this kind of automation would be more akin to how Excel (mis)interpretes user input than to a serious programming language. For example, currently each sizeof(char) is 1 in extern "C" blocks in source code compiled as C++. Under your proposal some of those sizeof('A') would become 4 (on most platforms), given that some part of the code appears to be valid C. But how large has the "valid C" part of the code to be, in order to change the meaning of a sizeof('A') inside it? Will every sizeof('A') in all extern "C" blocks 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? What happens if some code is accepted as valid C by some compiler extension with one compiler. but not with another? Does sizeof('A') silently change value when compiled with another compiler, or with/without -std or some other compiler-specific switches? Or is such code limited to some fixed C version, meaning that I cannot use compiler extensions even if I explicitly switch them on on command line? What happens if code inside an extern "C" block calls a C++ function? Is it now C code or C++ code? Does it depend on whether the other 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"? What happens if there is a bug in compiler due to which some code is 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? These are just first issues coming to mind, and I did not even reach function overloading yet. > now comes up short. Surely you at least admit that a major use > case for 'extern "C"' is to wrap an interface header for some C > code so that the C library can be used by a C++ program, right? Sure, this is a major use case, but that's basically also just an 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. (I used the word "basically" because the compiler has also to worry about calling convention details, but this does not affect the meaning of source code and is even much less visible than the name of the linker symbol.) |
| Bonita Montero <Bonita.Montero@gmail.com>: May 11 07:57AM +0200 > C++ programmers don't need to look stuff up on the Internet! Especially they need to do it because C++ is a complex language. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 11 08:23AM +0200 > It would be interesting to reflect why C++ has gone down so much. ... I think that is has been formerly used in places where now Java and .NET are used. Many business-applications have been written in C++ because there wasn't any alternative in the past. Now it is only used where systems-programming and / or performance are required. |
| Siri Cruise <chine.bleu@yahoo.com>: May 11 12:33AM -0700 In article <r99br2$j6e$1@dont-email.me>, > https://jaxenter.com/c-programming-may-2020-171598.html > C increased by 2.82% to 17.07% > C++ going down 1,97% to 6,13% This due to the good lord. Lord Jim, the god of dubious acheivements. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. @ 'I desire mercy, not sacrifice.' /|\ The first law of discordiamism: The more energy This post / \ to make order is nore energy made into entropy. insults Islam. Mohammed |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 11 12:36AM +0100 ... bans me because I accidentally posted a Killers lyric to it rather then to my main feed by mistake but didn't remove it quick enough. Fucktards. Reddit is shit too. Fucktards. /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." |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: May 11 12:45AM +0100 On 11/05/2020 00:36, Mr Flibble wrote: > Reddit is shit too. > Fucktards. > /Flibble I will resist the C++ mafiosi as they try to protect their bedded in positions built on sand! :D Where's North from here? /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." |
| 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