ons, 10.12.2003 kl. 08.24 skrev Shachar Shemesh: > Alexandre Julliard wrote: > > >"Subhobroto Sinha" <[EMAIL PROTECTED]> writes: > > > >>However, soon many of his elves found out that technologies like > >>MFC, WTL, ATL, COM, DCOM, COM+ and other MS bloops were getting too > >>complex to be implemented using plain C, and thus developments in > >>those areas were soon in limbo. > >> > >>But that could be solved using yet another language called C++ - if > >>only Santa would let it be. > > > >You don't need Santa's permission for that, just go ahead and > >implement DCOM in C++ and show us how easy it is. I suspect you will > >quickly realize that the complexity of the problem does not come from > >having to explicitly pass the this pointer around... > > > While You are, no doubt, right about the complexity problem, I fail to > understand the "no C++ in the wine source tree" rule.
Consider that the reason could be that C++ has too many interoperability problems to solve any within an interoperability project like Wine. Just try to compile something like MFC with g++ and see how well the result would run MSVC++-compiled programs. Okay, perhaps I should say right away that it won't run, because g++ won't generate VC++-compatible code. In any case, I don't see why MFC should be part of Wine, it's not a core Windows component. There's nothing wrong with having a separate FreeMFC project outside Wine using C++ (and compiling their FreeMFC libs with MSVC++ for the benefit of Wine users) As for COM/DCOM, having implemented big parts of it myself, I'm not so sure C++ would have helped a whole lot in any case. It's a mess and the only thing you'd achieve with C++ is a different style of mess (a more unreadable one, for starters).