- Boost - lists.boost.org

[dynamic_bitset] CW8 regression, a plea for help!
by Rene Rivera 06 Aug '04

06 Aug '04

In running my set of _release_ mode tests I ran into a regression for dynamic_bitset, you can see it here (the RSI results): http://www.meta-comm.com/engineering/boost-regression/developer/dynamic_bit… Boost regression: dynamic_bitset/CVS-HEAD This is a new regression... I just also ran the tests for the dynamic_bitset in 1.31.0, and 1.30.2 (this is the version I currently use in my production code) -- And both of those pass. I'm asking for help in tracking this down. I'm not familiar at all with the dynamic_bitset code so some direction as to likely causes of the problems, or where to start looking are much appreciated. For now I'll just be single stepping through the code, oh fun :-( -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

3 9

[boost.thread] at_thread_exit must be serialized?
by Roland 06 Aug '04

06 Aug '04

Dear Mike, could you please give me the reasoning why the cleanup handlers that are specified in at_thread_exit must be serialized? It turns out that this is caused by a mutex located in on_thread_exit. Essentially this prohibits more than an exit handler chain to run at the same time. While there might be sound reasons for this I'd like to know please. How did I run into this: I wanted to bind the lifetime of a second thread to the one who started it. So I did soemthing like: void start(void) { if (!at_thread_exit(stop)) syslog_thrd = new cthread::cancelable_thread(&syslog_run); } The stop function beeing declared as: void stop(void) { if (syslog_thrd) { syslog_thrd->cancel(); syslog_thrd->join(); delete syslog_thrd; syslog_thrd = 0; } } When my first thread is exiting now, the stop is getting called properly. However my cancel causes the thread to exit (calling into its exit handler chain in turn). This will of course cause deadlock (altough in an non obvious way) since stop also has been called from the exit handler chain. The thread cannot be joined because it does not really end. You see? Perhaps you even can suggest another solution to my problem? Regards, Roland

2 5

Proposal for New Iterator Adaptor
by Alex Chovanec 06 Aug '04

06 Aug '04

I realize that this isn't the best time for proposals, what with everyone trying to get the next release of boost out, but I have an idea for a new iterator adaptor which I'd like to propose. Consider an adapted iterator type Iter with base iterator type Base that has the following traits: typedef Base value_type; typedef const Base & reference; When you dereference an instance of the adapted iterator type Iter, you get a const reference to its base iterator of type Base. So instead of delegating the dereference operation to its base and returning the result, the iterator adaptor simply returns its base. Since it doesn't dereference its base, I would probably name it "lazy_iterator", or something like that. There are some interesting things that you can do with this. For example: typedef std::vector< CString > vector; typedef std::vector< vector::iterator > iter_vector; typedef lazy_iterator< vector::iterator > lazy_iter; vector my_vector; iter_vector my_iter_vector; ... std::unique_copy( lazy_iter( my_vector.begin() ), lazy_iter( my_vector.end() ), std::back_inserter( my_iter_vector ), indirect_equal_to()); where indirect_equal_to is a special binary predicate which is defined like this: struct indirect_equal_to { template <typename Iter> bool operator==(Iter a, Iter b) { return *a == *b; } }; After this call to std::unique_copy(), my_iter_vector is a sequence of iterators that point to the unique elements in my_vector. Typically, you would just copy the unique elements into another vector of strings, but the approach described here is advantageous if you need to access the original unique elements in my_vector (for instance, if you need to change them), or if you want to avoid the overhead of copying strings. You could also have an iterator adaptor type Iter whose dereferencing operator returns &(*b), where b is its base iterator of type Base. This could be useful for generating ranges of pointers from ranges of objects. I think that this would be a useful iterator adaptor that would complement indirect_iterator very nicely. Whereas indirect iterator is useful for performing operations on ranges of iterators, this adaptor is ideal for generating ranges of iterators. Is anyone else interested in this? Thanks, Alex Chovanec

3 4

[boost.thread] Static Library support for Windows
by Roland 06 Aug '04

06 Aug '04

In the attached file you will find a proposal for how the problem of static linkage can be solved for Windows. The files can be dircetly inserted into the boost library framework. They almost do not touch existing implementation and also provide for a backup solution (overrideable) in case some unforeseeable things are happening. The solution has been worked out for MS compilers so far. However the principle should be portable to borland compiler as well. I would like to encourage someone with knowledge in this field to attempt this. Roland ***************************************************************************** ** ** ** WARNING: This email contains an attachment of a very suspicious type. ** ** You are urged NOT to open this attachment unless you are absolutely ** ** sure it is legitmate. Opening this attachment may cause irreparable ** ** damage to your computer and your files. If you have any questions ** ** about the validity of this message, PLEASE SEEK HELP BEFORE OPENING IT. ** ** ** ** This warning was added by the IU Computer Science Dept. mail scanner. ** *****************************************************************************

5 15

Date time query
by John Maddock 06 Aug '04

06 Aug '04

Just out of interest, what is the problem that prevents the date-time library from implementing a microsecond clock using GetSystemTimeAsFileTime on Win32? Thanks, John.

4 8

Updated Darwin tools
by Marshall Clow 06 Aug '04

06 Aug '04

Apple has released a new version of their developer tools, including an updated version of gcc. I have rerun the tests using the new gcc (3.3 build 1666). No major changes in the test results; a ICE while compiling one of the tests has been fixed. 30 failures (old compiler) vs. 28 (new compiler). -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

1 0

Windows MSVC thread exit handler for staticly linked Boost.Thread
by Aaron W. LaFramboise 05 Aug '04

05 Aug '04

Following is an implementation of, and some comments on, a staticly linked Boost.Thread thread exit handler for MSVC. By the way, I appologize for talking so long to cough this up after posting teasing remarks about this months ago. Programming is presently a hobby and volunteer work for me, unfortunately. First, the handler itself: ---msvc_exit_handler.cpp--- // copyright disclaimed. ABSOLUTELY NO WARRANTY. #define WIN32_LEAN_AND_MEAN #include <windows.h> #define BOOST_THREAD_USE_LIB #include <boost/thread/thread.hpp> #include <boost/thread/tss.hpp> extern "C" BOOST_THREAD_DECL void on_process_exit(void); extern "C" BOOST_THREAD_DECL void on_thread_exit(void); namespace { // Force a TLS directory to be generated even when static TLS is not used. extern "C" int _tls_used; int dummy() { return _tls_used; } // Report thread and process detach events. void NTAPI tls_callback (PVOID, DWORD Reason, PVOID) { if(Reason == DLL_THREAD_DETACH) on_thread_exit(); else if(Reason == DLL_PROCESS_DETACH) { on_thread_exit(); on_process_exit(); } } // Add callback to the TLS callback list in TLS directory. #pragma data_seg(push, old_seg) #pragma data_seg(".CRT$XLB") DWORD tls_callback_ptr = (DWORD)tls_callback; #pragma data_seg(pop, old_seg) } // namespace // Indicate that TSS cleanup is implemented. extern "C" void tss_cleanup_implemented(void) { } ---EOF--- And a simple testcase: ---tss.cpp--- /* Uncomment the following to use _beginthread() to create theads instead * of CreateThread. */ // #define USE_BEGINTHREAD #include <iomanip> #include <iostream> #define WIN32_LEAN_AND_MEAN #include <windows.h> #include <process.h> #define BOOST_THREAD_USE_LIB #include <boost/thread/thread.hpp> #include <boost/thread/tss.hpp> class myclass { public: myclass(); ~myclass(); }; myclass::myclass() { std::cerr << "init: " << GetCurrentThreadId() << '\n'; } myclass::~myclass() { std::cerr << "fini: " << GetCurrentThreadId() << '\n'; } boost::thread_specific_ptr<myclass> value; #ifdef USE_BEGINTHREAD void thread_proc(void *) { value.reset(new myclass); } #else // USE_BEGINTHREAD DWORD WINAPI thread_proc(LPVOID) { value.reset(new myclass); return 0; } #endif // USE_BEGINTHREAD int main(int argc, char *argv[]) { value.reset(new myclass); for (int i=0; i<2; ++i) { #ifdef USE_BEGINTHREAD _beginthread(thread_proc, 0, 0); #else DWORD id; CreateThread(0, 0, thread_proc, 0, 0, &id); #endif } Sleep(100); } ---EOF--- I tested this on Microsoft Visual C++ Toolkit 2003 on Windows XP SP1, as follows: C:\aaronwl\cs\boost\tls\handler>cl /EHa /MT /I"C:\aaronwl\cs\boost\cvs\boost" tss.cpp msvc_exit_handler.cpp ... C:\aaronwl\cs\boost\tls\handler>tss init: 2976 init: 4080 fini: 4080 init: 4040 fini: 4040 fini: 2976 Note that thread termination is correctly reported for all of the main thread and the two extra threads. It is my guess that this mechanism will work correctly on all versions of i386 Windows since Windows 95 and Windows NT 3.51. However, I have not tested it exhaustively due to lack of access. This mechanism is required to work by the PECOFF specification, so I'd expect any compliant x86 PE loader to support it. It is also my guess that this method of generating a thread termination notification will work on any version of MSVC that generates "32-bit" Windows executables. Only part of this compiler support, as implemented, is mandated by PECOFF. While apparently unused, completely undocumented, and largely unknown, the TLS callback section support is very similar to the general CRT global initialization and finalization routines, which--while they are also undocumented--most likely can never be removed as it would break backward object compatibility. I would be suprised if this did not work on a future MSVC version. This method of catching thread termination shares a very serious flaw with the DllMain() method: the thread PTD has already been destroyed by the time this code runs. As you can see, everything appears to work fine despite this; however, this is only by chance. In some cases, I think the code will silently do the wrong thing. For example, output might be lost. There was some suggestion about re-creating the PTD temporarily. This sounds good to me, except I can not find a reasonable way to do this, as the ptd manipulation functions are not exported the MSVCRT runtime dll. It might be possible to create a ptd manually, but this seems very risky to me. There was also mention of some sort of runtime library floating point hook. I was unable to figure out anything about this; however, if this is possible, and the ptd is still valid when this hook is called, that method is probably superior. As far as I can tell, FlsCallback() offers no advantage with regards to the ptd issue. It is also called "too late." Another problem with this method is that it gets destructor order wrong. For example, in the case of termination of the main thread, global destructors will be called before the TSS destructors are. This also could lead to silent misbehavior. It is likely that a better method for handling termination of the main thread could be found, such as a global destructor. Note that, with this method, it doesn't particular matter how the thread was created. There will be no ptd regardless of whether the thread was created with _beginthread or not. I am working on code for the MinGW runtime that should be able to cause GCC on Windows to handle TSS destructors perfectly. I don't know anything about any of the other Windows compilers with regards to this issue. In summary, I beleive this is the best shot so far at implementing thread exit handlers when Boost.Thread is statically linked, despite its serious problems. It is possible that a way to mitigate these problems, or a superior alternative, could be found. Aaron W. LaFramboise

10 82

[regression] New CodeWarrior 8.3 tests
by Rene Rivera 05 Aug '04

05 Aug '04

In an effort to improve the situation with this toolset, and since it's the one I'm currently most interested in, I started running a set of regression tests for it on my machine. The results are the ones with "RSI" as the name. I'm running the tests on demand, that is whenever I do a CVS update, or otherwise don't have the machine tied. So if anyone wants a faster response than waiting the 12 or 24 hours for the other tests to run, email me (privately) and I'll try and do an update and run new tests as soon as possible. Also one important difference between this set of test and the rest, is that I run them in *release* mode. So regressions relating to optimizations show up, and also relating to NDEBUG being set. But more about that in another post :-) -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

Invalid include in half_open_range.hpp
by Stefan Slapeta 05 Aug '04

05 Aug '04

...breaks half_open_range_test (utility) on all compilers. OK to commit? Stefan Index: half_open_range.hpp =================================================================== RCS file: /cvsroot/boost/boost/boost/half_open_range.hpp,v retrieving revision 1.5 diff -u -r1.5 half_open_range.hpp --- half_open_range.hpp 26 Jul 2004 00:31:58 -0000 1.5 +++ half_open_range.hpp 4 Aug 2004 14:21:29 -0000 @@ -12,7 +12,7 @@ #ifndef BOOST_HALF_OPEN_RANGE_HPP_ # define BOOST_HALF_OPEN_RANGE_HPP_ -# include <boost/counting_iterator.hpp> +# include <boost/iterator/counting_iterator.hpp> # include <functional> # include <cassert> # include <boost/operators.hpp>

3 6

[program_options] printing the variable map
by Jeff Garland 05 Aug '04

05 Aug '04

I'm writing a program with program_options (very cool and useful library, BTW) and I found myself wanting to print out the variable_map values for debugging purposes. Is there an easy way to do this? Also couple of documentation nits: 1) From the first example.... if (vm.count("help")) { std::cout << desc << "\n"; I had to read the code to figure out that variable_map inherits from std::map, and this is why you can call this. Documentation only says: class variables_map : : public boost::program_options::abstract_variables_map 2) In the 'Storage Component' section -- there's this: Let's consider an example: variables_map vm; store(parse_command_line(argc, argv, desc), vm); store(parse_config_file("example.cfg", desc), vm); finish(vm); .... Finally the call to notify function runs user-specified notify functions and stores values into regular variables, if needed. I assume 'finish' is supposed to be notify? I don't see any docs for finish. Jeff

2 1