On 15.10.2010 19:41, Denis Washington wrote: > 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 *are* purely virtual classes. What SCF adds is, essentially, a mechanism to query interfaces from an object of which you don't know what interfaces it may posses. So yes, you could call it a home-grown dynamic_cast<>. On that, read on... > 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. CS has many classes which are _not_ SCF classes. If some class is, either because we wanted to allow separate implementations and/or we wanted to be able to safely pass objects across plugin (module) boundaries. (There are some things may not be doable safely across modules, like allocating memory in one, releasing it in another.) > 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. That's just moving the issue. You have to attach version to *something* anyway. Instead of having a plugin system for image loaders, and a plugin system for sound renderers, and a plugin system for meshes, and ... so on, we have a generic plugin system, and the interface versions also serve as our plugin versions. > 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), Exactly. SCF must've been written sometime around the turn on millenium, when the most popular compilers were VisualC++ 6 and gcc 2.95. I don't think dynamic_cast<> was reliably useable back then. (And I'm still skeptical about it, considering that stuff like passing exceptions across module boundaries didn't work with g++ until recently.) > 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. I don't consider it overly complex, once one got used to it. If you know about separating interfaces and implementation you're halfway there ;p Not to mention that going away from SCF would simply mean a lot of work and effort. Some things would simply have to be implemented from scratch. And for things which are not in C++ - like reference counting or weak references - you would need some custom code, anyway. -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
