- Boost - lists.boost.org

graph/adjacency_matrix: iterator goes past end
by Guillaume Melquiond 19 Jul '04

19 Jul '04

Hi, Line 567 of adjacency_matrix.hpp is: typename Graph::MatrixIter l = g.m_matrix.end() + u; Obviously l is an iterator past the end. Looking at the algorithm, it seems to me it shouldn't be g.m_matrix.end() but f. So here comes a patch. Regards, Guillaume

2 7

Re:[boost] Threads Rewrite?
by Tonko Juricic 19 Jul '04

19 Jul '04

I just started using boost on Win32 platform and the lack of the ability to stop the thread is what immediately caught my attention. I understand it is difficult portability issue but I've seen too many uses where stop functionality is necessary. Looking at the current Win32 implementation, I'm afraid that adding thread stop would affect both mutextes and condition: as these call WaitOnSingleObject it seems impossible to stop the thread waiting on some 'external' mutex or condition. Off-hand, maybe TLS for each thread can have a default stop mutex and Win32 implementation of other synchronization primitives would always wait on at least two objects. It would also be nice to be able to start thread suspended, even if I guess it can be done now with mutex at the beginning of custom thread functor. Tony __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/

1 0

Seeking Boost round() function
by Matt Verona 19 Jul '04

19 Jul '04

I was reading the Boost documentation, and couldn't find a function to round floating point numbers (up or down) to the nearest integer. I have my own implementation of this algorithm as follows: #include <math.h> double round(double number) { return number < 0.0 ? ceil(number-0.5) : floor(number+0.5); } This round function produces the following output: round(0.0) = 0 round(1.49) = 1 round(1.5) = 2 round(-1.49) = -1 round(-1.5) = -2 Does Boost contain a simple rounding function like this? Thanks in advance, ~Matt Verona matt_verona(a)acm.org Houston, Texas USA

3 2

Boost.Threads static linking FYI
by Michael Glassford 19 Jul '04

19 Jul '04

I've made some changes to the Boost.Threads static linking support on Win32. Previously I had added back support for static linking, but without thread-specific storage classes. Now I've added the thread-specific storage classes back in, and exposed two functions that need to be called at the appropriate time: The function on_thread_exit() should be called when a thread exists, *in the context of the exiting thread*. The function on_process_exit() should be called when the process exit. If these functions are not called at the appropriate time, leaks may occur. If you know you don't need tss cleanup, of course you can just omit to call these functions. In addition, Boost.Threads static library on Win32 requires the user of the library to define a function called tss_cleanup_implemented(); if it is not defined, a link error results. The only purpose of this function is as a "link-time assertion": the linker error stating that the function is missing warns the the user of the necessity of calling the cleanup functions. In addition, if Boost.Threads later implements tss cleanup in the static library, the linker's duplicate symbol error should warn the user that their custom implementation is no longer needed. Comments? Mike

5 11

Re:[boost] [serialization] CW problems...
by Robert Ramey 19 Jul '04

19 Jul '04

>Rene Rivera wrote: >> Robert Ramey wrote: >> >>> While your looking at CW, might you find the time to look a little bit >>> into >>> the serialization library build problems. The error message is pretty >>> bizarre so I don't think it can be addressed without having CW >>> installed on >>> ones machine. >> >> OK, I'll try... Should I look for anything in specific? Or is it a >> general health issue? >I'm looking at this and one of the basic problems is that you seem to >assume a variety of things are available in the global namespace, >specifically size_t and other std types. Those are easy to fix by >specifying std::size_t. But I do have some questions... >1. Is using an unqualified size_t your intention? And therefore >something else is broken? Wow - its amazing to me I could have come so far and not know that size_t wasn't a built in type or macro - I think it used to be a macro definition. Anyway, I'll qualify this with std::size_t and check that no other compilers complain. If fact, now I can't understand why no other compiler complained since I never included <cstddef> >2. There is a similar problem with mbstate_t, but in this case you >attempt to do something special to handle it (from >boost/archive/codecvt_null.hpp): >#if BOOST_WORKAROUND(__BORLANDC__, <= 0x564) > #ifndef _RWSTD_NO_NAMESPACE > using std::codecvt; > using std::min; > #ifdef _RWSTD_NO_MBSTATE_T > using std::mbstate_t; > #endif > #endif >#elif defined(__COMO__) || defined(_MSC_VER) && _MSC_VER <= 1300 || >defined(__BORLANDC__) > typedef ::mbstate_t mbstate_t; >#elif defined(BOOST_NO_STDC_NAMESPACE) > typedef std::mbstate_t mbstate_t; > namespace std{ > using ::codecvt; > } // namespace std >#endif >And then you go ahead to use an unqualified mbstate_t. This just doesn't >work for CW. And I don't see how this would work for any library runtime >that puts mbstate_t only in the std namespace. Could you explain what >your intent is for this? The situation with mbstate_t is problematic. Some compilers define it in the global namespace while others define it in std::mbstate_t. The intent is to permit the code to use mbstate_t without qualification for those compilers that don't define it as std::mbstate_t. This sort of grew one compiler at time without too much thought. The typedef ::mbstate_t mbstate_t makes me wonder what I was thinking. Following the logic here for CW this would add #elif defined(CW) using std::mbstate_t; so that the rest of the code could use unqualified mbstate_t . I'll fix this (and a bunch other stuff) and we'll try again later. Thanks a lot. Robert Ramey

6 11

Bjam won't build thread static library VC .NET
by Tonko Juricic 19 Jul '04

19 Jul '04

First excuse me if this topic is not appropriate for boost developers list. This is my first post so I decided on asking a question rather than sending an empty message with test as a subject. I just built boost 1.31.0 libraries on Windows XP, using Visual Studio .NET 2003, compiler version 13.10.3077. To build both static libs and dlls I used this bjam command parameter -sBUILD=debug release <runtime-link>static/dynamic. Build worked just fine for all libs (for ex. I got both libboost_signals.lib and boost_signals.dll targets for signals) except for the thread library that created only boost_thread.dll target. What am I missing? Is there a reason that static threads library was not built and is there any way I can help? Tony __________________________________ Do you Yahoo!? Vote for the stars of Yahoo!'s next ad campaign! http://advision.webevents.yahoo.com/yahoo/votelifeengine/

3 2

[date-time] not showing up in nightly CVS boostbook?
by Jeff Garland 19 Jul '04

19 Jul '04

I checked in a change to switch date-time over to boostbook (added to the docs/src/boost.xml file), but I haven't seen it show up on the web site yet. Is this not being run / uploaded on the weekend? Jeff

2 2

numeric/conversion/detail/meta: void_ in boost::mpl namespace
by Guillaume Melquiond 19 Jul '04

19 Jul '04

Hi, Is BOOST_MPL_AUX_VOID_SPEC_PARAM supposed to be used by other libraries than MPL? The conversion library uses it (it is the only one to use it) and it obviously results in an error since void_ is in the boost::mpl namespace. This error is flagged by GCC, CodeWarrior, Como, and Intel (Linux). I won't suggest a patch since I'm not even sure to understand what this macro is supposed to do (is there any documentation or is it an undocumented internal macro?), but it can't be a bad thing to remove any reference to BOOST_MPL_AUX macros from the conversion library. Regards, Guillaume

2 1

Another regression testing problem.
by Martin Wille 19 Jul '04

19 Jul '04

Hi, I ran into another (small) problem with regression testing: Unpacking the tar-ball containing the XSL based reports takes approximately 1 hour on the (not very busy) SF shell server. The tar-ball is only 60MB in size, but it contains ~24000 files, which could explain why it takes that long. Is there any way to reduce the number of files? Regards, m

2 1

RE: [boost] uBLAS regressions
by Michael Stevens 19 Jul '04

19 Jul '04

On Monday 19 July 2004 09:51, Aleksey Gurtovoy <agurtovoy(a)meta-comm.com> wrote: > Unfortunately, it did -- it was producing a composite library name > with back instead of forward slashes ("numeric\ublas" instead of > "numeric/ublas"), and that confused process_jam_log, causing uBLAS > disappear from the report. > > Fixed in the CVS now, together with a test case to prevent future > disturbance ("tools\build\v1\test\test-testing.jam"). Thanks Aleksey! It was noticed by me and a couple of others that it dropped out from the report. Just show people look at the reports everyday. They are very useful and your effort is very much appreciated. The developer format reports are really very clear and informative. One question. The Comeau tests seem to be in VC7 compatability mode. For me this is a bit of a shame as it is the only Comeau regression test and I would love to know how well we do in strict mode! > For no good reason, IMO. To uBLAS maintainers -- can we fix it > sometime after the release? Certainly will. The layout was historical! All the best, Michael

1 0