http://blog.gmane.org/gmane.comp.lib.boost.devel hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://comments.gmane.org/gmane.comp.lib.boost.devel/180802 In following instructions to commit to the releae ready branch I get the following message: Modified: BoostRelease\boost\archive\impl\basic_binary_iprimitive.ipp Error: Commit failed (details follow): Error: Your file or directory 'impl\basic_binary_iprimitive.ipp' is probably out-of-date Error: The version resource does not correspond to the resource within the transaction. Either the requested version resource is out of date (needs to be updated), or the requested version resource is newer than the transaction root (restart the commit). This was after a bunch of files got commit successfully. In the past when problems like this occured (as they often seem to), repeating the operation (with maybe an intervening clean up) seemed to plow through the situation. But this time it seems something is permantly stuck. Any help would be appreciated. Robert Ramey _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Robert Ramey 2008-10-07T15:43:31 http://comments.gmane.org/gmane.comp.lib.boost.devel/180798 Hi, This question was originally brought up here: http://lists.boost.org/boost-users/2006/08/21633.php but unfortunately was not answered. What I basically want to do is to enable something like running $ myprog -v -v -v Where -v is some Boolean switch. Thanks, -Sergey --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Khaikin, Sergey 2008-10-07T13:25:16 http://comments.gmane.org/gmane.comp.lib.boost.devel/180786 Hi all, I made a new release of my multiprecision integer library with the following changes: - improved documentation - serialization support - bugfixes - improved benchmark tool - prime generation has been reworked - probably some other things which I forgot I believe it's pretty much ready for review now. The mp_int reference section is slightly lacking in a few places, but other than that I think it's pretty solid. I have a few things in mind for the future of this library: - improved division and squaring algorithms according to the papers on my disk. - an implementation of an mp_int proxy type that acts on preallocated memory, but does not manage memory itself. This can then be used to improve the runtime of several algorithms. - expression template support There is pregenerated html documentation under libs/mp_math/doc/html/ http://www.boostpro.com/vault/index.php?action=downloadfile&filename=mp_math_v03.zip&directory=Math%20-%20Numerics& Kevin Sopp ___________________________________________ Kevin Sopp 2008-10-06T13:40:27 http://comments.gmane.org/gmane.comp.lib.boost.devel/180785 When looking at <http://thread.gmane.org/gmane.comp.lib.boost.devel/180769>, i noticed that <boost\spirit\home\classic\core\parser.hpp> includes <boost/type_traits.hpp>, when only part of it (remove_reference.hpp?) actually seems to be required. Not really a problem, but including the full type_traits.hpp does add quite a bit of weight to my precompiled header. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Richard Webb 2008-10-06T13:14:44 http://comments.gmane.org/gmane.comp.lib.boost.devel/180784 Title says it all really, any reason why I should define BOOST_HAS_LONG_LONG for sun's compiler? Seems to all work OK... John. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost John Maddock 2008-10-06T12:42:29 http://comments.gmane.org/gmane.comp.lib.boost.devel/180770 Hi boosters, I think that Adobe poly approach on "operator . overloading" could be extracted as orthogonal to the polymorphic object container concept, and easily generalized to serve all kinds of wrappers. My proposal (see code in the vault: *http://tinyurl.com/5xo9or*) is to have a class template (interface<T,W,B>) that describes the interface of type T, forwarding any operation to the implementation type, got directly from the wrapper (W). B is used when vertical inheritance is needed, either to benefit of EBO or to insert a base class on top of the hierarchy (see type_erasure_wrapper). There is actually a fourth boolean parameter, that will be explained later. interface<T,W,B> can be partially specialized for user types (and libraries can provide the specializations for theirs), leaving the wrapper as free parameter, so that the same specialization can be used for any wrapper we can subsequently write, thus decoupling the interface description step from the interface usage by a wrapper. The interface Corrado Zoccolo 2008-10-05T19:16:09 http://comments.gmane.org/gmane.comp.lib.boost.devel/180769 When test building some code with VC9 + the current Boost trunk i had a link failure due to a missing libboost_math_c99-vc90-mt-1_37.lib, which i hadnt built because i'm not using the math lib. On investigation, this seems to be down to using Spirit/Hash(via multi_index) when the "boost/tr1/tr1" dir is in the include path. More specifically, the files: spirit\home\classic\core\primitives\impl\numerics.ipp functional\detail\float_functions.hpp do an include <cmath>, which in this case includes <boost\tr1\cmath.hpp>, which then includes <boost/math/tr1.hpp>, autolinking and all. I can work around the problem by building the math lib or turning off auto linking for it but it seems wrong that i have to do that. Is there a better official solution for this, such as using <config/no_tr1/cmath.hpp> instead of <cmath> ? Thanks, Richard Webb Richard Webb 2008-10-05T17:24:23 http://comments.gmane.org/gmane.comp.lib.boost.devel/180767 (i think i might have mentioned this before, but it still happens with the current code, so...) Using Variant on VC9 with warning level 4 can result in an unreferenced parameter warning: boost/variant/variant.hpp(289) : warning C4100: 'operand' : unreferenced formal parameter This can be silenced by extending the existing Borland workaround to apply to VC as well. For example, change the existing: #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x0551)) operand; // suppresses warnings to #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x0551)) || BOOST_WORKAROUND(BOOST_MSVC, >= 1400) operand; // suppresses warnings Thanks, Richard Webb Richard Webb 2008-10-05T13:20:25 http://comments.gmane.org/gmane.comp.lib.boost.devel/180765 Dear all, it's kind of direct and easy to perform a gethostbyname-like operation with an asio::ip::tcp::resolver::query. But is there a way to perform the opposite operation? I mean to perform a gethostbyaddr-like operation where the input is an IP address, and output is the associated DNS name. Thanks in advance. Best regards, \Carlo Medas _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Carlo Medas 2008-10-05T12:25:09 http://comments.gmane.org/gmane.comp.lib.boost.devel/180763 Eric, I was recently hit by a stack overflow due to the way xpressive makes recursive calls when dealing with patterns like *_, etc and was wondering if there is an alternative, more efficient way of matching these types of patterns. p.s I know about keep() but that can get cumbersome to use everywhere. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Raindog 2008-10-05T04:54:33 http://comments.gmane.org/gmane.comp.lib.boost.devel/180761 The classic example: int main() { boost::asio::ip::tcp::iostream s("www.boost.org", "http"); s << "GET / HTTP/1.0\r\n"; s << "Host: www.boost.org\r\n"; s << "\r\n" << std::flush; std::cout << s.rdbuf(); return 0; } It works. But with a server on port 8080, it does not seem to work anymore. The host line was changed to s << "Host: www.boost.org:8080\r\n"; of course. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Gregory Dai 2008-10-05T04:54:04 http://comments.gmane.org/gmane.comp.lib.boost.devel/180752 Hi, I'm using GIL's dynamic image extension, namely any_image_views in certain places. However on every occasion where an any_image_view is used I have to include apply_operation.hpp so the operations can be instantiated. On gcc-4.3.2 the inclusion of this header raises the compilation time at least tenfold. Somewhere on this list I found the claim that gil::variant is supposed to reduce compilation time over boost::variant but for at least gcc-4.3.2 this is untrue. There are several places in which I use boost::variant and even with binary visitation the compilation time is barely unnoticable. To work around this problem, I tried to explicitly instantiate the functions generated for my any_image_view. Trying this technique with apply_operation and detail::destructor_op failed. Looking at nm's output told me that what I explicitly instantiated and what the binary needs had at least its mpl::vector elements reversed. So, I basically have two questions: 1) Wouldn't it be nicer to use boost::variant for gil Philipp Reh 2008-10-04T12:42:19 http://comments.gmane.org/gmane.comp.lib.boost.devel/180750 Hi, As part of Graduate program I have developed following useful functions that I like to submit to boost as a seperate library or part of math library - notable functions in my lists are, 1. ARBurg - Auto regressive coefficients using Burg's algorithm 2. ARCeps - Cepstrum coefficeint from Auto-regressive coefficients 3. 1-D filter function 4. 1-D convolution function 5. Moving - Average filter 6. Polynomial Fitting 7. Polynomial Value from Polynomial Coefficients Regards Syed Mamun Raihan 647.278.9083 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost S. Mamun Raihan 2008-10-04T01:46:56 http://comments.gmane.org/gmane.comp.lib.boost.devel/180747 AMDG The following code does not compile because phoenix tries to call the % operator with the types: boost::phoenix::detail::local_reference<boost::format> % int What is the rationale for local_reference? #include <boost/spirit/home/phoenix/operator.hpp> #include <boost/spirit/home/phoenix/core.hpp> #include <boost/spirit/home/phoenix/scope.hpp> #include <boost/format.hpp> #include <algorithm> #include <vector> using namespace boost::phoenix::arg_names; using namespace boost::phoenix::local_names; using namespace boost::phoenix; int main() { std::vector<int> values(10); std::for_each(values.begin(), values.end(), let(_f = boost::format("value is %d = %d\n")) [ std::cout << _f % _1 % _1 ] ); } C:\boost\trunk\boost/spirit/home/phoenix/operator/arithmetic.hpp(78) : error C2676: binary '%' : 'const boost::phoenix::detail::local_reference<T>' does not define this operator or a conversion to a type acceptable to the predefined operator with [ Steven Watanabe 2008-10-03T23:53:31 http://comments.gmane.org/gmane.comp.lib.boost.devel/180743 -----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); //... } Frank Mori Hess 2008-10-03T21:19:07 http://comments.gmane.org/gmane.comp.lib.boost.devel/180727 I could use one to enable a range constructor only where appropriate: class X { template<typename range_t> X (range_t const&, enable_if<is_range<range_t> >::type *dummy=0) Question is, what might 'is_range' look like? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Neal Becker 2008-10-03T17:12:39 http://comments.gmane.org/gmane.comp.lib.boost.devel/180720 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 Boris 2008-10-03T15:07:58 http://comments.gmane.org/gmane.comp.lib.boost.devel/180715 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Kasra Nassiri(Math & ComSci 2008-10-03T09:25:49 http://comments.gmane.org/gmane.comp.lib.boost.devel/180711 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 _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Mikko Vainio 2008-10-03T06:57:27 http://comments.gmane.org/gmane.comp.lib.boost.devel/180710 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) _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost vicente.botet 2008-10-03T06:26:17 http://comments.gmane.org/gmane.comp.lib.boost.devel/180706 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 poin vicente.botet 2008-10-03T05:41:43 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.lib.boost.devel