October 2008 - Boost - lists.preview.boost.org

link error "can not open file "libboost_regex-vc80-mt-gd-1_36.lib"
by ipangth 06 Oct '08

06 Oct '08

I built boost_1.36_0 with vs2005, used command "bjam.exe --build-dir="D:\src\boost_1_36_0" --toolset=msvc --build-type=complete stage". Then i built a project using regex, and link error "can not open file "libboost_regex-vc80-mt-gd-1_36.lib" ". I check the stage diretory, found regex libs: libboost_regex-vc80-mt-s-1_36.lib libboost_regex-vc80-mt-s.lib libboost_regex-vc80-mt-sgd-1_36.lib libboost_regex-vc80-mt-sgd.lib libboost_regex-vc80-s-1_36.lib libboost_regex-vc80-s.lib libboost_regex-vc80-sgd-1_36.lib libboost_regex-vc80-sgd.lib There are no "libboost_regex-vc80-mt-gd-1_36.lib" here. How can i get the "libboost_regex-vc80-mt-gd-1_36.lib" ? PS. I have a machine which has vs2005 and vs2008 install, when i built boost on it, it always uses vs2008 to compile. How can i just use vs2005 buiding it? -- Best regards, PangYongQiang

2 4

[asio] ip::tcp::iostream usage
by Gregory Dai 05 Oct '08

05 Oct '08

The classic example: int main() { boost::asio::ip::tcp::iostream s("www.boost.org", "http"); s << "GET / HTTP/1.0\r\n"; s << "Host: www.boost.org\r\n"; s << "\r\n" << std::flush; std::cout << s.rdbuf(); return 0; } It works. But with a server on port 8080, it does not seem to work anymore. The host line was changed to s << "Host: www.boost.org:8080\r\n"; of course.

2 2

[tr1][spirit][hash] Boost trunk +VC9 - autolinking libboost_math
by Richard Webb 05 Oct '08

05 Oct '08

When test building some code with VC9 + the current Boost trunk i had a link failure due to a missing libboost_math_c99-vc90-mt-1_37.lib, which i hadnt built because i'm not using the math lib. On investigation, this seems to be down to using Spirit/Hash(via multi_index) when the "boost/tr1/tr1" dir is in the include path. More specifically, the files: spirit\home\classic\core\primitives\impl\numerics.ipp functional\detail\float_functions.hpp do an include <cmath>, which in this case includes <boost\tr1\cmath.hpp>, which then includes <boost/math/tr1.hpp>, autolinking and all. I can work around the problem by building the math lib or turning off auto linking for it but it seems wrong that i have to do that. Is there a better official solution for this, such as using <config/no_tr1/cmath.hpp> instead of <cmath> ? Thanks, Richard Webb -- View this message in context: http://www.nabble.com/-tr1--spirit--hash--Boost-trunk-%2BVC9---autolinking-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[xpressive] recursive calls for matching repetitions.
by Raindog 05 Oct '08

05 Oct '08

Eric, I was recently hit by a stack overflow due to the way xpressive makes recursive calls when dealing with patterns like *_, etc and was wondering if there is an alternative, more efficient way of matching these types of patterns. p.s I know about keep() but that can get cumbersome to use everywhere.

2 1

[variant] unreferenced formal parameter warning from VC9
by Richard Webb 05 Oct '08

05 Oct '08

(i think i might have mentioned this before, but it still happens with the current code, so...) Using Variant on VC9 with warning level 4 can result in an unreferenced parameter warning: boost/variant/variant.hpp(289) : warning C4100: 'operand' : unreferenced formal parameter This can be silenced by extending the existing Borland workaround to apply to VC as well. For example, change the existing: #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x0551)) operand; // suppresses warnings to #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x0551)) || BOOST_WORKAROUND(BOOST_MSVC, >= 1400) operand; // suppresses warnings Thanks, Richard Webb -- View this message in context: http://www.nabble.com/-variant--unreferenced-formal-parameter-warning-from-… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

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