- Boost-users - lists.preview.boost.org

signals through Python
by mat_2775 19 Jul '03

19 Jul '03

Hi, I'm very new to BOOST so please forgive my ignorance. I want to use the signals library of BOOST through Python. My question is whether that is actually possible and if so how? Kind regards Mat

2 1

Bind To Lambda
by Richard Crossley 18 Jul '03

18 Jul '03

Hi, I'm trying merge some code some of which uses a mixture of BB and BLL to just use the BLL under VC7.1. Having changed some 200 expressions without incident if find I can't see the wood for the trees here. The existing code, working with BB, is; typedef boost::function<void(ICollection*)> FECCFunc; void ForEachCollectionInChannels(IAmplifier* pIAmp,FECCFunc const & fec); typedef boost::function<void(IProperty*)> FEPFunc; void ForEachProperty(ICollection* pCollection,FEPFunc const & fep); void CalcPropCurValMaxWidth(IProperty* pProp,CColumnMap& map); ... void Problem() { CColumnMap m_ChanCols; IAmplifier* pIAmp; ForEachCollectionInChannels(pAmp,bind(ForEachProperty,_1,cref(bind(&CalcProp CurValMaxWidth,_1,ref(m_ChanCols)))); //Here } What's the equivalent with using BLL? Thanks, Richard.

1 1

StlPort-4.5.3, ublas and MSVC 6.0 problem
by Bosko Ivanisevic 18 Jul '03

18 Jul '03

Although I found on the site that UBLAS supportes MSVC 6.0 with STLPort I couldn't compile any example with this configuration. It seems that using Boost ublas library with StlPort (with native MS streams) and MSVC 6.0 have some problems and require specific settings. Does anyone have any hint how this problem can be solved? When I try to compile some of the samples from libs\numeric\ublas\doc \samples (for example vecto_binary.cpp) I got following errors: c:\programming\boost_1_30_0\boost\numeric\ublas\hermitian.hpp(1534) : error C2027: use of undefined type 'const_iterator1' c:\programming\boost_1_30_0\boost\numeric\ublas\hermitian.hpp(1529) : see declaration of 'const_iterator1' c:\projects\test\boost_matrices\main.cpp(23) : see reference to class template instantiation 'boost::numeric::ublas::hermitian_adaptor <class boost::numeric::ublas::matrix<class std::complex<double>,struct boost::numeric::ublas::row_major,cla ss boost::numeric::ublas::unbounded_array<class std::complex<double> > >,struct boost::numeric::ublas::lower>' being compiled c:\programming\boost_1_30_0\boost\numeric\ublas\hermitian.hpp(1831) : error C2027: use of undefined type 'iterator1' c:\programming\boost_1_30_0\boost\numeric\ublas\hermitian.hpp(1826) : see declaration of 'iterator1' c:\projects\test\boost_matrices\main.cpp(23) : see reference to class template instantiation 'boost::numeric::ublas::hermitian_adaptor <class boost::numeric::ublas::matrix<class std::complex<double>,struct boost::numeric::ublas::row_major,cla ss boost::numeric::ublas::unbounded_array<class std::complex<double> > >,struct boost::numeric::ublas::lower>' being compiled c:\programming\boost_1_30_0\boost\numeric\ublas\hermitian.hpp(1950) : error C2027: use of undefined type 'const_iterator2' c:\programming\boost_1_30_0\boost\numeric\ublas\hermitian.hpp(1945) : see declaration of 'const_iterator2' c:\projects\test\boost_matrices\main.cpp(23) : see reference to class template instantiation 'boost::numeric::ublas::hermitian_adaptor <class boost::numeric::ublas::matrix<class std::complex<double>,struct boost::numeric::ublas::row_major,cla ss boost::numeric::ublas::unbounded_array<class std::complex<double> > >,struct boost::numeric::ublas::lower>' being compiled c:\programming\boost_1_30_0\boost\numeric\ublas\hermitian.hpp(2247) : error C2027: use of undefined type 'iterator2' c:\programming\boost_1_30_0\boost\numeric\ublas\hermitian.hpp(2242) : see declaration of 'iterator2' c:\projects\test\boost_matrices\main.cpp(23) : see reference to class template instantiation 'boost::numeric::ublas::hermitian_adaptor <class boost::numeric::ublas::matrix<class std::complex<double>,struct boost::numeric::ublas::row_major,cla ss boost::numeric::ublas::unbounded_array<class std::complex<double> > >,struct boost::numeric::ublas::lower>' being compiled c:\programming\boost_1_30_0\boost\numeric\ublas\hermitian.hpp(1534) : error C2027: use of undefined type 'const_iterator1' c:\programming\boost_1_30_0\boost\numeric\ublas\hermitian.hpp(1529) : see declaration of 'const_iterator1' c:\projects\test\boost_matrices\main.cpp(30) : see reference to class template instantiation 'boost::numeric::ublas::hermitian_adaptor <class boost::numeric::ublas::matrix<class std::complex<double>,struct boost::numeric::ublas::row_major,cla ss boost::numeric::ublas::unbounded_array<class std::complex<double> > >,struct boost::numeric::ublas::upper>' being compiled c:\programming\boost_1_30_0\boost\numeric\ublas\hermitian.hpp(1831) : error C2027: use of undefined type 'iterator1' c:\programming\boost_1_30_0\boost\numeric\ublas\hermitian.hpp(1826) : see declaration of 'iterator1' c:\projects\test\boost_matrices\main.cpp(30) : see reference to class template instantiation 'boost::numeric::ublas::hermitian_adaptor <class boost::numeric::ublas::matrix<class std::complex<double>,struct boost::numeric::ublas::row_major,cla ss boost::numeric::ublas::unbounded_array<class std::complex<double> > >,struct boost::numeric::ublas::upper>' being compiled c:\programming\boost_1_30_0\boost\numeric\ublas\hermitian.hpp(1950) : error C2027: use of undefined type 'const_iterator2' c:\programming\boost_1_30_0\boost\numeric\ublas\hermitian.hpp(1945) : see declaration of 'const_iterator2' c:\projects\test\boost_matrices\main.cpp(30) : see reference to class template instantiation 'boost::numeric::ublas::hermitian_adaptor <class boost::numeric::ublas::matrix<class std::complex<double>,struct boost::numeric::ublas::row_major,cla ss boost::numeric::ublas::unbounded_array<class std::complex<double> > >,struct boost::numeric::ublas::upper>' being compiled c:\programming\boost_1_30_0\boost\numeric\ublas\hermitian.hpp(2247) : error C2027: use of undefined type 'iterator2' c:\programming\boost_1_30_0\boost\numeric\ublas\hermitian.hpp(2242) : see declaration of 'iterator2' c:\projects\test\boost_matrices\main.cpp(30) : see reference to class template instantiation 'boost::numeric::ublas::hermitian_adaptor <class boost::numeric::ublas::matrix<class std::complex<double>,struct boost::numeric::ublas::row_major,cla ss boost::numeric::ublas::unbounded_array<class std::complex<double> > >,struct boost::numeric::ublas::upper>' being compiled c:\projects\test\boost_matrices\main.cpp(37) : warning C4508: 'main' : function should return a value; 'void' return type assumed Error executing cl.exe. Does anyone have any hint how this problem could be solved?

1 0

boost and Watcom
by filbico 18 Jul '03

18 Jul '03

Hello, I would like to use boost 1.29 under Watcom C++ complier (11.0C, Powersoft Optima 2.1). I am looking for configuration files. Robert Nowak.

1 0

Replace/Extend default execution_monitor
by aragorn_yes 18 Jul '03

18 Jul '03

Hi all, What is the best way to replace/extend the default execution_monitor (unit_test_monitor) in the test library. Thanks in advance. Manuel.

2 1

Known limitations of Boost threads across O/S platforms???
by Louis Caston 17 Jul '03

17 Jul '03

Are there any known limitations to Boost threads across Win, Solaris, and Linux? I'm in a planning cycle, and expect to be utilizing Boost as much as possible. Thanks, - Louis

2 2

indirect_iterator_generator<list<shared_ptr<X> >::iterator> again
by Raoul Gough 17 Jul '03

17 Jul '03

Using gcc 3.2 (on MinGW) the template parameter defaults for indirect_iterator_generator don't work with shared_ptr. This has been discussed* on the list before, but there doesn't seem to have been a user-friendly resolution to the issues involved (at least not in release 1_30_0). Using my compiler, the current situation requires the client code to supply all five of the template parameters. *some previous threads on the subject: http://groups.yahoo.com/group/Boost-Users/message/1618 http://lists.boost.org/MailArchives/boost/msg33273.php http://lists.boost.org/MailArchives/boost/msg33316.php My sample code: #include <boost/iterator_adaptors.hpp> #include <boost/shared_ptr.hpp> #include <list> int main () { typedef std::list<boost::shared_ptr<int> > ListType; typedef ListType::iterator BaseIterator; typedef boost::indirect_iterator_generator<BaseIterator>::type Adapter; } Error output: f:/mingw/include/c++/3.2/bits/stl_iterator_base_types.h: In instantiation of `std::iterator_traits<boost::shared_ptr<int> >': d:/CVS/boost/boost/boost/iterator_adaptors.hpp:1111: instantiated from `boost::detail::iterator_traits<boost::shared_ptr<int> >' d:/CVS/boost/boost/boost/iterator_adaptors.hpp:1111: instantiated from `boost::detail::traits_of_value_type<main()::BaseIterator>' iterator_adapter.cc:9: instantiated from here f:/mingw/include/c++/3.2/bits/stl_iterator_base_types.h:123: no type named ` iterator_category' in `class boost::shared_ptr<int>' f:/mingw/include/c++/3.2/bits/stl_iterator_base_types.h:125: no type named ` difference_type' in `class boost::shared_ptr<int>' Looking at iterator_adaptors.hpp:1111 we have (reformatted): struct traits_of_value_type { typedef typename boost::detail::iterator_traits<T>::value_type outer_value; typedef typename boost::detail::iterator_traits<outer_value>::value_type value_type; typedef typename boost::detail::iterator_traits<outer_value>::reference reference; typedef typename boost::detail::iterator_traits<outer_value>::pointer pointer; }; So traits_of_value_type tries to look up the *iterator_traits* of the *value type* for the supplied iterator. Does the value type really need to have complete iterator traits for the compiler to figure out the defaults here? Is anybody working on improving the ease-of-use for indirect_iterator_generator? -- Raoul Gough "Let there be one measure for wine throughout our kingdom, and one measure for ale, and one measure for corn" - Magna Carta

3 10

Preventing Cycles with shared_ptr
by Jason Winnebeck 17 Jul '03

17 Jul '03

Hello everyone, I am new to this list and a little new to Boost. I have a question on program design when using the excellent boost shared pointer's library. I am converting my old network library that uses explicit memory management to use shared_ptr where appropriate. So far this has gone well but I am having problem with cycles. This post is more of request for comments on my thought process, and if there is a "traditional" or better way of handling these issues. The question in general is "How to deal with the cycles that come about from event generator/listener designs?" The problem in more specific terms with my thinking follows. I'm having a problem with trying to mitigate reference cycles in a event generator/event listener paradigm. One creates a listener object, and registers itself as a listener of that object. As a result of the event, it may want to invoke methods of that object, so it contains a reference to that object. So Generator contains a reference to Listener, and Listener contains a reference to Generator. This is a problem with reference counted pointers. People tell me that cycles in general signify a flaw, so perhaps my fundamental design is indeed flawed. A real example from my library is a Connection object representing a network connection. Library user derives a new class implementing the ConnectionListener interface and registers it with Connection. When a packet arrives an event in the listener is invoked, and let's say the listener wants to process the packet and send a packet in response. It does this by passing a packet to the Connection. Thus the Connection refers to the listener, and the listener refers to the Connection (to send a packet). There are some possible solutions. One way to break cycles is to use weak references. In this way you can observe an object without preventing it from being collected. In the general case, cycles are very bad because you aren't sure which object can be deleted when. However in this case the relationship is simple. Generator can only generate events when it is alive, and Listener will only try to interact with Generator as a response to its event (so we know Generator is alive if we got its event). One could use a weak pointer in the Generator to the Listener, but then the Listener may die as soon as it is registered. The Listener can use a weak pointer to the Generator, and this seems intuitive since the Listener is merely an observer, but accessing a weak pointer safely in a multithreaded environment is expensive (I think so?) when we are positive it exists. The issue is compounded in my library since Generator is an object that I have written (therefore I can trust it to understand all of my "choices"), while the Listener is defined by the user. So I prefer to make the task as easy as possible on the user -- so I want to allow the user to use weak or strong references if possible so he doesn't have to worry about cycles. If I must impose a restriction along the lines of "you can have a pointer to object type x", I will, but I much prefer to not have restrictions like that. One way I've been considering (and have implemented some already) is to have the Generator release all its Listeners when it is done generating events. This works, but in my old API I have ways to retrieve the set listener, and this cannot work since the set listener may go to NULL at any time (as a weak pointer). So my best option for now seems to be to break my old API by allowing the user to set listeners and objects but not be able to retrieve them back (or allow retrieve function knowing that an empty shared_ptr may be returned). Another possible way is for the Generator always to pass a reference to itself in the event. This is possible and clean and very fast, but requires major changes to my API, but the prior way of disallowing gets is safe in that it allows the user to not have to think twice about keeping a reference to my object. I have more ideas but this post is getting long. If you have comments about how something like this using shared_ptr is typically designed, or comments related to my more specific problem, I would be grateful. Thanks in advance, Jason Winnebeck

2 2

RE: [Boost-Users] Preventing Cycles with shared_ptr
by Jim.Hyslop 17 Jul '03

17 Jul '03

Jason Winnebeck wrote: > I am converting my old network library that uses explicit memory > management to use shared_ptr where appropriate. So far this has gone > well but I am having problem with cycles. [...] > One could use a weak pointer in the Generator to the > Listener, but then > the Listener may die as soon as it is registered. That's OK, though - each time the Generator wants to use the Listener, it constructs a shared_ptr out of the weak_ptr it has. If the shared_ptr is NULL, the Generator knows the Listener has gone away, and can take the appropriate steps to unregister the Listener. > ... the Listener is defined by the user. So I prefer to > make the task as easy as possible on the user -- so I want to > allow the > user to use weak or strong references if possible so he > doesn't have to > worry about cycles. If you want to make things easy for the user, don't offer them a choice. Choice means complexity. Complexity is bad. Require the user to use a shared_ptr to the Generator. -- Jim

2 1

RE: [Boost-Users] vc6 stl's problem
by Jim.Hyslop 17 Jul '03

17 Jul '03

hlh771 wrot: > the stl's implementation of vc6 is buggy such as auto_ptr,xtree etc, > even if it is patched with sp5 The Service Packs do not include changes to the STL headers. The STL was provided by a third party, Dinkumware, which for a few years was unable to provide updates to Microsoft due to legal difficulties between Dinkumware and another party. You can find patches and fixes at Dinkumware's web site: http://www.dinkumware.com/vc_fixes.html -- Jim

2 1