Summary: Product feedback about ""Visual C++""
SeeAlso: ProductFeedback, VisualCPlus_Plus@Wikipedia

The MSDN team have started a central product feedback site at http://labs.msdn.microsoft.com/productfeedback/ - you can submit bug reports straight into their database! We'll gradually start deprecating this wiki, and pointing people over there instead -- JonathanHardwick

Standard C++ and MFC/ATL

needed. MFC would be great if it gave me a set of thin class wrappers around the ""WinAPI"" that would support the 'resource deallocation through destruction of temporary objects' paradigm and which throws an exception when an error occurs so I ""don't"" have to check return values. It gives this for the GDI classes, but I have felt the need for the file API (""CFile"" and its derivatives are not enough), the registery API as well as a whole host of other ""APIs"" and as a result have had to invest valuable time in coming up with my own implementation of a thin class wrapper. Similarly, wherever MFC imposes an execution sequence (e.g. if I register multiple document templates, by default it pops up a 'nasty' dialog box and as far as I know there is no intuitive way to override this behavior) it should provide an intuitive way of overriding that behaviour (provide a template argument that takes a ""CDialog"" derived class which the framework then calls). In short, I dearly want MFC/ATL to undergo a major overhaul that would bring it in conformance with current accpeted ""C++"" paradigms and idioms and more importantly which will allow us MORE flexibility in modifying behaviour than the current framework allows. (Ideally, this modification will be through template instantiation and multiple inheretence as in ATL. So the end result would be something like WTL with document template architecture etc and ATL added to it. No need for MFC AND ATL.)

As far as ATL is concerned, its ok it should somehow use the STL where possible (e.g. string instead of ""CString"").

Also, why am I insisting on using STL? OK multiple reasons here.

1) I once debugged some downloaded source code that relied on the MFC collection classes and was crashing. So I went on changed ""CString"" to string and MFC arrays and linked lists to STL ones and hey presto bug solved. OK, admittedly this would mean the MFC collections should be made bug free. But really why reinvent the square wheel?

2) You just ""won't"" believe the number of times we have written a desktop app and the client wants some feature to be implemented as daemon to run on their unix servers. So what we do is make a very very sharp distinction between business logic and GUI. To the extent of creating inner classes in ""CDialog"" with names like ""CBlahBlahManager"" and keeping the business logic (e.g. calculating a text box field or querying data from the database) in them. And at the interface we have to convert string to ""CString"" by hand which is a HASSLE. Again, one solution would be to have windows on the server side everywhere. hahaha. Well, until that happens and the world becomes a better (worse?) place it would be really helpful. And again, WHY REINVENT THE SQUARE WHEEL? Also, using STL might make the development team use the design philosophy of the STL more often and that would be great. I mean the way I can apply <algorithm> members to containers, pass predicate objects/functions to modify behaviour is superb and one can get used to it really quickly once they get a hang of it. -- compiler

---

Lets see if I can figure how this Wiki thing works. To the poster above on ATL/MFC, you've gone into some detail of your problems with MFC but not much on ATL. What does ATL do "wrong" in your opinion? While we're at it, if anyone at MS is reading, why not open source WTL? It would be a HUGE success

---

Microsoft did release WTL to Open Source - you can find it on Source Forge

http://sourceforge.net/projects/wtl/