September 2008 - Boost - lists.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

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

phoenix::bind
by Peter Dimov 05 Oct '08

05 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

[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

[Phoenix] review
by Giovanni Piero Deretta 02 Oct '08

02 Oct '08

- Please always state in your review, whether you think the library should be accepted as a Boost library! Having to review a library that is already expected to change is hard, OTOH functional programming in c++ need to go beyond boost.lambda (which has been basically in maintenance mode for a long time), and I think that Phoenix is the way to the future. Thus I think that Phoenix should be accepted. I support having an extra mini review after the implementation has been updated, but my vote is not under this condition. I think that the review plan proposed by Eric is great. - What is your evaluation of the documentation? I think that documentation of Phoenix is probably the most important part of the library and I consider it of high quality: I've been an happy lambda user for a couple of years. I went beyond its documented interface and started to play with its internal. I've been able to add lazy functions to lambda and other nice additions. But I would never even have attempted that if I hadn't been exposed to the Phoenix documentation. I've never really used the phoenix library, but I've read its documentation many times (starting maybe 4 years ago, I think it was the old V1 documentation). I remember that the first time I read it I understood basically nothing. But it got me interested in functional programming. Every time I read it I learned a bit more until something clicked. After that everything seemed so obvious. Thanks Joel, you exposed me to a new world. - What is your evaluation of the design? Very good. I'm a big fan of lazy functions (I try to make all my polymorphic functions object lazy, and leave bind only for good old function pointers), and I hope that Joel will make them 'optionally lazy'. But even if he didn't, thanks to phoenix extensibility, it wouldn't be hard to add it on top of the current design. Again, I vote for always requiring lambda[] around every lambda expression, as this could really help to solve many problems, like assignability and operator& problems. It will also open up the road for further improvements, like overriding capture defaults or selecting perfect forwarding. About perfect forwarding: it would be great if phoenix allowed it by default at least on compilers that support rvalue references. IMHO result_of support is necessary for a library released today :). I cannot really comment on the details of extension interface as it seems that it is bound to change, but I think it is, together with lazy functions, the bigger improvement to boost.lambda. - What is your evaluation of the implementation? I did only take a quick glance at the implementation, but the code looks surprisingly clean (even if comments are a bit spotty), with few compiler workarounds. This is most likely due to the clean separations of the various parts of the library. Even the use of the preprocessor seems limited to the strict neces. I did notice that stl function object instances are declared, as const, in an header file. This could cause ODR violations. - What is your evaluation of the potential usefulness of the library? Great, at least if one is interested in a more functional approach to C++. - Did you try to use the library? With what compiler? Did you have any problems? I tried some examples with gcc 4.2. Didn't have any problem after I figured out that the header placement inside spirit changed from boost 1.35 to 1.36. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? An in depth study of the documentation and a quick reading of the source. - Are you knowledgeable about the problem domain? A bit. I've never implemented a full lambda library, but played a lot with boost.lambda. [ I would have liked to make a more in-depth review, but I'm in the middle of a deadline, sorry] -- gpd

3 6

[Review] Phoenix review starts today, September 21st
by Hartmut Kaiser 02 Oct '08

02 Oct '08

Hi all, The review of Joel de Guzmans and Dan Marsdens Phoenix V2 library starts today, September 21st 2008, and will end on September 30th. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! --------------------------------------------------- About the library: The Phoenix library enables FP techniques such as higher order functions, lambda (unnamed functions), currying (partial function application) and lazy evaluation in C++. The focus is more on usefulness and practicality than purity, elegance and strict adherence to FP principles. History: Phoenix is a mature library from years of use as a sub-project under Spirit where it serves its purpose for semantic action handling. Phoenix predates Lambda's acceptance into Boost, but not Lambda itself. When Lambda was reviewed, it was concluded that both libraries were to be merged, and work on it began, culminating in Phoenix V2, what you are seeing now (an interesting offshoot of this effort is Boost.Fusion. We needed a powerful tuple facility with algorithms to get the design right). Recently, Eric Niebler did a (fully compatible) port to proto making use of boost.typeof for result type deduction. Eric's port, while significant, will not be the subject of the review, but can be regarded as the future of Phoenix (Phoenix V3). Phoenix V2 is currently a utility library included with Spirit V2 and therefore is already available from the latest Boost distributions (headers: $BOOST_ROOT/boost/spirit/home/phoenix, docs: $BOOST_ROOT/libs/spirit/phoenix, or http://www.boost.org/doc/libs/1_36_0/libs/spirit/phoenix/index.html) Phoenix V2 is a very important infrastructure library, IHMO. It has been used for several other library writing efforts already, most notably, Spirit V2. --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Regards Hartmut Review Manager

12 37

[integer] Promotion of endian library code from vault
by Neil Mayhew 01 Oct '08

01 Oct '08

On 2006-07-22 12:21:01, Beman Dawes wrote: > [boost] [integer] endian-0.6 posted w/ names changed > endian-0.6.zip has been posted in the integer directory of the file > vault at http://boost-consulting.com/vault/ This code is still in the vault, but I'd like to see it in the main part of boost. What needs to be done to make this happen? The endian library is exactly what I've been looking for, and I would really like to use it in my work, but I can't justify that to my colleagues if it's not an official part of boost. I would hate to become yet another person that reinvents this particular wheel. However, I notice there was a lot of discussion <http://lists.boost.org/Archives/boost/2006/07/108125.php> about PODs vs constructors, because of unions, so maybe not enough consensus was reached? There were some interesting proposals but no agreed-upon solution. In which case, I suspect that people will need to copy the code and each hack it to suit their own purposes, which is not what boost is all about. I have two use cases from my own work: TrueType fonts, and Mac HFS+ file systems. Both of these are big-endian file formats that need to be read into memory and processed, so (FWIW) I would support the POD approach. Currently, I can't use the code as-is because of the need to use the types in unions. References: http://lists.boost.org/Archives/boost/2000/03/2495.php http://lists.boost.org/Archives/boost/2006/05/105621.php http://lists.boost.org/Archives/boost/2006/06/105695.php http://lists.boost.org/Archives/boost/2006/06/105779.php http://lists.boost.org/Archives/boost/2006/06/105968.php http://lists.boost.org/Archives/boost/2006/06/106655.php http://lists.boost.org/Archives/boost/2006/07/108125.php http://lists.boost.org/Archives/boost/2006/07/108202.php --Neil

9 37

Phoenix and perfect forwarding
by Mathias Gaunard 01 Oct '08

01 Oct '08

Compilers are starting to support rvalue references. Wouldn't it be pertinent to use that to implement perfect forwarding, if available? Phoenix could surely benefit from that.

3 2

[python] Setting a pointer into an object
by Robert Dailey 01 Oct '08

01 Oct '08

Hi, I am trying to do the following: SomeClassOfMine* myInstance; // Assume valid pointer boost::python::object myObject( myInstance ); However, doing so causes an exception to be thrown when I run my application. The exception thrown is below (Note I'm using MSVC9): First-chance exception at 0x7c812aeb in Crusades_Debug.exe: Microsoft C++ exception: boost::python::error_already_set at memory location 0x0012f0cc.. Unhandled exception at 0x7c812aeb in Crusades_Debug.exe: Microsoft C++ exception: boost::python::error_already_set at memory location 0x0012f0cc.. How can I assign the pointer above to a boost::python::object? I'm trying to give my python scripts access to an instance of a class that I haven't really exposed to Python yet, so I'm not sure of the consequences of that. I was going to extend the SomeClassOfMine class to python later on after I verify that I can get this working. Once I have myObject in a valid state, I will insert it into the __main__'s __dict__ namespace for a specific module so that it has access to it as a global python variable. Help is appreciated.

2 3