|
Fellow coders,
RE: a C++ design problem.
I am attempting to construct a C++ class hierarchy on top of a C legacy system. The result
will be then placed into an embedded controller. The controller communicates with a Windows
program via a series of 'software pipes' to a supplied DLL and then calls in the Windows
program to fetch information from the DLL. The data in a given pipe will be of a specific type.
In order to generalize this process the third party library uses the following header:
typedef unsigned char BYTE;
typedef unsigned short WORD;
typedef unsigned long DWORD;
typedef union gen_scalar {
double _double;
__int64 _i64;
float _float;
long _i32;
short _i16;
DWORD _long;
WORD _word;
BYTE _byte;
} GENERIC_SCALAR;
And then, for example, reading a long from a pipe would be:
long Get(PIPE* pipe)
{
GENERIC_SCALAR v;
pipe_value_get(pipe, &v);
Return v._i32;
};
So, the hierarchy starts with a base class:
class Pipe
{
public:
Pipe(PIPE* pipe)
: pipe_(pipe)
{};
virtual ~Pipe()
{};
protected:
PIPE* pipe_;
};
where a PIPE* is just a handle to the communication pipe.
Then an input class is needed:
class IPipe : public Pipe
{
public:
IPipe(PIPE* pipe)
: Pipe(pipe)
{
pipe_open(pipe_, P_READ);
};
};
There would also be a corresponding output class OPipe.
And now the part I need help with!
Suppose I know a pipe will contain a series of 'shorts'. Then I could create:
class ShortIPipe : public IPipe
{
public:
ShortIPipe(IPIPE* pipe)
: IPipe(pipe)
{};
short Get() const
{
GENERIC_SCALAR v;
pipe_value_get(pipe_, &v);
return v._i16;
};
};
And so on for a long, double, float, etc, pipe(s).
However, the only difference between all these classes is the return value, that is,
v._i16 or v._i32, etc.
I'd prefer to create a single class which can handle them all. Maybe a template class?
For example:
template <typename T>
class IPipe : public Pipe
{
public:
IPipe(PIPE* pipe)
: Pipe(pipe)
{
pipe_open(pipe_, P_READ);
};
T Get() const
{
GENERIC_SCALAR v;
pipe_value_get(pipe_, &v);
return v._???;
};
};
Used like:
IPipe<short> spipe(...);
short s = spipe.Get();
And so, (finally) the question is how, within the Get() member, do I define the return value?
Note: the embedded controller cannot support RTTI. And I'd prefer not to have a big switch.
Any help would be much appreciated!
Kylur.
|
|
|
|
|
How about Template specialization?
template<> class IPipe<short>
{
...
return v._i16;
...
}
template class IPipe<long>
{
...
return v._i32;
....
}
|
|
|
|
|
Thanks for the reply, Jonathan.
Yes, this works - if fact it was my original attempt! I rejected it only because it just looked too wordy - I know, bad reason but I've got a little extra time to do investigations on this project so I thought I'd try a few other ideas.
Regards,
Kylur.
|
|
|
|
|
template<typename T> T
get_the_value(gen_scalar const& gs) const;
template<double> inline double
get_the_value(gen_scalar const& gs) const { return gs._double; }
template<short> short inline
get_the_value(gen_scalar const& gs) const { return gs._i16; }
template<typename T>
class IPipe : public Pipe
{
public:
IPipe(PIPE* pipe) : Pipe(pipe) { pipe_open(pipe_, P_READ); };
T Get() const
{
GENERIC_SCALAR v;
pipe_value_get(pipe_, &v);
return get_the_value<T>(v);
};
};
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
