- Can I pass a shared_ptr to a thread as a temporary ? - 5 Updates
- std::copy can't copy raw bytes from a file - 3 Updates
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 10 03:39PM -0800 On 2/10/2020 3:15 PM, Chris M. Thomasson wrote: > // this does not work wrt the > // last time I looked at shared_ptr > shared_ptr<bar> local = g_bar; // it would be nice to check for nullptr... if (! local) continue; |
Paavo Helde <myfirstname@osa.pri.ee>: Feb 11 08:37AM +0200 On 11.02.2020 0:04, Chris M. Thomasson wrote: > I don't really use std::shared_ptr all that much, preferring "intrusive" > counts that embed the refcount within the object itself. No need to avoid std::shared_ptr for this reason, std::make_shared() and std::allocate_shared() effectively do exactly this. One problem with home-grown intrusive refcounting schemas is that it would be too easy/too tempting to create new smartpointers during the main object construction and destruction, leading to conceptual problems and race conditions. Using std::shared_ptr will avoid such problems, by design. |
Bonita Montero <Bonita.Montero@gmail.com>: Feb 11 08:07AM +0100 > No need to avoid std::shared_ptr for this reason, std::make_shared() and > std::allocate_shared() effectively do exactly this. That's a matter of taste. |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 11 02:23PM -0800 On 2/10/2020 10:37 PM, Paavo Helde wrote: > would be too easy/too tempting to create new smartpointers during the > main object construction and destruction, leading to conceptual problems > and race conditions. I am not exactly sure what you mean here? Can you give a simple example? > Using std::shared_ptr will avoid such problems, by > design. Fwiw, shared_ptr does not provide strong thread safety, last time I looked. This can be dangerous in certain scenarios that require it. Here is the pattern, pseudo-code: static shared_ptr<bar> g_bar; // nullptr void multiple_threads() { for (;;) { // this does not work wrt the // last time I looked at shared_ptr shared_ptr<bar> local = g_bar; if (! local) continue; local->foobar(); } } void single_thread() { shared_ptr<bar> local(new bar()); g_bar = local; } Last time I checked, shared_ptr works only if a thread has a prior reference. The multiple_threads() function violates this. Now, there is a home-brew smart pointer than can easily handle such scenarios. Afaict, its basically crowbar proof: http://atomic-ptr-plus.sourceforge.net This has a patent: https://patents.google.com/patent/US5295262 expired but fee related. Humm... |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com>: Feb 11 02:29PM -0800 On 2/9/2020 7:28 AM, Paavo Helde wrote: > std::thread constructor where it will be copied or moved appropriately > before the thread starts. Any time later one will need more elaborate > synchronization. Afaict, this pretty much sums it all up. |
Frederick Gotham <cauldwell.thomas@gmail.com>: Feb 11 07:36AM -0800 I wanted to copy the contents of a binary file into a vector of unsigned chars. Here's what I tried to do: ifstream mofile("some_binary_file.exe", std::ios::binary); if ( !mofile.is_open() ) return; vector<char unsigned> tmp_vec; tmp_vec.reserve(10000ull); std::copy( istream_iterator<char unsigned>(mofile), istream_iterator<char unsigned>(), back_inserter(tmp_vec) ); This code compiles and appears to run just fine, but the file contents are copied properly. I had to change it to: ifstream mofile("some_binary_file.exe", std::ios::binary); if ( !mofile.is_open() ) return; vector<char unsigned> tmp_vec; tmp_vec.reserve(10000ull); char ctmp; while ( mofile.get(ctmp) ) //std::copy doesn't work here { tmp_vec.push_back( *reinterpret_cast<char unsigned*>(&ctmp) ); } I've had trouble in the past with using "std::copy" to copy raw bytes from a file like this, and I've always had to replace it with a loop that does byte-by-byte reads. Anyone know why the first one doesn't work properly? |
"Öö Tiib" <ootiib@hot.ee>: Feb 11 09:29AM -0800 On Tuesday, 11 February 2020 17:37:03 UTC+2, Frederick Gotham wrote: > return; > vector<char unsigned> tmp_vec; > tmp_vec.reserve(10000ull); I suspect the skipws format flag for the mofile stream is set. So it might be that you need ... mofile >> std::noskipws; ... here. > } > I've had trouble in the past with using "std::copy" to copy raw bytes from a file like this, and I've always had to replace it with a loop that does byte-by-byte reads. > Anyone know why the first one doesn't work properly? I suspect that it skips whitespace. However if that is not the case then check other such annoyance flags of your mofile and/or locale. I may be wrong since I have used same code of ifstream::reading as 4096 byte chunks almost everywhere as long I remember. |
Frederick Gotham <cauldwell.thomas@gmail.com>: Feb 11 01:06PM -0800 > for the mofile stream is set. > So it might be that you need ... > mofile >> std::noskipws; I looked at the differences in "meld" and it has loads of "0x20" bytes highlighted, which is the ASCII value for a space. Looks like you're right. I might try those extra flags when I'm at a PC tomorrow. |
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