|
farklem@gmail.com wrote:
the application tends to crash
"Tends to crash" is a bit vague What's the error exactly? An exception? What exception? Where?
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
I get the error: "Access violation reading location 0xcccccccc"
Its really not the error that bothers me but the time it takes to transfer such a small amount. I don't know of a proper way to write this code because I haven't found any good examples of something like this.
|
|
|
|
|
farklem@gmail.com wrote:
I get the error: "Access violation reading location 0xcccccccc"
Which still doesn't give us much information...
What happens when you break into the debugger after the exception? What is shown in the call stack? At what point in your code was the problem?
In any case, looking again at your code, I noticed this:
while(recv(ClientSocket, xrec, 2048, 0) > 0)
{
FILE *fp;
fp = fopen("C:\\TestFile.dat", "ab");
fprintf(fp, xrec);
fclose(fp);
memset(xrec, 0x0, 1025);
}
If you are receiving binary data, it doesn't make sense to use fprintf , which will treat xrec as a null-terminated char string. It will stop at the first byte with zero. It may encounter a zero way before the end of the buffer, or worse, way after the end. Further, if it happens to find what it thinks is a format specification (e.g.: %d, %s, etc.) it will try to extract an additional parameter from the stack and very bad things could happen. Even if you are using this for text files, I don't think recv will put a null terminator after each fragment it reads.
You should a) use the return value from the recv function to know exactly how many bytes were copied to the buffer (and so how many to write to the local file), and b) write to the file with a function that can handle binary data, like fwrite(xrec, 1, nBytesReceivedWithRecvFunction, fp) .
Also, avoid using "magic numbers" (like 2048, 1025, etc.), specially if you use them more than once in the code. Use defines, or better yet, const int variables. That way, if you need to change a value, you can be sure the new value will be used everywhere it's needed. For example, why are you reading from the socket up to 2048 bytes in each iterations and then resetting the memory for the first 1025? I don't think you need to reset the buffer before each read, but if you actually needed it, you would be doing it wrong. Seems like you changed the buffer size and forgot to update the resetting?
Those problems can be avoided if you simply declare a const int nBufLen = 2048; and use nBufLen wherever you need to refer to the buffer size.
Hope that helps,
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Thank you so so much!!! BTW, the reason I didn't post the entire error code is because this is running on an xbox and it confuses lots of people to see the errors when they aren't used to them. Here is what I changed based on your recomendations:
#define BufLen 2048
FILE *fp;
fp = fopen("D:\\wow.map", "wb");
int BytesRecieved = 1;
while(BytesRecieved)
{
BytesRecieved = recv(ClientSocket, xrec, BufLen, 0);
fwrite(xrec, 1, BytesRecieved, fp);
memset(xrec, 0x0, BufLen);
}
fclose(fp);
I'm not sure if you have any recomendations for making this faster but i'm open to suggestions. Currently it takes about 30 seconds to send a 15 mb file (thats not too bad but there are going to be lots of 400 meg file transferes going on).
|
|
|
|
|
Actually the code is basicly just fine, it has something to do with the way i'm doing it on the xbox I guess. I made a console app on the PC using the exact same code and it takes less than 2 seconds to transfere to another computer even though it takes over 35 seconds for the xbox to recieve the file.
Again thanks for the help
|
|
|
|
|
can anyone teach me how to use a listbox using GLUI and how to get the item from a listbox.
|
|
|
|
|
|
Hello,
Can anybody help me to create a list control with a tree view support?
Thank you!
|
|
|
|
|
|
I need to create a text link to a site in a dialog box. I have seen in many windows aplications it is a blue text and on mouse press an iexplorer window opens with the link in the address bar.
I know how to open an explorer window but I don't know how to create the text and the event listener that will underline the text and will listen to mouse clicks.
Any help will be apreciated.
I have a dialog based application in visual studio 6.
Thanks,
dragulceo.
|
|
|
|
|
|
Thank you very much ... that's what i'm looking for!
|
|
|
|
|
|
i want to make a game that can be run on two or more computers where the users can play each other (like an instant messaging game). how can i do this??
any code websites or information that can show me how to do this would be greatly appreciated.
thank you in advance for your help.
- Kyle
|
|
|
|
|
I have a problem whith change type
code like this:
for(int j=0;j<=str.list.GetCount();j++)
{
this->lst.AddTail(str.list.GetAt(j));
}
: error C2664: 'class CString &__thiscall CStringList::GetAt(struct __POSITION *)' : cannot convert parameter 1 from 'int' to 'struct __POSITION *'Conversion from integral type to pointer type requires reinterpret_cast, C-style cast or function-style cast
Error executing cl.exe.
can anyone help ~
thanks in andvance~~
nothing
|
|
|
|
|
|
Lists don't have indexed access using int, as arrays do. Instead you can iterate and access elements through POSITIONs. Internally, a POSITION is just a pointer to one of the list nodes, which in turn points to the actual data, but it's better if you avoid considering the internal details and just use it as an abstract POSITION, regardless of implementation details.
Iterating lists, as in the code you showed, can be written like this:
POSITION pos = str.list.GetHeadPosition();
while (pos)
{
lst.AddTail(str.list.GetNext(pos));
}
However, if both are CStringLists, you can add one to the other like this:
lst.AddTail(str.list);
--
jlr
http://jlamas.blogspot.com/[^]
|
|
|
|
|
Thanks that did it.
Robins E
ebinaini@163.com
nothing
|
|
|
|
|
In addition, MFC containers are total crap. Try moving to the STL.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
Christian Graus wrote:
...MFC containers are total crap.
How so?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
well, you realise they were written for use before the STL came online ?
Three things spring to mind:
1. They don't use common iterators, so it's not easy to move stuff from one to another, or work with two different types of container together
2. They don't support function objects
3. They don't have a library of prebuilt algorithms defining the majority of operations you're likely to want to do on items in a container.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
But the lack of those things does not explain why MFC is considered crap. If a person never has a need for common iterators, function objects, or prebuilt algorithms, are they therefore still considered crap?
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
Well, here are some points
1. If a person finds themselves suddenly in a non MFC app, they will be lost, because they've relied on MFC for things that it's not really good at, instead of using C++ itself
2. I can't see too many people NEVER needing the better support that the std library, which works everywhere, offers. So why learn a lesser library, that only works in MFC apps ?
Beyond that, I'm sure they do what they're supposed to, I just don't see the point in learning something that is limited in two ways, in how they can be used, and where you can use them.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
All valid points, but they still fail to explain why "MFC is crap." I've been using them since 1992 and they have served me quite well. The only classes that I still have no need for are ones beginning COlexxx. I recently found an error in CString::Delete() that has existed for several versions but is now fixed with VS 2005. That would hardly be fair of me to label the entire library as crap, however. Back in the mid 90s, I found a bug in one of the common controls (SysListView32). After proving that it could be reproduced in VB, C, and MFC, I was finally able to talk with level 2 support in the common controls group at Microsoft. I certainly did not consider any of the common controls, especially that one, to be crap. It was a very isolated problem.
Christian Graus wrote:
1. If a person finds themselves suddenly in a non MFC app, they will be lost, because they've relied on MFC for things that it's not really good at, instead of using C++ itself
Are you assuming that the non-MFC application is still GUI? If so, I'm not sure how the STL would be of any help to someone wanting to create a GUI application. If not, then the STL would certainly be of value.
Christian Graus wrote:
2. I can't see too many people NEVER needing the better support that the std library...
How is it better supported? Are you talking about support from Microsoft?
Christian Graus wrote:
I just don't see the point in learning something that is limited in two ways, in how they can be used, and where you can use them.
All tools have limitations. Those limitations, however, are not always relevant to the solution.
"One must learn from the bite of the fire to leave it alone." - Native American Proverb
|
|
|
|
|
DavidCrow wrote:
All valid points, but they still fail to explain why "MFC is crap."
The MFC *containers* are crap. For the reasons I have stated.
DavidCrow wrote:
Are you assuming that the non-MFC application is still GUI? If
No, why would I ?
DavidCrow wrote:
If so, I'm not sure how the STL would be of any help to someone wanting to create a GUI application. If not, then the STL would certainly be of value.
You seem to have missed my point. If I am working on a nonMFC app, and I need containers, if I have learned the MFC ones instead of STL ( as many do ), I will be initially lost.
DavidCrow wrote:
How is it better supported? Are you talking about support from Microsoft?
No, I'm talking about compilers that support the STL, compared to compilers that support MFC.
DavidCrow wrote:
All tools have limitations. Those limitations, however, are not always relevant to the solution.
Yes, I agree. MFC in general has limitations, but I still regard it as a good library, certainly a good alternative to Win32. However, like I said, it does include stuff that IMO does not add to the library, and encourages bad programming practice. The MFC containers were written prior to the C++ standard, and exist for legacy support. I'm aware of shops that don't let programmers use STL because 'Microsoft has containers and we're a Microsoft shop'. That sort of idiocy, combined with general ignorance ( that is, people using MFC find the containers, and have no idea there is a standard alternative ), is the reason I remain a pariah, a lone preacher in the wilderness, defending the use of the standard library for containers.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|