- Boost - lists.preview.boost.org

request for discussion - yet another approach to automated memory management that solves the cycles problem and is very efficient
by Achilleas Margaritis 16 Mar '09

16 Mar '09

Dear boost members, The file 'mm2.zip' (in boost vault/memory) contains yet another solution for automatic memory management. The solution has the following attributes: 1) it solves the problem of cycles. 2) it releases resources deterministically. 3) it does not scan the graph of objects for reachability. It uses simple numeric values (i.e. keys) to determine if an object can be collected or not. The idea is very simple: pointers obtain keys during their construction (a simple global variable that is incremented). The key remains constant throughout the lifetime of a ptr. During pointer release, the pointers that point to an object are scanned: if there is no pointer that points to the object that has a lower key from the key of the releasing pointer, then the object can be deleted. The pointer semantics are normal C pointer semantics, except for the construction: the solution requires that pointers that are lvalues should obtain a key before the heap object that they will be assigned to. i.e. you can't do this: ptr p1 = new object; You have to do this: ptr p1; p1 = new object; All the operations have O(1) complexity, except the release operation, which has O(N) complexity, whereas N is the number of pointers that point to an object. Practically, the complexity is minimal, because it is rare to have that many different pointers to a single object (I think :-)). I have no idea if it works for all cases. The file 'main2.cpp' contains a lot of tests, which all pass. I have also included the benchmark of the Boehm GC modified to use my special ptr classes. In my machine, an Athlon 64 2.2 GHz, the benchmark is executed, using boost pools, at roughly 1900 milliseconds, whereas the Boehm gc benchmark, using the Boehm gc collector, is executed at roughly 1200 milliseconds (and the Java benchmark at roughly 600 milliseconds). The amazing thing is that it looks like it works, but I am not sure. I am sure there is a catch :-).

9 17

Re: [boost] [geometry] robustness approaches
by Simonson, Lucanus J 16 Mar '09

16 Mar '09

Barend Gehrels wrote: > You'll probably found this on the mails and not on the library > itself. It has no circles so it is a bit unfair to compare the > approaches like this. It focusses on integer arithmetic and 45/90 > angled polygons so it is different, more or less complimentary. I'm a little hurt to hear you say this. I keep repeating that I currently handle arbitrary angle polgon set boolean operations and that the implementation is 100% robust for integer coordinates but not so for floating point. There are practically no robustness issues with 90 polygons and only very little with 45 polygons, so why would I discuss it if I didn't need to concern myself with it? When I talk about robustness I'm talking about my arbitrary angle polygon clipping implementation. Allow me to demonstrate this capability more clearly. I have just exercised my arbitrary angle polygons booleans with floating point coordinates. It worked and successfully XOR-ed a hand with a spiral which is a visually appealing but trivially small test case of mine. I can't claim that it is 100% robust for floating point coordinates (yet) but I do have working code. I have attached both sets of outputs the image of the result as well. It is clearly correct. Just because I don't claim floating point robustness doesn't mean the algorithm doesn't work or can't produce correct results. I just haven't designed in and verified 100% robustness for floating point. Regards, Luke

2 3

question regarding g++ 4.3.2 and maybe others
by Robert Ramey 16 Mar '09

16 Mar '09

On my local system I'm trying to build/test with gcc 4.3.2. The library builds with nocomplaint, but when I build/run the tests I get:Info: resolving typeinfo for boost::serialization::detail::extended_type_info_typeid_0 by linking to __imp___ZTIN5boost13serialization6detail27extended_type_info_typeid_0E (auto-import/usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld: warning: auto-importing has been activated without --enable-auto-import specified on the command line. This should work unless it involves constant data structures referencing symbols from auto-imported DLLs.) My site-config.shows gcc : 4.3.2 : g++-4 ;should it show some compile time switch besides this? Or ?Robert Ramey

2 3

[asio] experience with cygwin
by bnv＠nc.rr.com 16 Mar '09

16 Mar '09

I began porting a cygwin application to boost-1.38 asio this past weekend. So far things are working, and I'm pleased with the simplification of the application code, but a few items have come up... 1. The cygwin documentation only states that the __USE_W32_SOCKETS flag must be defined, but the documentation should also mention that the _WIN32_WINNT flag should be defined (0x0501 for XP) to avoid a warning, and that the ws2_32 and mswsock libraries are needed (at least for XP). 2. The documentation for the ip::tcp::socket object specifies that the cancel() member will "cancel all asynchronous operations associated with the socket". However, when called just before closing the socket, I get an exception along the lines of "operation not supported on this object" (I don't have the exact message in front of me right now). By not calling it, my async handlers are invoked with an error on closing the socket. 3. The application has a signal handler (e.g., SIGINT). However, when the process is inside asio::io_service::run(), the signal handler appears to somehow get suspended and I have to do a "kill -9" rather than just hitting ctrl-c. Is this intentional/expected? Is there a work around, perhaps looping on asio::io_service::run_one()? Thanks, Brian

2 1

Re: [boost] [Math] boost::math::signbit returns false for -NAN
by Hartmut Kaiser 16 Mar '09

16 Mar '09

Ping? Regards Hartmut > -----Original Message----- > From: Hartmut Kaiser [mailto:hartmut.kaiser@gmail.com] > Sent: Wednesday, March 11, 2009 8:35 AM > To: 'boost(a)lists.boost.org' > Cc: 'John Maddock' > Subject: [Math] boost::math::signbit returns false for -NAN > > Hi all, > > the boost::math::signbit function in trunk fails for an argument of - > NAN. > > #include <boost/math/special_functions/sign.hpp> > > int main() > { > using boost::math::signbit; > BOOST_ASSERT(signbit(-std::numeric_limits<double>::quiet_NaN())); > return 0; > } > > I'd expect to get a '1' back, but the function returns zero and the > assertion fails. I know it worked while using Jon Rade's floating point > utilities library from the vault. Does this have been integrated? > > Regards Hartmut >

1 0

[math] Please give me some advice.
by Kasra 15 Mar '09

15 Mar '09

Hi Dongfei, I have downloaded the code and took a good look at it. It is pretty cool. I think the best we could do is to work more on the optimisations (opt.h) to improve the performance. -- Kasra

1 0

[asio and thread] don't play well together under cygwin?
by Brian and Victoria 15 Mar '09

15 Mar '09

Greetings, I have a header file that includes both <boost/thread> and <boost/asio>, which results in the compilation errors below under cygwin. If I take out <boost/thread> then things are fine, except that I need it for my application :) I have "-D__USE_W32_SOCKETS -D_WIN32_WINNT=0x0501" in my compile flags, per the asio documentation. Taking them out appears to resolve the errors below, but causes other errors for asio. Has anyone else run into this problem and found a solution? -Brian In file included from /usr/include/cygwin/sys_time.h:13, from /usr/include/sys/time.h:27, from /usr/local/include/boost-1_38/boost/date_time/c_time.hpp:31, from /usr/local/include/boost-1_38/boost/date_time/microsec_time_clock.hpp:21, from /usr/local/include/boost-1_38/boost/thread/thread_time.hpp:9, from /usr/local/include/boost-1_38/boost/thread/locks.hpp:12, from /usr/local/include/boost-1_38/boost/thread/pthread/mutex.hpp:11, from /usr/local/include/boost-1_38/boost/thread/mutex.hpp:16, from /usr/local/include/boost-1_38/boost/thread/pthread/thread_data.hpp:12, from /usr/local/include/boost-1_38/boost/thread/thread.hpp:17, from /usr/local/include/boost-1_38/boost/thread.hpp:13, from chat.cpp:23: /usr/include/sys/select.h:31: error: `fd_set' has not been declared /usr/include/sys/select.h:31: error: `fd_set' has not been declared /usr/include/sys/select.h:31: error: `fd_set' has not been declared /usr/include/sys/select.h:33: error: `fd_set' has not been declared /usr/include/sys/select.h:33: error: `fd_set' has not been declared /usr/include/sys/select.h:33: error: `fd_set' has not been declared In file included from /usr/local/include/boost-1_38/boost/asio/detail/socket_types.hpp:79, from /usr/local/include/boost-1_38/boost/asio/detail/win_iocp_io_service_fwd.hpp:24, from /usr/local/include/boost-1_38/boost/asio/io_service.hpp:37, from /usr/local/include/boost-1_38/boost/asio/basic_io_object.hpp:20, from /usr/local/include/boost-1_38/boost/asio/basic_socket.hpp:24, from /usr/local/include/boost-1_38/boost/asio/basic_datagram_socket.hpp:25, from /usr/local/include/boost-1_38/boost/asio.hpp:20, from chat.cpp:30: /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:109: error: redefinition of `struct timeval' /usr/include/sys/time.h:16: error: previous definition of `struct timeval' /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/winsock2.h:632: error: declaration of C function `int select(int, fd_set*, fd_set*, fd_set*, const timeval*)' conflicts with /usr/include/sys/select.h:31: error: previous declaration `int select(int, int*, int*, int*, timeval*)' here

3 4

[array] remove static qualifier for size(), empty() and max_size() member function
by herve martin 15 Mar '09

15 Mar '09

Hi, I guess that the static qualifier for size(), empty() and max_size() makes the boost::array template class unsuitable for the STL sequence container interface. I recommend to remove the static qualifier. Anyone agrees with me ? best regards, herve

3 3

[array] array_cast helper function
by herve martin 15 Mar '09

15 Mar '09

Hi, I would present here a new helper function which could take place in the boost array package since it is related to C-array. the array_cast() function aims at making cast into C array more friendly than when using the esoteric syntax T(&)[N]. It can help also to check some consistency in size between original type and resulting C array. For some reason reference on C array is almost never used by developers even if a reference on C array encapsulates more information than just a pointer on the 1st element. A striking example is that the dynamic allocation of an array using the new syntax returns a pointer on first element ( int *ptr = new int[10]; ) although I would expect getting a pointer on an array ( int (*ptr)[10] = new int[10]; - this syntax fails but is more conform to what we could expect, even if I must admit that the second syntax is not really intuitive -). array_cast() could make reference on C array more common. The main benefit of array reference is that the size information of the array is encapsulated in the reference type. In the previous 'new' example, when writing { int *ptr = new int[10]; } we have to keep track of the array size by some other way which is not really smart (#define for example). array_cast() use will allow the following syntax: { int (&carray)[10] = array_cast<int>( *new int[10] ); } which is equivalent to: { int (&carray)[10] = *(int(*)[10]) new int[10] ); } Size of the C array can be retrieved just with operation sizeof(carray) In working with array reference rather than with pointer on element array we could imagine some generic algorithm whose implementation could be optimized according to the array size. array_cast() profits also from boost::math::static_gcd function and checks consistency between sizes. for example the following code will raise a static assert since type sizes are not consistent. {{{ struct { char d1; char d2; char d3; } toto; long (&carray)[1] = array_cast<long>( toto ); }}} Indeed, sizeof( toto ) is rarely equal to sizeof( long[1] ). 3 main functions are defined for array_cast(): array<T,N>( INPUT& data) array<T>( INPUT& data) array<N>( INPUT& data) and its derivatives for const, volatile and const volatile lvalues. for more details, take a look at the source code array_cast.hpp<http://www.boostpro.com/vault/index.php?action=downloadfile&filename=array_…>in the boost vault repository and let me know if there is any interest to include it in boost::array. thanks, herve

2 1

Re: [boost] [Boost-users] Maintenace Guidelines wiki page
by vicente.botet 15 Mar '09

15 Mar '09

----- Original Message ----- From: "Tomas Puverle" <Tomas.Puverle(a)morganstanley.com> To: <boost-users(a)lists.boost.org> Sent: Sunday, November 23, 2008 4:31 AM Subject: Re: [Boost-users] Maintenace Guidelines wiki page > >> I have started the Maintenace Guidelines wiki page. >> >> You can access it directly >> https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines >> >> or via https://svn.boost.org/trac/boost/wiki >> >> Guidelines >> * Maintenance Guidelines >> >> There page need to be completed and surely reworked but this is an starting >> point. >> >> Please be free to improve the page directly or post your comments or > suggestions to this list. >> >> Hopping this goes on the right direction, > > Vincente, > > A few ideas: How will you evaluate that your proposal is actually successful > and being followed by the boost developers? Hi, First this is proposal for guidelines. So people will be after all free to follow some of them or not. I'm expecting from people like you to improve it so it could be followed by more people. > Also, check out Daniel Walker's idea in the Boost.Range thread on boost.devel > about not having the engineers in charge of their own QA. Daniel Walker's idea " Perhaps a procedural solution that could avert this problem in the future is to quarantine the test cases. Authors can maintain commit privileges to their libraries on trunk, but only a select group of independent guardians have commit privileges to the test cases. That way there is a guarantee that libraries pass the same tests from one release to another. If an author would like to make a change that would break a test case, he or she would need to present the change to the list and submit a patch to the test case sentinels. This would be a fairly simple quality assurance protocol: engineers aren't allowed to do their own QA." This is already considered on the guidelines insome way. "Preserve the test from the preceding versions [author] The test from the preceding versions should not be changed when the author modifies its library. These not changed tests are a probe of compatibility with the preceding version. When these test must be changed they indicate a breaking user code issue. So instead of changing them add new ones stating explicitly on which version they were included. Old tests that should fail can be moved to the compile_fail or run_fail tests on the Jamfile. " The Daniel proposal implies some changes in the writing rights of the authors. I prefer to let this point out of these guidelines. Of course I think that this is a good idea. There is another guideline that could be used by the Boost comunity to check the author has not changed the old test cases. "Inspect announced modifications [author, user, RM] The use of the diff file will help to inspect that the modifications introduced have been correctly included on the documentation and a good test coverage has been done. This will result in a non official mini-review of the library. " I will add to check that the old testcases have not been changed. > Finally, please consider the idea of "core" and "new" release cycles, where the > components in "core" have much more stringent requirements on how and when they > are allowed to change. IMO this is out of the scope of the guidelines. Note that at the end it is up to the author to make the modification he/she consider pertinent. Could you send what you have in mind in the form of guidelines? > Finally, do you think it may have been better to start this thread on > boost.devel? I belived that i did it on both. I'm answering to both each time. Should I start a new thread including the guidelines contents? Vicente

14 46

Boost Lite Version
by Jean-Sebastien Stoezel 14 Mar '09

14 Mar '09

Hi, I have been using Boot for desktop applications and I'm very happy with it. It allows me to write portable and reusable code on all the platforms I've been supporting. I also develop C++ applications for small embedded devices, that have very limited ROM and RAM capabilities (several hundreds of kilo bytes of ROM and dozens of kilobytes of RAM). The Boost libraries cannot be used as is for these devices, since the OSes (RTOS I should say) that run on these devices are not supported by Boost. Then my code for these devices is not as portable and reusable as I which it would be. I've developed my own accross-platform generic interface for these devices and it's starting to look like Boost... Except it's not Boost and it's still very proprietary, in the niche sense. I am very interested in having a (real) lite version of Boost for these embedded devices, even if it only consists of stub functions. Is there already an on going effort to do this? Again, the idea is a lite version, something that would fit in less than 30% of the memory of a microcontroller. Jean-Sebastien

4 4

[math] calculate derivative automatically.
by Dongfei Yin 14 Mar '09

14 Mar '09

Hi Bruno, > But I can help you if you want of course.I think the first step for you would be to > learn about Boost.Proto as it's really the tool needed for that. Learn > how to search/replace patterns in an expression. Thank your for your guidance, I am really appreciate your help. I am now going to learn about Boost.Proto. If I have some problem, we can talk about it. Dongfei.

1 0

[geometry] area, length, centroid, behavior
by Barend Gehrels 13 Mar '09

13 Mar '09

I would like to hear the opinion of potential geometry users on the list about the following. For the three geometries, point, linestring (= sequence of points), polygon: What should the generic "area" algorithm return for point and linestring? - 0 (zero) - compiler error (so this function is not defined for them at all) - exception Personally I would feel for 0 (zero) because you can then request the "area" in a generic collection, regardless of what is inside. What should the generic "length" algorithm return for polygon? - 0 (zero) - its perimeter - compiler error - exception What should the generic "centroid" algorithm return for point and linestring? - the point / the average its points - compiler error - exception and for an invalid polygon (e.g. no points at all, or not closed)? - exception - return "false" (if centroid is passed as a reference parameter) - ? (we've not always the compiler error option here because points are usually stored in a runtime collection) Thanks, Barend

15 66

is_virtual_base_of ?
by Robert Ramey 13 Mar '09

13 Mar '09

Is there an implementation of the type trait is_virtual_base_of<D, B> anywhere? If not is there a way to make such a thing? Robert Ramey

7 17

Preview 4 of the Generic Geometry Library (ggl)
by Barend Gehrels 13 Mar '09

13 Mar '09

Dear list, It is a pleasure for us to present the fourth preview of the Generic Geometry Library. This time we've added the library to the SVN repository at boost, https://svn.boost.org/svn/boost/sandbox/ggl To store the library under a proper name, "ggl" is used, which stands for Generic Geometry Library. Before this we called it just Geometry Library, but we think Generic is appropriate from this version on. The first three previews were sent to this list in January, March and October 2008. Since then everything has been revised and reworked again, based on comments from the list. Thanks for all your comments! Concepts are now applied for all geometries. Algorithms now take any geometry fulfilling the concepts, and automatically take the right version of the underlying implementation. Ranges are now used instead of .begin()/end(). Tag dispatching is used instead of SFINAE. Transformations: previously these were just explained as an example, now transformations are included in the library, either to go from one coordinate system to another (for example from spherical to cartesian3D) or to translate/rotate/scale/map points from one Cartesian system to another, or otherwise. Map projections: included is an extensive addition with nearly 100 map projections. Those are not programmed by ourselves but automatically converted from C (PROJ4) into a our template-based approach, fitting with the geometry library, especially in the transformations explained above. License-wise this is possible. We're not sure about if this would fit in the Boost Library Collection, if there is interest in it, or that it might be "too much" for it, so we would be glad to hear your opinions. For more change descriptions, see the page on status and preview from the documentation (link below). The Generic Geometry Library is accessible from Boost SVN, mentioned above, or can be downloaded as well from http://geometrylibrary.geodan.nl Especially the examples, such as the custom point example and custom line string example show nicely how the library handles custom geometries and how they can be used inside the generic algorithms. We welcome any type of comment, opinion, cooperation, merge or join. Barend Gehrels, Amsterdam Bruno Lalande, Paris

3 11

GSoC 2009 Status
by troy d. straszheim 13 Mar '09

13 Mar '09

All- Our application to be a mentoring organization for the fourth year is in, I'm idling on the gsoc channel and watching things develop. We'll know soon if boost is accepted again this year, and at that time we'll be able to start getting our mentors into the system. Meanwhile there is a (currently empty) wiki page for project ideas: https://svn.boost.org/trac/boost/wiki/soc2009 Please feel free to post your gsoc ideas there. I believe there will be a stage soon where students will see that we are a potential mentoring organization and will peruse this list, looking for things that interest them... so have at it. -t

1 0

[accumulator] reset?
by Neal Becker 13 Mar '09

13 Mar '09

I don't suppose accumulators implement a reset?

2 1

[math] calculate derivative automatically.
by Dongfei Yin 13 Mar '09

13 Mar '09

> I personally signaled my interest for something much more general than > only derivatives. But as Dongfei's goal seems to be focused in that > direction Hi Bruno, Actually, I do interesting in simplifying, not only derivative. If you have good idea, we can work it out together if you don't mind. Some times, a expression is simply for computer but not for human. compromising is always needed, and it is hard to make a choice. But as you said, just for compile-time integral value, things become easier. Like the volume of hypersphere, when N = 2, after simplified, computation will be reduced a lot. Dongfei.

2 1

Boost.Asio asio::basic_socket_acceptor
by Joshua Pedrick 13 Mar '09

13 Mar '09

I'm trying to write an application that can simply switch between using local stream sockets and tcp stream sockets. I successfully implemented this behavior with BSD sockets in Linux, but it seems the class hierarchy in boost::asio makes this behavior awkward, since asio::basic_socket_acceptor template requires a protocol type, but there is so base class for protocols. I'm wondering if there is a reason for this or if it could possibly be changed? Basically, I have a client/server library for distributed processing, which in some cases, I wish to run using local sockets and other times run using TCP sockets. I was hoping Boost Asio could make the solution a little more elegant/clean, but at the moment I can't find an elegant manner to do this. I'd be glad to do all the work for this, provided some guidance, but I basically don't want to build my application on a custom version of boost::asio, which won't improve with the main version. So if this can't be changed, I just won't use asio, but if it can, I'll go ahead and take the time to implement the changes

2 1

To create a boost thread
by Filip Klasson 13 Mar '09

13 Mar '09

Hi, I have problems creating a thread. This is an example i found: #include <boost/thread/thread.hpp> #include <iostream> void hello() { std::cout << "Hello world, I'm a thread!" << std::endl; } int main(int argc, char* argv[]) { boost::thread thrd(&hello); thrd.join(); return 0; } What if i want to create a thread outside of main (in a class) like this: "myClass.h" class MyClass { public: hello(); myFunction(); }; "myClass.cpp" MyClass::hello() { std::cout << "Hello world, I'm a thread!" << std::endl; } MyClass::myFunction() { boost::thread thrd(&hello); thrd.join(); } This does not work and i get the compile error: '&' : illegal operation on bound member function expression

4 4

Re: [boost] [Fwd: Re: Google SOC Mentors?]
by Niall Douglas 12 Mar '09

12 Mar '09

On 12 Mar 2009 at 15:41, troy d. straszheim wrote: > >> Do have any interest in teaming up on this? > > > > Umm sure ... I can't find the message below in the Boost mailing list > > archives, so I'm unsure as to context. > > > > But if it's to mentor Google SoC then yes please, though do note I am > > extremely time pressed until the start of June after which I'll be > > finally free of academia. > > > > i.e. please do put my name forward. > > > > No worries. Whatever happens will be done on the mailing lists and > IRC, so you can join in at any point. Just to let everyone know, I have subscribed to boost(a)lists.boost.org and will remain until the Google SoC process is over. This is a very high volume list - this is why I normally lurk around Boost.Python only - so I won't be staying for much past the SoC process. I am *extremely* time pressed before the start of June and will neither be able to access IRC nor my own email (thank you very much university firewall!). However start of June onwards I'll be finally free and working from home for the next few years. Looking forward to hearing from you all, Niall

1 0

[mpi] Boost.MPI + GCC 4.3 + MPICH2 (1.0.3) Issue on Gentoo
by Dean Michael Berris 12 Mar '09

12 Mar '09

Hi Guys, Anybody been successful with combining Boost.MPI and MPICH2 before? I keep getting this link-time error about 'now' couldn't be found. The command I get from Boost.Build + Boost.Jam is the following (stripped of Friendster-specific names/symbols): "g++-4.3.3" -L"/usr/lib64" -o "output" -Wl,--start-group "main.o" "boost_1_38_0/bin.v2/libs/mpi/build/gcc-4.3.3/debug/link-static/optimization-speed/threading-multi/libboost_mpi-gcc43-mt-d-1_38.a" "boost_1_38_0/bin.v2/libs/serialization/build/gcc-4.3.3/debug/link-static/optimization-speed/threading-multi/libboost_serialization-gcc43-mt-d-1_38.a" -Wl,-Bstatic -Wl,-Bdynamic -lmpich -lpthread -lrt -lrt -Wl,--end-group -g -pthread -O2 -Wl,-rpath -Wl,-z,now -Wl,/usr/lib64 -march=opteron -pipe The auto-configuration worked for MPI: ===============MPI Auto-configuration=============== Found MPICH wrapper compiler: mpicc MPI compilation flags: -march=opteron -O2 -pipe -Wl,-z,now -I/usr/include -L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -lmpich -lpthread -lrt MPI link flags: -march=opteron -O2 -pipe -Wl,-z,now -I/usr/include -L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -lmpich -lpthread -lrt MPI build features: <include>/usr/include <library-path>/usr/lib64 <find-shared-library>mpich <find-shared-library>pthread <find-shared-library>rt <cxxflags>-march=opteron <cxxflags>-O2 <cxxflags>-pipe <cxxflags>-Wl,-z,now <cxxflags>-Wl,-rpath <cxxflags>-Wl,/usr/lib64 <include>/usr/include <library-path>/usr/lib64 <find-shared-library>mpich <find-shared-library>pthread <find-shared-library>rt <linkflags>-march=opteron <linkflags>-O2 <linkflags>-pipe <linkflags>-Wl,-z,now <linkflags>-Wl,-rpath <linkflags>-Wl,/usr/lib64 MPI launcher: mpirun -np ==================================================== In my Jamfile I have something like the following: exe output : main.cpp : <source>/boost//mpi <library>/mpi//mpi ; Am I missing anything obvious? TIA -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

2 3

[iostreams][repost] How can code conversion failure be detected
by Eric MALENFANT 12 Mar '09

12 Mar '09

Hi, I posted what's quoted below a while ago on the boost devel mailing list, but received no replies. (Naïvely?) assuming that this lack of feedback was caused by the excessive length of the post, let me try to summarize it: For the purpose of this example, assume the existence of always_fail_cvt, a codecvt facet which always returns "fail" namespace bio = boost::iostreams; std::wofstream fs("whatever"); fs.imbue(std::locale(fs.getloc(), new always_fail_cvt)); bio::filtering_wostream s(fs); s << L"Hello"; std::cout << std::boolalpha << s.good() << '\n'; // 1 s.flush(); // 2 std::cout << s.good() << '\n'; // 3 "s" being buffered, it is not surprising that line //1 outputs "true" (nothing failed yet, "Hello" is in the buffer) By stepping in the code, I see that line //2 tries to empty the buffer by calling sputn() on the underlying wofstream's filebuf, which fails because code conversion fails. I thus find it surprising that line //3 also ouputs "true" I'm also surprised that line //2 does not cause flush() to be called on the wofstream, or pubsync() on its filebuf Is this a bug or am I wrong in assuming that 1) The codecvt error occuring during flush() should cause the failbit to be set on the filtering_stream 2) flush()-ing a filtering_ostream wrapping an std::ostream should flush() the std::ostream ? Thanks, Éric Malenfant Original post follows: By default, filtering_streams do buffering. This means that what is written to them does not necessarily reach the underliyng Filters and Device immediately. It is thus my understanding that, in order to be sure that all data was written, one should somehow flush the buffered data, and then check the stream state before closing it. As a first attempt, I tried flush(), but it does not seem to do what I expected, as it is pretty lax in the failures that it tolerates. Looking at the docs, I then found what seemed to be what I was looking for: strict_sync(), whose documentation states that "A return value of true guarantees that all buffered data has been successfully forwarded.". Moreover, the FAQ entry "Can I swap Filters or Devices in the middle of a sequence of i/o operations?" seems to confirm this, as it says: "First call strict_sync. If it returns true, you can safely call set_auto_close(false) and pop one or more components without closing the stream. This applies to instances of filtering_stream, filtering_streambuf and chain." But again, this did not work: strict_sync() returns true altough buffered data remains. Consider this contrived example: // A codecvt facet that always fails class always_fail_cvt : public std::codecvt<wchar_t,char,mbstate_t> { protected: virtual result do_unshift(state_type&, char*, char*, char*&) const { return std::codecvt_base::error; } virtual int do_encoding() const throw() { return -1; } virtual bool do_always_noconv() const throw() { return false; } virtual int do_length(const state_type&, const char*, const char*, size_t max) const { return max; } virtual int do_max_length() const throw() { return 4; } virtual result do_out(state_type&, const intern_type*, const intern_type*, const intern_type*&, char* to, char*, char*&) const { return std::codecvt_base::error; } virtual result do_in(state_type&, const char*, const char*, const char*&, intern_type*, intern_type*, intern_type*&) const { return std::codecvt_base::error; } }; int main(int argc, char* argv[]) { namespace bio = boost::iostreams; std::wofstream fs("whatever"); fs.imbue(std::locale(fs.getloc(), new always_fail_cvt)); bio::filtering_wostream s(fs); s << L"Hello"; std::cout << std::boolalpha << s.good() << '\n'; // 1 s.flush(); std::cout << s.good() << '\n'; // 2 return 0; } Running this (on Windows with MSVC 7.1) produces true true The first "true", is not surprising, as the characters are buffered and code conversion has not taken place yet, but the second is. Considering the presence of strict_sync(), I assumed that the laxism of flush() is intentional, to allow stateful filters to retain buffered data, maybe. However, replacing the "s.flush();" line in the above program with "std::cout << s.strict_sync() << '\n';" does not seem to improve things. Although a conversion failure occured and data remains buffered, strict_sync() returns true, and the stream's state is still good(). So, to sum up: 1) If my understanding of the semantics of strict_sync() is correct, it seems that indirect_streambuf::strict_sync() should verify that the buffer is empty after the call to sync_impl(), and fail if it is not the case. Something like this maybe: template<typename T, typename Tr, typename Alloc, typename Mode> bool indirect_streambuf<T, Tr, Alloc, Mode>::strict_sync() { try { // sync() is no-throw. sync_impl(); return obj().flush(next_) && ((pptr() - pbase()) != 0); // Added this --^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ } catch (...) { return false; } } 2) Is it "correct" that filtering_stream::flush() does not completely flush without reporting an error? 3) Does this come from an incompatibility between Boost.IOStreams idea of error-reporting (throwing exceptions) and that of the std streambufs (returning EOF, mainly)? In particular, Boost.IOStreams writes in a wrapped std::streambuf by using sputn(), which, AFAI(don't)U, does not have a clear error reporting strategy. IOWs, should write_device_impl<streambuf_tag>::write() be modified like this: template<typename T> static std::streamsize write (T& t, const typename char_type_of<T>::type* s, std::streamsize n) // { return t.sputn(s, n); } { std::streamsize count = t.sputn(s, n); if (count == n){ return count; } // If all characters could not be written, check if it is because of an error or only because of blocking if (T::traits_type::eq_int_type(t.sputc(s[count]), T::traits_type::eof())){ throw std::ios_base::failure("write error"); } else{ return count + 1; } } so that errors occuring during a write on std::streams and streambufs are reported by an exception? -- Éric Malenfant If it ain't broke, you're not trying hard enough. - Seen on the Google testing blog home page

1 0

Now Accepting Mentor Applications for Google Summer of Code 2009
by Hartmut Kaiser 12 Mar '09

12 Mar '09

http://google-code-updates.blogspot.com/2009/03/now-accepting-applications-f or-google.html Will we apply this year? What's the procedure? Can I help? Regards Hartmut

4 10

[Property Tree] Maintenance Takeover
by Sebastian Redl 12 Mar '09

12 Mar '09

Hi, I'd like to officially announce that I have, with Marcin Kalicinski's permission, taken over maintenance of the Property Tree library. Over the next week I'll take a good look at it and see what there is to be done for inclusion in an official release. At the moment, it seems like the main problem is insufficient and outdated documentation. Marcin also had other concerns regarding the library (performance and interface), and I'll see if they should be addressed before an official release as well. (Interface concerns are more pressing, obviously.) If anybody has additional comments on the library, change requests, performance data, or simple discussion of ideas, now is the time to let me now. Sebastian

4 3