Click here to Skip to main content

Comments by David Serrano Martínez (Top 13 by date)

David Serrano Martínez at 15-Mar-14 14:19pm View
   
It is quite difficult to find an answer with only fragments of code. Maybe the problem lies in the notification part. Perhaps notify_one is never reached. I suppose "tpool->find(msg.source(), mobile_id.to_string(), t);" invokes some t methods. Are you sure after those invocations the mutex in t is properly released?
David Serrano Martínez at 15-Mar-14 8:47am View
   
Your implementation seems the canonical one, as described in:
http://www.boost.org/doc/libs/1_55_0/doc/html/thread/synchronization.html#thread.synchronization.condvar_ref
The only difference is that you get out of scope with a goto jump. Does it anything to do with your unique_lock correctly going out of scope? I really do not know. Perhaps you will have to try some little alternatives in order to figure out what it is going on.
David Serrano Martínez at 13-Nov-13 8:06am View
   
Thanks. After replacing "using" with "typedef", the (bad) behavior is the same. Maybe it could be a problem with g++ v.4.8.1-4.
David Serrano Martínez at 13-Nov-13 7:22am View
   
Checked. Exacty the same. Template parameters are correctly resolved.
David Serrano Martínez at 31-Mar-13 7:39am View
   
Are you sure your objective is properly stated? You should link a date of birth for each one of your students. So definitely creating a structure for holding your five students and another structure for holding a unique date of birth is a bizarre design to me.
 
You will also find multiple compilation errors. For instance, data() needs three arguments, not two. You are passing values to data() by value, not by reference and, inside data, you can set only one date of birth (????).
 
Please, reconsider what is exactly what you are trying to achieve with your code.
David Serrano Martínez at 22-Mar-13 10:55am View
   
Written. Now it is your turn...
David Serrano Martínez at 12-Mar-13 3:11am View
   
Not necessary for me. This conversation itself suffices. Thank you.
David Serrano Martínez at 11-Mar-13 15:32pm View
   
Hi Lukasz!
 
For your information. The solution also works without the use of store(...). For instance: instead of store(std::forward<...>(...)), it works by typing std::forward<...>(...), so the code simplifies even more.
 
Greetings.
David Serrano Martínez at 4-Mar-13 6:46am View
   
Where it reads t="", it must read T. Unable (twice) to write a well formatted answer :-(
Delete and other possible garbage.
David Serrano Martínez at 3-Mar-13 5:33am View
   
After some trials, it seems it works with const arguments by substituting:
 
typename std::remove_reference<U>::type>::value, int>::type=0
 
for
 
typename std::remove_const<typename std::remove_reference<U>::type>::type>::value, int>::type=0
 
Unfortunately I have not found any std::remove_const_reference<> to simplify things a little bit.
 
With this tiny change, I consider your solution accepted ;-).
 
Thanks again.
David Serrano Martínez at 3-Mar-13 3:07am View
   
Absolutely brilliant piece of metaprogramming! I have learnt a lot with your reply. Great work!
The main drawback is that this solution is quite difficult. I have been going over your code for a long, long time till I finally have understood ;-)
 
After doing my own checks, I have verified both solutions (four constructors and two constructors) are not exactly equivalent. Try this slightly changed main:
 
int main()
{
 
my_class c1( (A()), (B()) );
my_class c2( (A()), (C()) );
A a;
const B b;
const C c;
my_class c3(a, b);
my_class c4(a, c);
}
 
Seemingly std::remove_reference does not remove also constness. Any suggestions?
 
Thank you for such an elaborated answer.
David Serrano Martínez at 10-Feb-13 4:50am View
   
I have used boost::asio for a one to one server/client TCP/IP communication, but using only syncronous reads and writes in different execution threads. My experience has been good. It works. I did not used asyncronous calls because I never got a good grip on the matter. (I compiled with VS2005, by the way).
David Serrano Martínez at 2-Feb-13 6:43am View
   
Leaving apart all the garbage Sergey has pointed out, I think this is the crux of the problem. const_iterator is a dependent, qualified type.
It is dependent because it depends on template parameters (T and A) and it is qualified by the presence of "::".
Without using typename, the compiler could interprete const_iterator as a static variable into map<T,A>.

Advertise | Privacy | Mobile
Web01 | 2.8.140721.1 | Last Updated 1 Jan 1900
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid