- Boost - lists.boost.org

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

sandbox:spatialIndex example compilation fails on gcc-4.2
by Sandeep Gupta 02 Oct '08

02 Oct '08

Hi, Not sure if this known problem but example.cpp of spatial_index library fails to compile out of the box (this is latest version check out from svn repository). A brief look at the code shows that all avatar of spatial_index take two template-arguments but example calls it with one argument. Please find the error message pasted below. Thanks sandeep example.cpp:14: error: wrong number of template arguments (1, should be 3) ../../../boost/spatial_index/spatial_index.hpp:29: error: provided for 'template<class Point, class Value, class Index> class boost::spatial_index::spatial_index' example.cpp:14: error: invalid type in declaration before ';' token example.cpp:17: error: request for member 'get_nothing_count' in 'object', which is of non-class type 'int' example.cpp:18: error: request for member 'nothing' in 'object', which is of non-class type 'int' example.cpp:19: error: request for member 'get_nothing_count' in 'object', which is of non-class type 'int' example.cpp:21: error: request for member 'get_call_count' in 'object', which is of non-class type 'int' example.cpp:22: error: request for member 'nothing' in 'object', which is of non-class type 'int' example.cpp:23: error: request for member 'get_call_count' in 'object', which is of non-class type 'int' example.cpp:24: error: request for member 'get_nothing_count' in 'object', which is of non-class type 'int'

1 0

[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

error during compliation of documentation for SpatialIndexes
by Sandeep Gupta 01 Oct '08

01 Oct '08

Hi, I am getting following error while compiling the docs for spacial_indexing: ...patience... ...found 1299 targets... ...updating 2 targets... xslt-xsltproc ../../../bin.v2/libs/spatial_index/doc/gcc-4.2/debug/spatial_index_xml.docbook ../../../bin.v2/libs/spatial_index/doc/gcc-4.2/debug/spatial_index_xml.xml:82: parser error : Opening and ending tag mismatch: section line 44 and library </library> ^ ../../../bin.v2/libs/spatial_index/doc/gcc-4.2/debug/spatial_index_xml.xml:83: parser error : Premature end of data in tag library line 3 ^ unable to parse ../../../bin.v2/libs/spatial_index/doc/gcc-4.2/debug/spatial_index_xml.xml XML_CATALOG_FILES=/home/sandeep/develop/libraries/boost-trunk/bin.v2/boostbook_catalog.xml export XML_CATALOG_FILES "/usr/bin/X11/xsltproc" --stringparam annotation.support "1" --stringparam chunk.first.sections "1" --stringparam chunk.section.depth "3" --stringparam generate.section.toc.level "3" --stringparam toc.max.depth "3" --stringparam toc.section.depth "3" --xinclude -o "../../../bin.v2/libs/spatial_index/doc/gcc-4.2/debug/spatial_index_xml.docbook" "/home/sandeep/develop/libraries/boost-trunk/tools/boostbook/xsl/docbook.xsl" "../../../bin.v2/libs/spatial_index/doc/gcc-4.2/debug/spatial_index_xml.xml" ...failed xslt-xsltproc ../../../bin.v2/libs/spatial_index/doc/gcc-4.2/debug/spatial_index_xml.docbook... ...skipped <phtml>standalone_HTML.manifest for lack of <p../../../bin.v2/libs/spatial_index/doc/gcc-4.2/debug>spatial_index_xml.docbook... ...failed updating 1 target... ...skipped 1 target... Thanks sandeep

1 0