- Read my following thoughts about Volatile and Freepascal and Delphi - 1 Update
- More about my new invention of a lock-free bounded LIFO stack algorithm.. - 2 Updates
- Lockfree bounded LIFO stack and FIFO queue were updated to version 1.03 - 2 Updates
- "Robust C++: P and V Considered Harmful" - 1 Update
- who's at fault, me or compiler? - 11 Updates
- Should this compile? - 6 Updates
- Observable end padding in arrays - 1 Update
- Lockfree bounded LIFO stack and FIFO queue version 1.01 - 1 Update
| aminer68@gmail.com: Jul 10 12:56PM -0700 Hello, I am posting here my following thoughts, cause they are also speaking about C++, so read them carefully: Read my following thoughts about Volatile and Freepascal and Delphi: https://community.idera.com/developer-tools/programming-languages/f/delphi-language/71190/more-about-c-and-object-pascal-languages Thank you, Amine Moulay Ramdane. |
| aminer68@gmail.com: Jul 10 11:44AM -0700 Hello, More about my new invention of a lock-free bounded LIFO stack algorithm.. I have just invented a lock-free bounded LIFO stack algorithm and i have just made it work correctly in only one day, so i think version 1.04 is stable now. I think that my new lock-free bounded LIFO stack algorithm is really useful because it is not complicated , so it is easy to reason about and it doesn't need ABA prevention and it doesn't need Hazard pointers and it doesn't have false sharing, please look at its source code inside LockfreeStackBounded.pas inside the zipfile, in my next posts i will give you all the explanation of my new algorithm. Lockfree bounded LIFO stack and FIFO queue were updated to version 1.04 You can read about them and download them from my website here: https://sites.google.com/site/scalable68/lockfree-bounded-lifo-stack-and-fifo-queue Thank you, Amine Moulay Ramdane. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Jul 10 08:53PM +0100 On Fri, 10 Jul 2020 11:44:13 -0700 (PDT) aminer68@gmail.com wrote: [more rubbish] This has nothing to do with C++. You have previously agreed to stop posting your off-topic nonsense here. Please try to control yourself and do so. |
| aminer68@gmail.com: Jul 10 09:54AM -0700 Hello, Lockfree bounded LIFO stack and FIFO queue were updated to version 1.03 I think they are working correctly now. You can read about them and download them from my website here: https://sites.google.com/site/scalable68/lockfree-bounded-lifo-stack-and-fifo-queue Thank you, Amine Moulay Ramdane. |
| aminer68@gmail.com: Jul 10 10:59AM -0700 > https://sites.google.com/site/scalable68/lockfree-bounded-lifo-stack-and-fifo-queue > Thank you, > Amine Moulay Ramdane. Hello, Lockfree bounded LIFO stack and FIFO queue were updated to version 1.04 I have just corrected a last thing, and i think they are working correctly now. You can read about them and download them from my website here: https://sites.google.com/site/scalable68/lockfree-bounded-lifo-stack-and-fifo-queue Thank you, Amine Moulay Ramdane. |
| Lynn McGuire <lynnmcguire5@gmail.com>: Jul 10 12:48PM -0500 "Robust C++: P and V Considered Harmful" https://www.codeproject.com/Articles/5246597/Robust-Cplusplus-P-and-V-Considered-Harmful "This article's title is a little cheeky. Two essential contributions by the late Edsger Dijkstra were Go To Statement Considered Harmful, whose thesis is now accepted virtually without question, and Over de sequentialiteit van procesbeschrijvingen, which introduced the semaphore operations P (wait) and V (signal) to protect critical regions." Interesting. And playing on Dijkstra was neat. Lynn |
| boltar@nowhere.co.uk: Jul 10 07:55AM On Thu, 9 Jul 2020 19:44:06 +0100 >It is obvious to all that you certainly don't know. Here is a clue to help you >in your quest: The C++ Abstract Machine and the final running executable ARE >NOT THE SAME THING. Good luck. Thanks for that heads up there Captain State The Obvious. Still no explanation then? Whenever you're ready. |
| boltar@nowhere.co.uk: Jul 10 07:59AM On Thu, 9 Jul 2020 19:14:06 +0000 (UTC) >goalposts and sidetracking. You realized that your original statement >about the necessity of storing information about the class structure >was incorrect, so now to try to safe face and avoid having to admit A number of people have already said that the class structure is stored as memory offsets. Why do you keep denying any sort of storage exists? Does your understanding of how computers work end at the language level? >having made an error, you invent a new goalpost and pretend that that No, its called an analogy. Which either you were too dumb to see or your English isn't good enough for you to understand. >I have seen this kind of behavior many, many times over the >past two and a half decades. This is nothing new. Neither is what your approach: Accuse someone of doing exactly what you're doing. This is getting tedious - just admit you don't understand how binaries are laid out and move on. You'll feel better afterwards. |
| "Öö Tiib" <ootiib@hot.ee>: Jul 10 03:18AM -0700 > >NOT THE SAME THING. Good luck. > Thanks for that heads up there Captain State The Obvious. Still no explanation > then? Whenever you're ready. There won't be explanations. If you can't figure it out yourself then don't be too sad, ignorance allows you to not recognize your lack of ability and so to feel good. But if you actually want still to see how stupid you are then cheat using https://godbolt.org/ or something. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 10 12:19PM +0100 > doing. > This is getting tedious - just admit you don't understand how binaries are > laid out and move on. You'll feel better afterwards. You haven't embarked on the quest I set you to learn how things actually work as it is obvious that you still don't have a fucking clue. /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." |
| already5chosen@yahoo.com: Jul 10 06:26AM -0700 Is typical for comp.lang.c++ discussions to quickly degenerate into pointless mudslinging contests or is just my bad luck? |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 10 03:02PM +0100 > Is typical for comp.lang.c++ discussions to quickly degenerate into pointless mudslinging contests or is just my bad luck? Typical, yes. /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." |
| boltar@nowhere.co.uk: Jul 10 03:05PM On Fri, 10 Jul 2020 03:18:56 -0700 (PDT) >explanation >> then? Whenever you're ready. >There won't be explanations. If you can't figure it out yourself What is it with you Baltics? Is it the cold that gets to your brains? >lack of ability and so to feel good. But if you actually want still >to see how stupid you are then cheat using https://godbolt.org/ or >something. Or I could just use the -S compiler option to see the assembler, but you stick to using web compilers if it makes you happy. |
| boltar@nowhere.co.uk: Jul 10 03:06PM On Fri, 10 Jul 2020 12:19:13 +0100 >> laid out and move on. You'll feel better afterwards. >You haven't embarked on the quest I set you to learn how things actually work >as it is obvious that you still don't have a fucking clue. I see pot and kettle are getting aquainted again. |
| David Brown <david.brown@hesbynett.no>: Jul 10 05:17PM +0200 > Is typical for comp.lang.c++ discussions to quickly degenerate into > pointless mudslinging contests or is just my bad luck? There are some people here for whom such threads are common. In particular, there are some combinations of people that give threads like this, even though they can sometimes have sensible discussions with other people. You got unlucky in some of the replies to your original post. |
| Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk>: Jul 10 04:30PM +0100 >> You haven't embarked on the quest I set you to learn how things actually work >> as it is obvious that you still don't have a fucking clue. > I see pot and kettle are getting aquainted again. Your patheticly naive and transparent attempt to get me to "prove" that I know what I am talking about as a way of disguising that you will learn how things work from such proof isn't going to work, mate. If you want people to teach you things then you will have to learn to stop being such a cockwomble. /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." |
| Juha Nieminen <nospam@thanks.invalid>: Jul 10 05:22PM > A number of people have already said that the class structure is stored > as memory offsets. Why do you keep denying any sort of storage exists? Does > your understanding of how computers work end at the language level? No, they haven't. I already explained how code may access members of an object using offsets, but not necessarily all the members are accessed and thus their offset are not stored anywhere. Besides, this is irrelevant to your original assertion, which was that *it's not possible to instantiate a class* if its layout is not stored in the binary. Instantiating a class is not dependent on whether some code accesses it using offsets. The instantiating process does not read those offsets. You are doing exactly what I wrote: Deflecting. Pretending that your original claim was something else. Your original claim was not "the layout of the class is stored in the binary". Your original claim was "the class cannot be instantiated if its layout isn't in the binary". This whole thing started with your obsession with how classes are instantiated, not how their members may be accessed. As I have said, I have seen people with your problem many many times over the past 25 years. Maybe over the next decade or two you will grow up and wisen up. |
| Daniel P <danielaparker@gmail.com>: Jul 09 08:34PM -0700 #include <string> #include <utility> #include <type_traits> #include <cstdint> template <class T, class Enable = void> class A { }; template<class CharT,class Traits,class Allocator> class A<std::basic_string<CharT,Traits,Allocator>> { public: template <class ChT = CharT> typename std::enable_if<sizeof(ChT) == sizeof(uint8_t)>::type f() const { } template <class ChT = CharT> typename std::enable_if<sizeof(ChT) != sizeof(uint8_t)>::type f() const { A<std::string> convert; convert.f(); // (*) } }; int main() { A<std::string> a; a.f(); // (**) } With vs2019, Version 16.6.0, C++17, I get Error C2039 'f': is not a member of 'A<std::basic_string<char,std::char_traits<char>,std::allocator<char>>,void>' at (*) and (**). It compiles with earlier versions of vs. Thanks, Daniel |
| Ian Collins <ian-news@hotmail.com>: Jul 10 04:28PM +1200 On 10/07/2020 15:34, Daniel P wrote: > Error C2039 'f': is not a member of 'A<std::basic_string<char,std::char_traits<char>,std::allocator<char>>,void>' > at (*) and (**). > It compiles with earlier versions of vs. I can't see anything obviously wrong. Both clang-11 and gcc-9 compile it without warnings with "-Wall -Wextra -pedantic -std=c++17" -- Ian |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Jul 10 08:48AM +0200 On 10.07.2020 05:34, Daniel P wrote: > class A > { > }; I don't see the `Enable` parameter being used for anything? > template <class ChT = CharT> > typename std::enable_if<sizeof(ChT) == sizeof(uint8_t)>::type > f() const Tip 1: using `sizeof(uint8_t)` does two things: checking that `uint8_t` exists, and producing the compile time value 1. I would separate those aspects. In this code `uint8_t` is not formally guaranteed to exist even on an 8-bit byte machine, because there is no `using std::uint8_t`. However, that's not the problem. Adding that declaration doesn't fix things. Tip 2: instead of mind-boggling gymnastics to embed to `enable_if` in the return type specification, just use a defaulted type parameter. It's allowed on functions since C++11. > a.f(); // (**) > } > With vs2019, Version 16.6.0, C++17, I get Huh, version 16.6.0? Oh, the Visual Studio version. OK. The compiler with that version of VS is version 14.26, with `_MSC_VER` = 1926, and with the command line compiler reporting version number 19.26.28806. The offset is due to the higher version number going all the way back to Lattice C, the compiler that Microsoft built on for their first Visual C (hence, compiler name "cl.exe", or so I believe), while the lower version number only goes back to the introduction of Visual C++. > Error C2039 'f': is not a member of 'A<std::basic_string<char,std::char_traits<char>,std::allocator<char>>,void>' > at (*) and (**). > It compiles with earlier versions of vs. It should compile. Wait a little, I'll check. ------------------------------------------------------------------------------------ [P:\temp] > g++64 --version | find "++" g++ (GCC) 9.2.0 [P:\temp] > g++64 foo.cpp [P:\temp] > cl /nologo- 2>&1 | find "++" Microsoft (R) C/C++ Optimizing Compiler Version 19.26.28806 for x64 [P:\temp] > echo %CL% /nologo /utf-8 /EHsc /GR /permissive- /FI"iso646.h" /std:c++17 /Zc:__cplusplus /W4 /wd4459 /D _CRT_SECURE_NO_WARNINGS /D _STL_SECURE_NO_WARNINGS [P:\temp] > cl foo.cpp /Feb foo.cpp foo.cpp(26): error C2039: 'f': is not a member of 'A<std::basic_string<char,std::char_traits<char>,std::allocator<char>>,void>' foo.cpp(25): note: see declaration of 'A<std::basic_string<char,std::char_traits<char>,std::allocator<char>>,void>' foo.cpp(26): note: This diagnostic occurred in the compiler generated function 'std::enable_if<sizeof(ChT)!=1,void>::type A<std::basic_string<_Elem,_Traits,_Alloc>,void>::f(void) const' foo.cpp(28): note: see reference to class template instantiation 'A<std::basic_string<_Elem,_Traits,_Alloc>,void>' being compiled foo.cpp(34): error C2039: 'f': is not a member of 'A<std::basic_string<char,std::char_traits<char>,std::allocator<char>>,void>' foo.cpp(25): note: see declaration of 'A<std::basic_string<char,std::char_traits<char>,std::allocator<char>>,void>' ------------------------------------------------------------------------------------ Hm! I'm not sure what you're trying to do, but I would try something else, with less templating. - Alf |
| Daniel P <danielaparker@gmail.com>: Jul 10 05:53AM -0700 On Friday, July 10, 2020 at 2:49:13 AM UTC-4, Alf P. Steinbach wrote: > Lattice C, the compiler that Microsoft built on for their first Visual C > (hence, compiler name "cl.exe", or so I believe), while the lower > version number only goes back to the introduction of Visual C++. Thanks for the elucidation :-) I've never understood Microsoft's versioning, or rather, as soon as I've figured it out, I've already forgotten it. > ------------------------------------------------------------------------------------ > Hm! > ... I would try something else with less templating. Thanks for verifying. For better or worse, the actual code has far more templating. After some experimenting, I discovered that if I change line (*) in > > A<std::string> convert; // (*) > > convert.f(); > > } to A<std::string> convert(); // (**) it does compile. On the other hand, A<std::string> convert{}; does not. I think I'll consider this a compiler bug with workaround. Daniel |
| Manfred <noname@add.invalid>: Jul 10 04:18PM +0200 On 7/10/2020 2:53 PM, Daniel P wrote: > does not. > I think I'll consider this a compiler bug with workaround. > Daniel A weird workaround: (**) is not an object declaration, it is a /function/ declaration. This is the main reason the {} form (uniform initialization) was introduced. (gcc 9.3 compiles fine the original and the {} form, not the () form) |
| Daniel P <danielaparker@gmail.com>: Jul 10 07:52AM -0700 On Friday, July 10, 2020 at 10:18:29 AM UTC-4, Manfred wrote: > /function/ declaration. This is the main reason the {} form (uniform > initialization) was introduced. > (gcc 9.3 compiles fine the original and the {} form, not the () form) Indeed, in retrospect, I'm a little surprised that that _did_ compile in the test case. In the real code, it did not. However, the "fix" below succeeds, and does so as well in the real code. I'm sure this is a vs2019 bug. Daniel #include <string> #include <utility> #include <type_traits> #include <cstdint> template <class T, class = void> class A { }; template<class CharT,class Traits,class Allocator> class A<std::basic_string<CharT,Traits,Allocator>> { int dummy_; public: A(int dummy = 0) : dummy_(dummy) { } template <class ChT = CharT> typename std::enable_if<sizeof(ChT) == sizeof(uint8_t)>::type f() const { } template <class ChT = CharT> typename std::enable_if<sizeof(ChT) != sizeof(uint8_t)>::type f() const { A<std::string> convert{dummy_}; convert.f(); // (*) } }; int main() { A<std::string> a; a.f(); // (**) } |
| Tim Rentsch <tr.17687@z991.linuxsc.com>: Jul 10 07:43AM -0700 > "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> writes: <snip> > point to an object or function), but it seems unambiguous as it is. > My only complaint might be that the wording assumes that the object > or function exists rather than saying what happens *if* it exists. To me it looks like the wording here (for C++) is carelessly chosen. The wording used (about unary *) in the C standard is decidedly better. > My guess is that the authors of the standard thought it was so obvious > that arrays can't have padding at the end that they didn't bother to > state it. In the case of C, there is a strong case that the definition simply doesn't admit anything, whether padding or anything else, other than the array elements themselves. If that is true then it doesn't matter whether it's obvious or not - the definition given precludes the possibility of padding without needing to say so explicitly. In the case of C++, if the intention was to rely on the C standard for the definition of array type then again there no need to appeal to obviousness. If however the intention in the C++ standard was to stand on its own (in particular, for this aspect - there are other cases where reliance on the C standard is stated explicitly), then the wording in the C++ standard comes up short, and merits being revised to make the description less ambiguous. The above remarks includes in some respects my opinions on meaning and writing quality, in case that needs saying. |
| aminer68@gmail.com: Jul 09 06:00PM -0700 Hello, Lockfree bounded LIFO stack and FIFO queue version 1.01 Author: Amine Moulay Ramdane is the inventor of the Lockfree LIFO stack and he has corrected and enhanced the Lockfree FIFO queue Description: A fast Lockfree FIFO queue and a fast lockfree LIFO Stacks, they are bounded, the Lockfree FIFO queue was corrected and enhanced by Amine Moulay Ramdane and it doesn't have false sharing, also Amine Moulay Ramdane has invented a lockfree LIFO stack that doesn't need ABA prevention and it doesn't need Hazard pointers and it is not complicated and it doesn't have false sharing, please look at its source code inside LockfreeStackBounded.pas. Wait-free and lock-free algorithms enjoy more advantages derived from their definitions: Thread-killing Immunity: Any thread forcefully killed in the system won't delay other threads. Signal Immunity: The C and C++Standards prohibit signals or asynchronous interrupts from calling many system routines such as malloc. If the interrupt calls malloc at the same time with an interrupted thread, that could cause deadlock. With lock-free routines, there's no such problem anymore: Threads can freely interleave execution. Priority Inversion Immunity: Priority inversion occurs when a low-priority thread holds a lock to a mutex needed by a high-priority thread. Such tricky conflicts must be resolved by the OS kernel. Wait-free and lock-free algorithms are immune to such problems. An unbounded queue can hold infinite number of messages, while bounded - up to some predefined limit. If the limit is reached further enqueue operations fail. Note that array-based queue are always bounded. On first sight unbounded queues are more attractive (because they allow you to not care). But they are not. They are dangerous. What will happen if your queue will grow up to 10^6 messages? 10^7? 10^8? 10^9? What? It should not happen? So why you put an unbounded queue in the first place? In 95% of cases you need a bounded queue, because it will enforce what you think should happen, and will save you from bad things, it is the same for Stacks. Read the following paper: https://arxiv.org/pdf/1311.3200.pdf This paper suggests a simple solution to this problem. We show that, for a large class of lock- free algorithms, under scheduling conditions which approximate those found in commercial hardware architectures, lock-free algorithms behave as if they are wait-free. In other words, programmers can keep on designing simple lock-free algorithms instead of complex wait-free ones, and in practice, they will get wait-free progress. It says on the Analysis of the Class SCU(q, s): "Given an algorithm in SCU(q, s) on k correct processes under a uniform stochastic scheduler, the system latency is O(q + s*sqrt(k), and the individual latency is O(k(q + s*sqrt(k))." So i think lockfree algorithms are very interesting to work with, and the lockfree algorithms inside my zipfile are of the SCU(q, s) Class of Algorithms, so they are powerful. The size of the queue and the stack must be passed to the constructor and it must be the power of 2. You can download them from my website here: https://sites.google.com/site/scalable68/lockfree-bounded-lifo-stack-and-fifo-queue Language: FPC Pascal v2.2.0+ / Delphi 7+: http://www.freepascal.org/ Operating Systems: Windows, Mac OSX , Linux on (x86)... Required FPC switches: -O3 -Sd -Sd for delphi mode.... Required Delphi switches: -$H+ {$DEFINE CPU32} and {$DEFINE Windows32} for 32 bit systems {$DEFINE CPU64} and {$DEFINE Windows64} for 64 bit systems Thank you, Amine Moulay Ramdane. |
| 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