- recovering from std::bad_alloc in std::string reserve - 5 Updates
- std::thread does not follow RAII principles - 1 Update
- "STL: Amazing Speed Differences between std::vector and std::set - 3 Updates
- std::thread does not follow RAII principles - 16 Updates
| Lynn McGuire <lynnmcguire5@gmail.com>: May 26 09:07PM -0500 On 5/25/2021 1:49 PM, Lynn McGuire wrote: >> https://stackoverflow.com/questions/639540/how-much-memory-can-a-32-bit-process-access-on-a-64-bit-operating-system > Thanks ! I was aware of that but I had not tried it yet. > Lynn I tried the /LARGEADDRESSAWARE linker option but it did not help. I suspect that the memory is fragmented. We will need to move to Win64 to fix this problem long term. Thanks, Lynn |
| Christian Gollwitzer <auriocus@gmx.de>: May 27 07:50AM +0200 Am 26.05.21 um 20:32 schrieb Lynn McGuire: - Alf > __int64 outputFileLength = _ftelli64 (pOutputFile) + 42; // give it > some slop > int outputFileLengthInt = (int) outputFileLength; ...and here you restrict it to 2GB again, or worse, retrieve a negative file size for sizes between 2GB and 4GB. To prepare for a 64bit move, you should replace all size variables with size_t for unsigned or ptrdiff_t for signed. That will correspond to a 32bit integer in 32 bit and a 64 bit integer in 64 bit. Christian |
| Lynn McGuire <lynnmcguire5@gmail.com>: May 27 02:08PM -0500 On 5/27/2021 12:50 AM, Christian Gollwitzer wrote: > size_t for unsigned or ptrdiff_t for signed. That will correspond to a > 32bit integer in 32 bit and a 64 bit integer in 64 bit. > Christian Done. With checking against SIZE_MAX before casting the variable to size_t. Yeah, if 1 GB is having trouble in Win32, 2+ GB will be much worse. The code is now ok to fail without crashing the program. Porting to Win64 is needed in the near future. So many thing to do, so little time. I will be 61 in a couple of weeks, kinda hoping to retire before 75. Thanks, Lynn |
| scott@slp53.sl.home (Scott Lurndal): May 27 09:59PM >> 32bit integer in 32 bit and a 64 bit integer in 64 bit. >> Christian >Done. With checking against SIZE_MAX before casting the variable to size_t. Why? size_t is guaranteed to hold the size of any object, which implies that it must be large enough to accomodate an object the size of the virtual address space. Generally it's minimum size in bits is the same as long. |
| Keith Thompson <Keith.S.Thompson+u@gmail.com>: May 27 03:33PM -0700 > Why? size_t is guaranteed to hold the size of any object, which implies that > it must be large enough to accomodate an object the size of the virtual address > space. Generally it's minimum size in bits is the same as long. That's likely to be true, but it's not absolutely guaranteed. size_t is intended to hold the size of any single object, but it may not be able to hold the sum of sizes of all objects or the size of the virtual address space. An implementation might restrict the size of any single object to something smaller than the size of the entire virtual address space. (Think segments.) Also, I haven't found anything in the standard that says you can't at least try to create an object bigger than SIZE_MAX bytes. calloc(SIZE_MAX, 2) attempts to allocate such an object, and I don't see a requirement that it must fail. If an implementation lets you define a named object bigger than SIZE_MAX bytes, then presumably applying sizeof to it would result in an overflow, and therefore undefined behavior. Any reasonable implementation will simply make size_t big enough to hold the size of any object it can create, but I don't see a requirement for it. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */ |
| Udo Steinbach <trashcan@udoline.de>: May 27 10:45PM +0200 Am 2021-05-26 um 13:51 Uhr schrieb Juha Nieminen: > doSomething(); // this might throw! > // ... > } RAII is a great dream in most cases. ofstream's destructor has to ignore errors on closing the system handle --- a bad choice, data loss without detection. RAII works only if closing/destroying is guaranteed to be free of any errors. Threads are not an exception but have another quality, thats all. It's your responsibility to do the best in error case and noerror case, noone of the used objects can know it better. Usually call close() on file and use Bonitas scope guard for the thread. -- Fahrradverkehr in Deutschland: http://radwege.udoline.de/ GPG: A245 F153 0636 6E34 E2F3 E1EB 817A B14D 3E7E 482E |
| MrSpook_ig1zmU0@a07vn7.tv: May 27 08:24AM On Wed, 26 May 2021 17:06:59 -0500 >> Isn't that computer science 101? O(N) vs. [O(1) .. O(Log N)] for >> vector vs std::map (red-black tree). >Sorry, never took CS 101 at TAMU. My degree is in Mechanical Perhaps you need to learn the basics if you're going to write important software in C++ before you write some POS that maintenance programmers down the line will have to suffer with for years. >Engineering. I did take CS 204 or 304, IBM 370 Assembly Language >Programming, for grins. Not many programmers would assume they could just go and design a bridge yet it seems a certain arrogance in engineering circles that programming is something anyone can akin to making a coffee just because they once wrote 10 print "hello" 20 goto 10 Well guess what, we all built buildings out of lego when we were kids too. |
| Lynn McGuire <lynnmcguire5@gmail.com>: May 27 12:08PM -0500 > 10 print "hello" > 20 goto 10 > Well guess what, we all built buildings out of lego when we were kids too. Way too late dude. I am 60 and climbing. Been running my own engineering software company for 26 years now. The eight of us are shepherding about 1.3 million lines of C++ and F77 code that has been ported from several mainframes to vaxes to unix boxes to PCs to Windows. In fact, I'll bet that TAMU has not had a CS 204 IBM 370 Assembly Language Programming in over three decades. I took the course in 1979 after placing out of all the Fortran courses. Lynn |
| Vir Campestris <vir.campestris@invalid.invalid>: May 27 09:38PM +0100 On 26/05/2021 21:44, Scott Lurndal wrote: >> (>10,000 members) just because it is much faster than std::vector. > Isn't that computer science 101? O(N) vs. [O(1) .. O(Log N)] for > vector vs std::map (red-black tree). It's funny, I usually say "Use vector. No really, use vector. Oh, perhaps if you have a special case..." But having glanced through that code It's not clear to me _why_ set works so much better for that case. Most likely lots of insertions or searches. Andy |
| MrSpook_ry@939_6htz773e0qeya.eu: May 27 08:18AM On Wed, 26 May 2021 19:04:56 +0200 >We don't discuss physical threading but how the language presents >threading; and C++11-threading is by far more convenient than pure >pthreads. A Big Mac is convenient, doesn't make it the best meal. The pthreads library is extremely powerful, perhaps the boiler plate setup code can be a bit long winded but its not hard to use. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 27 11:02AM +0200 > A Big Mac is convenient, doesn't make it the best meal. ... Programming pthreads directly has no advantages and makes a lot of workd more. |
| Juha Nieminen <nospam@thanks.invalid>: May 27 10:13AM > I'll have to add this to my list of why the C++ threading library is crap. > I would suggest if your code doesn't need to be portable to either use > posix threads on *nix or its Windows equivalent. Why don't you just fuck off, asshole? You aren't contributing to the dicussion. You are just being an asshole. |
| MrSpook_v1czYss@9slt8vr2tlp1ljrvd8h.net: May 27 10:20AM On Thu, 27 May 2021 10:13:13 +0000 (UTC) >> posix threads on *nix or its Windows equivalent. >Why don't you just fuck off, asshole? You aren't contributing to the >dicussion. You are just being an asshole. Good morning Mr Happy, things going well in Finland today? |
| MrSpook_b28s@jxgz6zklebr1.tv: May 27 10:24AM On Thu, 27 May 2021 11:02:11 +0200 >> A Big Mac is convenient, doesn't make it the best meal. ... >Programming pthreads directly has no advantages Presumably you've never had to use 3 level locking or fine grain threading control. Also the lack of proper interoperability with signals makes C++ threading on unix a bit of a toy frankly. >and makes a lot of workd more. A bit, not a lot. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 27 12:33PM +0200 > Presumably you've never had to use 3 level locking or fine grain threading > control. Also the lack of proper interoperability with signals makes C++ > threading on unix a bit of a toy frankly. Signals are a plague. You can't write a libary which does have a Signal-handling which is coordinatet independently from the code it is later embedded into. Both have to be made of a single piece. Signals are even more worse since there can't be different handlers for synchonous signals for different threads. And signal-codd always have a reentrancy problem, that makes them a even bigger plague. And the ABI has to be designed around them (red zone). That's not clean coding. Therefore: Outsource asynchronous signals to differnt threads. Windows has a more powerful handling for something like synchronous signals, Structured Excetion Handling. And for the few asynchronous signals Windows knows, Windows spawns a diffrent thread if a signal happens. And which threading-contol is needed beyond that what C++ provides ? |
| Bonita Montero <Bonita.Montero@gmail.com>: May 27 12:40PM +0200 >> control. Also the lack of proper interoperability with signals makes C++ >> threading on unix a bit of a toy frankly. > Signals are a plague.... And even more: If I use C++-threading the places where signals could occur and where I can't get the EAGAIN are only where I have locking and / or waiting for a condition_variable. But the places where I lock a mutex or wait for a CV with pthreads, Posix mandates you to re-lock the mutex or re-wait for the CV - that's exactly what C++11 -synhroni-zation does also - so there's no difference here. So what do you complain here ? |
| Bonita Montero <Bonita.Montero@gmail.com>: May 27 12:55PM +0200 > re-lock the mutex or re-wait for the CV - that's exactly what C++11 > -synhroni-zation does also - so there's no difference here. So what > do you complain here ? Oh, I'm partitially wrong here: pthread_mutex_wait behaves as described _but_ pthread_cond_wait handles the signal-handler internally and con- tinues waiting afterwards. So there's still nothing different than with C+11-threads ! |
| MrSpook_d4c3Jb7l7@8dftupdzk09cop2.co.uk: May 27 11:05AM On Thu, 27 May 2021 12:33:28 +0200 >> control. Also the lack of proper interoperability with signals makes C++ >> threading on unix a bit of a toy frankly. >Signals are a plague. You can't write a libary which does have a Says the windows programmer. >Signal-handling which is coordinatet independently from the code Good, libraries should not be handling signals. >Therefore: Outsource asynchronous signals to differnt threads. You simply have a signal handling thread that sits in sigwait() and block signals to everything else using pthread_sigmask(SIG_BLOCK...) which - surprise! - you can't do in C++ threads. >signals, Structured Excetion Handling. And for the few asynchronous >signals Windows knows, Windows spawns a diffrent thread if a signal >happens. Spawning a new thread for every signal isn't powerful , its moronic. >And which threading-contol is needed beyond that what C++ provides ? I'm not going to keep repeating myself, you appear to be wilfully deaf. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 27 01:14PM +0200 >> Signals are a plague. You can't write a libary which does have a > Says the windows programmer. Signals are simply a bad concept. No one would invent them today. >> Signal-handling which is coordinatet independently from the code > Good, libraries should not be handling signals. The problem is that they partitially need. And that's not possible without coordination with the code the're embedded into. > You simply have a signal handling thread that sits in sigwait() and > block signals to everything else using pthread_sigmask(SIG_BLOCK...) > which - surprise! - you can't do in C++ threads. Of course you could call sigwait() from a C++11-thread. >> signals Windows knows, Windows spawns a diffrent thread if a signal >> happens. > Spawning a new thread for every signal isn't powerful , its moronic. That absolutely doesn't matter since the signals Windows knows are very infreqiernt. >> And which threading-contol is needed beyond that what C++ provides ? > I'm not going to keep repeating myself, you appear to be wilfully deaf. You are ultimately stupid ! |
| Bonita Montero <Bonita.Montero@gmail.com>: May 27 01:18PM +0200 > The problem is that they partitially need. And that's not possible > without coordination with the code the're embedded into. Imagine you've got two framworks with two configuration-files which are refreshed through SIGUP - that's not possible without central coordination. Or imagine you've a application which does asynchronous I/O and a include libary that does it as well. Handling SIGIO and passs the results back to the originating threads can be a complex task. And both must be coordinated centrally as there coudln't be any indi- vidual signal-handlers. Signals are simply a weak concept. |
| Juha Nieminen <nospam@thanks.invalid>: May 27 12:24PM >>Why don't you just fuck off, asshole? You aren't contributing to the >>dicussion. You are just being an asshole. > Good morning Mr Happy, things going well in Finland today? Fuck off, asshole. |
| MrSpook_zdNaq@bltmyc.gov.uk: May 27 03:39PM On Thu, 27 May 2021 12:24:36 +0000 (UTC) >>>dicussion. You are just being an asshole. >> Good morning Mr Happy, things going well in Finland today? >Fuck off, asshole. Oh dear, another bad day? Have a lie down and cuddle the therapy teddy. |
| MrSpook_b_x@ukpge.org: May 27 03:54PM On Thu, 27 May 2021 13:14:36 +0200 >>> Signals are a plague. You can't write a libary which does have a >> Says the windows programmer. >Signals are simply a bad concept. No one would invent them today. Behold! Our mighty sage has spoken - let it be known that interrupts are a bad idea! Whatever you say sweetie. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 27 07:32PM +0200 >> Signals are simply a bad concept. No one would invent them today. > Behold! Our mighty sage has spoken - let it be known that interrupts are a bad > idea! Interrupts in userland with reentrancy-constraints a very bad idea. And interrupting OS-calls with signals makes the operating-system design very complex if you really want to make it interruptible at every time while processing a call. That's not necessary if you'd design it not that stupid. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 27 07:00PM +0100 On Thu, 27 May 2021 19:32:58 +0200 > design very complex if you really want to make it interruptible at > every time while processing a call. That's not necessary if you'd > design it not that stupid. Interrupts were necessary with single-threaded programs. They are not usually necessary with multi-threaded programs and POSIX provides everything you need in consequence. You block the signals of interest in all your threads and then have a single handler thread with blocks on sigwait() and deals with the signals synchronously (synchronously for the handler thread that is). Job done. One other thing POSIX provides and C++11 doesn't is thread cancellation. Some programmers who don't have relevant experience think thread cancellation is a bad idea because it allows arbitrary cancellation which cannot be adequately controlled (the "combing your hair with a fork" jibe). Whilst that is true with windows it absolutely isn't with POSIX. What you do is use deferred cancellation (the default in POSIX) and block cancellation as normal policy, and only enable cancellation at defined points in the code which are able to deal with it (normally where a wait is to occur). Done properly, thread cancellation is far easier to use than exceptions, which can jump out of anywhere if you include std::bad_alloc in the mix. C++11 threads don't deal with cancellation and will never be able to do so because they require OS support - in this case POSIX support. |
| 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