[boost] Re: the boost::signal sample crashes
Bohdan wrote: E. Gladyshev [EMAIL PROTECTED] wrote in message Do you mean link of incompatible library problems ? If so ... as mentioned this is problem of boost build system and it will be finally solved. Look at boost::regex, it doesn't have such problems for compilers supporting #pragma comment. It means that correct library is linked automatically. Does regex address the issue of alignment and calling convention etc and other options (in BCB, treat enums as ints is a good one to screw up libraries) by wrapping the headers in push/pop option statements? Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
This is just what I would like to see in boost. I have created a duplicate set of headers for boost (same names, same structure but in boost_wrappers which do this and include the original header between the push and pop). We had a discussion about this a while back and I am all for it, but people seemed against it. I'll try and find a link to the discussion. Thanks Russell John Maddock wrote: Does regex address the issue of alignment and calling convention etc and other options (in BCB, treat enums as ints is a good one to screw up libraries) by wrapping the headers in push/pop option statements? Yes: #ifdef __BORLANDC__ # pragma option push -a8 -b -Vx -Ve -pc -w-8027 #endif // code here #ifdef __BORLANDC__ # pragma option pop #endif We should standardize this boost-wide really in some kind of prefix/suffix header. John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
Beman Dawes wrote: At 12:53 PM 8/6/2003, Russell Hind wrote: Perhaps coordinate with John Maddock? He is really our config header expert. So John, would you be interested in trying to get this sorted out for the next release? As I have said, I currenly only use BCB, and so can't offer much help for other compilers. Would it be best to have something like a boost/config/preinclude.hpp file which includes a compiler specific pre-include and then a boost/config/postinclude.hpp for afters? I've created ones for BCB which I use here, that simply do #praga nopushoptwarn #pragma option push -a8 -b -Vx -Ve -pc -w-8027 for pre and #pragma nopushoptwarn #pragma option pop for post (probably don't need the nopushoptwarn in postinclude though). These options are from regex. I may be a better idea not to include disabling warnings in the default boost options? And also, It might be worth adding -Vg- to disable codeguard for boost, unless the new build system will build CodeGuard libraries as well as non-cg enabled libraries. These options also should be the same as the default jam options for the compiler also. What do you think? Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: the boost::signal sample crashes
At 12:53 PM 8/6/2003, Russell Hind wrote: Beman Dawes wrote: I don't think people were against the idea of solving the problem, but rather there is a need for a unified prefix/suffix header solution such as John is suggesting. Developers need a canned solution; they can't be asked to code #ifdefs and pragmas for compilers they know nothing about. I thought people were against it for reasons of setting up test cases and such, not because of the implementation. Well, some of us are trying to get out of doing additional work:-) At the time, I assumed it would be a pre-header and post-header for each compiler supported under boost. In that case, it would be good thing to get in for the 1.31.0 release if possible. I can supply the options for Borland but not other compilers. Perhaps coordinate with John Maddock? He is really our config header expert. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: the boost::signal sample crashes
Russell Hind wrote: Peter Dimov wrote: To make out-of-line libraries plug and play we may have to prefix/suffix all* inline libraries as well, making their users pay for something they do not need. * Under the assumption that they are potential future dependencies. I understand this (and it was because signals relies on shared_ptr that I was bitten by it), The main problem with shared_ptr 1.30.x and below is that the single- and multithreaded versions are incompatible. The CVS version is now binary compatible on Windows, so 1.31 will work across different threading models; still, the correct default for Borland should probably be to do a multithreaded build. By the way, this can't be fixed with prefix/suffix headers. but by default the libraries are all built using the default compiler option for the tool. The inlined (header-only) library are only tested against that default set, so why not enforce that default set for all boost libraries? If an individual library author then wants to enforce another set (different alignment or something) for optimisation purposes, then let then over-ride the defaults, But I don't want to enforce a set. I want (for example) shared_ptr to use whatever set the user has specified and not to override his settings. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: the boost::signal sample crashes
On Wed, 6 Aug 2003, John Maddock wrote: Does regex address the issue of alignment and calling convention etc and other options (in BCB, treat enums as ints is a good one to screw up libraries) by wrapping the headers in push/pop option statements? Yes: [solution] We should standardize this boost-wide really in some kind of prefix/suffix header. John. Absolutely. Doug ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
Peter Dimov wrote: To make out-of-line libraries plug and play we may have to prefix/suffix all* inline libraries as well, making their users pay for something they do not need. * Under the assumption that they are potential future dependencies. I understand this (and it was because signals relies on shared_ptr that I was bitten by it), but by default the libraries are all built using the default compiler option for the tool. The inlined (header-only) library are only tested against that default set, so why not enforce that default set for all boost libraries? If an individual library author then wants to enforce another set (different alignment or something) for optimisation purposes, then let then over-ride the defaults, but at least everywhere that library is used, it will use the same compiler options and stop the problems of hangs/crashes at runtime due to mis-matched settings. Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: the boost::signal sample crashes
I'm not sure how to proceed with this so if there is anything I can do in the meantime, let me know. Feel free to e-mail me off the list. ABI prefix and suffix headers are now in cvs, as is boost/config/auto_link.hpp for selecting link libraries - for now refer to the header for usage, I'll add this to the config docs in due course, but lets get it running through the regression tests first... John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: the boost::signal sample crashes
So John, would you be interested in trying to get this sorted out for the next release? As I have said, I currenly only use BCB, and so can't offer much help for other compilers. Yep. Would it be best to have something like a boost/config/preinclude.hpp file which includes a compiler specific pre-include and then a boost/config/postinclude.hpp for afters? I'm wondering how complicated to make this - one option would be to do something a little like the config system does and have: #ifdef BOOST_ABI_INCLUDE #include BOOST_ABI_PREFIX #endif // code... #ifdef BOOST_ABI_INCLUDE #include BOOST_ABI_SUFFIX #endif which would let users define their own prefix/suffix headers if they want to. I've created ones for BCB which I use here, that simply do #praga nopushoptwarn #pragma option push -a8 -b -Vx -Ve -pc -w-8027 for pre and #pragma nopushoptwarn #pragma option pop for post (probably don't need the nopushoptwarn in postinclude though). Yep. These options are from regex. I may be a better idea not to include disabling warnings in the default boost options? Some of those warnings can get pretty pesky at times And also, It might be worth adding -Vg- to disable codeguard for boost, unless the new build system will build CodeGuard libraries as well as non-cg enabled libraries. Does adding codeguard info break the ABI? I didn't think it did so (there are no codeguard protected std libraries for example), and I mix and match codeguard and non-codeguard code all the time without any apparent issues... Here's what the STLPort that Borland ship is using: # pragma option push -Vx- -Ve- -a8 -b -pc -w-inl -w-aus -w-sig -w-8062 -w-8041 -w-8008 -w-80 12 -w-8027 -w-8057 -w-8091 -w-8092 -w-8066 These options also should be the same as the default jam options for the compiler also. Yes, that should be the case now I think. I'm slightly tied up this week, but I'll try and add something to regex and see how it looks. John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
John Maddock wrote: #ifdef __BORLANDC__ # pragma option push -a8 -b -Vx -Ve -pc -w-8027 #endif // code here #ifdef __BORLANDC__ # pragma option pop #endif We should standardize this boost-wide really in some kind of prefix/suffix header. Here is the discussion (it cropped up with signals library there too) http://tinyurl.com/j5xi Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: the boost::signal sample crashes
From: Beman Dawes [EMAIL PROTECTED] At 12:53 PM 8/6/2003, Russell Hind wrote: Beman Dawes wrote: I don't think people were against the idea of solving the problem, but rather there is a need for a unified prefix/suffix header solution such as John is suggesting. Developers need a canned solution; they can't be asked to code #ifdefs and pragmas for compilers they know nothing about. I thought people were against it for reasons of setting up test cases and such, not because of the implementation. Well, some of us are trying to get out of doing additional work:-) Not really. Prefix/suffix headers certainly work well for self-contained libraries (i.e. regex). The problem is that we have both inline and out-of-line libraries that depend on each other, and some of our users ( e.g. me :-) ) only need the first category. To make out-of-line libraries plug and play we may have to prefix/suffix all* inline libraries as well, making their users pay for something they do not need. * Under the assumption that they are potential future dependencies. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
Peter Dimov wrote: The main problem with shared_ptr 1.30.x and below is that the single- and multithreaded versions are incompatible. The CVS version is now binary compatible on Windows, so 1.31 will work across different threading models; still, the correct default for Borland should probably be to do a multithreaded build. By the way, this can't be fixed with prefix/suffix headers. No, you still need single/multi-threaded builds, but with out headers, I then need to add in 4-byte alignment builds, 8-byte alignment builds, different builds for different calling conventions etc. It doesn't get easy, especially for existing projects. We either end up making a custom build of the boost libs for each project? That would become a maintanence nightmare. How would you feel if you had to re-build your compiler's RTL just so you could change some project options? But I don't want to enforce a set. I want (for example) shared_ptr to use whatever set the user has specified and not to override his settings. Then we put options in to ignore the pre-post config headers so users can user there own settings if they wish, but it appears to me that most people don't care what options are set, they would just rather have it work, and currently, its very easy to break things as soon as you use a compiled lib. Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: the boost::signal sample crashes
Does regex address the issue of alignment and calling convention etc and other options (in BCB, treat enums as ints is a good one to screw up libraries) by wrapping the headers in push/pop option statements? Yes: #ifdef __BORLANDC__ # pragma option push -a8 -b -Vx -Ve -pc -w-8027 #endif // code here #ifdef __BORLANDC__ # pragma option pop #endif We should standardize this boost-wide really in some kind of prefix/suffix header. John. ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: the boost::signal sample crashes
At 09:53 AM 8/6/2003, Russell Hind wrote: John Maddock wrote: #ifdef __BORLANDC__ # pragma option push -a8 -b -Vx -Ve -pc -w-8027 #endif // code here #ifdef __BORLANDC__ # pragma option pop #endif We should standardize this boost-wide really in some kind of prefix/suffix header. Here is the discussion (it cropped up with signals library there too) http://tinyurl.com/j5xi We had a discussion about this a while back and I am all for it, but people seemed against it. I don't think people were against the idea of solving the problem, but rather there is a need for a unified prefix/suffix header solution such as John is suggesting. Developers need a canned solution; they can't be asked to code #ifdefs and pragmas for compilers they know nothing about. --Beman ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
E. Gladyshev wrote: Have you built the signals library multi-threaded or single threaded and Whatever the default build is. Single threaded. The application is set to use multi-thread run-time libraries and MFC.DLL. Not seen this specific one, the most common problem I saw was a hang so it may well not be your problem, but worth looking into. It may well be the problem. I didn't see crashes, just hangs. You have objects created inside the signals lib (non-multi-threaded) so it doesn't create/initialise the lock member variables. There is then header code which is compiled directly in your application (multi-threaded even though you only use 1 thread) and so it tries to access these non-existent locks in the objects created in single threaded signals lib. If you are going to use a multi-threaded application/run-time, you must build/link the multi-threaded version of the boost libs also. Because of the crash, you may still have another problem, but I would solve this one first, then look for the next. I saw the hangs under Borland C++ Builder, the bug may present itself in a different way under VC++. Thanks Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: the boost::signal sample crashes
--- Russell Hind [EMAIL PROTECTED] wrote:
E. Gladyshev wrote:
You have
objects created inside the signals lib
(non-multi-threaded) so it
doesn't create/initialise the lock member variables.
There is then
header code which is compiled directly in your
application
Thanks for taking a look at the problem. IMO,
distributing objects between inlines and DLL functions
is not a very good idea. The classic example is:
//intended to be used as DLL.
class A
{
public:
char* m_data;
//compiled into application
inline ~A()
{
if(m_data) delete[] m_data;
}
//calls DLL
void init();
};
void A::init()
{
m_data = new char[10];
}
IMHO, boost needs to get rid of any possibility of
this to happen. Why does boost::signal() need a
DLL/LIB in the first place? Would not be just the .h
file enough?
Eugene
__
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
___
Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
E. Gladyshev wrote: Thanks for taking a look at the problem. IMO, distributing objects between inlines and DLL functions is not a very good idea. The classic example is: It can cause problems but if you are aware of it, then you can work around it quite easily. Part of the reason in speed. Some code can be inlined to optimise things for release builds. This is a good thing IMHO. Also, some libraries are wholly or partly template based so they can't go completely in a .lib yet. I'm sure there are other reasons that other people could fill you in on. IMHO, boost needs to get rid of any possibility of this to happen. Why does boost::signal() need a DLL/LIB in the first place? Would not be just the .h file enough? It could be put in a .h, but there is a lot of code in the library and it makes sense to have it built as a .lib. Perhaps another solution would be for all the inlined code in the header to be moved into the .lib at a loss of performance. I would just prefer a solution mentioned above where the libs built by boost have different name endings for debug/release multi/single threaded. But this isn't the whole problem. The other problem is compiler options and such for the structures in the header files. For example, data alignment. boost builds with alignment of 8 for Borland by default. If your app uses another alignment option (we used to use 4 for historic reasons) then when you accessed objects returned from the dll, you would access the wrong offsets for the members because the boost headers don't force options such as this around there structures. I have created a duplicate set of headers for the parts of boost that I use that force compiler options using a #pragma push, then include the boost header, then pop those compiler options. I only ever include my wrappers so that I don't get caught by this and am free to use whatever compiler options I wish for the rest of the project. Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
E. Gladyshev wrote: IMO, I should be able to just use the library w/o this kind of workarounds. It is hard to debug these .lib/.h conflict issues. Why build the .lib at all? Why not just add the signals source file to your project? I did this for a while with thread and signals. I've since now got my own build system working with name .libs and generated headers to make sure project options are the same for the .lib and where I include the headers. I've made it easier by only using the multi-threaded libraries in boost and therefore never create the single threaded libraries. Also, boost releases don't come out that often that it is a PITA to keep up to date, although I am just about to go through it with 1.30.1 Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
[boost] Re: the boost::signal sample crashes
E. Gladyshev wrote: Anybody had problems with boost::signal? The following sample code crashes on my Win2k/VC++6 system. Have you built the signals library multi-threaded or single threaded and are you building an application of the same sort? This seems to be a common source of problems with the signal library. The default library build is single-threaded but most people appear to generate multi-threaded apps on win32 and run into problems. Not seen this specific one, the most common problem I saw was a hang so it may well not be your problem, but worth looking into. Cheers Russell ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Re: [boost] Re: the boost::signal sample crashes
Have you built the signals library multi-threaded or single threaded and Whatever the default build is. are you building an application of the same sort? The application is set to use multi-thread run-time libraries and MFC.DLL. Not seen this specific one, the most common problem I saw was a hang so it may well not be your problem, but worth looking into. The app itself is only one thread. The crash doesn't appear to have anything to do with threading. The boost::mutext and smart_ptr libraries work just fine. Eugene __ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com ___ Unsubscribe other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
