- Niuce C++14-feature - 9 Updates
- recovering from std::bad_alloc in std::string reserve - 4 Updates
- std::thread does not follow RAII principles - 1 Update
- lamda-optimization - 5 Updates
- Would D ever stop if simulating halt decider H never stopped simulating it? - 6 Updates
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 24 11:20PM -0700 On 5/24/2021 11:19 PM, Bonita Montero wrote: >>> sible with blocking). >> Why? > Because lock-free is without waiting in the kernel. Why, again? You are missing key things here... Think... |
| Bonita Montero <Bonita.Montero@gmail.com>: May 25 08:35AM +0200 > Really? Should I bring up the older thread? Yes, you've got false memories. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 25 08:55AM +0200 > God you are being dense right now. Lock-free structures never wait inside the kernel, that's while the're non-locking. But a condvar mostly waits inside the kernel. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 24 11:58PM -0700 On 5/24/2021 11:55 PM, Bonita Montero wrote: >> God you are being dense right now. > Lock-free structures never wait inside the kernel, that's while > the're non-locking. But a condvar mostly waits inside the kernel. Huh? You are missing the fact that there is an algorihtm that can turn a lock-free stack into something that can wait in the kernel when it needs to for the push/pop functions. It can be a futex, but there is another one out there... |
| Bonita Montero <Bonita.Montero@gmail.com>: May 25 09:00AM +0200 Lock-free algorithms never wait inside the kernel. Otherwise they woudln't be lock-free. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 25 12:03AM -0700 On 5/24/2021 11:59 PM, Bonita Montero wrote: >> You are the one who made Kaz correct you. I corrected you as well. > But you are wrong about which topic. > Sorry, but that's very weak, losing your memories so shortly. No, I just have to end up teaching you again. Oh well. The new thread will be beneficial to you and, perhaps, others. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 25 09:05AM +0200 >> Lock-free algorithms never wait inside the kernel. >> Otherwise they woudln't be lock-free. > Oh argh! Did you read where I mentioned predicates? Yes, this predicates are polled with all lock-free algorithms. |
| "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: May 25 12:02AM -0700 On 5/25/2021 12:00 AM, Bonita Montero wrote: > Lock-free algorithms never wait inside the kernel. > Otherwise they woudln't be lock-free. Oh argh! Did you read where I mentioned predicates? |
| Bonita Montero <Bonita.Montero@gmail.com>: May 25 09:04AM +0200 > No, I just have to end up teaching you again. Oh well. > The new thread will be beneficial to you and, perhaps, others. The discussion was about whether mutexes could be realized only with as counting mutexes and not whether they could be realized with compare-and-swap only. You have a weak memory ! |
| David Brown <david.brown@hesbynett.no>: May 31 08:33AM +0200 > One proposal is to make intmax_t mean int64_t, and leave it at that. > Have no requirement that integer types can't be larger. No more ABI > problem. It might make more sense to tie it to "long long int" rather than "int64_t", but someone would first have to check if it affected any real implementations before making such a change. But yes, that might be a way out and a way forward. >> backwards compatibility. > Hardly "most purposes", far from it. Without compiling with "-std=gnu++11", > you don't even have std::numeric_limits<__int128>. Well, it /is/ a gcc extension - choosing to enable it on the command line makes sense to me. But I was thinking of the core language, rather than the library, which can be somewhat independent of the compiler itself. > languages such as rust with better type support see rapid growth > of open source libraries that cover all manner of data interchange > standards, C++ is comparatively stagnant. Those relatively few programs that have need of int128_t can simply do a typedef. It won't magically allow literals of the type, but it will cover most cases. |
| "daniel...@gmail.com" <danielaparker@gmail.com>: May 31 08:21AM -0700 On Monday, May 31, 2021 at 2:33:52 AM UTC-4, David Brown wrote: > Those relatively few programs that have need of int128_t can simply do a > typedef. It won't magically allow literals of the type, but it will > cover most cases. A typedef? You've lost me. Daniel |
| David Brown <david.brown@hesbynett.no>: May 31 06:13PM +0200 >> cover most cases. > A typedef? You've lost me. > Daniel typedef signed __int128 int128_t; typedef unsigned __int128 uint128_t; You can wrap them in #ifdef's to check for gcc and support for the 128 bit almost integer types (and perhaps to check that your target doesn't support standard int128_t types, as it will if "long long" is 128 bits). |
| Paavo Helde <myfirstname@osa.pri.ee>: May 25 07:47AM +0300 25.05.2021 04:52 Lynn McGuire kirjutas: >> Thanks, >> Lynn > And I am building a Win32 program. Not a Win64 program. The usable memory space in a Windows 32-bit program is limited to 2GB. It can be increased to 3GB, but this does not buy you much. Catching std::bad_alloc as you have done in other responses is trivial, but now what? Your program still does not work as expected. If you are dealing with strings in GB range then you really should start thinking of switching over to x64 compilation (this will involve some 64-bit bugfixing if this is your first time). Either that, or you need to redesign your code to read and write files in smaller pieces, which might be a lot of work. Also, ftell() returns a signed 32-bit value in Windows so what you have written here will cease to work when your files grow larger than 2 GB. Suggesting to always use 64-bit alternatives for handling file sizes and positions, even in 32-bit programs. Unfortunately these alternatives are not portable and one needs to take some extra care for supporting different OS-es. It's also strange to base the program logic on the size of an *output* file. But there are probably reasons. |
| 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. |
| Bonita Montero <Bonita.Montero@gmail.com>: May 31 06:16AM +0200 You're so ultimately stupid. |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: May 31 06:33PM +0200 Am 30.05.21 um 13:18 schrieb Bonita Montero: > } > Can anyone tell me whether the lambda has three pointers (24 bytes > on 64 bit systems) instead of just one pointer inside the stack-frame, A generic function pointer typically take 3 machine size words to support all cases of polymorphism. Note that a lambda with closures is in fact equivalent to a class with a (virtual) interface function with the lambda signature. So we are talking about a /member function pointer/ in general. Due to multiple inheritance and implicit upcasts this is not simply a pointer to code. > which could be an easy optimization ? There is nothing you can do. The compiler on the other side is not required to allocate the storage unless it is really needed. Marcel |
| Bonita Montero <Bonita.Montero@gmail.com>: May 31 06:50PM +0200 > the lambda signature. So we are talking about a /member function > pointer/ in general. Due to multiple inheritance and implicit upcasts > this is not simply a pointer to code. The three pointers have a fixed relationship to each other so that the compiler could store a single pointer somewhere inside the stackframe and address the three variables as [reg+a], [reg+b] and [reg+c]. |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: May 31 08:27PM +0200 Am 31.05.21 um 18:50 schrieb Bonita Montero: [Lambda pointer] > The three pointers have a fixed relationship to each other so that the > compiler could store a single pointer somewhere inside the stackframe > and address the three variables as [reg+a], [reg+b] and [reg+c]. No they have not. You may assign any other function pointer to the function type f later. Marcel |
| red floyd <no.spam.here@its.invalid>: May 31 12:41PM -0700 On 5/30/2021 9:16 PM, Bonita Montero wrote: > You're so ultimately stupid. Hint: an ad hominem reply means you have lost the debate |
| Bonita Montero <Bonita.Montero@gmail.com>: May 31 06:18AM +0200 > error. I am very very happy that you suggested that I look into that. I > was able to completely abolish the contradiction. > https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument Your stop-problem-issues are interesting no one here. They're generic to any language, so they're off-topic here. |
| olcott <NoOne@NoWhere.com>: May 31 12:12AM -0500 On 5/30/2021 11:18 PM, Bonita Montero wrote: >> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument > Your stop-problem-issues are interesting no one here. > They're generic to any language, so they're off-topic here. Kaz was my best reviewer. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Bonita Montero <Bonita.Montero@gmail.com>: May 31 07:24AM +0200 >> Your stop-problem-issues are interesting no one here. >> They're generic to any language, so they're off-topic here. > Kaz was my best reviewer. Then Kaz made the same mistake like you. |
| olcott <NoOne@NoWhere.com>: May 31 12:35AM -0500 On 5/31/2021 12:24 AM, Bonita Montero wrote: >>> They're generic to any language, so they're off-topic here. >> Kaz was my best reviewer. > Then Kaz made the same mistake like you. Kaz suggested that I study diagonalization and now I can easily refute this much simpler proof. My refutation is on page 1 and Sipser's whole proof is on page 2. So far the only critiques have been about punctuation. https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| Bonita Montero <Bonita.Montero@gmail.com>: May 31 08:14AM +0200 > this much simpler proof. My refutation is on page 1 and Sipser's whole > proof is on page 2. So far the only critiques have been about punctuation. > https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument Are you stupid ? It's no matter what Kaz said. HERE IS THE WRONG PLACE ! |
| olcott <NoOne@NoWhere.com>: May 31 01:34AM -0500 On 5/31/2021 1:14 AM, Bonita Montero wrote: >> https://www.researchgate.net/publication/351947980_Refutation_of_Halting_Problem_Diagonalization_Argument > Are you stupid ? It's no matter what Kaz said. > HERE IS THE WRONG PLACE ! If here really was the wrong place then I would not have been able to get Kaz to come back to comp.theory by posting here. -- Copyright 2021 Pete Olcott "Great spirits have always encountered violent opposition from mediocre minds." Einstein |
| 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