- Boost - lists.boost.org

RE: [boost] Re: Boost.Threads: Do we need all those mutexes?
by Batov, Vladimir 15 Jul '04

15 Jul '04

Mike, IMHO your comments below justifying different mutex types make sense. However, I feel that you look at the problem from the *implementor* point of view that is drastically different from the view of the library *user*. And I feel that the interface (representing convenience, flexibility, usability, etc.) is the first thing that a library will be judged by. I feel that for the user having different types of mutexes is inconvenient and unnecessary restricting. It is because when I create a mutex, I identify a resource that I want to serialize access to (it's a strategic decision in military terms :-) ). However, *how* I serialize the access (via blocking lock or try/timed locks) is not generally known at the time and will be defined on the case-by-case basis (when I'll be actually creating appropriate locks -- it's a tactical decision). A typical and very basic application I am working on discriminates two threads (and, therefore the appropriate mutex) -- the first always applies a blocking lock (scoped_lock) and the other thread only steps in through the successful try-lock. Having additional (and maybe unused) data in a mutex does not seem like a huge problem (as long as it does not impose performance penalties) -- memory is cheap and mutexes are not usually created in huge numbers. More so, I believe in boost there are techniques/classes minimizing waste. Best, V. > > Now that we got rid of the excess locks, how about doing the same with > the > > mutexes? > > I had considered this, but there does seem to be some benefit in having > separate mutex types, which is what I assume led to there being three > mutex types and three lock types in the original design. You've noted > these reasons below, but I'll reiterate: > > * On pthreads, the timed mutex requires an additional data member, > (condition variable) to handle cases when pthreads_timedlock isn't > supported. > > * On WinNT, the timed mutex operations require a win32 mutex object, > while the mutex and try mutex can use a win32 critical section. > > * On Win9x, the timed mutex and try mutex operations require a win32 > mutex object, while the mutex can use a win32 critical section. > > In other words, on the most widely-used platforms, collapsing the mutex > types into one imposes some penalty (larger mutex object or more limited > implementation options) on users. Also (I ask, not as a hypothetical > question, but as a request for information): is there another platform > where combining the mutex types incurs a similar or worse penalty?

2 1

Is serialization going to be in 1.32?
by Jeff Garland 15 Jul '04

15 Jul '04

Awhile back we added code and tests in date_time for serialization of dates, times, durations, etc. The tests have been disabled since serialization wasn't in CVS. However, if serialization is going to be part of 1.32 I'd like to go ahead and turn on these date_time tests. Thoughts? Jeff

1 0

Program Options failures (and fixes)
by John Maddock 15 Jul '04

15 Jul '04

Vladimir, I have some fixes for the program_options library on Win32 for you, first off here's the problem: On Win32 you must use the a dynamic runtime if you are building or using a dll: if you don't do this then separate runtimes/memory managers etc get linked to each module and the result is almost always a runtime crash some point. However you are also using std::locale and so have added std::facet-support std::locale-support to your build requirements. Doing so however, causes the static runtime to be used, so you're in a bit of a catch-22 situation here I'm afraid. You've also failed to define BOOST_ALL_DYN_LINK when *using* your dll - this is causing the mscv link failures. The patches below address both of these issues, tested with: VC7.1: everything passes. VC7.0: everything passes except the tests that use \u (unsupported). Intel 8 on vc7.1: everything passes. Intel 7.1 on vc7.1 everything pases except the tests that use \u (unsupported). Borland 5.6.4: all tests pass. Borland 5.5.1: Internal compiler error in function from_8bit, haven't investigated further yet. The fact that these tests do pass with Intel, possibly means that std::facet-support could be deprecated - it looks like Intel have fixed that problem with their recent patches. However, you may still experience problems with Metrowerks - I think there is any way around this - the dll version of the library is going to be unusable with that compiler. One final thing: you declare the environ variable in your sources, which is leading to warnings from MSVC and Intel about conflicting dll-specifications for that variable, perhaps you should include the header required rather than defining the variable yourself (unistd.h when BOOST_HAS_UNISTD_H is defined, or stdlib.h on WIN32)? John Index: build/Jamfile =================================================================== RCS file: /cvsroot/boost/boost/libs/program_options/build/Jamfile,v retrieving revision 1.2 diff -u -r1.2 Jamfile --- build/Jamfile 18 May 2004 06:38:17 -0000 1.2 +++ build/Jamfile 14 Jul 2004 10:32:56 -0000 @@ -21,7 +21,7 @@ <define>BOOST_ALL_DYN_LINK=1 # tell source we're building dll's <runtime-link>dynamic # build only for dynamic runtimes <include>$(BOOST_ROOT) <sysinclude>$(BOOST_ROOT) - std::facet-support std::locale-support + #std::facet-support std::locale-support : debug release # build variants ; cvs diff: Diffing doc cvs diff: Diffing example cvs diff: Diffing src cvs diff: Diffing test Index: test/Jamfile =================================================================== RCS file: /cvsroot/boost/boost/libs/program_options/test/Jamfile,v retrieving revision 1.4 diff -u -r1.4 Jamfile --- test/Jamfile 28 Jun 2004 09:31:28 -0000 1.4 +++ test/Jamfile 14 Jul 2004 10:32:56 -0000 @@ -19,7 +19,9 @@ run $(name).cpp <dll>../build/boost_program_options <lib>../../test/build/boost_test_exec_monitor : : : <include>$(BOOST_ROOT) - std::facet-support std::locale-support + #std::facet-support std::locale-support + <define>BOOST_ALL_DYN_LINK=1 + <runtime-link>dynamic : $(name)_dll ] ; }

2 6

STLPort linking error
by Ian McCarty 15 Jul '04

15 Jul '04

Hi, I am in the middle of moving our development from the std STL to STLPort and I am having a problem with two Athlon boxes. SuSE Linux 9.0 gcc 3.3.1 STLPort 4.6.2 Boost 1.31 I am changing an existing application to use STLPort and I have successfully completed the transition on a number of Intel boxes. When I try to build on an Athlon box I get the following error message: undefined reference to `boost::thread::thread[in-charge](boost::function0<void, std::allocator<boost::function_base> > const&)' I'm linking against libboost_thread-gcc-mt-p-1_31 and libboost_date_time-gcc-mt-p-1_31. I can't see an obvious solution so I'm hoping someone has solved this problem already. Thanks in advance, Ian. __________________________________ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail

3 2

FW: [boost] Re: "memory access violation" in boost::serialization
by Dirk Griffioen 15 Jul '04

15 Jul '04

Hi Robert, We'll see what we can do - but sadly there's no bjam port for AS400 or MVS. On both we use the unix-like environment (something like 'qshell' and the mvs version I keep forgetting), so it might be doable. The mac-version (not too much) or the unix version of the bjam sources ("file*.c", "exec*.c" "path*.c" etc) could be used as a base - on the other hand, the gnu tools like 'make' on AS400 map their calls to the 'local' calls - which is not fopen :) - so it might be tricky. We'll let you know (If anoynone has ported bjam to AS400 or MVS - I'd lve to know) Dirk Robert Ramey wrote: Dirk Griffioen wrote: I also outcommented line 125. We will, however, upgrade to #20 as soon as possible. Note that #20 and subsequent versions do not have boost/serialization/shared_count.hpp but rather use a very crude hack to gain access to private variables within shared_count. Hopefully this will be addressed in a better way in the near future. You might want to wait just a tiny bit. It looks like serialization may be included in the upcoming boost release. If the release works out soon you might want to move right to boost 1.32. If the release boggs down or for some reason its inconvenient for you do move to 1.32 - you can use to #20. #20 is the last draft. I've tested it extensively with 1.31. We have a lot of platforms here (HP, AIX, SUN, VMS, AS400 and Mainframe - with different versions of native compilers and/or gcc) and it is likely we will port to those platforms. If there's an interest, it might be possible to gather some figures. Hmmm - embarrassment of riches. It is possible you might be able to run - at least occasionally the bjam test suite for some of the less common platforms? I would love to know how boost (and of course serialization) work with AS400 and Mainframe(?). I believe the others are already covered. If you're willing to run the tests, developers might be more willing the help with the porting. Robert Ramey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

regression tests not update
by Pavol Droba 15 Jul '04

15 Jul '04

Hi, I don't know what is wrong, but it seems, that regression test are not updated. I have commited markups for failuers two days ago and they are still not used in the regression test. (Specificaly not in the metacomm tables) Also some bugfixes seems to be not applied. Can anybody check this out? Thanks, Pavol

2 1

Re:[boost] Serialization Menu
by Robert Ramey 15 Jul '04

15 Jul '04

This is an interesting question. It seems I spend half my time bouncing back and forth between boost documentation pages. When this started to happen with my own boost serialization documentation I added a navigation frame with with a static index which would let be jump right to the part that I was interested in. Eventually as I added more pages to the documentation, the scrolling started to annoy me and I implemented the current scheme. I was inspired by the boost pre-processor documentation and I don't remember whether or not I was aware of the "kind of policy" against. I've been very, very pleased with the utility of the result. I made it and checked with both IE and netscape. I haven't checked with other browsers but have no received no reports that it doesn't work. I love this system. I think it should be adopted for all boost documentation. In this way I have a collapsible navigation pane which would let me navigate all of boost rather than just the serialization library. There are a couple of issues a) I had to make it "by hand" for the serialization library. OK for a prototype - but unsatisfactory in general. Ideally it should be generated automagically by Boost.Book. After all it's just an index which I would presume Boost.Book should be generating anyway. I haven't studied boost book so I don't really know anything about it. But if it doesn't include something like this I would consider it a glaring oversight. b) I believe that with a little effort the browser portability issues could be addressed. Basically there could be two index pages - a dynamic as well as a static one. All the "documentation pages" would be unchanged. I didn't really go into this because no one seemed to have a problem with the dynamic one. Of course the above doesn't raise the key issue that Dave raises. Should it be removed now? Should it be replaced with anything? - if so what? I would prefer to leave as it is. A final point regarding boost book. When I go to the main boost page and select nightly CVS I get a page which seems to have the look/feel that of the pages the boost.book is going to produce. I don't want to start a religious argument about aesthetics, but... I prefer the previous look and feel which was supported by the original documentation guidelines. Its just one man's opinion. Dave Abrahams wrote: >We have a kind of policy against using scripting in our library doc >pages, mostly because in the past scripts have caused major >portability or usability problems. I personally love the menu on the >left of the serialization lib docs page, but if it uses scripts and we >can't really be assured that they'll work everywhere, it probably >ought to be removed. >There are alternatives that might actually be more usable: >http://article.gmane.org/gmane.comp.lib.boost.documentation/389

3 2

Re:Re: [boost] serialization test failure on darwin
by Robert Ramey 15 Jul '04

15 Jul '04

Marshall Clow wrote: >So, I moved it so that it is only set when building on GCC 2.95.x. >Index: boost/boost/config/platform/macos.hpp >=================================================================== >RCS file: /cvsroot/boost/boost/boost/config/platform/macos.hpp,v >retrieving revision 1.13 >diff -r1.13 macos.hpp >19d18 >< # define BOOST_NO_CWCHAR >41a41,42 >> # define BOOST_NO_CWCHAR >> >This did not break any other tests, and made some (many) of the >serialization tests pass. There are still many failures, which I am still >investigating. >Could someone vet this change, and commit it to CVS? Thanks! When I look at this I conclude that define BOOST_NO_CWCHAR ( and BOOST_NO_CWTYPE) should just be removed from this file. Its not clear to me why its there. The MacOS compiled with GCC includes the file library configuration file that sets/doesn't set these macros according to the platform. And the gcc version isn't enough to do it right. E.G. Cygwin gcc doesn't support wchar_t etc even though its version 3.3. I would like to a) hear from someone who knows why that code was put in there in the first place. b) take it out and run the tests. If b) looks ok and we don't hear from anyone shortly, then I'll make the change in CVS. Robert Ramey

1 0

RE: [boost] BOOST_PP_REPEAT with internal macro problem
by Yossi.Itzkovich＠ecitele.com 15 Jul '04

15 Jul '04

Thanks all for your fast (and good) answers. Yossi "Paul Mensonides" <pmenso57@comcast. To: <boost(a)lists.boost.org> net> cc: Sent by: Subject: RE: [boost] BOOST_PP_REPEAT with internal macro problem boost-bounces@list s.boost.org 07/15/2004 07:00 Please respond to boost > -----Original Message----- > [mailto:boost-bounces@lists.boost.org] On Behalf Of > BOOST_PP_REPEAT works great for me when used like: > > #define MAX 5 > #define CODE my_code_goes_here > BOOST_PP_REPEAT(MAX, CODE, ) ^^ Passing nothing as a macro argument is undefined in C++. You should use a dummie argument instead--preferably not an identifier. I usually use ~ or ?. > > But it gets confused when used like: > > #define MAX (4+1) Arkadiy is correct. The library cannot understand the expression (4+1). It can only understand unadorned integer literals (such as 1, 2, 3, etc.) from 0 to 256. If you need to do arithmetic, you have to use the arithmetic primitives of the library, such as BOOST_PP_ADD or, in this case, BOOST_PP_INC (which is more efficient). Thus, if you want to do a repetition of MAX + 1, you need to say: BOOST_PP_REPEAT(BOOST_PP_INC(MAX), CODE, ~) Regards, Paul Mensonides _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

1 0

BOOST_PP_REPEAT with internal macro problem
by Yossi.Itzkovich＠ecitele.com 15 Jul '04

15 Jul '04

Hi, BOOST_PP_REPEAT works great for me when used like: #define MAX 5 #define CODE my_code_goes_here BOOST_PP_REPEAT(MAX, CODE, ) But it gets confused when used like: #define MAX (4+1) Is ther a work around ? I even tried: #define MAX (4+1) const int myMax=MAX; BOOST_PP_REPEAT(myMax, CODE , ) but still no luck. Any help ? Thanks Yossi

4 3