| Vir Campestris <vir.campestris@invalid.invalid>: Oct 13 09:37PM +0100 If you derive from enable_shared_from_this you get a method in your class "shared_from_this" that allows you to hand out shared pointers safely. The first time you assign a pointer from your object it sets up the shared_ptr, links the internal weak_ptr, and all is fine. If some **** later calls std::shared_ptr(this) you get an entirely new shared pointer, with a different ref count. If the STL is smart enough to detect the first case why doesn't it give an error in the second? I know a codebase where it would have saved lots of problems :( Andy |
| Paavo Helde <myfirstname@osa.pri.ee>: Oct 14 12:42AM +0300 On 13.10.2017 23:37, Vir Campestris wrote: > shared pointer, with a different ref count. > If the STL is smart enough to detect the first case why doesn't it give > an error in the second? What first case? Do you mean that C++ lets you wrap any raw pointer in a shared_ptr, regardless of if this makes sense or not? Yes, you are welcome to shoot your both legs off! Actually that's indeed a problem. I dealt with that by not using std::shared_ptr directly, but deriving my own smartpointer class from it and prohibiting the constructor and assignment from the raw pointer. The only constructor is from std::shared_ptr (which is not used otherwise in the codebase). Allowing reconstruction the smartpointer from *this is another, orthogonal topic. For that you need to derive from std::enable_shared_from_this and call shared_from_this() (for which I have provided my own function of course as well to wrap the result immediately into my own smartpointer class). If there are any better/cleaner solutions I would appreciate to hear about them of course! Cheers Paavo |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 14 12:40AM +0200 On 10/13/2017 11:42 PM, Paavo Helde wrote: > and prohibiting the constructor and assignment from the raw pointer. The > only constructor is from std::shared_ptr (which is not used otherwise in > the codebase). I think maybe better to provide a constructor that forwards arguments to make_shared. > immediately into my own smartpointer class). > If there are any better/cleaner solutions I would appreciate to hear > about them of course! Cheers!, - Alf |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Oct 13 11:02PM +0200 On 10/13/2017 11:29 AM, Ralf Goertz wrote: > "reallocation is not guaranteed to happen, and the vector capacity is > not guaranteed to change due to calling this function". That means it is > also not guaranteed not to change. Can I make sure it doesn't change? You can just resize it to 0. <url: http://en.cppreference.com/w/cpp/container/vector/resize> "Vector capacity is never reduced when resizing to smaller size because that would invalidate all iterators, rather than only the ones that would be invalidated by the equivalent sequence of pop_back() calls." In the other direction, to guarantee capacity reduction just swap with a vector with the desired new capacity. Cheers & hth., - Alf |
| David Brown <david.brown@hesbynett.no>: Oct 13 10:46AM +0200 On 12/10/17 21:50, Christian Gollwitzer wrote: > #pragma omp parallel for reduction(+:sum) > for (size_t i =0; i < vect.size(); i++) { sum += vect[i]; } > Christian I don't think Stefan's example was intended to be minimal code for doing a parallel sum. It was just an example of how to use packaged tasks and threads in C++. And my code was a correction of his attempt. OpenMP certainly makes some things easier for multi-threading - but explicitly controlling the threads as in this sample can have its advantages too. A tiny example like this will blow the code overheads out of proportion - in a real world program, the difference will be much smaller. |
| 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