- Is this a pseudo code or not? - 2 Updates
- LoopP( !isDigit( Ch ) ); - 4 Updates
- delete pointer type user defined object - 4 Updates
- You should be riding in a little red wagon, not a Ferrari. - 1 Update
- Why is inline function "not working" (like I expected)? - 8 Updates
- "Visual C++ - Microsoft Pushes C++ into the Future" - 1 Update
- "#define" and "goto" are like fast cars. - 2 Updates
- primitive function input/output param encapsulation.. - 1 Update
- Pick the LeastWorst option, and hope for the LeastWorst luck. - 1 Update
- delete pointer type user defined object - 1 Update
| fl <rxjwg98@gmail.com>: Jan 16 10:13AM -0800 Hi, I rarely use C++ template. Recently I find this code snippet interesting at this link: http://stackoverflow.com/questions/26489876/what-is-the-best-practice-for-passing-data-between-threads-queues-messages-or?noredirect=1&lq=1 When I paste it into a C++ project, it gives error: Description Resource Path Location Type 'queue' in namespace 'std' does not name a template type mthread_prj1_sensor.cpp /mthread_prj1_sensor/src line 24 C/C++ Problem Could you tell me how to make this code snippet compilable? Thanks, ..................... /* Thread_safe queue with conditional variable */ template<typename dataType> class CConcurrentQueue { private: /// Queue std::queue<dataType> m_queue; /// Mutex to controll multiple access std::mutex m_mutex; /// Conditional variable used to fire event std::condition_variable m_cv; /// Atomic variable used to terminate immediately wpop and wtpop functions std::atomic<bool> m_forceExit = false; public: /// <summary> Add a new element in the queue. </summary> /// <param name="data"> New element. </param> void push ( dataType const& data ) { m_forceExit.store ( false ); std::unique_lock<std::mutex> lk ( m_mutex ); m_queue.push ( data ); lk.unlock (); m_cv.notify_one (); } /// <summary> Check queue empty. </summary> /// <returns> True if the queue is empty. </returns> bool isEmpty () const { std::unique_lock<std::mutex> lk ( m_mutex ); return m_queue.empty (); } /// <summary> Pop element from queue. </summary> /// <param name="popped_value"> [in,out] Element. </param> /// <returns> false if the queue is empty. </returns> bool pop ( dataType& popped_value ) { std::unique_lock<std::mutex> lk ( m_mutex ); if ( m_queue.empty () ) { return false; } else { popped_value = m_queue.front (); m_queue.pop (); return true; } } /// <summary> Wait and pop an element in the queue. </summary> /// <param name="popped_value"> [in,out] Element. </param> /// <returns> False for forced exit. </returns> bool wpop ( dataType& popped_value ) { std::unique_lock<std::mutex> lk ( m_mutex ); m_cv.wait ( lk, [&]()->bool{ return !m_queue.empty () || m_forceExit.load(); } ); if ( m_forceExit.load() ) return false; popped_value = m_queue.front (); m_queue.pop (); return true; } /// <summary> Timed wait and pop an element in the queue. </summary> /// <param name="popped_value"> [in,out] Element. </param> /// <param name="milliseconds"> [in] Wait time. </param> /// <returns> False for timeout or forced exit. </returns> bool wtpop ( dataType& popped_value , long milliseconds = 1000) { std::unique_lock<std::mutex> lk ( m_mutex ); m_cv.wait_for ( lk, std::chrono::milliseconds ( milliseconds ), [&]()->bool{ return !m_queue.empty () || m_forceExit.load(); } ); if ( m_forceExit.load() ) return false; if ( m_queue.empty () ) return false; popped_value = m_queue.front (); m_queue.pop (); return true; } /// <summary> Queue size. </summary> int size () { std::unique_lock<std::mutex> lk ( m_mutex ); return static_cast< int >( m_queue.size () ); } /// <summary> Free the queue and force stop. </summary> void clear () { m_forceExit.store( true ); std::unique_lock<std::mutex> lk ( m_mutex ); while ( !m_queue.empty () ) { delete m_queue.front (); m_queue.pop (); } } /// <summary> Check queue in forced exit state. </summary> bool isExit () const { return m_forceExit.load(); } }; |
| scott@slp53.sl.home (Scott Lurndal): Jan 16 06:19PM >=E2=80=98queue=E2=80=99 in namespace =E2=80=98std=E2=80=99 does not name a = >template type mthread_prj1_sensor.cpp /mthread_prj1_sensor/src line 24 C/C+= >+ Problem #include <queue> |
| Jeff-Relf.Me <@.>: Jan 16 10:02AM -0800 |
| Jeff-Relf.Me <@.>: Jan 16 10:06AM -0800 |
| Jeff-Relf.Me <@.>: Jan 16 10:13AM -0800 |
| Jeff-Relf.Me <@.>: Jan 16 10:16AM -0800 |
| JiiPee <no@notvalid.com>: Jan 15 11:35PM On 14/01/2017 12:56, kushal bhattacharya wrote: > //after that i push it to vector of this class type(pointer type); > vector.push_back(j); > } In a professional code you would want to use unique_ptr instead of raw pointers. Then the pointer will automatically delete the object and you dont need to worry about it. But if for some reason you want to use raw pointers, then just loop the array and use "delete" to delete each object: like deleting the first object: delete vector[0]; If I was you I would do something like: std::vector<std::unique_ptr<Join>> myVector; and then (if possible) use emplace_back to add the elements. |
| JiiPee <no@notvalid.com>: Jan 16 12:02AM On 15/01/2017 23:53, Stefan Ram wrote: > list. Now, when a new T needs to be added, we will first > check the free list and then possibly use a placement new. > For many cases, not all, this will suffice. But this is more work and in many cases there is no need to optimize like this. I like the idea of unique pointer as it makes it easy... dont need to worry about it. |
| jonkalb <google@kalbweb.com>: Jan 15 04:03PM -0800 On Sunday, January 15, 2017 at 3:36:00 PM UTC-8, JiiPee wrote: > If I was you I would do something like: > std::vector<std::unique_ptr<Join>> myVector; > and then (if possible) use emplace_back to add the elements. A smart pointer such as std::unique_ptr is definitely a better the way to go. There is an even better solution. Don't call new at all and just create a std::vector<Join>. Jon |
| woodbrian77@gmail.com: Jan 16 10:00AM -0800 On Sunday, January 15, 2017 at 6:03:09 PM UTC-6, jonkalb wrote: > > and then (if possible) use emplace_back to add the elements. > A smart pointer such as std::unique_ptr is definitely a better the way to go. There is an even better solution. Don't call new at all and just create a std::vector<Join>. > Jon I think that's often good advice, but it seems to say there's little point for std::unique_ptr. If the class in question, in this case Join, is large enough, using a std::unique_ptr would be a good idea. I'm not sure how large a class has to be for it to pay off. I think it depends on the hardware and OS. I use a unique_ptr with a class that's size is over 170 bytes. That may be too small to justify the use, but there's also the possibility that the size of the class will grow in the future. Brian Ebenezer Enterprises - In G-d we trust. http://webEbenezer.net |
| Jeff-Relf.Me <@.>: Jan 16 09:52AM -0800 |
| Juha Nieminen <nospam@thanks.invalid>: Jan 16 07:12AM > I though inline function is placed in the place of calling and without > creating the temporary function parameters. The 'inline' keyword has absolutely nothing to do with optimization. It's an instruction for the linker (telling it that if it finds that same function in more than one object file, to use only one of them and discard the rest). Some compilers *might* use it as a hint for optimization, but that's just some extra that can't be relied upon. Some compilers might ignore it completely (other than for that linker thing). |
| Wouter van Ooijen <wouter@voti.nl>: Jan 16 08:31AM +0100 Op 16-Jan-17 om 08:12 schreef Juha Nieminen: > It's an instruction for the linker (telling it that if it finds that > same function in more than one object file, to use only one of them > and discard the rest). Where did you get this idea? Wouter "Objects? No Thanks!" van Ooijen |
| JiiPee <no@notvalid.com>: Jan 16 07:33AM On 16/01/2017 07:12, Juha Nieminen wrote: > Some compilers *might* use it as a hint for optimization, but that's > just some extra that can't be relied upon. Some compilers might ignore > it completely (other than for that linker thing). ok, but if think about it... lets say we have an inline funtion: inline int getSum(int a, int b) { return a + b; } and we call it: int x=9, y=8, ret; ret = getSum(x, y); ... for me it does not make any sense for the compiler NOT to do this like: ret = {x + y}; // (*) rather than first creating those two temprorarys a and b and then copy x,y into and this way give the sum. What is a good reason here (as the function is so super small) for a compiler NOT to do like in (*)? I see absolutely no reason for creating those temporaries here especially as the function is so tiny. Somebody give me a good argument please why its better here to create the temporaries (and waste time)? |
| Ian Collins <ian-news@hotmail.com>: Jan 16 09:20PM +1300 On 01/16/17 08:31 PM, Wouter van Ooijen wrote: >> same function in more than one object file, to use only one of them >> and discard the rest). > Where did you get this idea? Because it is just a hint. Its only practical use is for functions defined in headers. -- Ian |
| Jeff-Relf.Me <@.>: Jan 16 07:12AM -0800 |
| Bo Persson <bop@gmb.dk>: Jan 16 05:27PM +0100 On 2017-01-16 08:33, JiiPee wrote: > absolutely no reason for creating those temporaries here especially as > the function is so tiny. Somebody give me a good argument please why its > better here to create the temporaries (and waste time)? No, optimizing the code that way seems like a good idea. The thing is that the compiler likely does all that, whether you add inline to the function or not. The inline keyword is needed if you have the function in a header, but not if it is local to a .cpp file. Bo Persson |
| Wouter van Ooijen <wouter@voti.nl>: Jan 16 05:37PM +0100 Op 16-Jan-17 om 16:12 schreef Jeff-Relf.Me: > I know it works because I can't set a break point there, > on an inline function. See: > https://msdn.microsoft.com/en-us/library/cx3b23a3.aspx The fact that your setup does inline the functions marked as such doesn't prove that the inline keyword is no more than a hint. Wouter "Objects? No thanks!" van Ooijen |
| Wouter van Ooijen <wouter@voti.nl>: Jan 16 05:38PM +0100 Op 16-Jan-17 om 09:20 schreef Ian Collins: >> Where did you get this idea? > Because it is just a hint. Its only practical use is for functions > defined in headers. That it is "just a hint" is 100% correct, but that doesn't have anything to do with the linker. Wouter "Objects? No thanks!" van Ooijen |
| scott@slp53.sl.home (Scott Lurndal): Jan 16 01:40PM >You are referring to CFront version numbers, not language version numbers. The two were, of course, one and the same at the time. |
| Jeff-Relf.Me <@.>: Jan 15 10:18PM -0800 |
| David Brown <david.brown@hesbynett.no>: Jan 16 08:46AM +0100 On 16/01/17 07:18, Jeff-Relf.Me wrote: >> Please stop spamming your shit to this newsgroup. > "#define" and "goto" are like fast cars; > Yes, they're dangerous, but I _love them anyway. No, they are nothing like fast cars. #define has its uses - but what you write is abuse. It is obfuscation. > The code I post here not for you, or anyone else, > but for myself, so I can think about it, and change it; > I'm changing it now, and continue doing so. Since your code is not meant for anyone else, and everyone else thinks it is hideous (I honestly thought your "style guide" was a humorous list of every bad idea you could imagine), just don't post it. People who are experienced programmers will immediately reject your mess, but it's possible that people new to C++ might think this is what code is supposed to look like. |
| Juha Nieminen <nospam@thanks.invalid>: Jan 16 07:06AM >> Structured bindings have nothing to do with "returning multiple values >> from a function". > Forks have nothing to do with eating. If you count structs as "returning multiple values from a function", then you have been able to do that since C++ was invented. It has nothing to do with C++17. |
| Jeff-Relf.Me <@.>: Jan 15 08:06PM -0800 |
| ram@zedat.fu-berlin.de (Stefan Ram): Jan 15 11:53PM >But if for some reason you want to use raw pointers, then just loop the >array and use "delete" to delete each object: If one wants raw pointers, one still can often get by without new and delete. One just emplaces the new T objects to the end of a vector< T >, and then one can take the address of the new T entry (and possibly then append that to the end of another vector of raw pointers). Optimization: When individual entries should be deleted before the whole array is deleted, their destructor can be called and then their address can be added to a free list. Now, when a new T needs to be added, we will first check the free list and then possibly use a placement new. For many cases, not all, this will suffice. |
| 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