31
edits
IPDL/Getting started: Difference between revisions
m
Forgot one PluginProtocolParent -> PPluginParent
(Changed document to reflect naming scheme change of XProtocol* to PX*) |
m (Forgot one PluginProtocolParent -> PPluginParent) |
||
| Line 59: | Line 59: | ||
These Parent and Child abstract classes take care of all the "protocol layer" concerns: sending messages, checking protocol safety (we'll discuss that later), and so forth. However, these abstract classes can do nothing but send and receive messages; they don't actually ''do'' anything, like draw to the screen or write to files. It's up to ''implementing'' C++ code to actually do interesting things with the messages. | These Parent and Child abstract classes take care of all the "protocol layer" concerns: sending messages, checking protocol safety (we'll discuss that later), and so forth. However, these abstract classes can do nothing but send and receive messages; they don't actually ''do'' anything, like draw to the screen or write to files. It's up to ''implementing'' C++ code to actually do interesting things with the messages. | ||
So these abstract Parent and Child classes are meant to be used as base classes by C++ ''implementors''. | So these abstract Parent and Child classes are meant to be used as base classes by C++ ''implementors''. Here is a dirt-simple example of how a browser implementor might use PPluginParent. | ||
'''class''' PluginParent : '''public''' PPluginParent { | '''class''' PluginParent : '''public''' PPluginParent { | ||