July 2004 - Boost - lists.boost.org

mingw-stlport toolset
by Janusz Piwowarski 13 Aug '04

13 Aug '04

Hello, I created these toolset trying to run program_options library (mingw actually doesn't support wide char streams). Maybe it could be useful for someone else. Regards, Janusz

2 2

boost-build and version numbering
by Russell Hind 12 Aug '04

12 Aug '04

Given boost uses version numbers x.y.z such as 1.30.2 1.31.0 The build system generated libs and stuff with -1_31 appended. I have a few questions about this: How is this generated? We wish to build our own version of boost (based on one of the above releases, but with patches) so wanted to version it accordingly. The obvious way would be for us to version it 1.31.0.1 so it is differentiated from the official 1.31 release. Unfortunately, boost only appears to support the x.y.z format. So we could number it 1.31.1 and hope boost doesn't release a 1.31.1. But I've edited boost/version.hpp to be 103101 and 1_31_1 and also the jamrules file to be 1.31.1 but the build-generated libs are still only post-fixed with -1_31. Where does the bulid system pick up the version number so I can modify it for the build and would it be easy to modify it to support w.x.y.z format so we don't run a risk of coliding with boost versions? Thanks Russell

2 2

[thread] wrong name of the thread lib and dll.
by Sven Johannsen 12 Aug '04

12 Aug '04

Hi, when you compile the current boost with the following cmd-line the thread-lib has a wrong filename: bjam "-sTOOLS=msvc-stlport" "-sSTLPORT_PATH=D:\Develop" "-sSTLPORT_VERSION=4.5.3" this cmd-should generate "gdpn" files like: boost_thread-vc6-mt-gdpn-1_31.dll but it generate a "gdp" (without "n") file. the "n" stands for native iostreams. (boost_thread-vc6-mt-gdp-1_31.lib) the lib behave like "gdpn"-file, but i have to rename the lib. otherwise i get the following linker error: LINK : fatal error LNK1104: cannot open file "boost_thread-vc6-mt-gdpn-1_31.lib" who can modifier the jam-file. (i don't speak jam) Sven

3 5

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

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

Re: Boost Mathematicians
by Michael Stevens 05 Aug '04

05 Aug '04

Hi Dave, hi all, I read with interest you plans for reviving MTL. It is certainly a shame that development of MTL was been stagnant for so long. It certainly had many interesting design features and I used it for all my work for many years. That said I switched to using and developing uBLAS long ago and it has an excellent design. On Saturday 05 June 2004 13:53, David Abrahams wrote: > "Neal D. Becker" <ndbecker2(a)verizon.net> writes: > > David Abrahams wrote: > >> Tom Brinkman <reportbase(a)yahoo.com> writes: > >>> In short, lets tell the world that this is the > >>> premiere place for advanced mathmatical library > >>> development, as I believe that it could be. > >>> > >>> Comments? > >> > >> 1. I think oonumerics.org has the jump on us here, though the site > >> seems to be douwn at this moment. > >> > >> 2. I will be starting work on a rewrite of MTL (the Matrix > >> Template Library) for linear algebra soon. > > > > What do you plan for MTL? How is it different than ublas? > > MTL is aimed at linear algebra, whereas IIUC ublas is not. Well the L and A in uBLAS certainly stand for Linear Algebra! Of course the B stands for Basic and uBLAS's primary aim is to provide the standard set of BLAS functions in a modern C++ environment. Of course as it stands the complete uBLAS library is more then just the BLAS functions and includes some common Linear Algebra algorithms and many useful types. That said I think it is important to separate BLAS functions from domain specific linear algebra algorithm development. This is something that proved itself since the seventies. > There's a lot more to what's in the current plan than I can lay out > here, but the focus will be on support for different kinds of matrices > with combinations of these aspects > > o Shape > o Orientation > o Symmetry > o Sparsity > o Blocking > o Upper / Lower storage > o Unit diagonal Other then the many forms of blocking (other then banded) uBLAS supports all these in its design. This really is its strength! To a large extent they can even be combine these properties where it makes mathematical sense. For example you can wrap up one of a number of sparse matrix types in a symmetric adaptor. > > and operations like: > > o scalar-vector (vector-scalar) multiplication > o vector addition (and subtraction) > o apply linear operator (left) > o norm > o inner product > o triangular solve Other then 'apply linear operator' these are all in uBLAS! > with expression templates, and of course, zero abstraction penalty ;-) Of course uBLAS does this all with ET, but the abstraction penalty may not be zero :-) Other then the lack of ET in the current MTL the big difference between the two libraries is the definition of iterators. Neither design seems to be perfect with regard to efficiency. Since uBLAS is already in Boost and has a well established and clean user syntax it would seem strange to ignore it. For the perspective of building further Linear Algebra algorithms it would not be too hard to use the syntax sufficiently portably so that a future MTL with expression templates could not be used interchangeably. Michael -- ___________________________________ Michael Stevens Systems Engineering Navigation Systems, Estimation and Bayesian Filtering http://bayesclasses.sf.net ___________________________________

13 20

RE: [boost] RE: Re: DLL library (Was: Re: additional boost libraries?)
by Reece Dunn 04 Aug '04

04 Aug '04

Vladimir Prus wrote: >Reece Dunn wrote: > >>I also wonder if it makes sense to sumbit just "dll" library, or some > >>additional plugin support need to be developed first. > > > > What sort of plugin support are you looking for? Do you mean something > > like COM/CORBA support or wrapper, e.g. something that can target both > > (and others like them) in one implementation? > >I'm not CORBA expert, but I think it's entirely different beast. To use >CORBA object you use stub generated from IDL, how it's related to plugins? >While there are some ways to find object dynamically, it's different >mechanism from shared libraries, isn't it? I am not sure how CORBA works. COM generally uses a different mechanism to load COM objects via CoCreateInstance, although DirectX exposes creation functions that circumvent this. I was thinking about being able to use COM/CORBA as a platform for object lifetime and dll lifetime management (as well as things like interface extension, etc.). >I though more about at least some kind of map<string, BasePlugin*> which is >updated automatically when you load new DLLs. So the dll implements some function: __declspec(dllexport) BasePlugin * GetMyPlugin(); so you can do something like: void load_plugins( map< string, BasePlugin * > & pi ) { for( map< string, BasePlugin * >::iterator i = pi.begin(); i != pi.end(); ++i ) { boost::dll plugin(( *i ).first ); ( *i ).second = plugin.import< ... >( "GetMyPlugin" ); } } It is possible to keep the DLL in memory until all instances of a class (or set of classes) by incrementing/decrementing a global object count variable on construction/deconstruction as is done when using COM. You then check this variable in the DllCanUnload function. You may need some reference counting mechanism to keep the plugin alive, but this is not necessary if you load all plugins on startup and release them at the end of the run. It should be possible to implement these facilities in a library, e.g.: class object_counter { private: static int objectCount = 0; public: inline int get_object_count(){ return( objectCount ); } public: inline object_counter(){ ++objectCount; } // make MT aware inline ~object_counter(){ --objectCount; } // make MT aware }; class reference_counter { private: int refCount; public: inline void add_ref(){ ++refCount; } // make MT aware inline void dec_ref() { if( --refCount == 0 ) // make MT aware { delete this; } } public: inline reference_counter( int rc ): refCount( rc ){} inline ~reference_counter(){} }; allowing: class plugin: public object_counter, public reference_counter, public BasePlugin { // ... }; __declspec(dllexport) BOOL DllCanUnload() { return( object_counter::get_object_count() == 0 ); } I'm not sure what the Linux equivalent would be. Regards, Reece _________________________________________________________________ Want to block unwanted pop-ups? Download the free MSN Toolbar now! http://toolbar.msn.co.uk/

5 6

3 important Intel regressions and some other stuff
by Stefan Slapeta 03 Aug '04

03 Aug '04

The following regressions seem to be special to Intel 8: - numeric/uBLAS The only way to solve this seems at the moment not to use the "Multithreaded Debug DLL" runtime. When we can isolate the problem, Intel should investigate. - Python The slice test case is failing! Any ideas? - random error: no operator "<<" matches these operands I've not heard any comment in the last days about that. Any ideas? Aleksey, could we have a link to http://boost.sourceforge.net/regression-logs/developer/python.html on the boost regression site? I can't find any link to this page anywhere. I'm now going to leave now and I'll return on Sunday. I don't know if I can manage to get the regressions being run automatically, otherwise you get the next results for Intel 8 + CW 9 on Sunday. Stefan

5 16

[multi_index] spurious error in CW 9
by Joaquín Mª López Muñoz 03 Aug '04

03 Aug '04

This test occasionally fails: http://tinyurl.com/72xcb but there's no error output or any failure indication, nothing. The problem shows only at times, so I guess it'll have to do with the compiler being low on resources, but couldn't say for sure. Any idea? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

4 3

[program_options] Current status
by Vladimir Prus 03 Aug '04

03 Aug '04

I've leaving on vacation until Aug 23, so I though I'd explain the current release status of program_options. I believe that most failures are addressed. The Boost-wide table shows a lot of yellow cells, but I'm sure I've added explicit markup for most of them, and indeed the results for win32 are much better. The only two unexpected yellow cells are for intel- win32- 7.1- vc6- stlport- 4.5.3 at http://boost.sourceforge.net/regression-logs/cs-win32_metacomm/developer/pr… These are fresh problem and I'm not sure how I've missed them, or when they are introduced. In any case, it's too late to fix them. Another problem is that I still not sure about Darwin. All tests fail because of Boost.Test problem, and I'm not sure if Gennadiy is going to do anything about it. I think this is very bad situation, and would say that reverting the problematic change in Boost.Test is an option, but can't press for it. Apart from the above, during last week I've applied numerous editorial changes to the docs (big thanks to Charles Brockman), revived the remaining examples, and added new sections to the "howto" section, so I hope docs are in a good shape as well. If during the release process anybody would want to fix something, feel free to commit the change, making sure it does not breaks anything else, and dropping me a note by personal email. Thanks again to everyone who already sent patches for the library! - Volodya

2 3