|
I need to turn in by December 9th 4 programs and i don't know how to do them,,,they are for my introductary C++ class. they are very small...i am willing to pay if someone writes them for me,,,i need the programs to pass this class!
|
|
|
|
|
Cheap man Cheap, those programs are for you to learn c++ programming.
My God is more powerfull Than Your God.
|
|
|
|
|
What precisely do you need?
Phil
|
|
|
|
|
if they are so small and easy you can probably find them on the internet or, and this is just a crazy thought, actually take the time to do some studying and make them you self. How about that eh?
Er zit een korstje op mijn aars.
|
|
|
|
|
Pardon me for being obtuse, but isn't there a reason you're required to pass this class? Isn't it part of a degree program that (eventually) may lead to a job programming stuff? Or is it merely one of those elective things you're expected to do to round out your experience?
If you don't know how to do the programs by this stage of the term, you don't deserve to pass. When the school hands out a passing grade it is, in effect, issuing a guarantee that you have certain skills, and employers are entitled to depend upon that assumption. By attempting to circumvent actual learning and replace it by cheating, you are hurting not only yourself and your future employers, but are also reducing the credibility of your school.
If you can't do it, withdraw and take the class again, and earn a fair grade. Alternatively, you might consider changing majors to earn a degree in something that really interests you, or that you can grasp. Programming is much like Accounting - it can be boring, but it is also very complex at times. If you don't have the knack for it you really should move on to something that really excites you. It's not for everyone...
I wish you the best of luck, but buying grades is not a good way to acheive your goals. In the long term it will always backfire on you.
"Your village called - They're missing their idiot."
|
|
|
|
|
Roger Wright wrote:
buying grades is not a good way to acheive your goals
Even if he's planning to be a manager?
A quoi rêvent les personnes qui nous font vivre ce monde ?
|
|
|
|
|
I suppose there may be a few exceptions... Lawyer, politician, used car saleman - the slimeball professions.
"Your village called - They're missing their idiot."
|
|
|
|
|
My old CS teacher always said to class "Some of you should become a cab driver instead".
I know at least 3 who took his advice.
--
He is the painkiller. This is the painkiller!
|
|
|
|
|
Hi, there... I’m now getting a problem:
In my current Winsock2-based application, I need to deliver lots of data from the Server side to more Client sides via the UDP multicast mode. However, one or more Client sides cannot receive some data blocks sometimes After a hard debug process, I found the program is: the Server multicasts the data too fast, and the Client cannot receive all the sent blocks of data in time, i.e., the process speed of Client is more slower than the Server, some block of data is overcastted by the next block before the Client gets it At this time, to avoid this, I delay some time using the Sleep API after each block of data sent on the Server side.
Though that’s not a best way, it works. But another program brings out – It’s hard to know how long I exactly delay: if the delay is too long, the more unnecessary time used to deliver; if it’s too short, some Clients may still lost some blocks of – It’s just hard to control the delay time after each block of data sent
Does anyone can tell me another better way to synchronize the speed of sending and receiving data on both Server side and Client sides?
Thanks!
|
|
|
|
|
UDP is a poor choice if this is critical data. There is no way to predict how long it will take for some clients to receive the data because, by definiton, UDP makes no guaranteee that any of them will. It's strictly a "best effort" protocol - fire and forget. You could require a response from each client after each packet, but even that doesn't guarantee that you'll get reliable transport; some of the responses may also get lost. You could also require an acknowledgement from each client and analyze the round trip time to adjust your timer value - it might help. TCP is designed to overcome this problem, though, and would be your best choice.
"Your village called - They're missing their idiot."
|
|
|
|
|
Agree fully with what Roger said. If you find yourself having to re-invent synchronisation and error checking as part of using UDP, then you might as well use TCP - thats what it provides. If, however, you really do need to use UDP then I suggest taking a look at what other people have done. I cant remember anything off the top of my head other than mbone, but I recall their being several projects on Sourceforge relating to broadcasting video and such like. These people will need to have dealt with the same problems as you, so it's worth taking a look.
|
|
|
|
|
Well, big thanks to Roger and Johnny...
Now, I'm searching something useful on SourceForge.net...
|
|
|
|
|
|
I am looking for a simple Multithreaded Quicksort on the web. So far I have found this one but I get memory error for large arrays and the algorithm seems inefficient it uses as much as 2000 threads!
I am looking for a simple Multithreaded QuickSort with 2(or more) threads.(Yes, I want to take advantage of Hyper-Threaded processors )
Thanks for your help in advance.
Rob
|
|
|
|
|
Robert Buldoc wrote:
I am looking for a simple Multithreaded Quicksort on the web.
If you have only one CPU then it is impossible to make sorting faster by using multiple threads. Even if you know that you have n (>1) CPUs dedicated for sorting your data, you will have to use a better algorithm than QuickSort. The problem is, the QuickSort algorithm does not guarantee that it will finish the sorting in fixed number of comparisons (it depends on the values of the data items). Usually, a multi-threaded sorting algorithm divides the data into n equal subsets, sort each subset, and then merge the result. With QuickSort, one subset could take considerably longer to sort than the others.
BTW, I have never done multhreaded sorting myself, so I could be totally wrong on this.
My articles and software tools
|
|
|
|
|
Quick question...
I'm trying to change the Extended Styles on a CListCtrl. so that when an Item is selected
the entire Row is selected. I'm doing this in the OnInitDialog of a dialog class.
The following works for changing the normal Styles:
CListCtrl *pListCtrl = (CListCtrl *)GetDlgItem(IDC_LIST1);
LONG lStyle = GetWindowLong(pListCtrl->GetSafeHwnd(),GWL_STYLE);
// Changing the view on the CListCtrl to REPORT view
lStyle |= LVS_REPORT;
SetWindowLong(pListCtrl->GetSafeHwnd(),GWL_STYLE,lStyle );
Anyone know why the following won't work:
LONG lExStyle = GetWindowLong(pListCtrl->GetSafeHwnd(),GWL_EXSTYLE);
// Also Tried -> LONG lExStyle = pListCtrl->GetExStyle();
lExStyle |= LVS_EX_FULLROWSELECT;
SetWindowLong(pListCtrl->GetSafeHwnd(),GWL_EXSTYLE,lExStyle );
Please help..
It's driving me crazy..
|
|
|
|
|
Use pListCtrl->SetExtendedStyle(LVS_EX_FULLROWSELECT);
Hey how about taking a look at this article[^]? I believe you will find something useful.
|
|
|
|
|
Thanks for the help it worked like a charm..
You know what, I am soooo blind.. this is why you should not code when you're juiced-up on Mountain Dew and Starving.. The pointer that I was using to access the CListCtrl from GetDlgItem() was a (CWnd *) and not a (CListCtrl *). That's why I couldn't access those CListCtrl functions... Let that be a lession to you guys.. Don't Code while your brain is mush...
Thanks Again..
|
|
|
|
|
how can I transmite voice data to peer and restore it to a wave file at the same time. Having finished the two tasks separately,but I can't combine them into one project
|
|
|
|
|
Hi,
I need a little help here from the community members, I'll appreciate if you share any information about this problem if you saw it and tried to fix it or actually fixed it. The product I am working on invloves OpenGL APIs, but
1) On Windows XP
2) and on all kinds of Graphics cards we have (Nvidia, Wild Cat) here at the office
Windows desktop tooltips get completely garbled after a call to wglMakeCurrent function. As soon as the window whose DC was used in wglMakeCurrent call is destroyed, the tooltips come back.
By tooltips getting garbled, I mean that hovering mouse over program buttons in the taskbar would show wrong information for running programs, the tooltip window's size would be either smaller than the size the tooltip's text can fit in, or too much large showing the extra area as shadow or black color.
Any hints.. ideas?
Yawar
|
|
|
|
|
I have a function in my tcp server that starts a thread to try and stop the server, i'm using a thread because when the server stops, things have to be removed from a list of clients, and so it cant block the message queu or i cant use SendMessage(). The problem is that when i test, by connecting via telnet, and stop the server while the client is connected, WaitForMultipleObjects() usually returns WAIT_FAILED with error code 6 (Invalid handle). Only the first time i stop the server it sometimes works ok. But after that its always WAIT_FAILED. HEre's the code to the stopper thread:
DWORD WINAPI StopServerThread(void* prms)
{
HWND hWnd = (HWND)prms;
HL thread;
HLI hli;
int result=0;
shutdown(sListener,SD_BOTH);
closesocket(sListener);
if(client.size()>0)
{
DWORD err;
for(cli=client.begin();cli!=client.end();++cli)
{
thread.push_back((HANDLE)(*cli)->ThreadHandle);
}
if(!WSASetEvent(hSuicideEvent))
MessageBox(hWnd,"WSASetEvent() failed","Error",MB_ICONERROR);
result = WaitForMultipleObjects( thread.size(), thread.begin(), TRUE, 5000 );
switch ( result )
{
case WAIT_TIMEOUT:
ConsoleOutput("Not all threads died in time");
break;
case WAIT_FAILED:
err = GetLastError();
ConsoleOutput("WaitForMultipleObjects(): WAIT_FAILED (%i)", (int)err);
break;
default:
ConsoleOutput("All client threads terminated successfully");
break;
}
for ( hli = thread.begin(); hli != thread.end(); ++ hli )
CloseHandle( *hli );
client.clear();
thread.clear();
}
DeleteCriticalSection(&lpCritSection);
WSACloseEvent(hSuicideEvent);
bIsRunning = FALSE;
HMENU mainmenu = GetMenu(hWnd);
EnableMenuItem(mainmenu,IDM_START,MF_ENABLED);
EnableMenuItem(mainmenu,IDM_STOP,MF_GRAYED);
ExitThread(0);
return 0;
}
client is a list of client information, also containing the thread handles of each client thread. Weird thing is that the client threads DO exit and all, everything works fine except that WaitForMultipleObjects starts to return WAIT_FAILED. Anyone have any idea why?
Thanks
Kuniva
--------------------------------------------
|
|
|
|
|
I was getting this problem a couple of years ago. It was very frustrating until I read the chapter on threading in Jeff Prosise's book Programming Windows with MFC.
If the threads were created using AfxBeginThread which returns a CWinThread* then what is happening is that when at least one thread finishes the CWinThread is automatically deleting the thread handle which will cause WaitForMultipleObjects to return failed because at least one handle is invalid (closed). One way to resolve this is to create the thread suspended, duplicate the handle, and finally resume the thread. This means that the duplicate handle will be valid until YOU close it. Here is a simple code snippet:
CWinThread* pThread = AfxBeginThread(ThreadFunc, lpData, THREAD_PRIORITY_NORMAL, 0, CREATE_SUSPENDED);
::DuplicateHandle(AfxGetProcess(), pThread->m_hThread, AfxGetProcess(), &hThread, 0, FALSE, DUPLICATE_SAME_ACCESS);
pThread->ResumeThread();
...
...
::WaitForMultipleObjects...
::CloseHandle(hThread);
This is VERY abbreviated code but it should give you the general idea.
Kelly Herald
Software Developer
MPC
|
|
|
|
|
Hi! Thanks for replying I think you may have a point here, even though i'm not working in MFC, but i think there might be the possibility that the thread handle is closed before i call WaitForMultipleObjects() so i'll now try DuplicateHandle() and see if that works. Thanks!
Kuniva
--------------------------------------------
|
|
|
|
|
Yes! this fixed it, thanks!
Kuniva
--------------------------------------------
|
|
|
|
|
I hope HL is a typedef for vector< HANDLE > . Only vector among the STL containers guarantees that all contained items are contiguous (i.e. at adjacent memory locations), which is what WaitForMultipleObjects requires.
|
|
|
|
|