ons, 10.12.2003 kl. 08.24 skrev Shachar Shemesh:
Alexandre Julliard wrote:
"Subhobroto Sinha" subhobrotosinha@rediffmail.com 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).