- "Modern C++" != "New(est) Standard" - 3 Updates
- Should you use constexpr by default? - 5 Updates
| woodbrian77@gmail.com: Aug 25 06:31PM -0700 On Saturday, August 25, 2018 at 4:29:38 PM UTC-5, Öö Tiib wrote: > when unique_ptr means additional pointer, additional indirection > and additional dynamic allocation/deallocation. The situations may > certainly vary but can't be that by that lot. I only have measurements of the text segments. Moving a unique_ptr is a cheap, fixed time. Whereas moving an optional is linear in terms of the members of the type. My type in this case has almost all primitive subtypes that have to be copied. > In general what is currently pricey is not memory amount, nor throughput > but it is latency. Optionals are local and that always means less cache > misses and better latency. I could go along with that, but would point out that you are talking about the data and I was talking about the instructions/ text segment. Unique_ptr is cleaner from the instruction side. Brian Ebenezer Enterprises http://webEbenezer.net |
| "Öö Tiib" <ootiib@hot.ee>: Aug 26 04:18AM -0700 > unique_ptr is a cheap, fixed time. Whereas moving an optional > is linear in terms of the members of the type. My type in this > case has almost all primitive subtypes that have to be copied. I do not usually measure only one segment of memory. I measure memory usage peaks and performance under big loads. You are correct that if you need to frequently change ownership of large objects (to move those) then unique_ptr is likely better. That is so regardless if these are optional or not. Concretely your vector of pendingRequests is a queue where inserts are from one and erases from other end. It is likely that std::list<std::optional<T>> wins std::vector<std::unique_ptr<T>> there but both fragment memory so I would likely use boost::circular_buffer_space_optimized<std::optional<T>> instead. > I could go along with that, but would point out that you are > talking about the data and I was talking about the instructions/ > text segment. Unique_ptr is cleaner from the instruction side. I have had issues with code size only with embedded software and there are usually no dynamic memory. Most data there is kept in fixed arrays, ring buffers and stacks. Also stacks of threads are fixed, no general purpose threads. So optional is fine there but stock unique_ptr is out of question. |
| woodbrian77@gmail.com: Aug 26 11:32AM -0700 On Sunday, August 26, 2018 at 6:18:23 AM UTC-5, Öö Tiib wrote: > You are correct that if you need to frequently change ownership of > large objects (to move those) then unique_ptr is likely better. > That is so regardless if these are optional or not. If the internet is running well, I probably won't have to frequently move objects. Maybe 2% of the time when the internet is slow I could have scores of pending requests and unique_ptr is better then. > std::list<std::optional<T>> wins std::vector<std::unique_ptr<T>> > there but both fragment memory so I would likely use > boost::circular_buffer_space_optimized<std::optional<T>> instead. That or an intrusive list would make std::optional more appealing, but I only use Boost in closed source applications. Besides the standard, I only have one external dependency for compression. > arrays, ring buffers and stacks. Also stacks of threads are fixed, no > general purpose threads. So optional is fine there but stock > unique_ptr is out of question. The context here is that there's a file system. I don't think there's a problem with using a little dynamic memory in that context. Brian Ebenezer Enterprises https://github.com/Ebenezer-group/onwards |
| Juha Nieminen <nospam@thanks.invalid>: Aug 26 05:29AM > So what you are really proposing is a coding standard. No, it's not me who is proposing it. > function is called concurrently on the object. Otherwise "a locking > mechanism" (your words) is required when invoking the const member > functions (and any non-const member function). You proceeded to describe exactly what I was talking about. > call it safely in one thread irrespective of what another thread is > doing. What "thread safe" means is that you do not have to provide > external synchronisation. So now you start nitpicking about the exact terminology. Right. |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 26 10:43AM +0100 On Sun, 26 Aug 2018 05:29:47 -0000 (UTC) > > mechanism" (your words) is required when invoking the const member > > functions (and any non-const member function). > You proceeded to describe exactly what I was talking about. This is ridiculous. I repeat that what you said was: "Even beyond that, in the era of C++11 and newer, the constness of a member function should indicate that it's thread-safe to call it without a locking mechanism." That is not what the C++ standard library provides. The best you have been able to come up with is that in your opinion the standard library "should" do so; but it doesn't and it never will. > > doing. What "thread safe" means is that you do not have to provide > > external synchronisation. > So now you start nitpicking about the exact terminology. Right. No, you are wriggling. You have made an assertion about thread safety which (unless you are talking about your own personal coding standards) is wrong. In this business, labelling a function "thread-safe" means that users do not need to provide external synchronisation to maintain invariants, irrespective of what other threads are doing. |
| Daniel <danielaparker@gmail.com>: Aug 26 07:55AM -0700 On Saturday, August 25, 2018 at 2:14:27 PM UTC-4, Chris Vine wrote: > called concurrently with another thread calling that or another const > member function on the same object, provided that no non-const member > function is called concurrently on the object. For what definition of "safely"? In this context, as far as the the C++ standard is concerned, there is no distinction between calling unqualified f() and f() const, as both can mutate state and have side effects. Daniel |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: Aug 26 04:13PM +0100 On Sun, 26 Aug 2018 07:55:42 -0700 (PDT) > For what definition of "safely"? In this context, as far as the the C++ > standard is concerned, there is no distinction between calling unqualified f() > and f() const, as both can mutate state and have side effects. I was referring to the standard library - the text you have extracted was preceded by the words "The standard library doesn't guarantee that, so I think you are onto a loser. ...". The C++ standard provides this guarantee for the standard library somewhere, because I have read it. Are you asking me to look it up or were you making a more general observation about other code? If the latter I would agree with you: other code provides whatever guarantees it chooses to offer. |
| Daniel <danielaparker@gmail.com>: Aug 26 08:31AM -0700 On Sunday, August 26, 2018 at 11:14:10 AM UTC-4, Chris Vine wrote: > The C++ standard provides this guarantee for the standard library > somewhere, because I have read it. Sorry, I misread your comment, that this statement was about the C++ standard library, and not about the C++ standard generally. Daniel |
| 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