August 2005 - Boost - lists.boost.org

[range] How to extend Boost.Range?
by Eric Niebler 21 Sep '05

21 Sep '05

While investigating test failures with Boost.Foreach, I found this in Boost.Range's documentation for extending the Range library: http://boost.org/libs/range/doc/boost_range.html#minimal_interface This seems to suggest that the only way to extend Boost.Range is for user-defined types to implement a std-container-like interface, with nested iterator and const_iterator types, and begin() and end() member functions. Is this really the intention? I seem to recall some discussion about a more accomodating extensibility mechanism that makes allowances for non-std-container-like user-defined range types. In fact, Boost.Foreach assumes such an interface, with disastrous results. What became of Boost.Range's extensibility mechanism? Is it documented anywhere, and I'm just not seeing it? -- Eric Niebler Boost Consulting www.boost-consulting.com

9 74

[lambda] extension question
by Brock Peabody 18 Sep '05

18 Sep '05

Hi, I'm trying to learn how to make my own lambda compatible function objects and I'm hoping that someone can nudge me in the right direction. My first try is called tuple_element. It takes an index as a template parameter and a tuple as an argument, returning the element at the given index: //should print "x" cout << tuple_element<1>(_1)(tuple<int,std::string>(2, "x")); I've got everything working except for the sig template. tuple_element looks like (mostly copied from lambda source code): template <int Index> struct tuple_element_action {}; template <int Index, typename Arg> inline const lambda_functor< lambda_functor_base< tuple_element_action<Index>, tuple<lambda_functor<Arg> > > > tuple_element(const lambda_functor<Arg>& a) { return lambda_functor_base< tuple_element_action<Index>, tuple<lambda_functor<Arg> > > ( tuple<lambda_functor<Arg> >(a)); } and the action: template<typename Args, int Index> class lambda_functor_base<tuple_element_action<Index>, Args> { public: Args args; template <class T> struct sig : tuples::element<Index,T> {}; explicit lambda_functor_base(const Args& a) : args(a) {} template<class RET, CALL_TEMPLATE_ARGS> RET call(CALL_FORMAL_ARGS) const { return detail::select(get<0>(args), CALL_ACTUAL_ARGS).get<Index>(); } }; When I try to compile my example in VC 7.1 I get an error that seems to indicate that the type being passed to the sig template is boost::tuples::null_type. Everything works if I hardwire it like: template <class T> struct sig { typedef std::string type; }; Any ideas? Thanks, Brock

5 13

stlport toolset patches
by François Dumont 13 Sep '05

13 Sep '05

Here is a first patch to build boost using STLport 5.0 with MSVC compilers. STLport 5.0 has adopt a more simple naming schema for generated library, compiler name is not part of it anymore. Rather than changing existing variable in the .jam files I prefered to introduce a new variable STLPORT_USE_AUTO_LINK to signal support of the auto link feature. In this case no lib is specified at link phase, STLport takes care of it. Any remark on the patches will be welcome as I am a completely beginner with bjam. What I would like to achieve now is reflect in bajm files that 5.0 do not support 'wrapper' mode anymore, stlport-iostream feature has to be on per default with this version, is it possible? Bests *** msvc-stlport-tools.jam.orig Thu Aug 25 05:10:34 2005 --- msvc-stlport-tools.jam Thu Aug 25 16:36:23 2005 *************** *** 13,18 **** --- 13,19 ---- STLPORT_LIB_BASE_NAME ?= stlport_vc6 ; STLPORT_LIB_STATIC_SUFFIX ?= _static ; + STLPORT_USE_AUTO_LINK = yes ; # bring in the STLPort configuration SEARCH on stlport.jam = $(BOOST_BUILD_PATH) ; *** stlport.jam.orig Thu Aug 25 05:11:22 2005 --- stlport.jam Thu Aug 25 16:37:06 2005 *************** *** 105,111 **** flags $(CURR_TOOLSET) DEFINES <runtime-build>debug : _STLP_DEBUG=1 _STLP_DEBUG_UNINITIALIZED=1 ; flags $(CURR_TOOLSET) DEFINES <runtime-link>dynamic : _STLP_USE_DYNAMIC_LIB=1 ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX)$(STLPORT_LIB_STATIC_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_STATIC_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME) ; --- 105,114 ---- flags $(CURR_TOOLSET) DEFINES <runtime-build>debug : _STLP_DEBUG=1 _STLP_DEBUG_UNINITIALIZED=1 ; flags $(CURR_TOOLSET) DEFINES <runtime-link>dynamic : _STLP_USE_DYNAMIC_LIB=1 ; ! if ! $(STLPORT_USE_AUTO_LINK) ! { ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX)$(STLPORT_LIB_STATIC_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>debug/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_DEBUG_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>static : $(STLPORT_LIB_BASE_NAME)$(STLPORT_LIB_STATIC_SUFFIX) ; ! flags $(CURR_TOOLSET) FINDLIBS <stlport-iostream>on/<runtime-build>release/<runtime-link>dynamic : $(STLPORT_LIB_BASE_NAME) ; ! } *** vc7-stlport-tools.jam.orig Thu Aug 25 05:21:13 2005 --- vc7-stlport-tools.jam Thu Aug 25 16:36:40 2005 *************** *** 3,8 **** --- 3,9 ---- flags $(gCURRENT_TOOLSET) STLPORT_LIB_BASE_NAME ; STLPORT_LIB_BASE_NAME ?= stlport_vc70 ; + STLPORT_USE_AUTO_LINK ?= yes ; # bring in the STLPort configuration SEARCH on stlport.jam = $(BOOST_BUILD_PATH) ;

3 3

[Boost.Thread]: consider removing catch(...) from thread_proxy
by Slawomir Lisznianski 13 Sep '05

13 Sep '05

Hello, I find the catch(...) clause in the thread_proxy function (thread.cpp) causing more harm than good. If exception "leaks" from a function executing in the context of a thread, the thread silently goes away but the application continues to operate as if nothing happend. I think, in this instance, the library simply "does too much" by trying to do the cleanup. As a user, I can always wrap the code in the catch-all, but what I cannot change is the fact that when unhandled exception is thrown, I will not see the function in the stack trace where the exception originated. Here is the proposed proxy, after trivial changes: extern "C" { #if defined(BOOST_HAS_WINTHREADS) unsigned __stdcall thread_proxy(void* param) #elif defined(BOOST_HAS_PTHREADS) static void* thread_proxy(void* param) #elif defined(BOOST_HAS_MPTASKS) static OSStatus thread_proxy(void* param) #endif { thread_param* p = static_cast<thread_param*>(param); boost::function0<void> threadfunc = p->m_threadfunc; p->started(); threadfunc(); #if defined(BOOST_HAS_WINTHREADS) on_thread_exit(); #endif #if defined(BOOST_HAS_MPTASKS) ::boost::detail::thread_cleanup(); #endif return 0; } } Regards, Slawomir

14 47

File Vault broken
by Eric Niebler 12 Sep '05

12 Sep '05

I just noticed that *everything* in the file vault is gone: http://boost-sandbox.sf.net/vault What's up? -- Eric Niebler Boost Consulting www.boost-consulting.com

6 15

[serialization] Boost.Serialization 1.33.0 Breaks Serialization Code inDLLs
by martin.ecker＠tab.at 06 Sep '05

06 Sep '05

Hello, Boost.Serialization 1.33.0 breaks serialization of derived classes referenced via base class pointers when using DLLs on Windows and VC 7.1. It might also affect shared objects on Unix, but I'm not sure how the various Unix loaders handle multiple instances of the same template member function in multiple shared objects. In particular what happens is that objects that are serialized via a base class pointer are no longer deserialized correctly when deserialized in an application that uses the DLL (and not within the DLL itself). Instead they are deserialized as NULL pointers. The problem is that the virtual equal_to and not_equal_to member functions were removed from the extended_type_info base class. These functions were previously used by extended_type_info::operator == and extended_type_info::operator !=. Now operator == simply performs an equal check on the address of the extended_type_info object, whereas the previous version that used equal_to actually did a full compare of the stored type info keys. If DLLs are used and the DLLs themselves contain serialization code and BOOST_CLASS_EXPORT macros, this will fail because the extended_type_info objects are always static objects allocated on the stack of a member template function, e.g. in extended_type_info_typeid_1::get_instance. In a DLL situation this will cause multiple DLLs that include the header file with that template function to have multiple (i.e. separate) copies of that extended_type_info object. Thus, comparing them only via their addresses leads to disaster. The fix is easy. Simply put the old code for extended_type_info::operator == and extended_type_info::operator != back in. Note that I haven't looked any further if there were other changes made to the code that also rely on the addresses of equal extended_type_info objects to be the same. This will also break serialization code in DLLs. I can only say that after I put the old code back in, our system could deserialize its data properly again. Best Regards, Martin TAB Austria Haiderstraße 40 4052 Ansfelden Austria Phone: +43 7229 78040-218 Fax: +43 7229 78040-209 E-mail: martin.ecker(a)tab.at http://www.tab.at

6 23

[boost thread rework] New version uploaded to Boost Vault
by Ion Gaztañaga 06 Sep '05

06 Sep '05

Hi to all, I've just finished implementing the lockable objects of Kevlin's proposal based on Boost mutexes and conditions. Since boost mutex operations are private and only available with locks, I haven't found a way to implement Kevlin's interface over boost threads without using some very nasty tricks. If someone has a better idea, let me know. The implementation nearly fills all the proposal of the documentation, so I will wait for new elements so that I can continue with this project. This elements are present in the current version: -> threader and joiner classes -> lockable, try_lockable, condition_lockable -> locker, try_locker -> locking_ptr There are open issues in the paper like timeout handling and new possible lockers, (for example, for conditional_lockable objects). As soon as I get more information I will continue developing it. Regards, Ion

15 57

Repository access and cvs watch
by Thomas Witt 05 Sep '05

05 Sep '05

Hi, AFAICT there is currently no way to make cvs provide writable files when checking out/updating the boost repository. This causes me some grief and I might not be the only one out there. After reading the CVS manual (well the watch part) I have concluded that this is due to the fact that somebody issued a recursive 'cvs watch on' on the boost tree. AFAICS this has not been discussed on the mailing list. This forces a certain usage of cvs on everybody else. I.e. the users have to use 'cvs edit' (or fiddle with file permissions). For now I am strongly opposed to this way of using cvs. In my experience the use of 'cvs edit' does not provide significant benefit while it adds significant overhead to my work. Most users will change the permissions locally and not bother with cvs edit anyway. If there is anybody out there who has different experiences I would be very interested to hear about them. I therefore propose to turn cvs watch off thus giving the user a choice whether she wants read-only or read-write files. Please note that this does not disable the watching of files in general. Every user still can use cvs watch add to watch files and is still guaranteed to get notified about the really interesting events (i.e. those that alter a file in the repository). What did I miss? What do you think? Thomas

16 30

Boost.Python and slightly more tricky inheritance
by Vladimir Pozdyayev 05 Sep '05

05 Sep '05

Greetings. 1. First, about a bug (Boost 1.33.0, MSVC 7.1): After exporting void test1( const char * ) { } void test2( std::string ) { } we get an assertion failure _BLOCK_TYPE_IS_VALID( ... ) on std::strings longer than a dozen of characters: test1( 'hello' ) # OK test2( 'hello' ) # OK test1( 'how do you do, tell me please' ) # OK test2( 'how do you do, tell me please' ) # failure 2a. From `Exposing Classes' tutorial section: "If Base is polymorphic, Derived objects which have been passed to Python via a pointer or reference to Base can be passed where a pointer or reference to Derived is expected." Now, that's a great feature, but I couldn't help noticing that what Boost.Python actually does, is even more useful: not only such pointers can be passed instead of Derived ones, but their Python counterparts _are_ fully qualified Derived representations, with all the methods and everything. Probably worth mentioning in dox that way. 2b. Now, suppose we have one more derived class: class Base { ... }; class Derived: public Base { ... }; class HiddenImplementation: public Derived { ... }; with Derived being no more than an interface. Naturally, we don't want to export HiddenImplementation to Python, but still want to retain automatic conversions from Base* to Derived* whenever pointer to HiddenImplementation object is passed to Python. Any way to do this? Without hack-ins? I was able to trick the system by defining the fake empty implemetation class class HiddenImplementation: public Derived { }; right before the BOOST_PYTHON_MODULE and exporting it out there, but this kind of `solution' really annoys me. And I don't understand why it works, either :) . Oh, and it's only a partial solution, too: we do not have to access the real implementation class, but we still have to export something. Comments? -- TIA, Vladimir mailto:ardatur@mail.ru

3 6

[metamath] Plans for compile time double
by Chris Weed 05 Sep '05

05 Sep '05

Hi, I was wonder what the plans are for the compile time double library, metamath. Is there a plan to develop compile time versions of the functions in math.h, such as sin, cos, pow, abs, etc.? Thanks, Chris

3 7