- Lock-free LRU-cache-algorithm - 1 Update
- Vector with memory from global storage (static duration) - 3 Updates
- Which exception for a buffer overrun? - 1 Update
| Bonita Montero <Bonita.Montero@gmail.com>: Oct 21 04:42PM +0200 I just read about an option of MySQL / MariaDB to circumvent the locking-issue of the LRU list: the simply hash the block-key and adress a configurable number of LRU-list where each of those is locked with a single mutex. This gives not really a clean evition of the very oldest entry in the LRU-list, but it should definitely scale better than a single lock. How good this scales depends on relation the time spent while holding the mutexes to the time not holding a mutex and the number of threads involved here. In theory this could even scale slightly better than my solution, but you may have to have a lot of LRU-lists for that. |
| Frederick Gotham <cauldwell.thomas@gmail.com>: Oct 21 12:22AM -0700 On Saturday, October 19, 2019 at 11:02:50 PM UTC+1, James Kuyper wrote: > manages a fixed block of memory with static storage duration, and which > supports no more than a single allocation from that block - but this > isn't how you do it. Surely there should be such a class template in Boost? |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Oct 21 10:07AM -0400 On 10/21/19 3:22 AM, Frederick Gotham wrote: >> supports no more than a single allocation from that block - but this >> isn't how you do it. > Surely there should be such a class template in Boost? I recommend asking that question in a forum devoted to Boost. My news server doesn't know of any newsgroup whose name contains "Boost", but there are apparently mailing lists: <https://www.boost.org/community/groups.html>. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 21 07:34AM -0700 On Monday, 21 October 2019 10:23:10 UTC+3, Frederick Gotham wrote: > > supports no more than a single allocation from that block - but this > > isn't how you do it. > Surely there should be such a class template in Boost? Boost has lot of allocator-related things but none seems anything like what you do: https://www.boost.org/doc/libs/1_71_0/doc/html/interprocess/allocators_containers.html May I ask what is the usage for such odd allocator for unusual vector (whose implementation is expecting allocators to meet requirements to allocators that your example violates) instead of simply having something like static std::array<uint8_t, 4096>? Latter seems far more robust, more efficient in time and space and also honest about what it really is. |
| "Öö Tiib" <ootiib@hot.ee>: Oct 21 04:06AM -0700 On Monday, 21 October 2019 01:18:14 UTC+3, Jorgen Grahn wrote: > > program executes, such as violations of logical preconditions > > or class invariants." > I.e. bugs. Somehow the preconditions are violated. Can be bug in this program, can be data in file got corrupted, can be a person prepared it wrongly manually or can be other, external program made it wrongly. > But there is no such thing. The way I read this thread (after > snipping, reconstruction and a weekend) std::logic_error is for bugs, > and std::stoi() misuses it. And that's also what you argue. Right? If logic_error means only programming bug then yes, but it seems that it is not the case. It is wider in standard so it seems to be intent. For example we have similar logic_errors (invalid_argument) thrown by std::bitset constructors (from string or char*) and several other places. When there is code that does std::map::find, then compares it with std::map::end and if equal then throws something otherwise continues using found_iterator->second then why we may not use std::map::at instead that does same and we get reference not that ->second bloat? > commented on and believed that, seen in isolation, I didn't agree with > it. So I complained about that isolated part, added the disclaimer, > and snipped because I didn't want to imply I had read all of it. No problem. > string, and (among other things) throws std::out_of_range if the > string's number doesn't fit in an int. > That does seem a bit useless. It is useful in sense that it is never thrown when the number fits into int. When it is thrown then it depends on context how we should react. If the string came from configuration of program then we likely should refuse to run the program (as misconfigured). If it did come from network request then we perhaps should reject only the request (with some error code like 400). > I agree. I haven't used std::stoi, but I imagine if I /did/ use it > I would have to guard individual calls in try...catch, which to me > misses the point with exceptions. That seems to depend on context. For examples that I gave already above it may mean that configuration file of program is defective or that single external request is defective. What can immediate caller do to handle the situation? Take some "default" int value? That is likely transgressing over its responsibilities. Maybe I misunderstand your point. On most cases we should let exceptions to propagate to level that started the whole operation that now apparently failed (like reading configuration or parsing incoming request). |
| 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