On Thursday July 09, 2009 5:32 PM Chris Robinson wrote: >> With the same argument you could say that writing COM objects has to >> be done in C++. Yet Wine has lots and lots of COM code written all in >> standard C. > >It has to, because the class vtable layout and calling convention can >be different in Windows than how the host system's compiler will generate it. >COM objects have to interface with existing Windows code, and so need >to be setup in memory in a specific way.
Not entirely sure where your "It has too" is pointed at. If it is about COM code being written in C then it is not entirly true. All the MS examples about COM nowadays are completely in C++ and some newer API headers seem to not even include the C part. But of course that code is meant to be compiled with Visual C++ and I could see trouble trying to get the exact binary layout with gcc. This is maybe not such a problem with newest gcc but was certainly a problem with older versions. >If OSX will always have Obj-C support, and the Obj-C code can be >restricted to OSX-only code, then the only sticking point, in my eyes, >would be how maintainable it is. After all, if only one or two people >can work with Obj-C code, it can bit-rot that much more quickly. I think this is in fact the major issue here. There is certainly interest in starting such a project but maintaining it is a completely different beast. Rolf Kalbermatter