I'm using boost v1.33.1, works fine for me...

For the last couple of months I've gotten the feeling that CodeProject access has slowed to almost a crawl. It's noticable while browsing and when downloading files, I usually get < 5 kB/s. And the problem is not on my end.

That does indeed sound strange. Are you linking with the multithreaded runtime libraries? Because that kind of odd behavior could arise from linking with the single threaded ones.

Theres no problem per se. But the first reason thread_one is not waiting is because of the SetEvent (after the CreateEvent method). This means that when you get to the WaitForSingleObject, it will just continue right on. So as I said, you should remove it. The second reason is multithreading. When you start thread_two, don't assume that the ResetEvent in thread_two will get executed before you get to the WaitForSingleObject in thread_one (it is less probable than not that that will ever happen). So this is why thread_one does not wait sometimes, all at the mercy of Windows thread scheduling. So, remove the SetEvent in thread_one and the ResetEvent in thread_two (optionally of course, because it doesn't do anything) and the code as it stands should work A OK.

Indeed Andrew, I think the problem arised from having VC++ 6 projects ported to VS .NET . The "output files" section as you pointed out, was ".\Debug/" . By clicking the combobox and selecting "", the correct path was setup, i.e. "$(IntDir)/" and everything worked A OK. Thanks again Andrew, /Rob

After CreateEvent the only place you need to do anything with the event is at the end of thread_two. Remove the SetEvent in thread_one and ResetEvent in thread_two. Also make sure that the SetEvent in thread_two really sets the event that the WaitForSingleObject is waiting for. Mind local variable scope. I.e. if you have and event handle in your class called hEvent, and you do: HANDLE hEvent = ::CreateEvent(NULL, TRUE, FALSE, NULL); the class (or object really) hEvent (having the same name as above) will not be set and the WaitForSingleObject will wait for a non-initialized event, thus holding execution indefinitely. Hope this helps.

You do: Somewhere define an event that both threads know about: HANDLE hEvent = ::CreateEvent(NULL, TRUE, FALSE, NULL); which is a manual reset event with unsignalled state to begin with. Then in your worker thread: // Do something, stuff, thing or whatever... // Ok Ready, signal the event ::SetEvent(hEvent); Then in thread 2 you just wait for the event // Wait for event to be signalled ::WaitForSingleObject(hEvent, INFINITE); Execution will continue after the ::WaitForSinglObject as soon as the event gets signalled.

Will check that. Because the odd thing is that the buildlog.html file does end up in the directories specified, but not any of the output files *.obj etc. etc. Thanks Andrew.

Hmmm... do you have an instance in your module of CThis2That ? I.e. like: CThis2That myModuleThingyStuff; I think you need it because then the constructor/destructor of it will be called when the DLL is loaded (and _Module.Init()/ .Term() will also be called). Hope that helps, /Rob

Ok. I've tried putting in every valid path combination in the projects settings, but the .obj files ALWAYS ends up under $(ProjectDir)/Debug. No matter what I do. Any ideas? /Rob

What you should do is lookup "Named Pipes". This is in essence exactly what you want to do. Do a search on SS_Log on Codeproject and you'll find the SS_Log_Server article that does exactly that.

Thanks, but... that was what I said. There are no "Extensibility Projects" and thus no Add-in wizard ;)

Everywhere it says: "Create project by going to Other Projects/Extensibility Projects". I don't have that! OTOH I don't have the Pro version of VC++. Is that needed ? I've download the VSIP 2003 SDK, that don't help either :( /Rob

Thanks Aamir, I'm not sure what you mean by the "plain include"? I do use the include: #include for the std::ifstream and std::ofstream STL classes. I checked the VC7 STL implementation and a lot of stream operators are available for the std::ofstream (through std::ostream). All _except_ char* (!!). For example, when the ofstream was passed a char* it used the operator << (void * ptr), so it was no wonder that the pointer value got into the text file instead of the string content. I'm not convinced that this is according to the standard, as STLPort is much more standard compliant and with STLPort it works just as intended. I guess the VC6 STL bugs just have been replaced by VC7 STL bugs... ;-) /Rob

Recently upgrading to VC++ .NET 2003, a logging utility using std::ofstream has broken. When outputting a string, the _address_ of the string gets into the log file and not the string contents!!! What is going on?? Addendum: Seems ostream has no << _Elem* operator. When I changed to write(...) it works like a charm. The standard has changed I guess... /R