|
Errr, just a stupid question: what's the point of passing a pointer to a global structure ? Your thread can access it directly 
|
|
|
|
|
I try a stupid answer: the thread hasn't to know it is working on global scope. I mean, you may have two or three of such structs and the thread is designed to work always on a single one, then you select the proper one on thread call (i.e. something similar to a master/slave approach to threading).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
[my articles]
|
|
|
|
|
If you look closely, I stated:
"...it's a silly example since the thread proc has
direct access to the global struct object, but hopefully it
shows you a way to pass a pointer to the thread proc..."
So, basically, it's because I was too lazy to type a more
robust example 
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Mark Salsbery wrote: If you look closely
Ha ! That was the problem, I knew it
|
|
|
|
|
Cedric Moonen wrote: I knew it
I knew it too, because I now have my CPMRU
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Thanks you very much, it works, you 'da man.
|
|
|
|
|
Ok since this seemed to set off a side discussion. My ultimate plan is to have the thread function in an include file, does this change the equation?
|
|
|
|
|
I'm working on a small embedded web server for my app Surfulater and wonder if anyone knows the steps involved in a XMLHttpRequest POST.
It appears that the server gets the Headers first, then sends back a 200 OK response and then receives the BODY for the POST.
This isn't my understanding of how it should work from reading the HTTP 1.1 RFC etc. Which indicates the POST Headers and Body are sent as one. My testing so far has been from IE6 only.
I'm trying to work out if my code is wrong or my understanding of the HTTP spec or the Browser implementation varies.
|
|
|
|
|
Neville Franks wrote: It appears
Appears? 
led mike
|
|
|
|
|
led mike wrote: Appears
Verb: appear:
1. Give a certain impression or have a certain outward aspect "This appears to be a very difficult problem"; "They appeared like people who had not eaten or slept for a long time"
2...
|
|
|
|
|
Verb: appear:
also "It appears you still have not explained how you determined this is happening" 
led mike
|
|
|
|
|
led mike wrote: also "It appears you still have not explained how you determined this is happening"
By looking at what WSARecv received. The problem was the HTTP POST data was being received in multiple TCP packets, whereas I incorrectly assumed the Header & Body would come as one.
|
|
|
|
|
Neville Franks wrote: By looking at what WSARecv received. The problem was the HTTP POST data was being received in multiple TCP packets, whereas I incorrectly assumed the Header & Body would come as one.
Yes, that is an artifact of TCP not HTTP. However your original post said:
Neville Franks wrote: It appears that the server gets the Headers first, then sends back a 200 OK response and then receives the BODY for the POST.
How do you know that? What do you mean "the server"? If it's your server, the one you are developing then you are doing it wrong. Of course the client doesn't know that because by the time it gets your 200 reply it has already sent it's entire message so it has no way of knowing that didn't read it all before you sent your reply.
led mike
|
|
|
|
|
You are right, the code in my server was wrong. Up until now it only had code to handle a GET and this incorrectly handled POST. It got a packet with the "complete" headers which for a GET is the end of the story. For a POST there maybe a BODY still to come. It was simply a matter of updating the logic to correctly determine the end of the POST request.
|
|
|
|
|
I am developing a COM based exe that needs some already available functionality ( which exists in the form a static library using MFC ( MFC statically linked ) ). The API's exposed by the static library use primitive data types such as int , unsigned char etc .
However when I include the static library in the COM project, it gives me a linker error about some CString's used .
This is how the code is organized
static library header file mystatic.h
int LibFunc1( int in, char *out) ;
static library source file mystatic.cpp
int LibFunc1( int in, char *out) <br />
{<br />
<br />
.. <br />
CString s = "Hello"; <br />
}
Com Component using static library
#include "mystatic.h"<br />
<br />
<br />
..<br />
..<br />
LibFunc1(x, y)
I am wondering if there is a better way of re-using this as I dont want to rewrite the static library logic .
Help is appreciated.
Engineering is the effort !
|
|
|
|
|
What version of MFC is the library linked with?
If CString is the only class you use, it's no longer part of MFC,
and can be used without MFC.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
![Java | [Coffee]](https://www.codeproject.com/script/Forums/Images/coffee.gif)
|
|
|
|
|
MFC 4
Engineering is the effort !
|
|
|
|
|
I have stated CString as an eg however the static library uses other classes such as CStringArray , CArray etc
Engineering is the effort !
|
|
|
|
|
Cool.
What are the exact linker errors?
From the code you've shown, the COM module shouldn't know
anything about a CString in the library code.
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
Hi,
Suppose two processes are communication through Namedpipes and one of them gets killed.
Then how will the first process come to know that second process got killed.
Any kind of help would be welcome.
|
|
|
|
|
A read or write on the pipe will fail.
I would guess the error will be ERROR_BROKEN_PIPE...test it
Mark
Mark Salsbery
Microsoft MVP - Visual C++
|
|
|
|
|
I'm working with directX and I have noticed that this function take some time to complete.
150 calls for this function take several seconds (3 seconds).
Is there any way to make this faster ?
|
|
|
|
|
I never used DirectX myself but I suppose that it is a normal behavior. I suppose that the function will load data from the file, which is always a "slow" process. Do you need to load 150 different images ? Because then your software is not very optimized. The best way to tackle this is to use a unique resource manager (make it a singleton for example) from which you will load your textures. The manager will cache the textures internally so that later, if the same texture is needed, it is returned directly, no need to reload the file once again. This has another big advantage: you just have one copy of the same texture in memory (instead of having 150 instances of the same texture, which of course takes a LOT of memory).
Hope that helps.
|
|
|
|
|
Thank you. I'll probably do something similar.
Anyhow my suspicion was that there may some other way to create the IDirect3DTexture from file which will be more faster. like some other function or specify some arguments since my use of the texture is very specific and perhaps not require all the smart things that gets computed when I call D3DXCreateTextureFromFile().
|
|
|
|
|
Hanan888 wrote: like some other function or specify some arguments since my use of the texture is very specific and perhaps not require all the smart things that gets computed when I call D3DXCreateTextureFromFile().
Anyhow, file access is slow. So, that will probably the main reason of the slowness, even if you could remove all the 'smart things' (and I don't there are a lot). And as I said before, you cannot load this same file 150 times in memory, especially if the image is big. It's totally inneficient and you will consume a lot of memory for nothing.
Are you developing a game ? In all games, a resource manager for this kind of stuff is required.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
