|
Thank you for the reply, Berndus.
This answer really caught my eye as it 1) took advantage on templates and specialization, 2) the helper functions can all be moved into the IPipe class as private members, 3) is understandable and 4) is short.
Looking closer at the get_the_value functions and they start to look very similar to the reinterpret_cast as suggested in another reply - the only difference being explicitly returning the union member.
Good job! I think this is the solution I'll use.
Regards,
Kylur.
|
|
|
|
|
Did you try: return (T&)v;
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Thanks for the reply, "cmk".
And no I had not tried your suggestion.
But now I (almost) have (I used return reinterpret_cast<t&>(v);) and yes it does work! And I'm not sure if you're a friggin' genius or if I'm just an idiot for not seeing this solution.
For some unknown reason however, I'm a little reluctant to use this - "gurus" tend to frown on casts and in this case I'm not really sure what a reinterpret_cast of a union is really doing (although I have to say it does seem to work).
I'll really have to think about this some more!
Regards,
Kylur.
|
|
|
|
|
20 yrs of C++, more for C.
There is NOTHING wrong with using the (T&) cast.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
|
|
Hi,
if yes then thread id's are unique
as only the thread id is specfied on the PostThreadMessage
MSDN says that for msgs WM_USER and above sent to another process I must do custom marshalling
Don't know what this means ???
|
|
|
|
|
As far as i know, yes, PostThreadMessage does work between processes, and marshalling -also as far as i know- is executing code in the context of another thread, something like, if you have thread A and B and the method C and the thread A needs the method C to be executed by thread B then A "marshalls" the call to thread B (by sending messages, or using events...), there's probably much more to it but it basicly means this. Correct me anyone if i am completely wrong with this...
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
And Can I also use wparam and lparam
to send data to that thread/process
|
|
|
|
|
That depends on the kind of data you wish to send. For example sending a simple integer to the thread is ok, but for example sending a pointer to a string (converted to LPARAM or WPARAM) and trying to use it on the other end will most likely lead to crashes.
> The problem with computers is that they do what you tell them to do and not what you want them to do. <
> Sometimes you just have to hate coding to do it well. <
|
|
|
|
|
Please check the below, it will help correct ur understanding.
Величие не Бога может быть недооценена.
|
|
|
|
|
They are saying is that WM_USER and above are application specific. It's possible for WM_USER+1 to mean one thing in one app and another thing in another app. It is your responsibility to make sure they mean the same thing.
e.g.
Process A: #define WM_MYFOO WM_USER+10
Process B: #define WM_MYFOO WM_USER+11
This would be bad as the code would likely be:
Process A: PostThreadMessage(WM_MYFOO)
Process B: if( msg == WM_MYFOO )
and process B would think it's getting a different message.
Usually not an issue as both processes should use a common header that defines WM_MYFOO.
The same goes for whatever you pass as LPARAM and WPARAM.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Offcourse they are unique until they are process is alove, but once process is terminated, they can be assigned to another process.
And next is about marshalling. It duplicating the handles. Just have a look on this article which will help you get the knowledge regarding the same.
Inside Windows Handles
Now here is sample that explains, how you can send a message to other process thread.
Now here WM_QUIT is send to Task Manager and it can be terminated from our process using PostThreadMessage.
#include "stdafx.h"
#include <windows.h>
#include <commctrl.h>
#include <stdio.h>
char tWindow[]="Windows Task Manager";
int main(int argc, char *argv[])
{
HWND hWnd;
DWORD proc;
DWORD hThread;
hWnd = FindWindow(NULL,tWindow);
if(hWnd == NULL)
{
return 0;
}
hThread = GetWindowThreadProcessId(hWnd,&proc);
if(hThread == NULL)
{
return 0;
}
char buffer[MAX_PATH];
char *message = "hello";
sprintf(buffer, "say %s", message);
PostThreadMessage((DWORD) hThread,(UINT) WM_QUIT,0,(LPARAM)buffer);
printf("+ Done...\n");
return 0;
}
Hope things are clear 
Величие не Бога может быть недооценена.
modified on Saturday, April 10, 2010 1:26 AM
|
|
|
|
|
I'm missing something totally fundamental here but have yet to figure it out. I've got a class called JOBINFO. I create instances of it on the heap and add those pointers to a map. When I need to reuse the map, I call its RemoveAll() method. Internally, that method is supposed to call the overridden DestructElements() which then calls each object's destructor. That is not happening.
class JOBINFO
{
public:
JOBINFO()
{
TRACE("Constructor\n");
}
~JOBINFO()
{
TRACE("Destructor\n");
}
};
...
void AFXAPI DestructElements( JOBINFO* pJobInfo, int nCount )
{
TRACE("DestructElements()\n");
}
...
CMap<int, int, JOBINFO*, JOBINFO*> m_mapJobInfo;
...
m_mapJobInfo.SetAt(123, new JOBINFO);
...
m_mapJobInfo.RemoveAll();Any ideas?
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
RemoveAll doesn't actually delete objects - it might call the d'tor on the pointer, but that's a no-op.
you have to delete the objects manually.
MSDN discussion[^]
|
|
|
|
|
Chris Losinger wrote: RemoveAll doesn't actually delete objects...
I know that. It internally calls DestructElements() which then calls each object's destructor. I'm trying to figure out why neither is getting called in my case.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
DavidCrow wrote: It internally calls DestructElements()
not in the version of MFC that comes with VS05:
afxtempl.h
template < class KEY, class ARG_KEY, class VALUE, class ARG_VALUE>
void CMap < KEY, ARG_KEY, VALUE, ARG_VALUE >::RemoveAll()
{
ASSERT_VALID(this);
if (m_pHashTable != NULL)
{
for (UINT nHash = 0; nHash < m_nHashTableSize; nHash++)
{
CAssoc* pAssoc;
for (pAssoc = m_pHashTable[nHash]; pAssoc != NULL;
pAssoc = pAssoc->pNext)
{
pAssoc->CAssoc::~CAssoc();
}
}
}
...
VS08 has those two lines commented-out, as well.
|
|
|
|
|
Wow! In VS6, those two lines are not commented out. I guess that MSDN is wrong when it states:
Removes all the values from this map by calling the global helper function DestructElements.
So, is there no longer a way for the framework to assist in freeing heap objects from a map? I can work around this by deriving a class from CMap and implementing a "cleanup" method that I can call instead of RemoveAll(), but didn't want to unless I had to.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
that really is odd. wonder why they'd do that...
|
|
|
|
|
DavidCrow wrote: So, is there no longer a way for the framework to assist in freeing heap objects from a map?
Do you know any library with the maps,
that delete given pointers by default ? 
You could define a map with CString values
and you would get their destructors at removing.
An "overwritten" DestructElements(..) function has no role,
elsewise we could not instance a map or - at least - call RemoveAll(),
without to must implement it always
virtual void BeHappy() = 0;
|
|
|
|
|
Eugen Podsypalnikov wrote: Do you know any library with the maps,
that delete given pointers by default ?
I was not looking to have the map delete the pointers.
Eugen Podsypalnikov wrote: An "overwritten" DestructElements(..) function has no role,
elsewise we could not instance a map or - at least - call RemoveAll(),
without to must implement it always
Try as I might, I can make no sense of this.
"One man's wage rise is another man's price increase." - Harold Wilson
"Fireproof doesn't mean the fire will never come. It means when the fire comes that you will be able to withstand it." - Michael Simmons
"Man who follows car will be exhausted." - Confucius
|
|
|
|
|
Eugen Podsypalnikov wrote: Do you know any library with the maps,
that delete given pointers by default ? Smile
std::map with boost::shared_ptr comes in mind (or any STL compatible auto pointer)
/M
|
|
|
|
|
Good point !
This[^] class could provide a solution for David :
class Info
{
public:
Info() {};
~Info() {};
...
};
...
CMap <int,int, CAutoPtr<Info>, CAutoPtr<Info>> mapInfos;
...
mapInfos.SetAt(123, CAutoPtr<Info>(new Info));
...
mapInfos.RemoveAll();
virtual void BeHappy() = 0;
|
|
|
|
|
DavidCrow wrote: So, is there no longer a way for the framework to assist in freeing heap objects from a map?
No more, unless you wrap your pointers (if I understood correctly [^] and [^]).
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.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
m_mapJobInfo.SetAt(123, new JOBINFO);
You are calling constructor: JOBINFO*, not JOBINFO.
It is important to understand the difference.
Make the map as:
CMap<int, int, JOBINFO, JOBINFO&> m_mapJobInfo;
And the DTOR will be called.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
![Java | [Coffee]](https://codeproject.freetls.fastly.net/script/Forums/Images/coffee.gif)
Now with 26% more Twitter