Am 15.10.2010 15:00, schrieb res: > 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.
I know the benifits of programming against interfaces, but still can't figure out why SCF is needed. I have the feeling the the core features of C++ suffice. For instance, the same effect described above can be archieved by a simple purely virtual iImageIO class with concrete subclasses. > 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.) Such capability querying can be done with dynamic_cast. > 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.) Again, C++'s pure-virtual base classes provide the same interface-implementation separation. Granted, there needs to be a way for plugins to register itself, but this doesn't mean that this functionality is needed in the core object system, where it is inherited by many classes which don't need it. > 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 agree with you, but as I said, it can be done with C++ core features alone. I think there is no need to reinvent something already in the language. >> 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. Ok, the User's Manual is probably out-of-date here then. >> 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. A versioning mechanism in a dedicated plugin/module system would suffice. Again, I don't see why this is a reason to complexify the complete object system. > 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. > True, it wouldn't help with virtual function incompatibilities. However, as I said above, I think that in many cases where SCF seems to be used in CrystalSpace, core C++ features would be more than enough (purely virtual abstract base classes, dynamic_cast). I guess that these features might not have been widely available when CrystalSpace was first designed (dynamic_cast specifically), but today, I think SCF is overly complex for most of its uses in CS (as fas as I can tell from dipping into the code and API reference) except for the case of plugins, where a less general and more specifically tailored subsystem would probably suffice, though. Regards, Denis ------------------------------------------------------------------------------ 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
