- Blocking queue - 2 Updates
- About my scalable algorithms.. - 1 Update
- "The State of C++ on Windows" - 6 Updates
| mvorbrodt@gmail.com: Feb 03 06:19AM -0800 My multi-threaded blocking queue implementation: https://blog.vorbrodt.me/?p=409 |
| "Chris M. Thomasson" <invalid_chris_thomasson_invalid@invalid.com>: Feb 03 01:52PM -0800 > My multi-threaded blocking queue implementation: https://blog.vorbrodt.me/?p=409 Looks okay at first viewing. I should code it up in Relacy Race Detector. Not sure why you are using semaphores when a single mutex and condition variable will do. Your queue has a lot of overhead. Each semaphore has a mutex and condvar. You have two of them plus another mutex. That is: 3 mutexes and 2 condvars for a single queue? |
| Bonita Montero <Bonita.Montero@gmail.com>: Feb 03 06:39PM +0100 Can you manic-disordered idiot keep away from this group? |
| Cholo Lennon <chololennon@hotmail.com>: Feb 03 04:48AM -0300 On 1/28/19 4:44 PM, Lynn McGuire wrote: > "The State of C++ on Windows" > https://kennykerr.ca/2019/01/25/the-state-of-cpp-on-windows/ > According to Microsoft. Lucky me that I don't have to program for Windows/Microsoft anymore... It's been a long road since DOS days... DOS API, Win16/VB3/MFC/OLE, Win32/MFC/ATL/WTL/COM/VB5-6, .NET/C#, Managed C++, C++/CLI (my last engagement with Windows back to 2007) and after that WinRT, UWP, WRT, C++/CX, C++/WinRT, .NET Core... wow, what a mess! :-O What else is next? The neverending story of Windows development. At least C++/WinRT looks promising because it's only standard C++17. -- Cholo Lennon Bs.As. ARG |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Feb 03 11:55AM +0100 On 03.02.2019 08:48, Cholo Lennon wrote: > C++/CX, C++/WinRT, .NET Core... wow, what a mess! :-O What else is > next? The neverending story of Windows development. > At least C++/WinRT looks promising because it's only standard C++17. Microsoft claims, at <url: https://docs.microsoft.com/en-us/windows/uwp/cpp-and-winrt-apis/intro-to-using-cpp-with-winrt>, that "With C++/WinRT, you can author and consume Windows Runtime APIs using any standards-compliant C++17 compiler." Has anyone tried to use MinGW g++? Cheers!, - Alf (not very up-to-date) |
| Sam <sam@email-scan.com>: Feb 03 08:34AM -0500 Alf P. Steinbach writes: > and-winrt-apis/intro-to-using-cpp-with-winrt>, that > "With C++/WinRT, you can author and consume Windows Runtime APIs using any > standards-compliant C++17 compiler." Sure. The language itself it's written in will probably be C++17. But, the historical problem with Microsoft's APIs isn't the core language itself, it's the limited lifetime of their APIs. What were the leading MS-Windows APIs five years ago? Ten years ago? Twenty years ago? Are they worth anything today? Can you actually put them to use, right now? Of course, the answer is no. But just yesterday, I was hacking something on Linux, and used a little bit of something that, oh, I don't know, I learned 20 years ago, perhaps? Every Microsoft technology comes with a built-in expiration date. If you are a Microsoft Windows developer, your main job description is to generate recurring revenue to Microsoft; to purchase their documention, MSDN subscription, et. al., in order to actually be able to do something on Microsoft Windows. And Microsoft has every reason to periodically obsolete and replace every technology on their platform; otherwise there would be no reason for anyone to continue paying Microsoft for their development tools and documentation, or to pay for training. Meanwhile, everything I ever learned on Linux continues to be valid today. It never went to waste. Whatever this thing "C++/WinRT" turns out to be, it's a safe bet that in 2-3 years time it will be replaced with another shiny new ball, and every last bit of time everyone spent to learn it will go completely to waste, like all their alphabet soup of the years past. |
| Chris Ahlstrom <OFeem1987@teleworm.us>: Feb 03 08:27AM -0500 Lynn McGuire wrote this copyrighted missive and expects royalties: > "The State of C++ on Windows" > https://kennykerr.ca/2019/01/25/the-state-of-cpp-on-windows/ > According to Microsoft. At the moment I have a project that builds and runs on both Windows and Linux. It uses Qt 5 for the GUI, and host-specific APIs for the audio and MIDI support. I am in the process of refactoring it for C++14. That's about as much as I care about C++ on Windows. Not big fan of Microsoft "technology". Tends to be a will-o-the-wisp. At least Qt 5 seems to be <cough> stable. -- Q: How many marketing people does it take to change a light bulb? A: I'll have to get back to you on that. |
| Paavo Helde <myfirstname@osa.pri.ee>: Feb 03 04:57PM +0200 On 3.02.2019 15:34, Sam wrote: > What were the leading MS-Windows APIs five years ago? Ten years ago? > Twenty years ago? Are they worth anything today? Can you actually put > them to use, right now? Of course, the answer is no. Playing the devil's advocate, I have found the Windows API itself pretty stable. The Windows API calls I wrote into my programs 20 years ago are still working fine: LoadLibrary(), GetModuleFileName(), VerQueryValue(), RegOpenKeyEx(), MessageBox() etc. I guess you are complaining about not the Windows API, but about API-s for various overhyped software frameworks developed by Microsoft as it thinks it has to bring something new to the market every now and then. You cannot compare these API-s to the Linux API-s. These framework API-s would be more similar to API-s of specific applications or frameworks built on top of Linux, e.g. Netscape, Firefox, Qt etc. And for example, even though the Netscape NPAPI outlived Netscape for many years, it is now being deprecated and mostly removed from the browsers. The same has not happened to MFC which is about the same age and is still supported by MS. I am not a MS supporter, but back-compatibility is actually one of their strongest points. |
| Bart <bc@freeuk.com>: Feb 03 03:26PM On 03/02/2019 14:57, Paavo Helde wrote:> On 3.02.2019 15:34, Sam wrote: > stable. The Windows API calls I wrote into my programs 20 years ago are > still working fine: LoadLibrary(), GetModuleFileName(), VerQueryValue(), > RegOpenKeyEx(), MessageBox() etc. I agree. I still use the same API calls that I started using in the early 90s. And backwards compatibility has been superb, even being able to run the same binaries decades later (until they stopped Win64 from running Win16 programs, but a current win32 will still run them). (I didn't progress to later APIs, eg. GDI to GDI+, because they started using real C++ interfaces. Although the old interfaces like GDI are labeled C++, they are really C. I normally access WinAPI from different languages, and C++ is much harder than C for that purpose.) > by MS. > I am not a MS supporter, but back-compatibility is actually one of their > strongest points. Despite my comments above, MS' APIs are actually pretty terrible. Just compare CreateFile() to C's fopen(). They like to make them as complex and elaborate as they can, and every function seems to invent yet another set of typedefs, structs, macros, and messages. However, I understand that X11 isn't much better. |
| 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