Ove Kaaven wrote:
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.
I don't think anyone was talking about MFC. MFC is written in some strange language MS made up using CPP macros and visual studio wizards. Calling it C++ is an insult to C++.
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)
I believe you meant winelib. I'm with you on that one.
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).
I'm sorry, it has been YEARS since I wrote anything OLE related (my very first Windows program was an OLE server, hand coded, that did a shell extension. That was my only interaction with OLE). As such, I will not presume to decide whether that statement is correct or not.
I do know, however, a thing or two about C++. I have coded quite a lot in C++, and I believe I am pretty much aware of the things the language does well, and the things it is poor at. It all boils down to this - C++ is a language (much much) more difficult to learn well than C, and OOP is something that is difficult to do right. Add to that the fact that there are (quite a few) jobs for which OOP is the wrong tool, and you get the origins of the common belief that C++ is evil.
Personally, I *love* C++. I don't use it for OOP much, because I spent the last 3/4 year trying to set up a business, and the preceding 2 1/4 years writing kernel level code for CheckPoint's FireWall-1. Not much C++ used there, for reasons purely technical. I do believe that, ABI interface problems aside (nothing unsolveable with extern "C"), C++ is a superior language to use to C for almost any task, provided you can master the art of not getting carried away with using features you don't need (with OOP being one of those). Granted, it's a difficult art to master.
When working with environments where most of those differences would amount to just more warnings for logic errors when using C++, I don't mind saying "everyone knows C, let's use only that". However, when really complicated stuff is involved (Boaz mentioned Direct something codecs), I believe there is room to use the best tool for the job.
To sum it all up - it may not be MFC (as I agree with Ove that MFC can be saftely left out of Wine proper), and it may not be OLE (as I don't know it well enough to judge), but I think C++ does have a place in certain parts of Wine. I do believe that most of the "less readable" claims are a result of either over-engineering the solution or people's expectance to "just read" the code. OOD will, occasionally, require you to read the docs before messing with the code.
Shachar