- Boost - lists.boost.org

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

[string algo] Documentation errors
by Jeff Garland 03 Aug '04

03 Aug '04

I've been writing some code with string algorithms and I noticed a couple documentation issues: 1) First example: #include <boost/string_algo.hpp> should be #include <boost/alogorithm/string.hpp> 2) In the 'split' section example: typedef vector< string > split_vector_type; split_vector_type SplitVec; // #2: Search for tokens split( SplitVec, str1, is_any_of<char>("-*") ); // SplitVec == { "hello abc","ABC","aBc goodbye" } This doesn't work for me on gcc3.3.2 Linux (passes all regression tests) and it conflicts with the documentation of is_any_of which takes a collection not a char string as the parameter. Jeff

2 2

Looking for a simple example of instantiating normal_distribution from the random library correctly
by Kuntz, David A 03 Aug '04

03 Aug '04

> I am instantiating normal_distribution from the random library > incorrectly and looking for a simple example of how to do it > correctly. > > I compiled, built and ran random_test.cpp and can see when I > step through the normal_distribution () operator that _r1 and _r2 have > values < 1. > > Here are the relevant excerpts from my incorrect attempt at > instantiation and calling the () operator: > > typedef boost::mt19937 base_generator_type; > > boost::uint32_t x = 42u; > Ideal4045EsmModel::base_generator_type base_generator(x); > > double randomDrawResult; > > boost::normal_distribution<double> boostNormalRand; > > boostNormalRand.reset(); > > randomDrawResult = boostNormalRand(base_generator); > > This compiles, builds, and runs, but when I step through the > normal_distribution () operator, _r1 and _r2 have very large positive > values, resulting in an attempt to take the log of a negative number > and an Indefinite value being returned. > > I am a relatively inexperienced C++ developer. I have built and > stepped through random_test.cpp > (http://www.boost.org/libs/random/random_test.cpp) and can see that > its gets correct results, but I found it quite difficult to follow. Is > there anyone out there who could show me a simpler way? > > Thanks, > > Dave > > > >

1 0