- Boost - lists.boost.org

Like to submit timeseries related functions
by S. Mamun Raihan 04 Oct '08

04 Oct '08

Hi, As part of Graduate program I have developed following useful functions that I like to submit to boost as a seperate library or part of math library - notable functions in my lists are, 1. ARBurg - Auto regressive coefficients using Burg's algorithm 2. ARCeps - Cepstrum coefficeint from Auto-regressive coefficients 3. 1-D filter function 4. 1-D convolution function 5. Moving - Average filter 6. Polynomial Fitting 7. Polynomial Value from Polynomial Coefficients Regards Syed Mamun Raihan 647.278.9083

1 0

Re: [boost] [Phoenix] Review ended September 30th
by Joel de Guzman 03 Oct '08

03 Oct '08

Jaakko Järvi wrote: > Hi All, > > Unfortunately I cannot find the time at this point for > reviewing the Phoenix library. I am familiar with the library, however, > based on careful inspection some time ago. > Phoenix "modernizes", extends, and improves over > Lambda (and FC++), and there's no question about the quality of code or documentation. > > So as much as my opinion counts without conducting a proper review, > I hope it is all right to express my support for Joel's and Dan's work, > and that I wish to see Phoenix accepted to Boost. Thank you, Jaakko for your support. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

1 0

[shared_ptr] Where is the bug?
by vicente.botet 03 Oct '08

03 Oct '08

Hi, I have the following program with the following output #include <iostream> #include <boost/shared_ptr.hpp> using namespace boost; struct B { ~B() { std::cout << "~B" << std::endl; }; }; struct X : B { ~X() { std::cout << "~X" << std::endl; }; int i; }; int main () { shared_ptr<B>* ptr=0; { shared_ptr<X> ptrX1(new X()); ptr = new shared_ptr<B>(ptrX1); } std::cout << "BEFORE" << std::endl; delete ptr; std::cout << "AFTER" << std::endl; B* b = new X(); std::cout << "BEFORE" << std::endl; delete b; std::cout << "AFTER" << std::endl; return 0; } BEFORE ~X ~B AFTER BEFORE ~B AFTER EXIT STATUS: 0 Where is the bug? Vicente P.S. I'm using g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

4 7

[thread_safe_signals] making the connection accesible from slot
by Frank Mori Hess 03 Oct '08

03 Oct '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm curious if anyone has a good idea on how to make a slot's connection easily accesible to it when it is running. A common case is a slot blocks it's own connection to avoid infinite recursion when it is about to do something that will cause its signal to be invoked again. The problem is, for a slot to block its own connection, it needs access to a connection object. But it is a pain in a multi-threaded situation to pass the connection to the slot, since the connection is not available until after the slot has already been connected to the signal. In a single-threaded program, you can do something like: namespace bs2 = boost::signals2 bs2::signal<void (void)> sig; void myslot(boost::shared_ptr<bs2::connection> conn); boost::shared_ptr<bs2::connection> conn(new bs2::connection); *conn = sig.connect(boost::bind(&myslot, conn)); void myslot(boost::shared_ptr<bs2::connection> conn) { //... { bs2::shared_connection_block blocker(*conn); //... } } However, even in thread_safe_signals, assignment of a connection object is not thread-safe. So if the signal can be invoked concurrently, you would need to protect the connect with a mutex, and also protect any use of the connection inside the slot with the mutex, which starts to get a bit tedious. Maybe an additional connect overload for signals, which takes a slot that has an additional parameter added to its signature (a reference to its connection)? For example, for a signal<void (int)> The slot_type is usually slot<void (int), function<void (int)> > I could add an extended_slot_type typedef as a slot<void (int, const connection&), function<void (int, const connection&)> > Then I would add overloads to signalN::connect which accept the new extended_slot_type. That would also mean an additional template parameter for signals, like ExtendedSlotFunction. Or, the SlotFunction template could be dropped entirely and the signal class hard-coded to use boost::function. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI5oxM5vihyNWuA4URAhKkAJwImDkQjMXbBD+81a925QXS5vKvNACgkBr9 dGC3G/2YLGVRu/CJl1zUzSY= =3oKu -----END PGP SIGNATURE-----

1 0

RFC: Integrating Boost.Process and Boost.Asio
by Boris 03 Oct '08

03 Oct '08

I'm looking for ideas how to integrate Boost.Process and Boost.Asio. As of today it is possible to use asynchronous I/O with Boost.Process. However you have to pass around low-level file descriptors/HANDLEs like this: bp::child c = start_child(); bp::pistream &is = c.get_stdout(); #if defined(BOOST_POSIX_API) ba::posix::stream_descriptor in(io_service); #elif defined(BOOST_WINDOWS_API) ba::windows::stream_handle in(io_service); #endif in.assign(is.handle().release()); is.async_read_some(...); It would be nice if you could write: bp::child c = start_child(); bp::pistream &is = c.get_stdout(); is.async_read_some(...); The first question is then where to pass the io_service instance to Boost.Process? In Boost.Asio I/O objects are typically initialized with io_service. As both child and pistream are created in the library io_service would need to be passed to Boost.Process when the child is spawned. However developers who don't want to use asynchronous I/O really shouldn't create an io_service instance first. If io_service is not passed to the constructor I wonder where to pass it then? As far as I see there are no recommendations or guidelines in the Boost.Asio documentation (probably because all I/O objects so far are always initialized with io_service). Another idea is of course adding a new class to Boost.Process (pistream would then only be used for synchronous I/O)? Right now I'd probably go this way? Boris

2 5

Subject: Re: [shared_ptr] Where is the bug?
by Kasra Nassiri(Math & ComSci) 03 Oct '08

03 Oct '08

Hi, Well the bug is in the fact the when you allocated: B* b = new X(); You have allocated an int extra, thus when you call: delete b; You are only destructing what was allocated by B, which cause a sizeof(int) bytes memory leak each time you do this. Just use a virtual destructor on virtual ~B() ... and that would take care of it all. With best regards Kasra Nassiri

4 4

Re: [boost] [shared_ptr] Where is the bug?
by Kasra Nassiri(Math & ComSci) 03 Oct '08

03 Oct '08

> No. > You are invoking undefined behaviour. Well, by definition you could not be more right, however, in practice my point applies. It is like the x86 sh(l/r) instructions, although for some values larger than the bitfield of the operand the instruction is undefined it behaves in a certain way :D. However, you are right and I am wrong! With best regards Kasra Nassiri

1 0

[threadalert] alternative design for thread_member_ptr and thread preamble
by vicente.botet 03 Oct '08

03 Oct '08

Hello, I have do some refactoring on the thdmbrptr.hpp and thdmbrptr.cpp files. * The design is now more decoupled, separating the thread preamble initialization and the thread_member_ptr type. * The thread_member_ptr constructor supports now a cleanup functions parameter. * I have added the release function * We don't need any more a new class thread (boostex::thread) that inherits from boost::thread, to store the common context for the thread to manage the detaching of the pointer from the map (this is done using the thread_specific_ptr cleanup). * I have renamed boostex::thread::init by boost::thread_preamble, and these preamble functions will be called on the threads initialized using the thread_preamble::proxy. You can find the code and example in the attached files. Just to recall the goals: * thread_preamble allows to define some preample functions which will be called by each thread initialized using the thread_preamble::proxy * thread_member_ptr: The intent of this class is to allow two threads to establish a shared memory space, without requiring the user code to pass any information. This basically does work like a thread local storage from inside the thread: boost::thread_member_ptr<myclass> pmyclass; All functions known from thread_specific_ptr are available, and so is semantics from inside the thread. Besides this another thread can get access to the data by: pmyclass[th->get_id()]->foo(); where "th" is a boost::thread* and "foo()" is a function of "myclass". The lifetime of the myclass instance is managed by a shared_ptr. One reference is held by the thread (by means of a tss), a second is held by the boost::thread object that created the thread, and additional references might be held by other threads that obtained it by "*pmyclass[th]". Please let me know what do you think of this new design. I'll use these classes for some libraries: * a software transaction library: transactional thread specific context which can also be accesible from other threads during consistency checking * a thread keep alive: the keep_alive_manager will check the registered threads by looking on the associated keep_alive thread_member_ptr. Do you think that these two classes might be a candidate to a separated Boost library or that it will be better to integrate them on the thread library? Best, Vicente

2 1

[mp_math_v02] Bug in assignment operator
by Mikko Vainio 03 Oct '08

03 Oct '08

Hi, Referring to the mp_math_v02 library in the Vault, the assignment operator of class mp_int<> does not quite behave the way it should. The following program #include <iostream> #include <boost/mp_math/mp_int.hpp> using namespace std; int main( int argc, char* argv[] ) { boost::mp_math::mp_int<> a, b(-1); a = -1; cout << a << " == " << b << endl; return 0; } produces the output -4294967295 == -1 It seems that the constructor code behaves as expected. I'm using gcc 4.3.0 on x86 Fedora 9. Cheers, Mikko

2 1

[shared_ptr] towards a static_cast applied to smart_ptr
by vicente.botet 03 Oct '08

03 Oct '08

Hello Peter, the following simplified example do not compile when DONT_NOT_COMPILE is defined. #include <boost/shared_ptr.hpp> using namespace boost; struct X { int i; }; int main () { shared_ptr<X> ptrX1(new X()); shared_ptr<void> ptr_void(ptrX1); #if DONT_NOT_COMPILE shared_ptr<X> ptrX2(ptr_void); #endif return 0; } test_thread_shared_ptr.cpp: In function `int main()': test_thread_shared_ptr.cpp:37: error: no matching function for call to `boost::s hared_ptr<X>::shared_ptr(boost::shared_ptr<void>&)' ../../../boost/shared_ptr.hpp:154: note: candidates are: boost::shared_ptr<X>::s hared_ptr(const boost::shared_ptr<X>&) ../../../boost/shared_ptr.hpp:241: note: boost::shared_ptr< <template-parameter -1-1> >::shared_ptr(const boost::detail::shared_count&, T*) [with T = X] ../../../boost/shared_ptr.hpp:167: note: boost::shared_ptr< <template-parameter -1-1> >::shared_ptr() [with T = X] This is normal as void* is not convertibel to X*. But in my program I can ensure that the pointeed object by ptr_void is a X pointer. So it would be safe to do a kind of static_cast on shared_ptr. At the end smart pointers should behave like pointers. My real use case is a map of void* to shared_ptr<void>. I insert pairs of T* and shared_ptr<T> and I want be able to static_cast the resulting shared_ptr<void> of find function to shared_ptr<T>. Can I achieve this already? I was thinking is something like something like shared_ptr<X> ptrX2(boost::static_cast<shared_ptr<X> >(ptr_void)); If we can not achieve this now, I think that it should be not too dificult to implement inside your library. Do you think that this is an interesting feature to be included in the Boost.SmartPtr library? Best, Vicente Botet

2 2