- Boost-users - lists.boost.org

[Signals] Proposal effort for TR2
by Doug Gregor 28 Jul '05

28 Jul '05

At the C++ committee meeting in Lillehammer last April, I'd asked if there was any interest in a TR2 proposal for the Signals library, and got a positive response. I'll be collaborating with the libsigc++ folks to put together a proposal for the upcoming meeting, which will be discussed on the libsigc mailing list: http://mail.gnome.org/mailman/listinfo/libsigc-list We'll naturally be taking the good features from both libraries (tracking, combining, syntax, etc.) and tossing out the bad (*ahem* named slot groups). Interested Boosters are welcome to join us over in that forum. Doug

4 4

Re: [Boost-users] [Signals] Proposal effort for TR2
by Foster, Gareth 27 Jul '05

27 Jul '05

> We can't write any standardese for thread safety (Standard > C++ doesn't > have threads... yet), but we'll try to be ensure that the Did anyone propose a boost::threads like api for the new standard library? Or is there some reason why it is to be left to a later date? Gaz

2 1

bjam and environment variable DOT
by Andrew Kaluzniacki 27 Jul '05

27 Jul '05

In building boost I ran into an issue with bjam in having DOT as an environment variable and I did not find any other posts documenting the problem so I am adding this to save others the effort. DOT is in my environment for doxygen to find. Once I cleared DOT for the build everything seemed to be fine. Below is the output when DOT="C:\Program Files\ATT\Graphviz\bin" C:\boost1\boost_1_32_0>bjam -sTOOLS=vc-7_1 install C:\boost1\boost_1_32_0\tools/build/v1\allyourbase.jam:1358: in SubDir *** argument error * rule split-path ( path ) * called with: ( C:\Program Files\ATT\Graphviz\bin ) * extra argument Files\ATT\Graphviz\bin C:\boost1\boost_1_32_0\tools/build/v1\allyourbase.jam:1582:see definition of rule 'split-path' being called C:\boost1\boost_1_32_0\tools/build/v1\allyourbase.jam:1222: in project-root Jamfile:154: in load-jamfiles C:\boost1\boost_1_32_0\tools\build\v1\bootstrap.jam:21: in boost-build C:\boost1\boost_1_32_0\boost-build.jam:16: in module scope C:\boost1\boost_1_32_0> Andrew Kaluzniacki Senior Software Engineer Intelligent Systems BAE Systems. Burlington, MA (781) 273-3388 x269

2 1

Re: [Boost-users] [Iterators] Change in transform_iterator from1.31 to 1.32?
by Nat Goodspeed 27 Jul '05

27 Jul '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of David Abrahams > Sent: Tuesday, July 26, 2005 11:01 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [Iterators] Change in transform_iterator > from 1.31 to 1.32? > > "Nat Goodspeed" <ngoodspeed(a)solidworks.com> writes: > > > [Nat] boost::bind() is a runtime expression. I need to write a > > typedef for const_iterator before we get anywhere near that point. How > > can I use a type defined on the bind object for the typedef I need? > > If the bind documentation doesn't tell you the type of that object > (does it?), then officially you can't. [Nat] This page: http://www.boost.org/libs/bind/bind.html#Interface uses 'unspecified-N' as the type returned by boost::bind(). > Unofficially, you could pass > the result of the bind expression to a function template that does > something illegal on it, like > > template <class F> > void show_me_the_type(F const& f) { f += "hello"; } > > and your compiler will probably show it to you. [Nat] Heh, a useful trick to remember. I do need a reference, so I'm using Peter Dimov's suggested bind<R>() syntax. With this construct: show_me_the_type(boost::bind<const MapType::mapped_type&> (&MapType::value_type::second, _1)); The type described in the compiler output translates to: boost::_bi::bind_t< const MapType::mapped_type&, (ugly pointer-to-data-member syntax), boost::_bi::list1<boost::_bi::list_av_1<boost::arg<1> >::B1> > Forgive me, but that seems a bit too implementation-dependent to capture in my own code. I do want to be able to migrate forward to Boost 1.33 and beyond... As far as I'm aware, the only documented way to capture an object created by boost::bind() is to use boost::function. I understand your point about the inefficiency of using boost::function in my const_iterator type, but right now I know no better way to express it. Perhaps it would be useful to augment bind.hpp with a companion template that could reliably describe the type of the object produced by a particular call to boost::bind()?

2 1

Re: [Boost-users] [Signals] Proposal effort for TR2
by Foster, Gareth 27 Jul '05

27 Jul '05

> You probably don't want this question here, but would > thread-safety by > discussed for the proposal? We couldn't use boost::signals > because it > wasn't thread-safe and ended-up using our own wrapper around > boost::signals which made them thread-safe. > I had wondered about the thread safety of this stuff, is the story the same for libsigc++? It ought to be worth thinking about really shouldn't it? Gaz

1 0

boost::tokenizer problem, maybe a bug.
by Jarl Friis 27 Jul '05

27 Jul '05

Hi. I discovered the following problem using boost::tokenizer. The following program should print "hello", but it prints "hell": #include <iostream> #include <boost/tokenizer.hpp> int main(){ typedef boost::tokenizer<boost::char_separator<char> > tokenizer; boost::char_separator<char> sep(",", ""); tokenizer values(std::string(",hello,"), sep); for( tokenizer::iterator valueI = values.begin(); valueI != values.end(); ++valueI){ std::cout << "\"" << *valueI << "\"" << std::endl; } } Problem is confirmed using boost 1.32.0 and both GCC 3.3.4 and GCC 3.3.5 If anybody have a newer GCC installed, I would like to hear if the problems also exists in later GCC releases. I believe it is a bug in the std::string::assign implementation (i.e. not boost directly), but a the workaround for msvc in boost/token_functions.hpp, line 215-228 has also been tried for the GCC but it just moves the problem; it will mibehave when the line tokenizer values(std::string(",hello,"), sep); is replaced with tokenizer values(std::string("hello,"), sep); since it will then print "hel". So maybe another boost workaround is needed for GCC for the lines 215-228 in boost/token_functions.hpp Jarl -- Jarl Friis Softace ApS Omøgade 8, 2.sal 2100 København Ø. Denmark Phone: +45 26 13 20 90 E-mail: jarl(a)softace.dk

3 3

Re: [Boost-users] Simple Boost Lambda problem using argument as object. part II
by Tino S. 27 Jul '05

27 Jul '05

Hi Thaddeus, this code works for me... Greetings Tino int main() { std::string in; std::vector<A *> alist; std::vector<A *> longAList; typedef std::vector<A *> myType; // std::back_insert_iterator< myType > inserter(longAList); while(in!="end") { in=""; std::getline(std::cin,in); alist.push_back(new A(in)); } std::for_each(alist.begin(),alist.end(), //*inserter++ = &(*_1) boost::lambda::if_then( bind(&A::isLong,_1), bind(&myType::push_back ,&longAList, _1) )); return 1; } ___________________________________________________________ Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos - Hier anmelden: http://mail.yahoo.de

1 0

[Iterators] Change in transform_iterator from 1.31 to 1.32?
by Nat Goodspeed 27 Jul '05

27 Jul '05

We have a class that contains a std::map. This class wants to provide its clients with iterators over just the values in the map, hiding the fact that there's a map under the covers at all. transform_iterator seems like just the ticket, and with Boost 1.31 we used these methods: typedef std::map<KEYTYPE, VALUETYPE> MapType; typedef boost::transform_iterator< boost::function<const MapType::mapped_type&(const MapType::value_type&)>, MapType::const_iterator > const_iterator; const_iterator begin() const { return boost::make_transform_iterator(mymap.begin(), boost::bind(&MapType::value_type::second, _1)); } const_iterator end() const { return boost::make_transform_iterator(mymap.end(), boost::bind(&MapType::value_type::second, _1)); } The above compiled cleanly, except when it caused a compiler ICE, and the instances that compile seem to run okay. Now we're trying to upgrade to Boost 1.32 -- I know, a little late in the 1.32 lifespan. The same code now produces an ominous warning (full text at end of message): c:/videobranch\boost\boost\function\function_template.hpp(111) : warning C4172: returning address of local variable or temporary When it finally gets around to mentioning a line number in our own source code, the indicated line is the return statement in the above begin() method. The reason I'm concerned is that when compiled with Boost 1.32, our program suffers mysterious crashes that it did not when compiled with Boost 1.31. :-( I don't *know* that this warning is related, but I thought it prudent to try to eliminate such warnings to see if that might help. I can't figure out what temporary is driving the warning, though. I tried factoring out our own code a couple of different ways without making the warning go away. Can you suggest anything? Platform: Microsoft Windows XP Pro Compiler: Microsoft Visual C++ .NET, aka 7.1 *** Message ends; what follows is Microsoft warning output *** cl /EHsc /I c:/videobranch/boost $FF Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.10.3077 for 80x86 Copyright (C) Microsoft Corporation 1984-2002. All rights reserved. WrapMap.cpp c:/videobranch\boost\boost\function\function_template.hpp(111) : warning C4172: returning address of local variable or temporary c:/videobranch\boost\boost\function\function_template.hpp(109) : while compiling class-template member function 'const int boost::detail::function::function_obj_invoker1<FunctionObj,R,T0>::invoke (boost::detail::function::any_pointer,T0)' with [ FunctionObj=boost::_bi::bind_t<int,boost::_mfi::dm<int,std::pair<const std::string,int>>,boost::_bi::list1<boost::_bi::list_av_1<boost::arg<1>> ::B1>>, R=const int &, T0=const std::pair<const std::string,int> & ] c:/videobranch\boost\boost\function\function_template.hpp(482) : see reference to class template instantiation 'boost::detail::function::function_obj_invoker1<FunctionObj,R,T0>' being compiled with [ FunctionObj=boost::_bi::bind_t<int,boost::_mfi::dm<int,std::pair<const std::string,int>>,boost::_bi::list1<boost::_bi::list_av_1<boost::arg<1>> ::B1>>, R=const int &, T0=const std::pair<const std::string,int> & ] c:/videobranch\boost\boost\function\function_template.hpp(433) : see reference to function template instantiation 'void boost::function1<R,T0,Allocator>::assign_to<Functor>(FunctionObj,boost:: detail::function::function_obj_tag)' being compiled with [ R=const int &, T0=const std::pair<const std::string,int> &, Allocator=std::allocator<void>, Functor=boost::_bi::bind_t<int,boost::_mfi::dm<int,std::pair<const std::string,int>>,boost::_bi::list1<boost::_bi::list_av_1<boost::arg<1>> ::B1>>, FunctionObj=boost::_bi::bind_t<int,boost::_mfi::dm<int,std::pair<const std::string,int>>,boost::_bi::list1<boost::_bi::list_av_1<boost::arg<1>> ::B1>> ] c:/videobranch\boost\boost\function\function_template.hpp(289) : see reference to function template instantiation 'void boost::function1<R,T0,Allocator>::assign_to<Functor>(Functor)' being compiled with [ R=const int &, T0=const std::pair<const std::string,int> &, Allocator=std::allocator<void>, Functor=boost::_bi::bind_t<int,boost::_mfi::dm<int,std::pair<const std::string,int>>,boost::_bi::list1<boost::_bi::list_av_1<boost::arg<1>> ::B1>> ] c:/videobranch\boost\boost\function\function_template.hpp(649) : see reference to function template instantiation 'boost::function1<R,T0,Allocator>::function1<UnaryFunction>(Functor,boos t::enable_if_c<B,T>::type)' being compiled with [ R=const int &, T0=const std::pair<const std::string,int> &, Allocator=std::allocator<void>, UnaryFunction=boost::_bi::bind_t<int,boost::_mfi::dm<int,std::pair<const std::string,int>>,boost::_bi::list1<boost::_bi::list_av_1<boost::arg<1>> ::B1>>, Functor=boost::_bi::bind_t<int,boost::_mfi::dm<int,std::pair<const std::string,int>>,boost::_bi::list1<boost::_bi::list_av_1<boost::arg<1>> ::B1>>, B=true, T=int ] c:/videobranch\boost\boost\iterator\transform_iterator.hpp(130) : see reference to function template instantiation 'boost::function<Signature>::function<UnaryFunction>(Functor,boost::enab le_if_c<B,T>::type)' being compiled with [ Signature=const std::map<std::string,int>::mapped_type &(const std::map<std::string,int>::value_type &), UnaryFunction=boost::_bi::bind_t<int,boost::_mfi::dm<int,std::pair<const std::string,int>>,boost::_bi::list1<boost::_bi::list_av_1<boost::arg<1>> ::B1>>, Functor=boost::_bi::bind_t<int,boost::_mfi::dm<int,std::pair<const std::string,int>>,boost::_bi::list1<boost::_bi::list_av_1<boost::arg<1>> ::B1>>, B=true, T=int ] WrapMap.cpp(20) : see reference to function template instantiation 'boost::transform_iterator<UnaryFunction,Iterator>::transform_iterator<b oost::_bi::bind_t<R,F,L>,std::_Tree<_Traits>::const_iterator,boost::use_ default,boost::use_default>(const boost::transform_iterator<boost::_bi::bind_t<R,F,L>,Iterator,Reference,V alue> &,boost::iterators::enabled<__formal>::base<T>::type *)' being compiled with [ UnaryFunction=boost::function<const std::map<std::string,int>::mapped_type &(const std::map<std::string,int>::value_type &)>, Iterator=std::map<std::string,int>::const_iterator, R=int, F=boost::_mfi::dm<int,std::pair<const std::string,int>>, L=boost::_bi::list1<boost::_bi::list_av_1<boost::arg<1>>::B1>, _Traits=std::_Tmap_traits<std::string,int,std::less<std::string>,std::al locator<std::pair<const std::string,int>>,false>, Reference=boost::use_default, Value=boost::use_default, __formal=true, T=boost::detail::enable_type ]

4 3

Re: [Boost-users] [Iterators] Change in transform_iterator from1.31 to1.32?
by Nat Goodspeed 27 Jul '05

27 Jul '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of David Abrahams > Sent: Tuesday, July 26, 2005 5:41 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [Iterators] Change in transform_iterator > from1.31 to1.32? > > If Nat were using the actual type of the bind expression as the first > argument to transform_iterator, this wouldn't be a problem (except -- > not sure if you care -- that it would be returned by value from the > iterator). Presumably, the bind object has an appropriate > non-reference nested result_type. [Nat] I must be missing something here -- but I'm eager for enlightenment. boost::bind() is a runtime expression. I need to write a typedef for const_iterator before we get anywhere near that point. How can I use a type defined on the bind object for the typedef I need? > Nat, what you are doing looks _really_ inefficient. The result of > make_transform_iterator is some iterator type that's very different > from, but convertible to, your const_iterator type. Going through > that extra layer using boost::function means you are doing a lot of > extra copying -- and potentially, dynamic memory allocation -- > whenever you ask for an iterator. [Nat] I would be very happy to do it better, once I discover how.

2 1

Re: [Boost-users] [Iterators] Change in transform_iterator from1.31 to1.32?
by Nat Goodspeed 26 Jul '05

26 Jul '05

> -----Original Message----- > From: boost-users-bounces(a)lists.boost.org [mailto:boost-users- > bounces(a)lists.boost.org] On Behalf Of David Abrahams > Sent: Tuesday, July 26, 2005 5:41 PM > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [Iterators] Change in transform_iterator > from1.31 to1.32? > > Nat, what you are doing looks _really_ inefficient. The result of > make_transform_iterator is some iterator type that's very different > from, but convertible to, your const_iterator type. Going through > that extra layer using boost::function means you are doing a lot of > extra copying -- and potentially, dynamic memory allocation -- > whenever you ask for an iterator. [Nat] Truth to tell, I'm looking forward to when you introduce the equivalent of transform_iterator in Boost.Range... that will remove a lot of redundant declaration! ;-)

1 0