|
Ah! Thank you for clearing that!!!! I was really puzzled on this one!!
Appreciate your help,
ns
|
|
|
|
|
The release exe runs fine. The debug one crashes on:
CBKDoc * pDoc = (CBKDoc *)GetDocument();
pDoc->dynaMenuMap.clear();
where:
typedef std::set <CString> SubMenuSet;
typedef std::map <CString, SubMenuSet> DynaMenuMap;
;
THe very first time I entere the function, DynaMenuMap dynaMenuMap is empty, so perhaps clearing an empty map is a no-no? The release exe doesnt care....
How do I sidestep this?
Appreciate your help,
ns
|
|
|
|
|
int size = pDoc->dynaMenuMap.size();
if (pDoc->dynaMenuMap.size())
{
pDoc->dynaMenuMap.clear();
}
THe map starts out empty, and I clear only if its not empty....but now my debug version is saying size = some large neg number. All I have in the code mentioning the map untilk this point is DynaMenuMap dynaMenuMap in the .h file...
Appreciate your help,
ns
|
|
|
|
|
Are you certain it's crashing on the clear() call?
(It may be the case that pDoc is NULL, though I don't see why that would work in release but not in debug)
--
Help me! I'm turning into a grapefruit!
|
|
|
|
|
pDoc is not null. The size of the empty map is weird: some larege neg number. If I get rid of the clear(), it still crashes , but on the line in red!!!!!! If I put the clear(0 in it crashes on the clear()!!!!!!!!!!!
int size = pDoc->dynaMenuMap.size();
if (pDoc->dynaMenuMap.size())
{
pDoc->dynaMenuMap.clear();
}
<code>SubMenuSet & subMenuCat = pDoc->dynaMenuMap["Cat</code>"];
//crashes here if I comment out the clear()
size = -125......
Appreciate your help,
ns
|
|
|
|
|
ns wrote:
The size of the empty map is weird: some larege neg number
No;P Its just unsigned int.
You can use dynaMenuMap::size_type as type for your size results, but in the current implementation, this is just typedefed to unsigned int.
Personally, I use size_t, AFAIK defined by Microsoft to be unsigned int.
Less typing as 'unsigned int', and conveyes a meaning.
<edit> Something must be rotten with your doc-pointer.
My opinions may have changed, but not the fact that I am right.
|
|
|
|
|
I guess its the pointer...but what can I do?
In a view class where I generate the map:
unsigned int size = pDoc->dynaMenuMap.size();
with unsigned, I still get a non zero number --- large positive!!! Theres been no map created so far!!! So it should be zero!
But in the doc class whose member the map is:
BOOL CBKDoc::OnNewDocument()
{
if (!CDocument::OnNewDocument())
return FALSE;
CString abc;
abc.Format(" size of map in doc is %d", dynaMenuMap.size());
AfxMessageBox(abc);
return TRUE;
}retiurns size of zero!!! As it should...
Appreciate your help,
ns
|
|
|
|
|
Hi ns, most likely pDoc is not a valid pointer: check if other members of this object hold consistent values.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
What he said...
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
Pardon me? I don't get what you mean.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
Whoops, I guess that is a colloquialism.
I basically said I agree with you on all counts.
Tim Smith
I'm going to patent thought. I have yet to see any prior art.
|
|
|
|
|
OK  Excuse my poor understanding, I'm not a native English speaker and I guess it shows.
Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo
|
|
|
|
|
This is really really upsetting!! I went and put in a member int testing variable in the doc (like you suggested) , and retrieved it in the offending view with the pDoc->. That came out fine! The next line was my size(). Now this came out 0!!!! Like it should be. Then the program ran perfectly in debug. SO I went and undid the addition of the int test variable in doc, and viola!!!! it still works perfectly. I am really puzzled and mistrustful now.....it bothers me when things get fixed miraculously...........
I am nonplussed!
Appreciate your help,
ns
|
|
|
|
|
You'd be better of testing it with the empty() function instead of size()
~RaGE();
|
|
|
|
|
I'm betting this is due to the cast on the document pointer. Didn't you add that GetDocument member I told you about? On a more serious note, you shouldn't have to cast that document pointer. I spent 2 weeks debugging a similar problem a couple years ago, where the compiler wasn't generating the correct address for the pointer because I was doing a "C" style cast. This would explain your "garbage" number, and (partially) the fact that adding a variable to the class solved the problem. If you are worried about it, try doing a "Build->Clean" on the Debug build, and run it again. If it fails, you're still in trouble.
Chris Richardson
Programmers find all sorts of ingenious ways to screw ourselves over. - Tim Smith
|
|
|
|
|
Yes. I did add the GetDocument to my second view. That was the first thing I did since you told me about it. If you are saying that its not good to do:
CBKDoc * pDoc = (CBKDoc *)GetDocument();
, then what should one do? I've always seen it this way. This is the cast you are talking about right? Are you saying that I should just do:
CBKDoc * pDoc = GetDocument();
since it returns the right thing anyways? It does the cast too......(CBKDoc*)m_pDocument
CBKDoc* CSearchView::GetDocument()
{
ASSERT(m_pDocument->IsKindOf(RUNTIME_CLASS(CBKDoc)));
return (CBKDoc*)m_pDocument;
}
#endif //_DEBUG
Appreciate your help,
ns
|
|
|
|
|
I'm write a application with two threads which are sender and receiver to send and receive data :
//Global
CSocket send_sock, recv_sock;
//These two sockets were created some where at start up
//before creating two threads : sender and receiver
// send_sock.Create(0, SOCK_DGRAM);
// recv_sock.Create(1111, SOCK_DGRAM);
//Sender thread
int sender(LPVOID)
{
while(bFlag)
{
//Some code here
send_sock.SendTo(data, size, port, addr);
//Some code here
}
}
//Receiver thread
int receiver(LPVOID)
{
while(bFlag)
{
//Some code here
recv_sock.ReceiveFrom(data, size, addr, port);
//Some code here
}
}
The sender runs ok but the receiver can not. The receiver just returns an error (WSAWOULDBLOCK) at the ReceiveFrom statement.
To solve this problem I use a socket variable as a local variable in the receiver function :
int receiver(LPVOID)
{
CSocket sk;
sk.Create(1111, SOCK_DGRAM);
while(bFlag)
{
//Some code here
sk.ReceiveFrom(data, size, addr, port);
//Some code here
}
}
So it runs ok in the 'Share MFC DLL' compile mode, it can not run in the 'Static MFC DLL' compile mode.
I don't know why because I'm starting with Window Socket.
So many problems to me. Please help me. Thanks in advance.
|
|
|
|
|
I think the program requires winsock DLL that the compiler will not assemble as static.
Kuphryn
|
|
|
|
|
You can't have two "sockets" using the same port at the same time. That's why it's blocking.
------- signature starts
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
Please review the Legal Disclaimer in my bio.
------- signature ends
|
|
|
|
|
But they are not in the same port.
The former : send_sock.Create(0, SOCK_DGRAM);
The later : recv_sock.Create(1111, SOCK_DGRAM);
If the method of using local socket variable in the receiver thread core is applied, I do not create the recv_sock. Thus, there are nothing in the same port.
Another question : how to configure the linker to link the winsock dll as static, not dynamic ?.
|
|
|
|
|
TPN wrote:
Another question : how to configure the linker to link the winsock dll as static, not dynamic ?.
I believe that you simply find the .lib file on the MSVC installation CD. I can't quite recall but I think that is how. Borland used to have a utility that would create a library file from a dll called, ImpLib. But, I am not sure that MSVC has one.
|
|
|
|
|
Who can give me a sample?
Thanks in advance.
George
|
|
|
|
|
The difference is that one wouldn’t work--declaring a const * char would give you an error. The compiler, VC6 anyway, would interpret it as a pointer to a constant int, named char. The reason it would crap out is because you can't use keywords as variable names.
cheers,
-B
|
|
|
|
|
Thanks, Ben pal!
Cheers,
George
|
|
|
|
|
As mentioned above, const * char is meaningless. However char * const has meaning. As mentioned here[^], you have to read pointer declarations backwards.
const char * means a pointer to a character that is constant. The pointer can change but the data being pointed to cannot.
char * const means a constant pointer to a character. The pointer cannot change but the data can.
const char * const means a constant pointer to a constant character. Neither the pointer nor the data can change.
The C++ FAQ is a terrific place to learn all kinds of good stuff. Go here[^].
J
May the bear never have cause to eat you.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
