- Boost - lists.boost.org

generative geometry algorithms library idea
by Brandon Kohn 05 Oct '08

05 Oct '08

Hi all, I've been doing some work for the past few weeks on a generative/generic 2D geometry library (leaving open the possibility for 3D in the future). The idea is for all the algorithms to be generative taking coordinate, point, segment, polyline/gon types as template parameters (or deducing where presented as nested typedefs) and specialized traits types for accessing type traits and methods ( things like access_traits<point_type>::get_x( point ) .). So far the library has allowed me to work with the same algorithms in native floating type and exact types like gmp's mpq_class. It's just a first rough draft of ideas, and I would really like some input from the community to see if I'm on the right track for something that boost would be interested in having. I'll post a copy of the lib in the vault. It's header only (with a small testbed with trivial testing and a visual studio 2008 solution/project). I hope there should not be too many issues compiling these tests/headers under other platforms. I'll put it in the vault as generative_geometry_algorithms.zip link: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=genera… Thanks for any constructive input. With regards, Brandon Kohn

6 10

[asio] using a resolver::query to perform a "gethostbyaddr"
by Carlo Medas 05 Oct '08

05 Oct '08

Dear all, it's kind of direct and easy to perform a gethostbyname-like operation with an asio::ip::tcp::resolver::query. But is there a way to perform the opposite operation? I mean to perform a gethostbyaddr-like operation where the input is an IP address, and output is the associated DNS name. Thanks in advance. Best regards, \Carlo Medas

1 0

phoenix::bind
by Peter Dimov 04 Oct '08

04 Oct '08

This is not a review, sorry. Is it a goal of phoenix::bind to one day replace lambda::bind and boost::bind, being a superset of both, as well of std::bind? I have hoped for boost::lambda::bind to supercede boost::bind. It is a common claim that the only advantage of boost::bind is that it works on more compilers. But this isn't true. It supports constructs which lambda::bind does not; using smart pointers with member functions, member functions of abstract classes, proper const propagation, is_placeholder, _4.._9, and so on. There were other differences (lack of result_type support...) for which I was able to contribute patches to Lambda. But some of the differences are systemic and can only be addressed by a maintainer. Having two components named "bind" has always been a problem for our users. Having three will not help. Ideally, all "bind"s ought to resolve (on a supported compiler circa '08) to the same component. When I heard that the next Phoenix (at the time this meant V2) was intended to be the successor to both Phoenix 1 and Lambda, I thought that we were about to finally have a single bind that "just works". But - and sorry if this is not the case - I do not get the impression that this is a high priority goal for V2. It'd be nice if I were mistaken; it would be nicer still if phoenix::bind passed all boost::bind tests so that we can just replace boost/bind.hpp with a single using declaration. :-) To avoid any misunderstandings: this is not a review, and the above is not a condition for acceptance.

8 74

[simple_segregated_storage] segfault
by Phil Bouchard 04 Oct '08

04 Oct '08

I haven't tried this yet on Linux but so far on Gcc for Wndows my test application segfaults on an allocation routine. Here is the backtrace: #0 0x00415ace in boost::simple_segregated_storage<unsigned int>::try_malloc_n (start=@0x22fc00, n=16, partition_size=4) at simple_segregated_storage.hpp:234 #1 0x00415bc7 in boost::simple_segregated_storage<unsigned int>::malloc_n (this=0x463010, n=17, partition_size=4) at simple_segregated_storage.hpp:256 #2 0x0041c7f2 in boost::pool<boost::default_user_allocator_new_delete>::ordered_malloc (this=0x463010, n=68) at pool.hpp:511 #3 0x0041fb25 in boost::detail::sh::pool::allocate (this=0x463010, s=68) at sh_owned_base_nt.hpp:103 #4 0x00426669 in boost::detail::sh::shifted<std::_List_node<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > > >::operator new (s=68) at sh_owned_base_nt.hpp:213 #5 0x0041f420 in boost::detail::sh::shifted_allocator<std::_List_node<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > > >::allocate (this=0x3e5094, s=1) at shifted_allocator.hpp:83 #6 0x0044aa5d in std::_List_base<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > >::_M_get_node (this=0x3e5094) at stl_list.h:333 #7 0x00453ff2 in std::list<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > >::_M_create_node (this=0x3e5094, __x=@0x22ff50) at stl_list.h:457 #8 0x0045414c in std::list<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > >::_M_insert (this=0x3e5094, __position={_M_node = 0x3e50c8}, __x=@0x22ff50) at stl_list.h:1185 #9 0x0045418d in std::list<boost::detail::sh::shifted_ptr<vector>, boost::detail::sh::shifted_allocator<boost::detail::sh::shifted_ptr<vector> > >::push_back (this=0x3e5094, __x=@0x22ff50) at stl_list.h:807 #10 0x00401708 in main () at shifted_ptr_test2.cpp:102 -Phil

2 14

[Review] Phoenix review results
by Hartmut Kaiser 04 Oct '08

04 Oct '08

Hi all, the Phoenix review is over and I counted 15 votes, 11 of which vote for acceptance and 4 vote for conditional acceptance. Let me explain. All reviewers stated that the outstanding quality of the library and its documentation fully merit immediate acceptance. There is no direct concern with regard to the library itself. Phoenix V2 is already in the Boost distribution as a Spirit sub-library and has matured for a long time, proving its stability and usability. On the other hand, Phoenix provides functionality already covered by Boost.Bind and Boost.Lambda. It is the general intention to use Phoenix as the development ground for a new unified Boost library in this area. The review discussions revealed quite some details and certain problems which have to be resolved for this merger to happen. Joel has a full list of these details and promised to address all of them before adding Phoenix to the Boost SVN. The library authors made clear from the beginning that the review of the current Version 2 of the library is just a stepping stone towards this goal. At the same time Eric Niebler presented a first version of a Proto based Phoenix rewrite (referenced as Phoenix V3). It is the general consensus to use Phoenix V3 as the basis for further development. At the same time Phoenix V3 exposes the same interface as Phoenix V2 and passes all related tests. This review formally was about Phoenix V2, but largely turned out to be a discussion of the future of Bind/Lambda and how Boost should go forward in this direction. Again, the general consensus here is that a) we need a unified approach to bind, lambda, et.al., and b) Boost users need interface stability and minimal disruption. So here is the review result: The quality of Phoenix warrants immediate acceptance into Boost. OTOH, adding Phoenix to Boost as is introduces yet another library dealing with functional idioms. This possibly increases the confusion around the fact which of the libraries to use, etc. The goal should be to have a clear integration of, and migration path from the existing Boost.Bind and Boost.Lambda libraries before final addition of Phoenix to Boost. We will have a mini review before Phoenix gets merged to SVN to make sure whether the feedback from the v2 review was accommodated. Additionally this review will have to discuss: - the breaking interface changes from v2 - the migration path from boost::bind and lambda to Phoenix - how the interoperability with std::bind is solved (result_of semantics) - C++0x features such as rvalue references and variadic templates - the new extensibility mechanism - unified placeholders and interoperability issues with other Proto-based DSELs (such as Spirit.Qi, Spirit.Karma, and Xpressive) - compile times In general, the review was valuable for what it accomplished. It moved us closer towards a unified Boost library in the domain of functional programming idioms. Thanks to Joel and Dan for the high quality submission and to all participating the discussion for their valuable insights! Regards Hartmut Review Manager

1 0

[phoenix] local_reference problems
by Steven Watanabe 04 Oct '08

04 Oct '08

AMDG The following code does not compile because phoenix tries to call the % operator with the types: boost::phoenix::detail::local_reference<boost::format> % int What is the rationale for local_reference? #include <boost/spirit/home/phoenix/operator.hpp> #include <boost/spirit/home/phoenix/core.hpp> #include <boost/spirit/home/phoenix/scope.hpp> #include <boost/format.hpp> #include <algorithm> #include <vector> using namespace boost::phoenix::arg_names; using namespace boost::phoenix::local_names; using namespace boost::phoenix; int main() { std::vector<int> values(10); std::for_each(values.begin(), values.end(), let(_f = boost::format("value is %d = %d\n")) [ std::cout << _f % _1 % _1 ] ); } C:\boost\trunk\boost/spirit/home/phoenix/operator/arithmetic.hpp(78) : error C2676: binary '%' : 'const boost::phoenix::detail::local_reference<T>' does not define this operator or a conversion to a type acceptable to the predefined operator with [ T=boost::basic_format<char> ] In Christ, Steven Watanabe

2 1

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