Comments by Stephen Hewitt (Top 34 by date)

Your question is a little vague. Can you be more specific?

If you include the headers I did and make sure you've got the "using namespace std;" it should work.

To me a hook seems like overkill. I'd go with the subclassing approach as mentioned above if I could.

No, they don't handle the key combination. They handle the "device lost" event. This can occur for many reasons, only one of which is CTRL-ALT-DELETE, and even then it's only a by-product of the process.

Yeah, you did say rarely. I was wondering if you were going to point that out;)

I can think of reasons you may want to do it. For example, to make it harder to misuse some sort of scope guard class.

That's true. The OP didn't mention who creates who and such. I prefer not to use named objects if I can.

Cross-process notification is the whole point of the question. From OP:
'but I want to be able to "wake up" a console Win32 Console Application each time another application has updated variables in shared memory.'

There certainly are people like that, but not all people are.

The two copies of the DLL are distinct. The fact that the same DLL is loaded into both process does not enable cross-process callbacks.

Or you can use handle inheritence.

I don't vote posts down to punish the poster but as a guide to the person who asked the question, and others who are interested in a solution. In short, helpful answers should be easily identified - people come here for help after all.

The client and server are in different processes. A simple callback isn't possible in this scenario.

What is the crash? What type of exception is generated?

Perhaps we need a "flame war" tag...

To me invoking the command interpreter to clear the console seems inefficient and inelegant. I will admit it seems to be the easiest way. There's an article <a href="http://support.microsoft.com/kb/99261">here</a> that describes how it can be done using your method and one more to my liking.

One thing which may be applicable is to derive the new interface from the old one and simply add some extra methods. I don;t know your exact sutuation however.

The standard states that map's (and multimaps, for that matter) should behave as per the text I quoted. Only the iterators of erased elements are invalidated.

http://www.sgi.com/tech/stl/Multimap.html

"Multimap has the important property that inserting a new element into a multimap does not invalidate iterators that point to existing elements. Erasing an element from a multimap also does not invalidate any iterators, except, of course, for iterators that actually point to the element that is being erased."

One of the advantages to using exceptions oftern cited by advocates is that it makes it hard to ignore errors: you can ignore an error code by see what happens if you don't handle an excpetion. Handling all exceptions in you thread function negates this benifit to a degree.

Perhaps if you explained in more detail.

If you know that you're not supposed to throw exceptions from COM methods what's the problem? btw. Exceptions thrown with RaiseException are included (you're not meant to thow them).

Explain some details:
What programming language?
What libraries, if any are you using? OpenGL, DirectX, nothing?
How are you representing the polygons?

Give us something to work with!

Reason for my vote of 1
COM is far from dead. It's not the right tool for every job and for some things where in the past you'd have used may be better implemented using newer technologies, but that doesn't mean there aren't jobs where it's useful. Also note that COM is essentially a packing technology: it describes what servers look like on the outside, but they can be implemented in many languages including C#.

Reason for my vote of 1
What's the question? Some specifics would help!

Reason for my vote of 2
Clearly both behaviours have their uses and there are also cases which could force your hand.

Single instance:
GOOD: Since only a single process is used it may be more efficient.
BAD: A fault in one server object could crash the process and will effect all clients.

Multiple instance:
GOOD: Faults in one server object that causes a crash only effects one client.
BAD: Multiple processes mean more system resources are used.

Things that could force your hand:
- If you're using a library that has global (per process) settings and you want each instance of the object to be able to use different settings. In this case you're forced to the use separate instances model.

I mean the file itself.

Reason for my vote of 1
What the hell is he on about?