- Boost - lists.boost.org

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

Sizes, signed and unsigned integers, MPL and Fusion
by Mathias Gaunard 10 Sep '12

10 Sep '12

Hi folks, I am writing this message to bring to your attention ticket #7304 <https://svn.boost.org/trac/boost/ticket/7304> Sizes of fusion sequences are of type 'int', because it mimics MPL. However, sizes of standard containers, some of which are fusion sequences, are of type std::size_t, which is unsigned. This seems a bit inconsistent, and can lead to unexpected signed/unsigned mismatch warnings in certain scenarios. Should both MPL and Fusion be modified to use unsigned size types? I think it is best to discuss this with the whole of Boost.

2 1

Making use of extern template
by Jens Auer 10 Sep '12

10 Sep '12

Hi, I tried to use C++11 extern template mechanism to reduce the turn-around time for our main project, but it turns out that the way people write template code in libraries is not suited well for that purpose. I tried to explicitly instantiate the template base class of boost::posix_time_ptime, date_time::base_time<ptime, posix_time_system>, because ptime is a value class which is used quite often in our project. The base class is then instantiated in every translation unit and later removed by the linker (we use MS Visual C++ 2010. The linker is single threaded and dead slow). The problem with extern template and the boost library is that inline template code is still instantiated in every translation unit even when using extern template, so it basically has no effect with the current boost code: $14.7.2.10: "Except for inline functions and class template specializations, explicit instantiation declarations have the effect of suppressing the implicit instantiation of the entity to which they refer." I would like to have a discussion of how boost could support extern template to reduce built times, maybe by changing the coding style to not write template code inline and use extern template in the library to automatically suppress instantiation of library instantiations such as the base class of ptime. Best regards, Jens

1 0

[atomic, 1.52] adoption & merge request
by Tim Blechmann 09 Sep '12

09 Sep '12

hi all, boost.atomic has been accepted as boost library and has been in trunk for a few months. however there are some issues and pending patches and helge bahmann, the original author, did not comment on any of them. therefore, hartmut and me would like to adopt the library temporarily to support helge, and merge these pending patches. we also like to add the library into the release branch, so that it will make it into 1.52. any objections? thanks, tim

3 2