| Doug Mika <dougmmika@gmail.com>: Aug 10 05:00PM -0700 On Monday, August 10, 2015 at 5:26:58 PM UTC-5, Bo Persson wrote: > atomic& operator=(const atomic&) = delete; > atomic& operator=(const atomic&) volatile = delete; > Bo Persson so which operator is used to assign a bool to an atomic, as in my case above? |
| Ian Collins <ian-news@hotmail.com>: Aug 11 01:14PM +1200 Doug Mika wrote: >> atomic& operator=(const atomic&) volatile = delete; >> Bo Persson > so which operator is used to assign a bool to an atomic, as in my case above? atomic& operator=( T ); -- Ian Collins |
| Juha Nieminen <nospam@thanks.invalid>: Aug 11 08:10AM > atomic<bool> b(true); > b=false; //assignment operation which relies on the overloaded copy assignment operator. > What is copy assignable and which operator does it rely on? "Copy-assignable" means that you can assign one instance to another. In other words: std::atomic<bool> a(true), b(true); a = b; // error --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Vir Campestris <vir.campestris@invalid.invalid>: Aug 11 09:49PM +0100 On 11/08/2015 09:10, Juha Nieminen wrote: > "Copy-assignable" means that you can assign one instance to another. In other words: > std::atomic<bool> a(true), b(true); > a = b; // error Presumably a = static_cast<bool>(b); would work - extracting to a non-atomic in the middle? It would not of course be atomic... Andy |
| Richard Damon <Richard@Damon-Family.org>: Aug 10 10:48PM -0400 One way to process the last item differently is have the loop provide the value for the NEXT loop, process the item from the last loop (skipping if this is the first time), and then moving the value to the variable to remember it for the next loop. You then process the last item after the loop. Not sure if this is cleaner than a numeric loop, but sometimes you don't really know you are on the last item until after you have gotten it (like detecting the end of file after it). |
| Gert-Jan de Vos <gert-jan.de.vos@onsneteindhoven.nl>: Aug 11 03:59AM -0700 How about this: void f(const vector<T>& vec) { for (auto& e : vec) { if (&e == vec.front()) HandleFirst(e); else if (&e == vec.back()) HandleLast(e); else HandleCenter(e); } } |
| Juha Nieminen <nospam@thanks.invalid>: Aug 11 02:01PM > for (auto& e : vec) > { > if (&e == vec.front()) You are comparing a pointer to a value of type T. --- news://freenews.netfront.net/ - complaints: news@netfront.net --- |
| Gert-Jan de Vos <gert-jan.de.vos@onsneteindhoven.nl>: Aug 11 08:22AM -0700 On Tuesday, 11 August 2015 16:01:25 UTC+2, Juha Nieminen wrote: > > { > > if (&e == vec.front()) > You are comparing a pointer to a value of type T. Indeed, I meant this: void f(const vector<T>& vec) { for (auto& e : vec) { if (&e == &vec.front()) HandleFirst(e); else if (&e == &vec.back()) HandleLast(e); else HandleCenter(e); } } |
| ram@zedat.fu-berlin.de (Stefan Ram): Aug 11 11:09AM > HandleFirst(e); > else if (&e == vec.back()) > HandleLast(e); In the case of a vector with exactly one component, this applies »HandleFirst« to this component, but not »HandleLast«, because of the »else«. |
| ram@zedat.fu-berlin.de (Stefan Ram): Aug 11 11:26AM > HandleLast(e); >else > HandleCenter(e); Also, if these are really to be three function calls, it is somewhat simplified, because often more values than just »e« will need to be passed. Moreover, often »HandleFirst«, »HandleLast« and »HandleCenter« will share a lot of code, so a either a lot of code will have to be trebled or even more functions will have to be introduced to take the common code and even more arguments will have to be passed. |
| ram@zedat.fu-berlin.de (Stefan Ram): Aug 11 03:02PM >. However, having to write >[]( int const i, bool const isfirst, bool const islast ) >in the client of »foreach« is rather cumbersome! I underestimated the type inference capabilities of C++14! Actually the above /can/ be abbreviated omitting the types. template< class T > void test( T const container ) { ::std::cout << "[ "; foreach( container, []( auto i, auto isfirst, auto islast ) { ::std::cout <<( isfirst ? "" : ", " )<< i <<( islast ? "." : "" ); return true; } ); ::std::cout << " ]\n"; } Now, we do not have that much overhead in the loop anymore. The header of the loop now is: foreach( container, []( auto i, auto isfirst, auto islast ) Compared to for( auto i: container ) the largest part of the overhead is »auto isfirst, auto islast«, but this is made up by the additional feature of indicating the first and the last iteration. The implementation of »foreach« can be used unchanged as in the preceding post. Here is a simple main function with its output: int main() { test( ::std::vector< int >{} ); test( ::std::vector< int >{ 4 } ); test( ::std::vector< int >{ 7, 9 } ); test( ::std::vector< int >{ 8, 2, 9 } ); } [ ] [ 4. ] [ 7, 9. ] [ 8, 2, 9. ] |
| "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com>: Aug 11 02:47PM +0200 > With C++11, I had thought to use unique_ptr, but the deleter on unique_ptr is calling > the standard delete, not array delete, even though the "new" underneath is allocating > an array explicitly. No, it doesn't do that. Your code should look like this: unique_ptr<float[]> data( thirdParty.getData() ); Was it? [snip] > { > std::unique_ptr<float> (goo()); // Calls wrong deleter > } Oh, it wasn't. Well then. --- Additional info: The deleter of unique_ptr is customizable in two ways: * By specializing default_delete (or whatever it was called) for a type. * By providing a deleter argument to the constructor. It's worth having in mind that with unique_ptr, as opposed to shared_ptr, a deleter is not stored with type erasure, and so effective casts of a unique_ptr can cause a custom deleter to be called with incorrect pointer value, due to static_cast changing the address. Cheers & hth., - Alf -- Using Thunderbird as Usenet client, Eternal September as NNTP server. |
| 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