|
Thanks for the answer. My desired behavior was to actually see that a separate thread is created and that the output from the thread is intertwined with the output from the main thread. I had the impression i had done this before and it worked (by creating two threads directly from the main function) but it's getting clear to me that this is not the case 
And yes, it wasn't a POSIX threads question as much as it was a threading question. But right now it's clear to me what is happening. Thank you. 
|
|
|
|
|
tiberiuv wrote: My desired behavior was to actually see that a separate thread is created and that the output from the thread is intertwined with the output from the main thread. I had the impression i had done this before and it worked (by creating two threads directly from the main function) but it's getting clear to me that this is not the case
Well, depends on what you mean by "working".
It does work, in the sense that a new thread will be created with pthread_create().
However, I think you are implementing it in a strange way and mixing Win32, MFC and pthread.
I suggest you read this excellent article[^] to get started with multithreading using the MFC framework and also understand how and when to use multithreading.
The article also helps you avoid common pitfalls. Even though the implementation details may differ from the POSIX thread library, the concept of multithreading is still the same.
The POSIX thread port library adds a lot of limitations to the Win32 API and should, in my opinion, only be used to write code that is supposed to be portable between Win32 and e.g. Linux. One of the worst limitations is that you cannot wait on multiple synchronization objects. Compare with ::WaitForMultipleObjects().
There are also some features of the POSIX thread library that are unsupported in the Win32 port, such as cleanup handlers.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Ah, damn. I asked this in the wrong place. I'm actually doing this under Linux. No MFC/Visual C++ involved here. Sorry.
|
|
|
|
|
I still have one small question, if you do not mind
on the server side i have something like this:
while( pThread->stream->read( recBuff, MAX_LEN) )
{
cout << recBuff;
}
and on the client side i have something like this:
while ( true )
{
cin >> sendBuff;
cs->write( sendBuff, MAX_LEN);
}
So when i write a sentence like: "timmy hates guns" on receiving i get it like i would have entered every word followed by a new line. I think that this is just what the client is doing. It's sending each word at a time in rapid succession. For this reason, some words do not pop out at the other end. I can end up with "timmy guns" and so on. Any idea why the client isn't sending the whole sentence? I'm using ::send(socket, (void*)msg, strlen(msg)+1, 0) to send over the network . Thanks
|
|
|
|
|
Try using cin.getline() instead of the >> operator since the operator break at least on every whitespace and possibly on every char.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
you my friend, are a genius 
|
|
|
|
|
tiberiuv wrote: you my friend, are a genius
My most humble thanks.
Glad I could help you.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Hi every one!
Can any one explain me why is this happening
struct SOME
{
char s0[1];
char s1[2];
char s2[1];
};
int main()
{
SOME *sm = new SOME;
delete sm;
return 0;
}
before allocation (with new)
0xcccccccc
{
s0=0xcccccccc <bad ptr="">
s1=0xcccccccd <bad ptr="">
s2=0xcccccccf <bad ptr="">
}
after allocation
0x00332e98
{
s0=0x00332e98 "
πΊ««««««««ξώξώ"
s1=0x00332e99 "πΊ««««««««ξώξώ"
s2=0x00332e9b "Ί««««««««ξώξώ"
}
after deallocation (with delete)
0x00332e98 <----- Is that a problem?
{
s0=0x00332e98 "" <-----
s1=0x00332e99 "3" <-----
s2=0x00332e9b "" <-----
}
thanks!
|
|
|
|
|
I don't see a problem. What specifically are you asking?
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
first:
in that below, why the memory addresses of s0, s1, s2 are different and has these values
0xcccccccc
{
s0=0xcccccccc <bad ptr="">
s1=0xcccccccd <bad ptr="">
s2=0xcccccccf <bad ptr="">
}
second:
after deallocation the memory addresses are still assigned to s0, s1, s2
0x00332e98
{
s0=0x00332e98 ""
s1=0x00332e99 "3" is that a problem
s2=0x00332e9b ""
}
|
|
|
|
|
Dennis L wrote: in that below, why the memory addresses of s0, s1, s2 are different...
As opposed to all being the same?
Dennis L wrote: after deallocation the memory addresses are still assigned to s0, s1, s2
And what would you expect them to be? All delete does is tell the memory manager that address 0x00332e98 is available for use again.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
first
I have read that all local variables that are not initialized explicitly are being intialiazed to 0xcccccccc with the Microsoft compilers. The first OK but the other two?
second
what happens with this address if the program exits
or
is this
void func1()
{
SOME *sm = new SOME;
delete sm;
}
void func2()
{
func1();
// What happents here?
}
|
|
|
|
|
Dennis L wrote: what happens with this address if the program exits
It is reclaimed by the memory manager.
Dennis L wrote: // What happents here?
Nothing.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
I think i got it now
Thanks for your reply!
|
|
|
|
|
Dennis L wrote: Is that a problem?
In short: no, unless you're trying to use it.
The fact that you have released the memory you previously allocated does not make the pointer to point somewhere else. The memory should not be used after being deallocated since it may contain invalid data as you've instructed the memory manager that you don't need it any longer by deallocating it.
This is why it's considered best practice to assign NULL to pointers you've deallocated to be able to test on the pointer to see if you can use the memory it points to.
"It's supposed to be hard, otherwise anybody could do it!" - selfquote
"High speed never compensates for wrong direction!" - unknown
|
|
|
|
|
Dennis L wrote:
Can any one explain me why is this happening
...
before allocation (with new)
0xcccccccc
{
s0=0xcccccccc
s1=0xcccccccd
s2=0xcccccccf
}
It's for debugging purposes I think - this way it's easier to detect if you're using your data before you've initialized it.
There is sufficient light for those who desire to see, and there is sufficient darkness for those of a contrary disposition.
Blaise Pascal
|
|
|
|
|
Well, what's being missed is that s0,s1 and s2 are char Arrays of 1,2 and 1 byte respectively, and NOT poiners! Why are they being displayed as DWORD.
What byte packing is used. Unless if you have a constructor SOME(), in which you specifically initialise the structure, you should not rely on the content of the structure because it is unpredictable.
The DEBUG version of the compiler tries to pad uninitialised and deleted structures with garbage in an attempt to make your code blow if you by mistake forget to initialise, or attempt to refer to de-allocated data.
The Release version is by no means as friendly, in that it does none of these things. If your code works while referring to data outside their validity scope, you create a timebomb which at some time in the future will cause unpredictable and mysterious crashes. I note that you read the structure after deallocation, This mere read could lead to an invalid memory access crash. (ever tried to read a NULL pointer?)
Regards,
Bram van Kampen
|
|
|
|
|
I need a constant array with pointers to two words - OK, CANCEL.
I tried:
const TCHAR Texts[2][7] = {L"OK", L"Cancel"};
It works fine, but I want to remove [7] and put [] instead, so when I change the text, I don't need to calculate the largest possible size.
Also I want to have pointers to this words ...
|
|
|
|
|
first of all, you're making a type mistake.
if you're prepending the strings with a L, then you must use WCHAR.
if you still want to continue with TCHAR, then L is not what you're after. You must use _T() around the string.
this being said, why don't you just do this :
const TCHAR* Texts[2] = { _T("OK"), _T("Cancel") };
|
|
|
|
|
Than you very much!!! It worked !!!
Actually I'm compiling for WM5.0, and TCHAR is WCHAR by default, so L is ok.
Is there a place when I can read for the foundation of C++??
I don't know the difference of TCHAR* xx and TCHAR *XX
|
|
|
|
|
akirilov wrote: I don't know the difference of TCHAR* xx and TCHAR *XX
actually, this is just a C++ language stuff.
FOO* XX has absolutely no difference with FOO *XX.
it's just a matter of taste when declaring a variable...
TCHAR however is part of the MFC, and is declared like the following IIRC:
#if defined(UNICODE) || defined(_UNICODE)
#define TCHAR WCHAR
#else
#define TCHAR char
#endif
On the same, _T() is defined like this:
#if defined(UNICODE) || defined(_UNICODE)
#define _T(x) L##x
#else
#define x
#endif
|
|
|
|
|
I know that _T(xx) is better (it works for ANSI and Unicode) then Lxx , but when I need a constant string it is easier to put just L (because for WM you almost always work with Unicode).
P.S. If you know a place on Internet, where I can learn some basic C++ conception this will be great.
|
|
|
|
|
It is not a question of "one is better than the other".
you MUST use _T() with TCHAR and L with WCHAR.
the point that UNICODE is defined is not for "WM" at all. it is defined in your project settings, and some might want to build a non unicode version.
if your code is well written then, only switching the parameter in the project settings will do. otherwise, you'd have to change every line of code using L to remove it, so that the ANSI build can perform successfully.
so be independant of that, and use _T() 
|
|
|
|
|
akirilov wrote: I don't know the difference of TCHAR* xx and TCHAR *XX
xx is a different variable than XX. Whether you put the space before or after is irrelevant, as the compiler sees tokens rather than spaces.
"Love people and use things, not love things and use people." - Unknown
"The brick walls are there for a reason...to stop the people who don't want it badly enough." - Randy Pausch
|
|
|
|
|
Hi,
I have an application which executes query through ExecuteSQL statement in an postgres 8.1 windows native version.
During ExecuteSQL if the server is switched off(power off) the system gets hanged and no exception is thrown.
The reason we found out is since the communication happens through TCP/IP and the TCP_KEEPALIVE_IDLE time is 2hrs by default it takes lot of time for sending the next heartbeat request.
It can be reduced by changing the value in registry , but the problem we are facing is since it will be modified for all the TCP/IP ports,it will increase the network traffic.
Is there any way to restrict the option only to a port ? If so how to apply it to the port confiured for the datasource.
Else is there any other ways to solve the issue?
Thanks
Krishnan
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
