- Read again, i correct a typo - 1 Update
- About my library and Linux - 1 Update
- Let's call the <=> operator "trike" because of the math term - 2 Updates
- Lockfree bounded LIFO stack and FIFO queue is here.. - 2 Updates
- Std::any vs std::optional - 3 Updates
- Is it possible to reimplement new and delete? - 1 Update
| Sky89 <Sky89@sky68.com>: May 12 09:48PM -0400 Hello... Read again, i correct a typo About my library and Linux: As you have noticed i have provided you with a Lockfree bounded LIFO stack and a Lockfree bounded FIFO queue , they are very fast.. But as you have noticed the Lockfree FIFO queue works with both Windows and Linux, but the Lockfree stack works with only windows, but i am right now coming with a Lockfree unbound LIFO stack that works on Linux too. They can be ported easily to other operating systems. So stay tuned ! And you can port those Lockfree algorithms to C++ Thank youm Amine Moulay Ramdane. |
| Sky89 <Sky89@sky68.com>: May 12 09:46PM -0400 Hello, About my library and Linux: As you have noticed i have provided you with a Lockfree bounded LIFO stack and a Lockfree bounded FIFO queue , they are very fast.. But as you have noticed the Lockfree FIFO queue works with both Windows and Linux, but the Lockfree stack works with only windows, but i am right now coming with a Lockfree unbound LIFO stack that works on Linux too. They can be ported weasily to other operating systems. So stay tuned ! And you can port those Lockfree algorithms to C++ Thank youm Amine Moulay Ramdane. |
| Jorgen Grahn <grahn+nntp@snipabacken.se>: May 12 02:59PM >> higher-level concurrency stuff in C++11.) > There's no shortage of stuff for std::junkpile. Some of it > gets used for awhile, but then is discarded. For the record, I don't agree with the junkpile metaphor. C++98 was a success from my point of view, and we don't know yet about C++11 and later. But neither am I going to jump on anything new that gets standardized as part of C++, when I already have a mechanism that I know, and that's already standardized on the platforms I care about. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o . |
| jameskuyper@alumni.caltech.edu: May 12 01:51PM -0700 > On Wed, 09 May 2018 14:49:43 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >On 09/05/18 13:46, boltar@cylonHQ.com wrote: ... > >Neither Win32 nor POSIX are language standard libraries. > Define standard. win32 is the standard windows C API and posix the standard > unix C API. ... The key issue isn't the meaning of "standard", but the meaning of "language". In context, I would assume that "language standard libraries" refers to libraries whose existence is mandated by a language standard, such as the C and C++ standards, both of which mandate the existence of libraries. With that interpretation, neither the Win32 nor the POSIX APIs qualify. I'm curious - what role did you understand the term "language" to play in that context, or did you simply ignore it? > ... Try writing anything useful in C/C++ on those OS's without them. I've tried it - it's not very difficult. I've spent most of the last 22 years writing C code that makes little or no use of POSIX-specific features (because it has no need to) or Win32 (because it wasn't being developed on Windows systems), and much of the last 6 years doing the same with C++ code. Usefulness is always debatable, but my employers have paid me a fairly decent salary for producing such code, which mplies that they, at least, found it useful. |
| Sky89 <Sky89@sky68.com>: May 12 07:38PM -0400 Hello, Lockfree bounded LIFO stack and FIFO queue is here, you can port the algorithms to C++.. Description: A fast Lockfree FIFO queue and a fast Lockfree LIFO Stack, they are bounded, the Lockfree FIFO queue was correct and enhanced by Amine Moulay Ramdane. 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. The size of the queue must be passed to the constructor and it must be the power of 2. You can download them from: https://sites.google.com/site/aminer68/lockfree-bounded-stack-and-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. |
| Sky89 <Sky89@sky68.com>: May 12 07:48PM -0400 On 5/12/2018 7:38 PM, Sky89 wrote: > A fast Lockfree FIFO queue and a fast Lockfree LIFO Stack, they are > bounded, the Lockfree FIFO queue was correct and enhanced by Amine > Moulay Ramdane. I correct a typo: I mean: the Lockfree FIFO queue was corrected and enhanced by Amine Moulay Ramdane. |
| woodbrian77@gmail.com: May 11 06:21PM -0700 On Friday, May 11, 2018 at 5:47:35 PM UTC-5, Mr Flibble wrote: > So what? Alexandrescu has become less relevant as a C++ "authority" in > recent times. He still has a lot of credibility. > std::optional is great IMO My opinion of it is between yours and Andrei's. > and certainly has more utility > than std::any which I hardly ever use. Yeah. Brian Ebenezer Enterprises https://github.com/Ebenezer-group/onwards |
| Melzzzzz <Melzzzzz@zzzzz.com>: May 12 01:44AM > recent times. std::optional is great IMO and certainly has more utility > than std::any which I hardly ever use. Sometimes you want type erasure > but most of the time you don't. std::any is variant, and std::optional would better be replaced by future addition of tagged unions as in Rust eg ADT's in functional languages. They started with decomposition of tuples, next are tagged unions ;) -- press any key to continue or any other to quit... |
| Sam <sam@email-scan.com>: May 12 11:33AM -0400 > opinion of std::any than std::optional. If you were > banished to an island with just a few active volcanoes, > and could only have one of these, which one would it be? Based on my recent experience, I'd pick std::optional. I'm using it fairly often, but I've yet to find much use for std::any. |
| wyniijj@gmail.com: May 12 08:16AM -0700 Paavo Helde於 2018年5月11日星期五 UTC+8下午11時42分32秒寫道： > The cloning issue should become nicely resolved by the metaclasses > proposal, but I'm told this is still far away. > Anyway, I don't see how malloc would help in any way with cloning. Good to know this information, many thanks. So far, I had only *one* case using the clone function, and the need of that usecase was not strong enough, neither. I might be also thinking something else about using malloc for operator new, but not in a hurry. Probably just preparing to face the future C++. |
| 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