May 2011 - Boost-users - lists.preview.boost.org

Re: [Boost-users] Boost-users Digest, Vol 2714, Issue 3
by bill comment 06 May '11

06 May '11

> > 2719 ?The file handle supplied is not valid?. > > FWIW, this usually means that the socket is already closed. > yes. by the time my connection::do_writeMessage() is called, socket_.is_open() returs false. but, why has it been closed and what the correct way to keep it open? i attempt to keep it open after writing the 1st response as follows: in connection::handle_writeResponse() call start(), which calls socket_.async_read_some() this is similar to the chat client sample. apparently that's not sufficient to keep the socket open for when i want to write to it again. fwiw, TcpView (from SysInternals) shows the socket's state as "established" after the 1st successful write and after the failed 2nd attempt. ???

1 0

MPI with threads - adress not mapped problem
by Kraus Philipp 06 May '11

06 May '11

Hello. I'm using Boost 1.46.0 with OpenMPI 1.5.3 under Gentoo x64. I have compiled OpenMPI with thread and mpithread option and Boost with MPI support. A little testprogram with: #include <boost/mpi.hpp> namespace mpi = boost::mpi; int main(int argc, char* argv[]) { mpi::environment loMPIenv(argc, argv); mpi::communicator loMPICom; return 0; } crashes alway if I run it with "mpiexec -np" (without mpiexec it runs). Sometimes the program hangs or creates the message "adress not mapped" with "Segmentation fault". I have recompiled OpenMPI without threads and mpithreads and it seems, that the errors are gone. Is this a problem with OpenMPI or Boost MPI? Phil

2 3

[boost] [xint] Formal Review Result
by Vladimir Prus 06 May '11

06 May '11

I apologize for the delay in producing the final summary and result of the Boost.Xint review, but here it is. Votes ===== YES: - Christian Henning - Steven Watanabe - Jarrad Waterloo - Edward Diener - Paul A. Bristow NO : - Mathias Gaunard - Joel Falcou - Anders Dalvander - Joachim Faulhaber - Phil Endecott - Domagoj Saric - Gordon Woodhull ("fraction of a vote") I might have missed somebody inside the 454 messages I have as result of the review, but the overall picture is clear -- the votes are split. High-level issues ================= - The claim that the library is "fast" is not necessary true. Phil has did some checking against hand-written assembler that don't look too good. - It is not clear whether the design allows for improving performance of fixed-size integers using specialization (again, see Phil's comments) - There were concerns about COW. In particular, it was very clearly stated that if COW is used, it should work fine in multi-threaded programs. - It was suggested to use ET. - Some folks suggested better separation between algorithms and data representation. Specific issues =============== - It was pointed out that "a + b + c" creates a pile of temporaries, and this can be improved without using ET. - Joachim's review raised a lot of valid points. Section 3 of his reviews in something that should be addressed, more or less entirely. Note that while we normally don't force specific coding style, some of formatting pointed out is simply unacceptable if this code is to be read by anybody. - 'Secure' flag is probably not so much of it. Future directions ================= I think that reviews by Phil and Joachim are most important in specying evolutionary directions for Boost.XInt. Chad made several comments about what he plans to do, in particular: - http://article.gmane.org/gmane.comp.lib.boost.devel/216935 Conclusion ========== I think there's no doubt that (i) this domain is important and (ii) Chad has put a lot of work into this library, producing several iterations. It was pointed out that we have many arbitrary-precision libraries skeletons all around Boost, and providing such a solid offering for review is a significant accomplishment. And it everybody learned a lot during the review. There was a couple of important meta-points raised during review -- whether review should focus on external interface only, and what is the scope of the library. Some reviewers argued that only external interface matters. However, it seems to me (as review manager), that concerns about internal design are valid, and may not be rejected offhand. After all, external interface of an integer library is more or less defined by mathematics, and internal design plays a key role in successfull evolution of the library. There was also heated discussion about the scope of the library, in particular support for fixed-width integers. I think that it's abstractly OK for this library to treat fixed-width integers as second-class citizens. However, I am having hard time determining the intended scope of the library. If I'm doing cryptography, would I really want to implement cryptography algorithms from the books with Boost.XInt, only to introduce bugs that are probably fixed in existing implementations (often, included in the OS). And if I'm really intent on doing that, I probably want raw performance, including a way to plug in optimized backends using SSE 2011, CUDA, and whatever fancy technology is there. If I'm doing general programming, then I'm most likely interested in not too big integers. They might be fixed-width 128-bit integers, or they might be something larger-than-64, but not necessary fixed. However, such integers are not the scope of the library, and they were found to have suboptimal performance. It is certainly possible to refine/define the scope, optimize everything for that scope, accomodate the proposals made during review, and obtain an excellent Boost library. However, there are some many suggestions, and so many planned redesigns and changes, that we need a second look at the library. Further, because of the global nature of the changes, it would be very hard to identify a specific subset that must be improved and then go through mini-review. For that reason, I've arrived at the the following result: Boost.Xint library is not accepted at this time. We'll be happy to have another full review of the library when the next version is ready. Thanks to Chad for the submission and for everybody who participated in the review! - Volodya -- Vladimir Prus Mentor Graphics +7 (812) 677-68-40 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[Phoenix] Can we use boost::phoenix::function<Impl const&>?
by TONGARI 06 May '11

06 May '11

Greetings, The intuitive way to make a PFO having state is letting boost::phoenix::function hold the impl's reference, however, the following does not work. struct Impl { ...defines a functor having state... }; Impl impl; boost::phoenix::function<Impl const&> f(impl); f(...lazy call...); // should return an actor here, but not compiles Is this intended behavior?

1 0

Syntax Error identifier heap_memory when using Thread library from precompiled boost version 1.46.1
by Lasse Laursen 06 May '11

06 May '11

Hello boostah's, Sorry for the bad bro lingo. I'm having a spot of trouble getting the latest precompiled boost version to work with vs2010. So far I've only added the include directory, added the lib directory and then tried to include the thread.hpp file which results in the following error: Error 1 error C2061: syntax error : identifier 'heap_memory' c:\boost_1_46_1\boost\thread\win32\thread_heap_alloc.hpp 97 1 texsyn I googled this problem-o and found a response asking if the user had any code which replaced the "new" command for debugging purposes. I did have such code and proceeded to comment it out. Unfortunately, no change. Still the same error. Has anyone experienced anything similar and have an idea of how to best proceed? The bestest of all regards in the world, Lasse

1 1

[Boost.Spirit] RFC: bin_float parser
by Vitaly Budovski 06 May '11

06 May '11

Hello, Please see the attached headers and test case for a bin_float parser. Please provide comments/suggestions/criticisms. Regards, Vitaly Budovski

3 3

serialization
by grahamo 06 May '11

06 May '11

Hi, I'm working on an atrocious project whereby the persistence/serialization of various objects is done by an internal framework. Data is stored in binary format. Each piece of data is stored with an integer identifier that assicates it with the bindary data. I won't go into the details here. Anyways, this framework is very old and appears to present more problems than it solves. My goal is to convince the project manager that boost serialization is the way to go. They are against external 3rd party libraries despite the fact that boost is maintained by hundreds of developers (perhaps more). If I can provide a persuasive argument to migrating to boost, I can rid this project of a lot of issues. Here's the issues we currently face; A) The objects we persist are very much subject to change. New fields are added, moved around and deleted more or less as the wind blows. With each version of the application, various objects are persisted to disk in a file. This file *must* be compatible with the next version of the application. V1 objects and V2 objects are similar but not always identical (sometimes they are). Migration from V1 to V2 is done by massacring the the codebase with if/else statements. -- View this message in context: http://boost.2283326.n4.nabble.com/serialization-tp3498451p3498451.html Sent from the Boost - Users mailing list archive at Nabble.com.

2 1

mpi all reduce with std::vector and back_inserter
by Kraus Philipp 05 May '11

05 May '11

Hello, I have a std::vector<std::string> vector at each CPU. I would like to "reduce" all vectors on all CPUs. For example: CPU 0: vec = [a, b, c, d] CPU 1: vec = [e, f, g, h] std::vector<std::string> myreduce; mpi::all_reduce( mpi com object, vec, myreduce, #); myreduce = [a, b, c, d, e, f, g, h] How can I do this? Should I replace my # with a back_inserter of the std::vector? Thx for help Phil

2 3

Getting multi_index_container in 1.46.1 to work with VC++ 6.0
by tangleman＠secules.net 05 May '11

05 May '11

I've got a legacy MFC project that was built in VC++ 6.0. It needs to stay compatible with VC6 runtime so that I can just drop it into Windows NT4 where the original program was and have it just work. I've finally gotten MFC and VC6 runtime to play nice in VS2003. Now I'm trying to work in boost libraries so that I can use the ethernet and serial aspects of ASIO. Of course, I downloaded and am working with the latest version of boost (1.46.1), and I have it to the point where 311 errors are reported at compile time, all having to do with multi_index_container. I've looked through the compiler specifics pages of the 1.46.1 and 1.45.0 releases with respect to the multi_index and have made the workaround changes that I could (i.e. member->member_offset, boost::multi_index::multi_index_container), but I am still getting syntax errors related to the typedef of my multi_index_container. If it will help, here is my definition: struct ID{}; struct Name{}; typedef boost::multi_index::multi_index_container< PDCUTestMessage, boost::multi_index::indexed_by< boost::multi_index::ordered_unique< boost::multi_index::tag<ID>, boost::multi_index::member_offset<PDCUTestMessage, unsigned char, offsetof(PDCUTestMessage, id)>>, boost::multi_index::ordered_unique< boost::multi_index::tag<Name>, boost::multi_index::member_offset<PDCUTestMessage, string, offsetof(PDCUTestMessage, name)>> > > PDCUMessageList; The first error I'm getting is a syntax error calling out the comma on the line with member_offset PDCUTestMessage id. Then, since that doesn't compile, subsequent error messages snowball for every time I instantiate PDCUTestMessage and every time I add to the multi_index_container. Please help as soon as possible. I'm on a tight schedule, and this is the only major hurdle I see at this point. Thanks! Chris

2 1

[variant] Custom swap() Not Called
by Andreas Grosam 05 May '11

05 May '11

Hi, I'm using a boost::variant whose types have a custom swap() defined. When calling swap() on the variant variable, the custom swap() of the current type will not be called. The "swapable" class has a member function swap(), and there is also a free function swap() defined in the same namespace (see below). To illustrate and test the behavior I defined a special "swapable" class: namespace test { // This class is for testing purpose only! class swapable { public: swapable() : swapped_(0) {} swapable(const swapable& other) : swapped_(0) { } ~swapable() { } int swapped() const { return swapped_; } void swap(swapable& other) { ++swapped_; ++other.swapped_; } swapable& operator= (const swapable& other) { return *this; } private: int swapped_; }; void swap(swapable& lhv, swapable& rhv) { lhv.swap(rhv); } } The calling context looks as follows: void test() { typedef boost::variant< test::swapable > variant_t; variant_t v0( (test::swapable()) ); variant_t v1( (test::swapable()) ); swap(v0, v1); bool swapCalled = boost::get<test::swapable>(v0).swapped() == 1 and boost::get<test::swapable>(v1).swapped() == 1; std::cout << "boost::variant swap test: " << (swapCalled ? "PASSED":"FAILED" ) << std::endl; } So, assuming Koenig lookup works (which in fact does work for the compilers I'm using) calling swap() for the varaint variable should finally call the custom swap(), but it doesn't. Looking deeper into the sources, the culprit seem to be a workaround declaration in file move.hpp (please see below). Note: I'm using gcc, clang and apple's versions of clang. For these compilers __GNUC__ is defined as 4, and in the current config setup BOOST_WORKAROUND(__GNUC__, BOOST_TESTED_AT(2)) evaluates to true. So, when the workaround has been selected, it seems this effectively prevents Koenig lookup which then uses a std::swap like mechanism. Well, now since the compilers I'm using do not have issues with argument-dependent name lookup, how can I fix this - respectively, what is the preferred way to make this work (config setting, maybe)? Note: for testing purposes, I defined BOOST_STRICT_CONFIG 1 (which disables all workarounds) - and this test ran fine. As a side note: I only figured that there is an issue with custom swap() through making performance test - as they ran as slow as a copy. As far as I can see, the boost::variant test suite does not cover such cases. The types which the variant shall hold are copy-expensive - but they are very fast when swap is used (or rvalue reference is enabled some times for boost::variant). Thanks in advance for tips! Regards Andreas ////////////////////////////////////////////////////////////////////////// // function template move_swap // // Swaps using Koenig lookup but falls back to move-swap for primitive // types and on non-conforming compilers. // #if defined(BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP) \ || BOOST_WORKAROUND(__GNUC__, BOOST_TESTED_AT(2)) // [Indicate that move_swap by overload is disabled...] #define BOOST_NO_MOVE_SWAP_BY_OVERLOAD // [...and provide straight swap-by-move implementation:] template <typename T> inline void move_swap(T& lhs, T& rhs) { T tmp( boost::detail::variant::move(lhs) ); lhs = boost::detail::variant::move(rhs); rhs = boost::detail::variant::move(tmp); } #else// !workaround namespace detail { namespace move_swap { template <typename T> inline void swap(T& lhs, T& rhs) { T tmp( boost::detail::variant::move(lhs) ); lhs = boost::detail::variant::move(rhs); rhs = boost::detail::variant::move(tmp); } }} // namespace detail::move_swap

1 0