C / C++ / MFC

You have declared marks as a 2 element array, but your loop runs 3 times. for (int k = 0; k <= 2; k++) { // <-- this will run three loops cout << "Enter Student NO " << i + 1 << " Subject " << k + 1 << " Marks : \t"; cin >> Student[i].marks[k]; // when k == 2 you are overwriting unallocated memory if ((Student\[i\].marks\[k\]) < 40) { failSubjects++; } } It should be: for (int k = 0; k < 2; k++) { // k must be only 0 or 1

See 21. Internet Protocols and Support — Python 3.3.7 documentation[^].

Thanks for your reply. In the client side: I used OnReceive() and a timer variable which is reset to zero in that function. In a separate thread of 1 second frequency, I increment the timer variable to one. So every one second the timer variable is incremented but it is reset to zero in the OnReceive since the data is received in OnReceive() which is sent by the server every second. When the timer variable exceeds 30 counts, it is elapsed. When the timer is elapsed, I closed the client socket using shutdown and deleted the socket. But When I tested the Server and the client, the server hangs after some 2 hours. Previously my client got hanged or lost connection. Any suggestion, why the server is getting hanged this time?

It is how you should use/implement it: [WorkerThreads](http://www.flounder.com/workerthreads.htm)

Have you tried this: Working with Excel in MFC[^] ? It is working ?

I think, this will not work for my solution. Anyways, let me try.

I've done cooperative multitaskers on a number of platforms (not ARM, but I don't think it should present any unusual problems) and found them to be extremely handy in cases where the set of tasks is fixed. Even if a task would spend most of its time in a loop: while(!x\_ready) task\_spin(); the cost to switch to the task, check x_ready, and then switch to the next task may be less than the cost of a more complicated scheduler trying to decide if it should switch to that task. The biggest design issue with a cooperative task switcher is deciding what invariants are going to hold any time code does a task_spin(). While a preemptive multitasker would require that functions acquire locks before breaking any invariant even temporarily, and re-establish the invariant before releasing the lock, cooperative task switching doesn't require that. More significantly, it doesn't require that tasks do anything special to handle the fact that a lock isn't available. The gotcha is that if an invariant can't be upheld during some operation, and the time required to perform that operation could grow beyond the maximum amount of time one wants to go without a task_spin(), handling that situation may be complicated.

You can iterate over the keys and check for known virus scanners. Have a look here how to do this in C++: Enumerating Registry Subkeys (Windows)[^]

Which one is more secure coding language c or c++? To know more visit Ask a Question[^]

To write code for enabling DHCP using win32 API visit Hp printer support . I am sure that if you know windows programming then you can able to write this code.

That's the thing with parallelism, it never does what you expect.

Sorry, my description was not elaborate. I updated the error. But I found out the reason and posted it below. Jesus saves

What you want is called an "owner drawn" combobox. There's a great article right here on CP that explains how to do it with all the code you need: Implementing an OwnerDrawn ComboBox[^] And by the way, you posted this in the C++ forum instead of the C# forum where it belongs. :) The difficult we do right away... ...the impossible takes slightly longer.

I don't think "register" is a good term to describe a system's smallest addressable storage unit. If you don't like "byte", I'd suggest "smallest addressable storage unit" would be a precise term. In any case, I was responding to the claim that the size of a uint32_t is "set in stone" at four bytes for all conforming implementations, which a reasonable person might interpret as saying that sizeof (uint32_t) is required to be 4. I think it's rather silly that the Standard defines no category of programs between Strictly Conforming programs, a category so narrow as to be almost useless, and Conforming programs, a category so broad as to be essentially meaningless, and only defines two categories of implementations, either of which would be allowed (because of the "One Program" loophole) to behave in arbitrary fashion when given almost any program. If the Standard sought to actually categorize things usefully, separating out common-integer-size implementations from weird-integer-size implementations would make a lot of sense. Unfortunately, the authors of the Standard seem to go out of their way to avoid suggesting that some implementations should be considered inferior to others.

You are welcome.

you need to love it, you need to have fun while solving problems, you need to have patience and open mind, you need to be regular, you need lot's of practice and good books, and the rest will follow. that's what i have experienced till date.