"Robert Ramey" writes:

Thread documentation contains some dire warnings about using the package with MFC. Will this patch permit these warnings to be ignored and use the thread package with MFC?

I'm not sure which warnings you're referring to, but if I can apply the patch successfully in a way that works with and without MFC then yes, the thread library will be usable alongside MFC. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

Igor MI writes:

Is it safe to comment it out? I mean I know I will lose some memory resources and thats fine by me, are there any other side effects of commenting this hook?

For threads started with boost::thread then there should be no side effects. The "leak" affects threads not started with boost::thread, such as the main thread. Any use of boost::this_thread::get_id() from such a thread will allocate some memory for the ID, which won't be freed until app exit. The big issue is with boost::thread_specific_ptr --- any non-NULL pointers normally have their object destroyed on thread exit, but this won't happen for non-boost threads if the exit handler is not called. You can call it manually --- the function to call is on_thread_exit() from boost/thread/detail/tss_hooks.hpp Anthony -- Anthony Williams Author of C++ Concurrency in Action | http://www.manning.com/williams Custom Software Development | http://www.justsoftwaresolutions.co.uk Just Software Solutions Ltd, Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK

tinkertom writes:

I would like to know when this patch is made available. I am having the same issue and commenting out that line fixed my problems as well. Will you reply to this when it is available?

Yes. Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams just::thread C++0x thread library | http://www.stdthread.co.uk Just Software Solutions Ltd | http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

aaaaa .... what do you use instead for development of a C++ windows GUI program? Robert Ramey peter_foelsche@agilent.com wrote:

It amazes me, that there are still people working with MFC. It does not make much sense to use MFC, after C++ Exception Handling was introduced in 1995. After C++ Exception Handling was introduced one can use constructors to allocate fallible resources.

I've heard that even Microsoft doesn't use MFC :)

What do they use? -- Scanned for viruses and dangerous content at http://www.oneunified.net and is believed to be clean.

Andreas Masur wrote:

On Apr 11, 2009, at 5:20 PM, Ray Burkholder wrote:

...

...

I've heard that even Microsoft doesn't use MFC :)

What do they use?

Well...currently they more or less shift over to more WPF (Windows Presentation Foundation) for their *big* applications such as Visual Studio. Nonetheless, as already indicated before in this thread....MFC is far from being dead. It got left aside for a couple of years but Microsoft did overhaul it quite substantially not that long ago.

Ciao, Andreas

So far to my knowledge only the text editor in VS2010 is implemented using WPF, and probably a lot of other newer features but the majority is still MFC and COM

Ray Burkholder wrote:

...

I've heard that even Microsoft doesn't use MFC :)

What do they use?

They use MFC, office is MFC. A lot of the stuff they use is COM based now since vista. Otherwise they are rapidly moving towards .NET based everything except in the OS

Well, I guess I'm just an amazing guy. Actually, I'm not all that happy with MFC. But whenver I consider something another alternative, I find them lacking. MFC is a huge body of code which is (mostly) well documented. I typically need and application to support some other project. Recent examples have been a GUI interface to and embedded system. My customers expect this "tail end" application to be doable in say two weeks or so. And they want it to "look like" a "standard" windows app including dockable tool bars, menus, email and web connectivity, support for things like file drag and drop. etc. The only thing I see that can do this besides MFC is Visual Basic. I haven't looked at C#. But those have even bigger downsides. As I said before, I have a lot of complaints about it, but I don't seen anything available that is nearly as comprehensive for windows application development. Robert Ramey peter_foelsche@agilent.com wrote:

last time I developed a GUI application for windows (in 1998), I was using C++ and Win32.

That might explain it.

We tried MFC and it just did not do it. I remember sick solutions for sick problems in MFC, like sending messages to be called back again later.

I simply wrote some C++ wrappers for win32 calls. And I joined these wrappers into base class and member class relationships. The resulting code was very clear, short and maintainable. It contained an activex control container (written in C++) -- not using ATL.

I'm amazed that there are still C++ programmers, which don't know about how to wrap a fallible Win32 resource into a C++ class and how to chain such classes into base and member class relationships.

I'm amazed that there still seem to be C++ programmers, which don't know how to abort the construction of an object.

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Thursday, April 09, 2009 12:17 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Boost thread conflicts with MFC

aaaaa .... what do you use instead for development of a C++ windows GUI program?

Robert Ramey

peter_foelsche@agilent.com wrote:

...

It amazes me, that there are still people working with MFC. It does not make much sense to use MFC, after C++ Exception Handling was introduced in 1995. After C++ Exception Handling was introduced one can use constructors to allocate fallible resources.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

----------------------------------------

To: boost-users@lists.boost.org From: Date: Thu, 9 Apr 2009 12:56:20 -0800 Subject: Re: [Boost-users] Boost thread conflicts with MFC

Well, I guess I'm just an amazing guy.

Actually, I'm not all that happy with MFC. But whenver I consider something another alternative, I find them lacking. MFC is a huge body of code which is (mostly) well documented. I typically need and application to support some other project. Recent examples have been a GUI interface to and embedded system. My customers expect this "tail end" application to be doable in say two weeks or so. And they want it to "look like" a "standard" windows app including dockable tool bars, menus, email and web connectivity, support for things like file drag and drop. etc.

Have you considered java for the gui? You can get platform-look-and-feel etc but if your customers absolutely need it to look like Windoze, well... I wouldn't rec it for performance but if you need a gui it is safe and has a lot stuff and has a native interface. It is also a bit more portable than MFC LOL. And, I have to admit I'm still ticked off that the utiliy app that came with my wireless card has to be killed or, even while minimized, it uses up all the GDI objects in a few hours and crashes my machine. If you need to include some production code as an "Afterthought" java avoids really bad things like memory leaks etc...

The only thing I see that can do this besides MFC is Visual Basic. I haven't looked at C#. But those have even bigger downsides.

_________________________________________________________________ Windows Live™: Keep your life in sync. http://windowslive.com/explore?ocid=TXT_TAGLM_WL_allup_1a_explore_042009

On Apr 9, 2009, at 2:23 PM, Robert Ramey wrote:

Mike Marchywka wrote:

...

Have you considered java for the gui? You can get platform-look-and-feel etc but if your customers absolutely need it to look like Windoze, well... I wouldn't rec it for performance but if you need a gui it is safe and has a lot stuff and has a native interface. It is also a bit more portable than MFC LOL.

I was always turned off by java. My perception was that as an interpreted language it was going to be slower than C++. Why learn yet another language just to go slower.

The clincher was that I got a contract to take over a project that had missed its delivery target and the software wasn't even close. The hard ware was all done and tested so there was huge financial pressure to deliver the machine. (usually I only get a job when every other alternative has been exhausted). The previous programmers had taken this approach. It was very, very slow. This ratified my prejudice. I took the job with the understanding I was to produce a working prototype in 30 days. I keep the C++ part and added on a gui with mfc. Made the deadline with a couple of days to spare.

...

And, I have to admit I'm still ticked off that the utiliy app that came with my wireless card has to be killed or, even while minimized, it uses up all the GDI objects in a few hours and crashes my machine. If you need to include some production code as an "Afterthought" java avoids really bad things like memory leaks etc...

The hassles with things like memory leaks, threading races, etc with this application were what led me to boost in the first place. That's how I got here. Currently I prefer to use boost for the "guts" and MFC for the "GUI viewer/manuiplator". But they don't always play nice together. This my core complaint with MFC. It's too coupled so you endup sucking in a lot of stuff you don't want.

When I look at wxWidgets, QT, etc. I see they have classes for strings, multithreading, etc. This gives me pause as it would seem that the GUI layer might be coupled to other parts of the library which I would prefer to use boost for.

I've also been looking at WTL (microsoft Windows Template Library) which looks like a thin templatized layer over Win32.

I'm sort of limited in that I need a system which "just works" rather "can be made to work".

Have you looked at: http://smartwin.sourceforge.net/ I have never tried it (if I did Windows GUIs I would check it out) so I cannot vouch for it, but it sounds interesting: "SmartWin++ is a modern designed C++ library, it uses STL where possible and boost where needed..." "...We believe that STL and Boost are good tools and should be used in favor of creating your own bug-prone classes to substitute them! If it exists in Boost or in STL it does NOT exist in SmartWin++!! :)..." "... SmartWin++ does NOT try to solve your marriage problems. It cares only about GUI. If you need a network library, search elsewhere. SmartWin++ will not solve your TCP/IP problems or your HTTP problems or your Dijkstra's Extra problems! SmartWin++ is about GUI, nothing more, nothing less! We try to be the best in ONE area which is GUI development! This makes the library small, slick, fast and good looking! ;)" -- Michael

On a couple of occasions I've seen teams abandon MFC for WTL, though the lack of documentation and the fact that it's not officially supported by Microsoft is a problem. On Thu, Apr 9, 2009 at 1:56 PM, Robert Ramey wrote:

Well, I guess I'm just an amazing guy.

Actually, I'm not all that happy with MFC.  But whenver I consider something another alternative, I find them lacking.  MFC is a huge body of code which is (mostly) well documented.  I typically need and application to support some other project.  Recent examples have been a GUI interface to and embedded system.  My customers expect this "tail end" application to be doable in say two weeks or so. And they want it to "look like" a "standard" windows app including dockable tool bars, menus, email and web connectivity, support for things like file drag and drop.  etc.

The only thing I see that can do this besides MFC is Visual Basic. I haven't looked at C#.  But those have even bigger downsides.

As I said before, I have a lot of complaints about it, but I don't seen anything available that is nearly as comprehensive for windows application development.

Robert Ramey

peter_foelsche@agilent.com wrote:

...

last time I developed a GUI application for windows (in 1998), I was using C++ and Win32.

That might explain it.

...

We tried MFC and it just did not do it. I remember sick solutions for sick problems in MFC, like sending messages to be called back again later.

I simply wrote some C++ wrappers for win32 calls. And I joined these wrappers into base class and member class relationships. The resulting code was very clear, short and maintainable. It contained an activex control container (written in C++) -- not using ATL.

I'm amazed that there are still C++ programmers, which don't know about how to wrap a fallible Win32 resource into a C++ class and how to chain such classes into base and member class relationships.

I'm amazed that there still seem to be C++ programmers, which don't know how to abort the construction of an object.

-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Thursday, April 09, 2009 12:17 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Boost thread conflicts with MFC

aaaaa .... what do you use instead for development of a C++ windows GUI program?

Robert Ramey

peter_foelsche@agilent.com wrote:

...

It amazes me, that there are still people working with MFC. It does not make much sense to use MFC, after C++ Exception Handling was introduced in 1995. After C++ Exception Handling was introduced one can use constructors to allocate fallible resources.

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

peter_foelsche@agilent.com wrote:

...

last time I developed a GUI application for windows (in 1998), I was using C++ and Win32.

That might explain it.

you mean, MFC has dramatically changed meanwhile?

Michael Fawcett wrote:

On Fri, Apr 10, 2009 at 12:21 PM, wrote:

...

...

peter_foelsche@agilent.com wrote:

...

last time I developed a GUI application for windows (in 1998), I was using C++ and Win32.

That might explain it.

you mean, MFC has dramatically changed meanwhile?

While I don't advocate MFC (I suggest ATL or WTL), MFC was version 6.x in 1998. There have been 6 releases since then, and it's now at version 9.x.

Quote for the latest one from Microsoft's Download Center:

"The VC++ 2008 MFC libraries have been extended to support creation of applications that have:

* Office Ribbon style interface

* Office 2007, Office 2003 and Office XP look and feel

* Modern Visual Studio-style docking toolbars and panes

* Fully customizable toolbars and menus

* A rich set of advanced GUI controls

* Advanced MDI tabs and groups

* And much more!"

Actually for me one should add * context sensitive help * support for addng 3rd party controls * black box support of COM automation * free support for file system stuff * idiot proof implemenations for things like and internet connection with http protocol * complete and consistent documentation with the same practice and format throughout. But this all comes with a cost - conflict with other libraries. It's not that I'm all the crazy about this stuff. It's just that the people I do this for expect a "professional looking application" (That is some thing that looks like the applications they are used to). And that won't pay me to spend any thing more than the minimum time required to get it done. So I'm addicted to libraries of all kinds.

Robert, one of the nice things about ATL is that it doesn't require that your application ship with support DLLs like MFC requires.

with the installation of VC 9.0 on my system - this has suddenly - without warning - become a huge problem for me. I downloaded WTL sometime ago and liked the fact that it would probably be easier for me since I'm familiar with MFC. I expect that I will try this in the future. I realise that what I really want is what everyone really wants. A platform independent GUI library which does what MFC, VB, etc do. Use a wizard to generate a skeletal application, Layout a GUI, automatically generate a working app, fill in the hooks to the backend code. Oh and don't forget real documentation with sample applications. Microsoft has done this - but its a love/hate thing. It works but then I have to deal with a few hacks with every project to get everything to play together. I suppose that's why we earn the big bucks.

ATL also uses constructors to initialize objects, instead of two-phase initialization like MFC.

I'll look into it. Robert Ramey

--Michael Fawcett

On Apr 11, 2009, at 12:49 AM, Raindog wrote:

[...] What I don't understand is why nearly every C++ GUI framework out there tries to be the next C++ standard in that they all provide strings, containers, network classes, xml parsers, etc. If you already have a code base, you have to write simple wrappers around everything just so you can communicate with the GUI library.

I agree 100%....this seems to be an (unfortunate) trend with many libraries (not only in regards to GUI development either). Sometimes I look at the facilities of a certain library and you can literally see the questions marks on my face once I hit things that barely have to do with the original target of the library.

SmartWin++ looked like it definitely had the right philosophy but sadly, it appears to be abandoned in favor of some ajax project by the authors. Cppgui looks promising too but it is pretty new and incomplete

Thay may actually be a result of not being considered for real projects. I certainly cannot speak for the owners of SmartWin++ however, one really wonders if acceptance of a library grows once it adds more and more (hardly related or unrelated) stuff to it. Or whether it is more like a *ego* thing in building the ultimate one and only library. Certainly I don't imply any offense to any library creator/developer/ maintainer...it just some things I try to understand.... Ciao, Andreas

Andreas Masur wrote:

On Apr 11, 2009, at 12:49 AM, Raindog wrote:

...

[...] What I don't understand is why nearly every C++ GUI framework out there tries to be the next C++ standard in that they all provide strings, containers, network classes, xml parsers, etc. If you already have a code base, you have to write simple wrappers around everything just so you can communicate with the GUI library.

I agree 100%....this seems to be an (unfortunate) trend with many libraries (not only in regards to GUI development either).

Unfortunately some of these libraries are old. MFC and WxWindows have their own Strings classes because they needed them before the standards solidified or were well supported. This is just the cost of getting something done. In some cases, the interface propagated through the entire system and can't be easily removed, in others cases, the classes are just there for backward compatibility and can be ignored. WxWindows is a nice cross platform gui toolkit, but when you are targeting MS windows, the native toolkits make it much easier to produce polished apps. Carl -- Carl Zmola czmola@woti.com

Robert Ramey wrote:

aaaaa .... what do you use instead for development of a C++ windows GUI program?

C++/CLI. It is an extension to C++. It is a RAD language which makes GUI design much easier than MFC. It is a better .Net language than C# and will do .Net GUI using Windows Forms. One can easily mix standard C++ libraries/code with it. But the poster who assumed that Microsoft no longer supports MFC is completely wrong, even though I also dislike MFC. They are actually putting almost all C++ work into MFC, mainly because Microsoft will never allow C++/CLI to seriously compete with their own .Net langauge, C#, even though C++/CLI is a superior .Net language thanks to Herb Sutter.

Robert Ramey

peter_foelsche@agilent.com wrote:

...

It amazes me, that there are still people working with MFC. It does not make much sense to use MFC, after C++ Exception Handling was introduced in 1995. After C++ Exception Handling was introduced one can use constructors to allocate fallible resources.

MFC uses methods instead of constructors to initialize objects. ________________________________ From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of console shark Sent: Thursday, April 09, 2009 13:05 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Boost thread conflicts with MFC What does exception handling have to do with whether one uses MFC or not? ________________________________ From: "peter_foelsche@agilent.com" To: boost-users@lists.boost.org Sent: Thursday, April 9, 2009 1:59:55 PM Subject: Re: [Boost-users] Boost thread conflicts with MFC It amazes me, that there are still people working with MFC. It does not make much sense to use MFC, after C++ Exception Handling was introduced in 1995. After C++ Exception Handling was introduced one can use constructors to allocate fallible resources. _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users