views:

213

answers:

4

http://msdn.microsoft.com/en-us/library/ee2k0a7d.aspx

Event handling is also supported for native C++ classes (C++ classes that do not implement COM objects), however, that support is deprecated and will be removed in a future release.

Anyone knows why? Couldn't find any explanation for this statement.

+1  A: 

I'd hazard a guess, and it is just that, that similar functionality can be achieved by a signal/slots type library in a more more portable/standard C++ (with templates) fashion rather than requiring compiler support by MS.

Gareth Wilson
More likely looking at the MSDN page as MS expect you do do the events and marshalling in COM
Mark
A: 

Have a look at Boost::Signals

MSalters
FYI, this link is now broken.
Richard Szalay
+1  A: 

I'd hazard a guess that they would want you to do it all the .Net way now.

Duracell
+5  A: 
  1. It's totally non-standard kludge that probably has very little actual users. And I mean non-stndard kludge even in WinNT and Microsoft-private world.

  2. COM has much richer repertoire for event-like mechanisms and also allow fully multi-threaded code these days

  3. This one is lethal - that functionality is doing implicit locking (probably our grandpa's idea of "synchonized" before templates and widespread safe use of normal critical sections). That makes it more dangerous than COM's single apartment, ahem, thing :-) As in it can give you a deadlock out of nowhere (happened to Java's synchronized methods as well - nothing special :-)

  4. Everyone and their dogs know how to use normal multi-threading and at least critical sections with smart pointers these days, so besides being dangerous, that thing is also irrelevant.

ZXX
+1, though I'd disagree with "irrelevant" - a native mechanism would be welcome. It can be implemented through libraries, but first class support with elegant syntax, good compiler diagnostics, debug support ("break when this even fires") etc. would be welcome.
peterchen
It's really nothing more than async call for which you don't check completion. Forgot the name of a API - just fires up a thread which gets closed when the function returns - perfecly debuggable and no locking if you know what you are doing.
ZXX