September 2012 - Boost - lists.boost.org

[thread] std::this_thread reference in docs
by Lars Viklund 11 Sep '12

11 Sep '12

Hi list. Since 1.50.0, the Boost.Thread documentation has started making references to std::this_thread::get_id() like in [1]. This is a bit strange, considering that the Thead library itself to my knowledge does not require C++11 (yet). Is this an accidental change? Should one read this as that the error condition is not achievable on C++03? 1.49: Preconditions: this->get_id()!=boost::this_thread::get_id() 1.50 (and 1.51): Preconditions: the thread is joinable. Error Conditions: resource_deadlock_would_occur: if deadlock is detected or this->get_id() == std::this_thread::get_id(). [1] http://www.boost.org/doc/libs/1_51_0/doc/html/thread/thread_management.html… [2] http://www.boost.org/doc/libs/1_49_0/doc/html/thread/thread_management.html… -- Lars Viklund | zao(a)acc.umu.se

2 1

[context] Trying to compile Coroutine on trunk
by Vicente J. Botet Escriba 11 Sep '12

11 Sep '12

Hi, I don't reach to compile Boost.Coroutine under Mac using trunk ../../../boost/coroutine/coroutine.hpp:14:45: error: boost/context/stack_allocator.hpp: No such file or directory ../../../boost/coroutine/coroutine.hpp:15:41: error: boost/context/stack_utils.hpp: No such file or directory Are you changing the interface of Boost.Context? Best, Vicente

4 4

[log] library status?
by Igor R 11 Sep '12

11 Sep '12

Hello, Is Boost.Log expected to enter one the Boost version soon? I see that its last update on sourceforge took place about a year ago... Thanks.

3 2

quest for member ‘read_some’ in ‘socket’, which is of non-class type ‘boost::asio::ip::tcp::socket* {aka boost::asio::basic_stream_socket<boost::asio::ip::tcp>*}
by neha_mysql 11 Sep '12

11 Sep '12

Hii, i am trying to execute a code and im getting error in this part of the code(in line no 3) for(;;) char buf[4]; size_t len = socket.read_some(boost::asio::buffer(buf,4)); if(error == boost::asio::error::eof) break; else if(error) throw boost::system::system_error(error); std::cout << "[!]"; std::cout.write(buf.data(), len); } The error is *" quest for member ‘read_some’ in ‘socket’, which is of non-class type ‘boost::asio::ip::tcp::socket* {aka boost::asio::basic_stream_socket<boost::asio::ip::tcp>*}"* -- View this message in context: http://boost.2283326.n4.nabble.com/quest-for-member-read-some-in-socket-whi… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 1

[Review.Coroutine] More comments, questions and suggestions
by Vicente J. Botet Escriba 11 Sep '12

11 Sep '12

Hi, I understand Oliver that you are busy as all of us and that it is better to provide first the minimal scope you are confident with. I expect however that you will add symmetric coroutines based on the work done by Giovanni in a near future. BTW, adding a link to the Giovanni documentation will be welcome. I have more questions concerning the interface before finishing my review: * How the library behaves when the coroutine parameters are const& typedef boost::coro::coroutine< int( AType const& ) > coro_t; int fn( coro_t::self_t & self, AType const& v) { ???j = self.yield( v.get_int() ); /// ... } What should be the type (???) of j? Does AType const& works? * Have you tested with other kind of parameters? arrays, pointers, ... It would be great if the documentation includes some examples, with the different types that can be used. * The way the parameters of the coroutine call are retrieved the second time is a little bit disturbing at a first glance, but once you understand how this works, it is not so complex (This applies to the library under review and the original one, as both share the same design). I don't know if the the self object couldn't store the parameter binding, so that the user will not be concerned by the yield result type. typedef boost::coro::coroutine< int( int) > coro_t; int fn( coro_t::self_t & self, int i) { // binds current parameters to the self object. Done only once. self.bind(i); // *** std::cout << "fn(): local variable i ==" << i << std::endl; // save current coroutine context // transfer execution control back to caller // no need to assign the result. It is up to yield to fill the binded parameters. self.yield(i); // OTHERS *** // i == 10 because c( 10) in main() and i has been bound in self. std::cout << "fn(): local variable i ==" << i<< std::endl; return i; // LAST } I don't know this bind design introduce more problems that it could solve. I don't know neither if this could degrade the performances. * In the preceding example there is an asymmetry between the value returned the last time and the others. self.yield( i); // OTHERS return i; // LAST What about forcing the coroutine function return void, as it is the case now for the generator? voidfn( coro_t::self_t & self, int i) { self.bind(i); std::cout << "fn(): local variable i ==" << i << std::endl; self.yield(i); std::cout << "fn(): local variable i ==" << i<< std::endl; self.yield(i); } This should help to simplify user code, isn't it? * I don't know if you have reached to make the StackAllocator standard compliant, but if this is the case you could add also a specializations of the use_allocator template so that Boost.Container can take it in account. Best, Vicente

5 13

[Review.Coroutine] Lifetime of coroutine parameters
by Vicente J. Botet Escriba 11 Sep '12

11 Sep '12

Hi, I have some concerns about the lifetime of the coroutine parameters. Surprisingly (well not really), the following example doesn't fails at *1*. This is because the coroutine have access to its coroutine parameters *2*, which has a sens only for the first time the coroutine is called. Once the first call to yield return, the memory these parameter *3* can point to trash, as the example shows. typedef int TT; typedef boost::coro::coroutine< void(TT&) > coro_TT; void lifetime( coro_TT::self_t & self, TT& i ) // *2* { i=1; TT& j = self.yield(); std::cout << i << j << std::endl; i=2; // *3* UNSAFE access to i self.yield(); } void test_lifetime() { coro_TT c( boost::bind( lifetime, _1, _2) ); { int k = 0; c( k ); BOOST_CHECK(k = 1); } { int k = 0; int i = 0; c( i ); BOOST_CHECK(k = 2); // *1* std::cout << i << k << std::endl; } } This could hide errors that are difficult to catch. In addition to merit to be mentioned in the documentation as a limitation of the current library interface I really think that it merits to see if this can be solved. Best, Vicente

3 3

[Variant] C++11 variadic template implementation
by Florian Goujeon 11 Sep '12

11 Sep '12

Hi Boosters, I'd like to know if anybody were working on a C++11 version (using variadic templates) of Boost.Variant. I currently use the 'classic' version in my project, but since I need more-than-20-type variants, the compilation take a lot of time (extending the number of types that variant can support forces you to disable the use of precompiled headers). Plus, I'll need to use 70 type variants (MPL lists are physically limited to 50 types). If nobody has started to implement such a version yet, I'd be pleased to contribute. I've written an implementation. It's incomplete and far from perfect, but it could (hopefully) be a viable working basis.

6 16

[HELP] fatal error LNK1120: 5 unresolved externals
by Seow Hui, Saw 10 Sep '12

10 Sep '12

Dear Sir/ Madam, A very good day to you. I installed boost 1.50 installer (32-bit) which downloaded from http://www.boostpro.com/download/ and did the appropriate settings (including CGAL) in Microsoft Visual Studio 2010. I would like to run the following sample code: #include <iostream> #include <CGAL\Exact_predicates_inexact_constructions_kernel.h> #include <CGAL\convex_hull_2.h> typedef CGAL::Exact_predicates_inexact_constructions_kernel K; typedef K::Point_2 Point_2; int main() { Point_2 points[5] = { Point_2(0, 0), Point_2(10, 0), Point_2(10, 10), Point_2(6, 5), Point_2(4, 1) }; Point_2 result[5]; Point_2 *ptr = CGAL::convex_hull_2( points, points+5, result ); std::cout << ptr - result << " points on the convex hull" << std::endl; return 0; } There are no errors during compilation but there are errors during the build as shown below: 1>------ Build started: Project: Cgal_Hello, Configuration: Debug Win32 ------ 1>libboost_system-vc100-mt-gd-1_50.lib(error_code.obj) : error LNK2005: "public: __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(class std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> > const &)" (??0?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QAE@ABV01@@Z) already defined in msvcprtd.lib(MSVCP90D.dll) 1>libboost_system-vc100-mt-gd-1_50.lib(error_code.obj) : error LNK2019: unresolved external symbol "__declspec(dllimport) void __cdecl std::_Xout_of_range(char const *)" (__imp_?_Xout_of_range@std@@YAXPBD@Z) referenced in function "public: void __thiscall std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::_Xran(void)const " (?_Xran@?$basic_string@DU ?$char_traits@D@std@@V?$allocator@D@2@@std@@QBEXXZ) 1>D:\Cgal_Hello\Debug\Cgal_Hello.exe : fatal error LNK1120: 5 unresolved externals Can anyone please help me with this issues? desperately need help... In addition, if I have installed the installer, do I still have to use bjam.exe to build the libraries? Hope to hear from you soon. Thank you very much. -- Best Regards, Saw

2 1

[program_option] Better compiler checks?
by Klaim - Joël Lamotte 10 Sep '12

10 Sep '12

Hi I was adding program_option to my prorgam when I discovered a related leak. Fortunately it was false positive, but it pointed a hidden problem. I used: - Visual Studio 2012 - Boost 1.51.0 - Visual Leak Detector to detect the leak This, generate the leak: {{{ #include <boost/program_options.hpp> int main() { namespace bpo = boost::program_options; bpo::options_description options( "Options" ); options.add_options() ( "test" , "Test." ) , ( "value" , bpo::value<int>(), "Value." ) ; } }}} The second option is leaking. The reason is because of the comma in the beginning of the line. I first added it by reflex when using function arguments so it took me some time to find what was leaking. Part of the time I spend was figuring out why it don't leak if you don't set a value type: {{{ #include <boost/program_options.hpp> int main() { namespace bpo = boost::program_options; bpo::options_description options( "Options" ); options.add_options() ( "test" , "Test." ) , ( "value" , "Value." ) // no leak but still wrong! ; } }}} The main problem I see with this is that it is compiled without any problem nor warning. So here is my question: Would it be possible to forbid comma operator with options_description_easy_init? I added a ticket for this, #7361 : https://svn.boost.org/trac/boost/ticket/7361 Joel Lamotte

1 0

Forward declaration headers
by Jens Auer 10 Sep '12

10 Sep '12

Hi, we often have to provide forward declarations of boost types by hand when we write interfaces. This is kind of dangerous because we will have to change the forward declarations when the boost libraries change and impossible for typedefs. Shouldn't there be a standard forward declaration headers in each of the boost libraries? Best regards, Jens

2 1