On 14.10.2010 23:21, Denis Washington wrote: > Being relatively new to CrystalSpace, I digged a bit deeper into the > User's Manual again and came across the chapter about SCF. While having > read it from beginning to end, I still don't have any clue about what > this mechanism does bring to the table. I mean, what is the benefit to > just declaring the implementing class itself and using that instead of > an extra SCF interface?
Generally, separating interface and implementation allows you to switch out the implementation without changing client code (which would only use the interface class). For example: image loaders. All loaders in CS use exhibit the same interface (iImageIO), but we have multiple implementations - a PNG loader, a JPG loader, and so on. Another application is platform abstraction - we have the “iGraphics2D” interface to abstract window setup etc. and have different implementations for Windows, X11 etc. Interfaces can also be “queried” from an SCF object. That makes it possible to realize things like querying capabilities and runtime/optional features. (For example, after loading an MNG image, the returned image will also exhibit an iAnimatedImage interface, indicating animation support. For all the static images this is not the case.) SCF is also the system that handles CS' plugin support. So we not only have a system to separate interfaces and implementations, but we can also add implementations dynamically resp. switch them out. (For example, we support OpenAL and other sound renderers like DirectSound - by choosing which plugin to use you can choose the sound system; it can be changes without needing a recompile or such.) Separating interface and implementation makes all that more convenient - client code doesn't have to care about the implementation at all (i.e.g whether sound is OpenAL or DirectSound, whether an image was a PNG or a JPG...) as long as it sticks to the interface “contract”. > I read something in the introduction about being able to do let SCF > objects communicate between processes with COM and CORBA and the like, > but why should somebody do that? It's a game engine, after all! In 99% > of the case, a game does not have to integrate with its environment. > (Maybe with other instances of itself running on other machines for > multiplayer, but this should probably be the job of a network subsystem, > not of a basic object framework.) It's not used for IPC at all. > I also don't grasp the versioning argument. The manual says "if it > happened that you compiled the shared library with a slightly different > version of [concrete class] (that, say, had one member variable fewer) > you will end up with a SIGSEGV crash." Isn't that what the d-pointer > idiom [1] is for? I see no reason how SCF solves this better. The issue here is binary compatibility. Internally, a C++ class is just a simple structure, after all; virtual methods are actually realized fields with function pointers. When calling a virtual method, the compiler generates code that looks at _a particular position_ inside the “class structure”, fetches the method pointer and executes it. Now, when adding or removing virtual methods from a class, the layout of that structure changes - the order of the “method fields” changes and such any binary code that the compiler generated might be wrong - it could look into the wrong place for the method. Obviously, calling the wrong methods as all kinds of unexpected, unwanted results. Since SCF allows for dynamic loading of modules, it's possible that mix-ups occur - say, you changes an interface but didn't rebuild all plugins that use that interface (perhaps unintendedly, perhaps out of laziness). The versioning system is a safeguard for this case - if properly used, the old plugins will fail the version test and will not attempt to use interface as it was the old variant, thus potentially avoiding crashes and such. The d-pointer idiom wouldn't help here. The implementation of “Account“ after all needs to know the layout of the AccountPrivate private class - it's not a guard against binary incompatibility. -f.r.
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------ Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev
_______________________________________________ Crystal-main mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/crystal-main Unsubscribe: mailto:[email protected]?subject=unsubscribe
