|
Louis Clayton wrote: I have noticed that in order for derived classes to be true singletons, their constructors must be declared private (or rather not public) otherwise an instance of the derived class may be declared.
Correct.
Louis Clayton wrote: I was hoping that maybe the fact the singleton base class's constructors were private might have prevented this.
If a class has only private constructors, you can't inherit from it. To make a base class implement a singleton, you'll need to declare the base class constructor to be protected. To prevent a class from being constructed by anyone, you'll have to make the constructor either protected or private, and put code in the constructor to enforce the singleton condition.
Louis Clayton wrote: it seems that unless the class used as the singleton base class's creation policy is declared as a friend in the derived class, the code does not compile saying that the creation policy cannot access the private constructor.
Correct. This is one of the reasons I don't like creation policies, they have a tendency to make the code "unclean". However, I have seen some really neat policy setups that are classes given as template parameters, the advantage being that friend declarations are sometimes unnecessary. Have a look at the book Modern C++ Design by Alexandrescu for a very comprehensive and well thought-out singleton design.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
1st off... I'm new to threads so be gentil..
My problem: I am writing an application that opens a socket and reads in image data from a camera. It works... but its slow. I believe this is because the Socket OnReceive is on the same message pump as the UI (onPaint etc) and isnt getting enough attention.
a. I want to move the socket to its own thread so it has its own message pump.
b. The only thing this thread will do is fill a buffer for each frame and then that frame will get processed by the original thread.
What I need:
Some direction... I'm not sure if this is the right approach and I"d like to know if it would even work.
some quick examples would help as well since this will be my first multithreaded application.
thank you in advance!!
-- modified at 16:10 Wednesday 24th May, 2006
|
|
|
|
|
SPowers wrote: a. I want to move the socket to its own thread so it has its own message pump.
See here and here.
"The largest fire starts but with the smallest spark." - David Crow
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
That answers a lot... I'm still a little confused how I can write to a buffer within a thread and have another thread read from it.
Do I keep a pointer to the buffer within both threads and only read from the buffer when i pass a message from the socket thread saying that it is ready to be read?
|
|
|
|
|
This sounds like the reader/writer problem.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
what is the reader/writer problem?
Is my assumption correct?
|
|
|
|
|
SPowers wrote: what is the reader/writer problem?
See here.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
Ok that makes sense....
So I should plan it like this:
Databuffers:
buffer A: w/mutex
holds image data for frame X
buffer B: w/mutex
holds image data for frame y
x & y are concurrent image frames
Thread 1: main prgrm (reading and displaying data from buffer)
will hold pointers to buffer A & B
Thread 2: Socket exists on this thread and will handle sending and receiving data from socket as well as writing data to the data buffers
will hold pointers to buffer A & B
I'll have to put a mutex on the shared buffers so that they dont access it concurrently. And the mutex permissions will switch between the two buffers so that Thread2 can write constantly and Thread1 can read constantly.
Sound like a plan or did I miss the whole point completely?
|
|
|
|
|
Quick question:
Will reading memory that is currently being written cause an error or will it simply cause a versioning problem.
I ask this only because whenever I'm ready to write a frame I just want to dump the buffer into an image and I dont really care much about any versioning concerns.
|
|
|
|
|
It means that a frame could contain half of one image and half of another...
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
That would definately not be a problem (knock on wood). If it is I could always implement a double buffer with mutexes.
I still havnt really gotten an answer about the shared memory. Since I'm new to threads my guess would be that each thread would have a pointer to the same piece of memory. Is that correct?
|
|
|
|
|
SPowers wrote: each thread would have a pointer to the same piece of memory. Is that correct?
Yes, that would work. Each thread shares the same address space, so any thread can access any memory that the application owns.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
I have one more question (I think)
http://flounder.com/detach.htm#Sockets shows me how to detach the socket and assign it to a thread.
How do I use the Message Pump within the thread to catch the onReceive()/onSend() Messages
-- modified at 14:45 Thursday 25th May, 2006
|
|
|
|
|
Sorry, can't help you there. I've never used MFC sockets - I always use the raw Win32 versions.
Ryan "Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late" John Nichol "Point Of Impact"
|
|
|
|
|
The help files recommend that user messages be defined in the range WM_USER to 0x7fff, but opening the Resource Symbols dialog to create a new ID and letting it choose the value seems to work fine. Does anyone know if there is anything wrong with this?
Best Regards
Cliff Hatch
-- modified at 14:42 Wednesday 24th May, 2006
|
|
|
|
|
Cliff Hatch wrote: The help files recommend that user messages be defined in the range WM_USER to 0x7fff...
It should be WM_APP .
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
Depends on the usage. If you are defining a message that will only be used within the application, then use WM_APP. If the message is for a control that could be used in other apps the use WM_USER. If it is a message that is used to communicate between different modules then use ::RegisterWindowMessage().
You may be right
I may be crazy
-- Billy Joel --
Within you lies the power for good - Use it!
|
|
|
|
|
PJ Arends wrote: If the message is for a control that could be used in other apps the use WM_USER.
WM_USER should not be used at it can conflict with messages that Microsoft uses. RegisterWindowMessage() is the safest/preferred method in any case.
"The largest fire starts but with the smallest spark." - David Crow
|
|
|
|
|
Thanks guys.
I can see that there is a problem if messages conflict, but what's puzzling me is why does it matter what the value is so long as it is unique - and if I use the Resource Symbols dialog to create it, doesn't that guarantee uniqueness?
Is it a matter of standardisation and ease of maintenance perhaps?
Best Regards
Cliff
|
|
|
|
|
|
Thanks Michael, that answers my question perfectly.
Best Regards
Cliff
|
|
|
|
|
I've created a handler for a user defined message with the following declaration:
afx_msg LRESULT OnIdleScan(WPARAM wPar, LPARAM lPar);
It works, but what value (of type LRESULT) should the function return, and what does the system do with this? I assume it is not passed back via PostMessage, because it doesn't wait for the handler to execute. I'm arbitrarily returning 0 at present.
Best Regards
Cliff Hatch
|
|
|
|
|
The result is not used for PostMessage()'s, but it is when using SendMessage(). The return value is completely up to you. I usually just return 0, if its not important.
I have come across a few messages that are used in this way to indicate success or failure.
I Dream of Absolute Zero
|
|
|
|
|
Thanks for your reply. It makes perfect sense now.
Best Regards
Cliff
|
|
|
|
|
I have read several sources on when to use the extern keyword and when not to, but I still have some confusion.
Could someone explain the proper use of extern when it comes to variables and function:
extern void MyFunction(void);<br />
extern int MyVariable;
Thanks.
|
|
|
|