- Boost - lists.preview.boost.org

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

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

Re: [boost] [switch] Is there any interest in library switch extention?
by Kasra Nassiri(Math & ComSci) 01 Oct '08

01 Oct '08

>I hardly see how this could work for a O(1) lookup (the point of the >switch statement). I have found a compile time solution! However, we need C++0x :( A hash functions with output type of <int> so we could embed the statement in a normal switch statement on C++0x. #define BOOST_SWITCH( object ) switch ( const_hash_function(object) ) #define BOOST_CASE( case_object ) case const_hash_function(case_object) #define BOOST_DEFAULT default So we could write code like: BOOST_SWITCH( "Hello World" ) { BOOST_CASE("wrong value"): BOOST_CASE("another wrong value"): cout << "Reached wrong statements" << endl; BOOST_BREAK; BOOST_DEFAULT: cout << "Hello World" << endl; }; What I like to add is a reference to the value of the BOOST_SWITCH(...), in this example "Hello World".

2 1

[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] Review ended September 30th
by Hartmut Kaiser 01 Oct '08

01 Oct '08

Hi all, just a (last) reminder for all of you still wanting to submit a review. The official review period is over, but since I'm going prepare the review summary this weekend only anyway - you still have a day or two. Regards Hartmut Review Manager

1 0

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 30 Sep '08

30 Sep '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

[interprocess] message_queue documentation issue
by Michael Caisse 30 Sep '08

30 Sep '08

The message_queue documentation states: message_queue(open_only_t <http://www.boost.org/doc/libs/1_36_0/doc/html/boost/interprocess/open_only_…> open_only, *const* *char* * name); Opens a previously created process shared message queue with name "name". If the was not previously created or there are no free resources, the function returns false. The constructor doesn't return a value of course. It does look like the message_queue constructors can throw however... and the documentation should mention that. Best Regards - michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 1

[Phoenix] Some questions and notes...
by Giovanni Piero Deretta 30 Sep '08

30 Sep '08

Hi all, I'm writing a review of phoenix, but first I have a some questions and notes. * First of all, it is not clear to me how 'lambda' works. I would have thought that it just introduced a new scope, but it seems that it does something more: 1: int i = 10; 2: cout << arg1(i) <<endl; 3: cout << lambda[ arg1 ](i) <<endl; // doesn't compile 4: cout << lambda[ arg1 ]()(i) The use of lambda at line 3 is completely superfluous, nevertheless, I prefer that syntax because it makes it clear that I'm using a lambda expression (always using lambda will also allow some other tricks I'll discuss later). Surprisingly, line 3 doesn't compile. lambda::operator[] actually returns a nullary stub that must be evaluated to actually get our unary function. Is this really necessary? can it be fixed? * non-standard result<> protocol. IMHO for Phoenix to become a first class boost library, it should support result_of out of the box. I understand that this is not done for backward compatibility, but I think that there are three solutions: 1) old users will still be able to use the Phoenix inside spirit if they have a large codebase that uses the old protocol. 2) phoenix could provide a wrapper that converts from the old to the new protocol and viceversa. This would require some changes in the client code. 3) phoenix could detect the protocol used by the user function and switch between the old and new 'result'. This is hard to do in a robust way, but breaks no user code. I would prefer the first option. * Perfect forwarding. I'm used to the perfect forwarding in boost lambda (which, contrary to what the documentation states, perfectly forwards up to 3 args). Personally have little use for lambdas that take their arguments by non const reference as I strive for referential transparency. I know that implementing this feature has an high compile time cost, but there should at least be an option to enable it. I would vote for two additional 'lambda' syntaxes: clambda and plambda (better names are wellcome). The first one would work like boost lambda const_arguments and should have no compile time cost, while the second will do perfect forwarding up to some parameter number. This would require the lambda[] syntax to actually return the wrapped function object, not a stub (as per first question). * operator->*. I sometimes use this operator with boost lambda, as a short hand for binding member functions, but, as in phoenix, it requires it lhs to be a pointer. Would it possible to extend it to any functions? for example: struct foo { int bar; }; std::vector<foo> in =...; std::vector<int> out; std::transform(in.begin(), in.end(), std::back_inserter(out), (&arg1)->*&foo::bar); The parenthesis, and ampersand are ugly, it would be great if this worked: std::transform(in.begin(), in.end(), std::back_inserter(out), arg1->*&foo::bar); I think this would interfere with foo implementing its own operator->*. Which brings the question... * ... how do I implement type deduction for the my own overloaded operators? I.e. what is the phoenix equivalent of http://tinyurl.com/4botne ? By reading of the documentation I couldn't figure out an easy way to do it. Well, that's all for now, those questions are mostly to get the discussion rolling, more to come. -- gpd

3 10

Re: [boost] [Review] Phoenix review starts today, September 21st
by dan marsden 30 Sep '08

30 Sep '08

Daniel Walker wrote: <snip> >Of course not. :-) But going in-depth into V2's implementation is not >the same as going in-depth into V3. The design may be the same, but >simple diffing and greping shows the implementations are not. And >that's to be expected. As I understand, whole components were gutted >and replaced with Proto, which is a good thing. So let's continue that >effort and spend our energy on V3 and not look back! > >Now, how that relates to the review formalities and the fact that >apparently V2 is under review, I am not sure. As far as I can tell, >all the reviews thus far have assumed the V2 implementation. I would >suggest withdrawing V2 from consideration (leaving it as is in >Boost.Spirit), finishing V3 (which becomes the new Boost.Lambda), and >then resubmitting for review, but I'm no expert on this process. > It is my understanding that Boost authors retain the "rights" to modify and upgrade their libraries once accepted, both in terms of implementation and interface changes. Boost.Xpressive has seen many changes iirc, including the sorts of changes that we're discussing (reimplementing in terms of proto + I believe some smaller interface changes). Many other libraries have similar history. If the authors of these libraries had stated their development plans, in advance of review, should they have been rejected until they were "finished"? Joel has been very open in stating his future plans, but what he plans has happened many times before to accepted libraries. Obviously the rather fluid state of the libraries does muddy the purpose of the review. I'd suggest we review libraries as is, answer all the usual questions about interface, quality of implementation, docs etc. There seems to be some implicit assumption that the author will act in the spirit of Boost, and reimplement + extend to the same level of quality as seen in the review. I think Joels track record in this area speaks for itself. On your other comment about Phoenix2 remaining under Spirit if it were not to be accepted, that is obviously true, but at some employers/organizations passing the review process and being an official part of a Boost release is a prerequisite to using a library. Cheers Dan

10 24

[threadpool] new version with work-stealing
by k-oli＠gmx.de 30 Sep '08

30 Sep '08

Hi, I've uploaded a new version of threadpool lib (http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost_…) changes: - support of work-stealing strategy - task can be interrupted an waited for its termination - thread management strategies lazy and adaptive removed - channel rendezvous removed regards, Oliver

1 0

[config] BOOST_HAS_THREADS with libstdc++
by Frank Mori Hess 30 Sep '08

30 Sep '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It looks like the gcc bug (pr 11953) that inspired the workaround in boost/config/stdlib/libstdcpp3.hpp that goes: #ifdef __GLIBCXX__ // gcc 3.4 and greater: # if defined(_GLIBCXX_HAVE_GTHR_DEFAULT) \ || defined(_GLIBCXX__PTHREADS) // // If the std lib has thread support turned on, then turn it on in Boost // as well. We do this because some gcc-3.4 std lib headers define _REENTANT // while others do not... // # define BOOST_HAS_THREADS was fixed for mainstream gcc 4.1.2 and later versions in December of 2006. So can we change the first line to something like: #ifdef __GLIBCXX__ && __GLIBCXX__<20070101 so detection of whether gcc is in multi-threaded mode or not works again? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFI4Rim5vihyNWuA4URAs/NAJ45aP24OAUerZUaV48Y1faYt0GsSACeOoJi eiWSbyfmjW8653luxIe0U/s= =HySJ -----END PGP SIGNATURE-----

2 1

Phoenix review
by Peter Dimov 30 Sep '08

30 Sep '08

I apologize in advance that I could not dedicate the appropriate amount of time for my evaluation of the library. * Design - The placeholders probably belong in namespace phoenix::placeholders instead of arg_names, for consistency with std::placeholders. - It is very odd to include phoenix_bind.hpp and not have the placeholders available. For that I need phoenix_core.hpp. - The decision to capture the left side of @= and = by value is debatable. It is indeed not clear which one is 'better', but we do have Lambda in Boost, and to deviate from it one needs a stronger supporting argument than that. - In general, the subtle differences between Bind, Lambda and Phoenix need an explanation, even if its only purpose is to clearly show that the deviation is deliberate and not an accident. - bind<R> is not supported. - Smart pointers do not seem to be supported well in conjunction with bind, even though they seem to work in other contexts. - What is the equivalent of boost::unlambda in Phoenix? I think I agree with Giovanni Piero Deretta that lambda[] is an intuitive way to put a 'wall' between the inside lambda expression and the outside world. It doesn't seem to; the following fails: px::bind( px::lambda[ arg1 + arg2 ], 0, 1 )(); - It is not clear what introspection facilities are provided. Users sometimes want to derive a signature from a bind expression, or to compute the minimum arity of a lambda expression. They ought to be able to implement these queries themselves via a documented introspection interface that will not break when V3 arrives. * Implementation - Phoenix objects do not take rvalues. This is a very common stumbling block for people wanting to experiment with lambda libraries. - boost::is_placeholder needs to be specialized for the placeholder types. It might be interesting to see Phoenix respecting is_placeholder in the other direction, too, if possible. - The test coverage seems relatively sparse. I know very well how painful it is to write tests (for arities from 0 to 9 inclusive), but Phoenix 2.0 needs and deserves more of them. Take this, for example: test::x x_; bind(&test::x::m, x_)() = 123; bind(&test::x::m, arg1)(x_) = 123; BOOST_TEST(x_.m == 123); It doesn't test whether the first bind worked, and doesn't try to read from a member using bind. * Documentation - The examples assume a number of using directives without this being stated. - I believe that it would be better to leave the std:: names qualified. As it stands, it is not immediately obvious whether cout is std::cout or phoenix::cout (a plausible assumption would be for a phoenix::cout to be defined as phoenix::ref(std::cout) to avoid capture by value). - The val(3) example stresses that it returns a nullary function, but val(3) happily accepts (and discards) arguments - as it should. - The relationship between phoenix::ref and boost::ref is not made clear, or even mentioned. Can one use boost::ref instead? In what contexts? std::ref? (As an aside, there is a slight tendency in the documentation to be a bit too independent of the rest of Boost for my taste. It mentions Lambda in passing, but doesn't go into any details; it completely ignores boost::bind.) - The "Forwarding Problem" paper is so 2002. :-) - The note that the binders are monomorphic should probably be fixed. - It might be instructive to add an introspection example to the final chapter that returns the (minimum) arity of a Phoenix expression. - The documentation is missing a reference section, or at least an index of the identifiers in the phoenix namespace. * Vote This is hard. On the one hand, it is ridiculous to include <boost/spirit/include/phoenix_bind.hpp> for phoenix::bind instead of <boost/phoenix/bind.hpp>, as one would reasonably expect. As Phoenix is already in Boost, the review merely needs to formally acknowledge the facts. And the library certainly meets the criteria for acceptance. On the other hand... I sense from the state of the documentation that Phoenix being under the Spirit umbrella and not an "official top level" library has led to a somewhat isolated development. It is very high quality, above the Boost median, but somehow doesn't yet feel like a top level library. Still being on the other hand... We know that having two libraries with overlapping goals, overlapping syntax, overlapping identifiers and placeholders, and subtle differences is confusing and a continuous source of recurring questions. Now we will have three. But the fair thing to do is vote for acceptance. Which I will.

2 1

[Review] Phoenix
by John 30 Sep '08

30 Sep '08

First, the big question I vote for a second fast track review of the v3 implementation. The reasoning is simple, if a little painful. I have a lot of sympathy for the view that we should be reviewing the version that is actually going to be released (or at least something close to it). Joel is right that some libraries have been admitted with the condition of large changes. In general, given the exceptional quality of his work to date, I also consider him quite trustworthy when he says that is what he plans to do. However, I have problems with how I'm supposed to review the implementation of a library that won't be implemented the same way when it goes into Boost. That said, even the v2 edition is an exceptional library. It has been pointed out elsewhere that there are some current details missing from v2, and Joel has already promised their inclusion in v3. Aside from those artifacts of its history, it is a very nice piece of work. I have used it in a few projects and I find it clear to use, well documented and largely well behaved (except for afore mentioned problems). It works on compilers that live close enough to the standard, and that happens to be what I currently use. It is well documented (I also vote for the return of the section on FP.), and I enjoy the style. There is a lot to learn to use the library well, but that is partially because it is a powerful library in a programming idiom that many of us have only learned we need recently. It is practical, and so provides a gentler step into functional programming than would be the case if it stressed purity. However, it allows clearly functional constructs and has well thought out abstractions underlying the interface The reasoning is painful because it has me voting against immediate inclusion for a library I obviously like and respect. However, I think this review is valuable for what it accomplishes. In my following of the discussion so far, I haven't seen anyone who has issues with the need for the library, with the basics of the interface, or with the abstractions it embodies. I think this is the 85% good stuff (I may be remembering the wrong number here.) that Joel spoke of. That allows us to focus the fast track I am voting for on the implementation and compliance with a few specific changes. v2 will be available, and the small breaking changes in v3 will be the first boost release (since I'd be very surprised if Joel didn't do all requested and more for v3), so there will be a minimal legacy code base issue. As for the naming, I would also like to see the release version become the new Lambda v2. Though I appreciate creative names for some things, it seems to cause problems for software libraries. John Phillips

2 1