- Smelly std::pair and std::tuple - 2 Updates
- std::experimental::atomic_shared_ptr - 2 Updates
- I was thinking about Transactional memory more.. - 1 Update
| Ian Collins <ian-news@hotmail.com>: May 07 05:52PM +1200 On 05/ 7/17 05:38 AM, Jorgen Grahn wrote: >> them misused a lot. > At this point, I'd appreciate some words about how they should be > used. I haven't (as far as I know) had reason to use them myself yet. I guess there are a couple of glib answers to get out of the way first: 1) whenever you would have used a hand rolled typelist 2) whenever you want to bamboozle your colleagues :) Regarding the first point: tuples are to compile time operations what structs are to run time operations. That point was completely overlooked in the article, especially where the authour criticised the use of std::get to access members of a tuple. If you don't do much generic programming with templates, you probably won't use them. My most frequent use of a tuple is to check a type is valid for a template. A recent requirement from my work was given a class template used to hold the latest instance of a particular system message, fail at compile time if the template get() method was instantiated with a type that hadn't been created. My solution was to built a tuple of all the types created and to embed a std::get<T>(Tuple) in the get() member. Another similar use is for classes that subscribe to a number of system messages. Rather than have a receive member function I use a template member function and store the messages in a tuple. If someone tries to send the wrong message type, the code fails to compile in the same was it would with individual receive member functions. -- Ian |
| Chris Vine <chris@cvine--nospam--.freeserve.co.uk>: May 07 11:09AM +0100 On Sun, 7 May 2017 17:52:34 +1200 > someone tries to send the wrong message type, the code fails to > compile in the same was it would with individual receive member > functions. To add to this, I have used tuples most frequently to return multiple values from a function. It is usually much easier than returning a hand-rolled struct, and you can destructure the return values with std::tie. I believe C++17 also has a more versatile destructuring bind for tuples for this explicit purpose, although I have not used it. Another thing I have sometimes used them for is compile-time function overloading - you pass a variable number of arguments as a single (run-time) object, the tuple, which is introspectable at compile time. I have mainly used it for type erasure, say for constructing opaque callback objects, but I suspect it is something which has wider uses, such as the ones you have mentioned. And sometimes they are just more convenient than passing hand-rolled structs as an argument, just as std::pair can be more useful than providing a number of hand-rolled two element structs in some cases. Chris |
| bitrex <bitrex@de.lete.earthlink.net>: May 06 08:00PM -0400 On 05/06/2017 04:09 PM, Marcel Mueller wrote: > a reference which implies that the object is no longer needed and > probably needs no screen redraw. You can safely discard it. > Marcel Ok, so I traced down the segfault problem in my implementation to this section of code that uses software to render some "motion trails" on 2D sprites: void update() override { auto obj_ptr = _effect_object_buf.back().get(); _effect_object_buf.push_front(std::move(_effect_object_buf.back())); _effect_object_buf.pop_back(); new (obj_ptr) DisplayObject2D(*_effect_target); etc. _effect_object_buf is a boost::circular_buffer holding shared pointers that are instantiated with objects, and then weak_pointers are handed off to the visualizer thread at startup. It just holds copies of the object from further back in time with its alpha transparency reduced to represent the "trail", and when one fades out completely it's pushed to the front and reassigned to a copy of where the object is now. It works fine in practice and looks pretty good, for a random amount of time until the code segfaults, or throws a "pure virtual method called, terminate called without an active exception" error. Appears doing this weird thing might not be thread-safe? The report Valgrind is giving on the crash is that I'm performing invalid reads on blocks that are already free-d. |
| Marcel Mueller <news.5.maazl@spamgourmet.org>: May 07 08:29AM +0200 On 07.05.17 02.00, bitrex wrote: > void update() override > { > auto obj_ptr = _effect_object_buf.back().get(); Err, _effect_object_buf is a container of shared_ptr? Then obj_ptr here is a raw pointer, not taking the ownership of the object. Neither holding the storage behind it. Rule of thumb: *never use raw pointers* expecially not in conjunction with smart pointers. > _effect_object_buf.push_front(std::move(_effect_object_buf.back())); > _effect_object_buf.pop_back(); Is the mutable access to _effect_object_buf synchronized or single threaded? Including readers? (Btw. be aware of priority inversion if readers and writers do not operate at the same scheduling priority.) And why do you put the objects in the circular buffer from back to front instead of just cycling with an iterator? > new (obj_ptr) DisplayObject2D(*_effect_target); Who destroyed the old object at old_ptr before this placement new? Can no one else access the object behind obj_ptr which is still an entry in _effect_object_buf at this point? > The report Valgrind is giving on the crash is that I'm performing > invalid reads on blocks that are already free-d. Probably. This explains the pure function exception, but a race with placement new could result in a similar problem. Marcel |
| rami17 <rami17@rami17.net>: May 06 09:19PM -0400 Hello..... I was thinking about Transactional memory more.. Here is the problem of optimistic transactional memory: If there is more conflicts between reads and writes you have to rollback etc. and this will be less energy efficient than pessimistic locking mechanisms and it will be less faster. So i think that my C++ Synchronization objects library is still useful.. You can download it from: https://sites.google.com/site/aminer68/c-synchronization-objects-library Thank you, Amine Moulay Ramdane. |
| 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