Comments by David Serrano Martínez

David Serrano Martínez 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 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 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 13-Nov-13 7:22am View

Checked. Exacty the same. Template parameters are correctly resolved.

David Serrano Martínez 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 22-Mar-13 10:55am View

Written. Now it is your turn...

David Serrano Martínez 12-Mar-13 3:11am View

Not necessary for me. This conversation itself suffices. Thank you.

David Serrano Martínez 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 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 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 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 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 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>.

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