[Boost-users] Boost thread conflicts with MFC
Igor MI
I updated from 1.35 to 1.38 when the conflicts started. My MFC application
wouldn't start, it would throw an exception. I pinned down the problem to
the hook that boost thread library is using which is located in tss_pe.cpp:
extern "C"
{
extern BOOL (WINAPI * const _pRawDllMain)(HANDLE, DWORD,
LPVOID)=&dll_callback;
}
What I did is comment this declaration and rebuild the library and now my
application seems to be running normally. My question is can boost thread
library run properly without this hook? If not, what other solution do you
suggest.
Thanks, Igor.
--
View this message in context: http://www.nabble.com/Boost-thread-conflicts-with-MFC-tp22946168p22946168.html
Sent from the Boost - Users mailing list archive at Nabble.com.
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Anthony Williams
> I updated from 1.35 to 1.38 when the conflicts started. My MFC application
> wouldn't start, it would throw an exception. I pinned down the problem to
> the hook that boost thread library is using which is located in tss_pe.cpp:
>
> extern "C"
> {
> extern BOOL (WINAPI * const _pRawDllMain)(HANDLE, DWORD,
> LPVOID)=&dll_callback;
> }
>
> What I did is comment this declaration and rebuild the library and now my
> application seems to be running normally. My question is can boost thread
> library run properly without this hook? If not, what other solution do you
> suggest.
This hook is necessary when using static-linked boost.thread in a DLL,
in order to ensure that the thread-specific data allocated for each
thread is cleaned up.
I have been sent a patch to handle this case, and will try and integrate
it into boost.thread sometime soon.
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
Robert Ramey
with MFC. Will this patch permit these warnings to be ignored and use
the thread package with MFC?
Robert Ramey
Anthony Williams wrote:
> Igor MI <kostadi...@gmail.com> writes:
>
>> I updated from 1.35 to 1.38 when the conflicts started. My MFC
>> application wouldn't start, it would throw an exception. I pinned
>> down the problem to the hook that boost thread library is using
>> which is located in tss_pe.cpp:
>>
>> extern "C"
>> {
>> extern BOOL (WINAPI * const _pRawDllMain)(HANDLE, DWORD,
>> LPVOID)=&dll_callback;
>> }
>>
>> What I did is comment this declaration and rebuild the library and
>> now my application seems to be running normally. My question is can
>> boost thread library run properly without this hook? If not, what
>> other solution do you suggest.
>
> This hook is necessary when using static-linked boost.thread in a DLL,
> in order to ensure that the thread-specific data allocated for each
> thread is cleaned up.
>
> I have been sent a patch to handle this case, and will try and
> integrate it into boost.thread sometime soon.
>
> Anthony
_______________________________________________
Anthony Williams
> 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
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?
--
View this message in context: http://www.nabble.com/Boost-thread-conflicts-with-MFC-tp22946168p22966177.html
Sent from the Boost - Users mailing list archive at Nabble.com.
_______________________________________________
Anthony Williams
> 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
peter_f...@agilent.com
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.
Robert Ramey
program?
Robert Ramey
Emil Dotchevski
> peter_f...@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.
>
> program?
I've heard that even Microsoft doesn't use MFC :)
I'm not a C++ GUI guy but I'd rather use a third-party lib like Qt or
do WIN32 directly.
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
peter_f...@agilent.com
I was using C++ and Win32.
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.
Robert Ramey
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_f...@agilent.com wrote:
> last time I developed a GUI application for windows (in 1998),
> I was using C++ and Win32.
That might explain it.
Michael Fawcett
>
> 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.
We mostly use C# and ATL for C++. Have you considered ATL? For our
cross-platform apps we use QT, GTK and wxWidgets. Sometimes we just
use MainWin which has a port of most of the Win32 library.
--Michael Fawcett
Mike Marchywka
----------------------------------------
> To: boost...@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
console shark
From: "peter_f...@agilent.com" <peter_f...@agilent.com>
To: boost...@lists.boost.org
Sent: Thursday, April 9, 2009 1:59:55 PM
Subject: Re: [Boost-users] Boost thread conflicts with MFC
Emil Dotchevski
the lack of documentation and the fact that it's not officially
supported by Microsoft is a problem.
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode
peter_f...@agilent.com
MFC uses methods instead of constructors to initialize objects.
From:
boost-use...@lists.boost.org
[mailto:boost-use...@lists.boost.org] On
Behalf Of console shark
Sent: Thursday, April 09, 2009
13:05
To: boost...@lists.boost.org
Subject: Re: [Boost-users] Boost
thread conflicts with MFC
Robert Ramey
> 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".
Robert Ramey
John Wilkinson
WTL is open source, and has been for several years: http://sourceforge.net/projects/wtl/
There is a support list on Yahoo! Groups: http://tech.groups.yahoo.com/group/wtl/ It has a fair amount of sample source, and some extensions. There are also some WTL resources available on CodeProject.com.
Disclosure: I am the moderator of the Yahoo group, and a member of the project on SourceForge. Development activity on the project has been fairly low for a while, and I'm not sure what the intent is for a new version (the latest is coming up on two years old).
John
Michael Olea
Raindog
>
> 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
>
It looks like this library hasn't been worked on in nearly 2 years.
Felipe Magno de Almeida
> aaaaa .... what do you use instead for development of a C++ windows GUI
> program?
I use cppgui (http://www.assembla.com/wiki/show/cppgui) and I implement
the widgets as I go along.
> Robert Ramey
[snip]
--
Felipe Magno de Almeida
peter_f...@agilent.com
> > 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
>> peter_f...@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!"
Robert, one of the nice things about ATL is that it doesn't require
that your application ship with support DLLs like MFC requires.
ATL also uses constructors to initialize objects, instead of two-phase
initialization like MFC.
--Michael Fawcett
Robert Ramey
> On Fri, Apr 10, 2009 at 12:21 PM, <peter_f...@agilent.com> wrote:
>>> peter_f...@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
Raindog
> 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.
>
>
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.
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
Andreas Masur
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
Igor R
boost.gui library:
http://lists.boost.org/Archives/boost/2003/07/50400.php
Unfortunately, it faded with no practical results...
Ray Burkholder
> 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.
Edward Diener
> 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.
Andreas Masur
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
Raindog
> >
> > I've heard that even Microsoft doesn't use MFC :)
> >
>
> What do they use?
>
>
>
now since vista. Otherwise they are rapidly moving towards .NET based
everything except in the OS
Raindog
>
> 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
using WPF, and probably a lot of other newer features but the majority
is still MFC and COM
Andreas Masur
On Apr 11, 2009, at 9:32 PM, Raindog wrote:
> Andreas Masur wrote:
>>
>> [...]
>> 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
Yes...currently they only annunced the rewrite of the shell in Visual
Studio 2010. But I actually expect more to come over time....certainly
they won't turn one of their flagship applications completely over
right away.
Anyway....I fear that this thread is already driven far beyond its
original topic....thus...I actually should refrain from pushing it
further.... ;)
Ciao, Andreas
tinkertom
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?
Anthony Williams-4 wrote:
>
> I have been sent a patch to handle this case, and will try and integrate
> it into boost.thread sometime soon.
>
--
View this message in context: http://www.nabble.com/Boost-thread-conflicts-with-MFC-tp22946168p23024393.html
Sent from the Boost - Users mailing list archive at Nabble.com.
Carl Zmola
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
czm...@woti.com
Anthony Williams
> 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