I've been working with some code that uses a TCP connection for the past few weeks. I have a socket class derived from CAsyncSocket.
Everything works fine initially. I instantiate my manager class which wraps around the socket class and calls connect (via a member pointer to the socket class). I am then able to send a receive data. The problem comes when there is a socket error. For a currently unknown reason, part of my code is causing a socket error. I have yet to find where this is happening but the problem forced me to test out the part of my code which shoudl attempt to recover the connection. It doesn't work, and I can't get things going.
I have overriden OnClose, which calls a method on the manager class (its parent) called OnSocketClose. This calls socket.shutdown(), socket.close() and 'delete socket'. It then sets the pointer to 0. From here, the next time I attempt to send anything down the socket it looks for the socket pointer == 0, to indicate that it should create a pointer to a new socket.
This new socket is created but fails to connect. I have got it to appear connected on a couple of occasions by moving things around but OnConnect doesn't seem to get called and I am unable to send data. The returned value from socket.connect however reports that the socket is already connected if I call socket.connect again, after a short period of time from the first call to connect (socket error 10056).
Apologies if this sounds a little confusing, but I think I have managed to confuse myself... massively
If it will help, I can post code? Just let me know which parts you need to see.
Thankfully, I have managed to solve this issue so thought I would post the solution in the hope that it might help someone else with the same problem.
The problem (rather annoyingly) came because the socket was being created initially on the main thread, but was later being created again (after the socket was destroyed because of a connection error) on a worker thread. This meant that the On* callbacks weren't being implemented, and so I got no feedback from OnConnect and didn't receive any data because OnReceive was never being called.
As soon as I managed the socket entirely from the main thread, everything was fixed
I am doing program in c++ . But I faced some problem to create dsn dynamically using SQLConfigDataSoure function. It does not create dsn...
Here is my following code
CString strAttribute ;
strAttribute.Format (_T("DSN=DSNPREVIOUSLOG\\0 FIL=MS Access\\0 UID= \\0 SafeTransactions=0 \\0DBQ=%s\0"),strDest);
SQLConfigDataSource(NULL,ODBC_ADD_SYS_DSN,_T("Microsoft Access Driver (*.mdb)"),strAttribute);
it returns false...
kindly help me ...
Thank u in advance
I'm trying to animate a box moving from point A to point B. I'm using a .Net timer to
animate but I'm not sure on the math to get the box moving in a straight line. So far
the box finishes moving down before it finishes moving to the right.
I'm not very good at math but I'm thinking the equation should be straight foreward?
4. Change the box position by the given step in each timer tick. Because the steps are rounded down (see step 3) you should also store the end position you want to get to and move the box there in the last step (not too elegant, but it will get the job done without anyone noticing).
Sure hope this helps, but seriously if this math is too complex to figure out you've got a long way to go my friend. Best of luck to you.
This is what's called the explicit function for a straight line, meaning that you calculate one coordinate based on the value of the other coordinate. The explicit representation comes with a few shortcomings that can be confusing at times when you deal with 2D geometrical elements. For example you wouldn't be able to draw a vertical line with an equation like what you posted! Also, for near vertical lines you'd have to take care what values of x would produce a valid y - you'll find that most values of x that lie well within the screen corrdinate range will produce y values that are way outside the screen.
The implicit representation avoids this confusion, but it is often much easier to use the parametric representation: In this case, you have two points, A and B. The parametric representation of a line through these two points is:
P(t) = A + t*(B-A)
. This equation is in fact a set of equations, referring to the two coordinates, x and y:
If you implement a function to calculate P(t), using the formulas above, each value of t will yield a point P(t) somewhere on this line. For t==0 you will find that P(0)==A, and for t==1 you will find that P(1)==B.
Of course, you have to be careful with these calculations when dealing with pixel coordinates: you have to convert these coordinates to float values first, or else the rounding effects may lead to some unexpected results.
I know that the cbegin()/cend() and such methods were implemented to allow for easy const type inference, but I'm curious as to why there wasn't any equivalent added for find()? Also, there isn't a real easy way to "trick" auto into inferring a const version, is there?
Although it doesn't show itself as non-mutating in code, all I can think to do is use a const ref/pointer to the container, which would "force" a const_iterator return, right?
However, I really like how cbegin() clearly states it's const-ness, right where it's being used.
I've searched around off and on, looked through the (what I think is) the original proposal paper, nothing seems to hint as to why poor find() got the const-shaft.
The problem with find is that it's not a member function, and the const-ness of its return type depends on the const-ness of its arguments. If you call find with a search range defined by const_iterator's, the return type will be a const_iterator, whether you like it or not. Similarly, if you tried to define a cfind() function that should return a const_iterator even if the arguments defining the range are non-const iterator, then you're facing the problem of how to derive the former type from the latter - it's impossible!
For begin and end it's different: their return types are derived from the list object, and it's easy to derive both iterator and const_iterator from the list type. find() has no such base type to refer to.
Sorry, I should have been more specific. Rather than general containers (some of which, you're right, have to use the find function) the map/set and the new unordered ones. They do have a member function, so could quite easily do the same thing as cbegin()/cend(), at least I can't see any reason why not.
For the not-to-const, I don't exactly follow. Gonna go play a bit to see what you mean.