- Boost - lists.preview.boost.org

RE: [boost] Review Wizard Status Report
by Rozental, Gennadiy 04 Aug '04

04 Aug '04

> 2) Algorithm Mini-Reviews > > If there are no objections, I will also schedule a > mini-review of some of the algorithms from wiki > starting September15, 2004. The format of the boost > algorithms review has yet to be established and will > evolve over time. > > Please contact me if you have any suggestions as to > how this first boost algorithms review proceeds. Does my submission get into this picture? > 3) Review Managers Needed > > Please contact me if you would like to serve as a > review manager for a library > under consideration for inclusion into boost. It > would be greatly appreciated > and is a great way for you to network with other boost > users. I am ready to help, though it's subject to schedule conflicts resolution. > > Tom Brinkman > Boost Review Wizard Gennadiy.

1 0

Re:[boost] [serialization] CW8 status...
by Robert Ramey 04 Aug '04

04 Aug '04

Rene Rivera wrote: >A quick summary of what your recent changes did for CW8, in case the >metacomm tests don't soon: >* test_delete_pointer pass. >* test_demo_auto_ptr pass. >* test_deque pass. >* test_diamond pass. >* test_map pass. >* test_non_default_ctor pass. >* test_non_intrusive pass. >* test_optional pass. >* test_private_ctor pass. >* test_split pass. >* test_vector pass. >I only tested the previous failures. And for some the metacomm tests >show a failure for things were previously fixed. Also it looks like some >of the failures are now different, meaning you fixed something only to >have it fail on something else. Oh yeah - sometimes you get more than one issue per test - sort of a free bonus. Several compilers/platforms/combinations have problems with wide character i/o. These are CW, Comeau, Darwin/GCC. I'm looking at this - I believe it may be an error in the utf8 codecvt facet. (interestingly, this doesn't occur with the column marked "CW" hmmmm) I have a problem with my own cwpro9 installation in that for some programs I get multiply defined symbols at link time. The resulting exectutable goes kind of haywire. The column marked "CW" doesn't show this problem and I hopeful that it will pass almost 100% on the next round of tests. I suspect there is issue with build/jamfile for cwpro8/9. Test_list has an issue with slist.hpp and iterators of all things. This effects all CW versions. Its possible its an slist issue on all platforms for all I know. As far as CW is concerned - I'm smelling blood and feel that I'm closing in on final victory. Anyone who wants to take a look at any of the above issues is free to do so. Robert Ramey

1 0

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

range & mpl
by Rob Lievaart 04 Aug '04

04 Aug '04

Hi All, The workaround test of the range library is failing for gcc 3.2 and 3.3 and for mingw with gcc 3.2. This seams to be caused by an incorrect placement of some macro's in mpl/if.hpp However, I do not know the correct placement. I've tried a few locations, but they all result in other errors, so I do not know what the right place is. mpl/if.hpp contains the follwoing code: ...snip... #if !defined(BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION) BOOST_MPL_AUX_AGLORITHM_NAMESPACE_BEGIN ...snip... #else // no partial class template specialization ...snip... #endif // BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION BOOST_MPL_AUX_AGLORITHM_NAMESPACE_END ...snip... The value of BOOST_MPL_AUX_AGLORITHM_NAMESPACE_XXX depends on wheter we are using gcc ( >=3) or not. So the _BEGIN is set inside the #if and the and the _END outside. I tried putting the begin before the #if but that din't work, and the _END inside before the #else but that didn't work either. Looking at the other mpl files it seems things are not as simple as that :-(, but I have no idea how the mpl works, so I do not know what the correct solution is. Rob Lievaart.

2 1

RE: [boost] Re: Windows MSVC thread exit handler for staticly linkedBoost.Threadn
by Richard_Cox＠Dell.com 04 Aug '04

04 Aug '04

> -----Original Message----- > From: Aaron W. LaFramboise [mailto:aaronrabiddog51@aaronwl.com] > Sent: Tuesday, August 03, 2004 4:20 AM > To: boost(a)lists.boost.org > Subject: Re: [boost] Re: Windows MSVC thread exit handler for > staticly linkedBoost.Threadn > The only concern I have--I don't know how important this is--is that > when a thread is killed with TerminateThread, I think neither TLS > callbacks nor DllMain()s will be called. This would cause > the TLS count > to never reach zero, and for TlsFree to never be called. > > These threads might not even be associated with the Boost TSS at all. > For example, another third party library in some DLL might be using > TerminateThread, and the application programmer may not even > know about > this, so it may be suprising to him when the reference count never > reaches zero for apparently no good reason. > I don't think cleanup after a TerminateThread would make any sense. TerminateThread does zero cleanup to start with (e.g. the threads is not freed). It would be inconsistent if any TLS cleanup was done in this case). Richard All opinions are mine and do not represent in any way the position of Dell Corporation.

1 0

RE: [boost] [build_monitor] again
by Rob Lievaart 04 Aug '04

04 Aug '04

Oops, it looks like I spoke to soon. _Assuming_ the ftp server is reporting file times in local time somewhere in the (middle of) the US, then the regression script did upload the results. In that case, the failing tests were stopped and it was just the error message that hung around. Wat remains is that monitor kills other windows that have error in the name on Windows 200 SP5. Other reports were from XP IIRC. I do not have nay problem with long lived processes being killed when they shouldn't be. Kind regards, Rob Lievaart. > I am having some trouble with the build monitor, it works fine > most of the time, but: > 1) Yesterday I locked the screen of the computer, this morning > when I returned the division by 0 errors were showing, and they > were not killed build_monitor, so the tests blocked. > > 2) As reported earlier, any window with error in the title is killed. > > This is on Windows 2000, SP5.

1 0

[build_monitor] again
by Rob Lievaart 04 Aug '04

04 Aug '04

Hi, I am having some trouble with the build monitor, it works fine most of the time, but: 1) Yesterday I locked the screen of the computer, this morning when I returned the division by 0 errors were showing, and they were not killed build_monitor, so the tests blocked. 2) As reported earlier, any window with error in the title is killed. This is on Windows 2000, SP5. Kind regards, Rob Lievaart. PS. I'll try to look into it in more detail this evening, but I am kind of busy at the moment, so I may not get around to it.

1 0

[serialization] CW8 status...
by Rene Rivera 04 Aug '04

04 Aug '04

Robert, A quick summary of what your recent changes did for CW8, in case the metacomm tests don't soon: * test_delete_pointer pass. * test_demo_auto_ptr pass. * test_deque pass. * test_diamond pass. * test_map pass. * test_non_default_ctor pass. * test_non_intrusive pass. * test_optional pass. * test_private_ctor pass. * test_split pass. * test_vector pass. I only tested the previous failures. And for some the metacomm tests show a failure for things were previously fixed. Also it looks like some of the failures are now different, meaning you fixed something only to have it fail on something else. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com - 102708583/icq

1 0

serialization test all fail on darwin
by Robert Ramey 04 Aug '04

04 Aug '04

I'm getting all failures in the serialization library on Darwin - gcc 3.1 A few days ago I got all passes for this platform(exception wide char xml - a separate issue). I had hoped it my go away spontaneously - as it arrived - but no luck. Does anyone have a suggestion on how to address this? Robert Ramey ld: multiple definitions of symbol boost::unit_test::(anonymous namespace)::first_failed_assertion() /Volumes/stuff/users/alexy/__boost_regressions/results/bin/boost/libs/test/b uild/libboost_test_exec_monitor.a/gcc-3.1-darwin/debug/libboost_test_exec_mo nitor.a(unit_test_log.o) definition of boost::unit_test::(anonymous namespace)::first_failed_assertion() in section (__TEXT,__text) /Volumes/stuff/users/alexy/__boost_regressions/results/bin/boost/libs/test/b uild/libboost_test_exec_monitor.a/gcc-3.1-darwin/debug/libboost_test_exec_mo nitor.a(supplied_log_formatters.o) definition of boost::unit_test::(anonymous namespace)::first_failed_assertion() in section (__TEXT,__text)

3 2

RE: [boost] serialization test all fail on darwin
by Rozental, Gennadiy 03 Aug '04

03 Aug '04

Ok I will commit these later today. Gennadiy.

1 0