- Boost - lists.preview.boost.org

[preprocessor] automatic recursion curiosity
by Lorenzo Caminiti 14 Sep '12

14 Sep '12

Hello all, I have a curiosity about an implementation detail of Boost.Preprocessor: How does the lib implement Automatic Recursion? >From the docs under Topic > Reentrancy > Automatic Recursion: http://www.boost.org/doc/libs/1_51_0/libs/preprocessor/doc/index.html `` Using automatic recursion to reenter various sets of macros is obviously much simpler. It completely hides the underlying implementation details. So, if it is so much easier to use, why do the state parameters still exist? The reason is simple as well. When state parameters are used, the state is known at all times. This is not the case when automatic recursion is used. The automatic recursion mechanism has to deduce the state at each point that it is used. This implies a cost in macro complexity that in some situations--notably at deep macro depths--will slow some preprocessors to a crawl. '' I have not looked at the source code and I'm looking for the glory details. However, I'd like to understand at a high level how Boost.Preprocessor is able to implement Automatic Recursion behind the scene (it just bothers me not being able to imagine how this is actually done and why it is expensive on some preprocessors). Can anyone provide a quick explanation or point me to some email thread / docs that explain that? Thanks a lot! --Lorenzo

2 1

[Review.Coroutine] Vicente's review
by Vicente J. Botet Escriba 13 Sep '12

13 Sep '12

Hi, I understand that Oliver is busy as all of us and that it is better to provide first the minimal and well designed scope he is confident with. I expect however that Oliver will add soon symmetric coroutines based on the work done by Giovanni in a near future. - What is your evaluation of the design? I have some suggestions about changing the interface, but I'm not sure all of them could be implemented in an efficient way. * The use of thecoro_t::self_t & self parameter makes too much noise. This parameter must be forwarded to any function that could yield the coroutine. An alternative design using a thread specific pointer could allow to access the current coroutine int f20() { typedef this_coroutine<int(void)> this_coro; this_coro::yield(5); } Is the rationale for using self_t to get better performances? Maybe both interfaces could be provided. * There is an asymmetry between the value returned the last time and the others. self.yield( i); // OTHERS return i; // LAST This asymmetry forces the user to manage the last return in a specific case, changing the readability of the code. I would prefer coroutine function returns void. voidfn( coro_t::self_t & self) { self.yield(1); self.yield(2); } * If this is not adopted, the implementation should check at compile time that the return type of the coroutine function is the one of the signature. * The access to the actual coroutine parameters is asymmetric, letting access to old actual parameters that can point to objects that have already been destroyed. Maybe the self_t object could take care of this (or this_coroutine). We can use a get<> function to give access to the actual parameters. int f20(coro_t::self_t & self) { self.yield(2*self.get<0>()); } int f20() { typedef this_coroutine<int(int)> this_coro; this_coro::yield(2*this_coro::get<0>()); } Or even use some kind of bind parameter int f20(coro_t::self_t & self) { int i; int j; self::bind(i, j); self.yield( i + j ); } int f20() { int i; int j; typedef this_coroutine<int(int)> this_coro; this_coro::bind(i, j); this_coro::yield( i + j ); } If bind is adopted, the implementation could use it to store directly the actual parameters, instead of needing to store them in the self_t instance and them returning them when yield is called. */As// Boost.Coroutine is able to transfer user exceptions, and there is no difference between calling to coroutine<>::self_t::yield_break()/ and throwing/coroutine_terminated,/both (/coroutine<>::self_t::yield_break()/ and throwing/coroutine_terminated)/be removed from the library. The same applies for generators. * noexcept specifier should be added to class coroutine { // ... coroutine() BOOST_NOEXCEPT; coroutine( coroutine && other) BOOST_NOEXCEPT; coroutine & operator=( coroutine && other) BOOST_NOEXCEPT; explicitoperator bool() const BOOST_NOEXCEPT; bool is_complete() const BOOST_NOEXCEPT; //... }; void swap( coroutine & l, coroutine & r) BOOST_NOEXCEPT; The same applies to generator. * Type-erase on the Allocator parameter as the standard std::packaged_task does. * Make coroutine/generator classes to follow the allocator aware standard protocol adding the constructor with the standard allocator. A specializations of the use_allocator template should be added for this purpose. * Moving some of the coroutine/generator optional parameters to a coro::attributes class could simplify the interface std::size_t size = ctx::default_stacksize(), flag_unwind_t do_unwind = stack_unwind, bool preserve_fpu = true, * The lib shouldn't throw when preconditions are not satisfied, assert should instead. * It is a shame that the library can not support completely move semantics for the coroutine parameters, as the used boost::tuple don't support it yet. I would like this point be addressed before the first release so that there is no break in the interface when this will be solved either using boost::tuple, boost::fusion::tuple or std::tuple. At a last resort the library could either define a macro that allows to parameterize the tuple implementation, or alternatively it could implement a wrapper that forwards to the best implementation. * As others have noted, providing a view of a generator as an output iterator will be welcome. Viewing it as a range will be also appreciated. BTW, I don't like the alternative using optional as the result of a generator. Following the output iterator concept the access is defined only if the generator has not finished. - What is your evaluation of the implementation? I have not a deep opinion as I have not found the time to inspect it. At first glance, it seems that the inheritance hierarchy is deeper than needed and the use of the pre-processor to manage with variadic templates hides a possible good design (as it is usual in those cases). Maybe now that most of the c++ compilers support them, using the preprocessor is less imperative. - What is your evaluation of the documentation? I find the documentation a little bit sparse and contain a lot or typos and minor errors. I would appreciate if the original Boost.Coroutine documentation from Giovannii were not lost, at least for Motivation and Tutorial parts. I would appreciate also if the documentation include the rationale to don't include symmetric coroutines and show how the current library can be used to solve the problems the missing features provide, why not as examples. * showing the signature in the documentation will be more informative. template< typename Signature, typename Allocator = ctx::stack_allocator >class coroutine; template< typename R, typename ...ArgTypes, typename Allocator > class coroutine<R(ArgTypes...)> { public: class self_t { public: tuple<ArgTypes...>yield( R); void yield_break(); }; * documentation for the following constructor is missing in the reference template< typename Fn > coroutine( Fn && fn, std::size_t size = ctx::default_stacksize(), flag_unwind_t do_unwind = stack_unwind, bool preserve_fpu = true, Allocator alloc = Allocator() ); *The example typedef boost::coro::coroutine< void(int) > coro_t; void f( coro_t::self_t & self, int i) { ... self.yield(); ... } coro_t c( boost::bind( f, _1) ); c( 7); doesn't compiles. It should be something like coro_t c( boost::bind( f, _1, _2) ); BTW, I don't see the need to use boost::bind in this case, as coro_t c( f ); works as well. The superfluous uses of bind in the documentation should be removed: - What is your evaluation of the potential usefulness of the library? Very useful. coroutines and generators are some useful constructions that are missing in the language. - Did you try to use the library? With what compiler? Did you have any problems? Yes. I used gcc-4.2.1,4.6.0, 4.7.0,clang2.9 andclang-3.0 on darwin. I had no problem running the provided examples and tests. I have written some examples. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have read the documentations of Oliver and Giovanii libraries, followed the review and used the library. - Are you knowledgeable about the problem domain? From the theoretical point of view, yes. Never used in practice. Finally, my vote is YES. Even if the current interface has some drawbacks that should be mentioned in the documentation, I think I Boost.Coroutine is already useful and should be accepted into Boost. Best, Vicente P.S. Maybe I have forgotten to include some of the remarks I did on preceding posts.

4 11

[optional] using gdb to inspect optional value
by Pedro Larroy 13 Sep '12

13 Sep '12

Hi Is there a way to inspect an optional with gdb? I had to remove the usage if boost::optional as it caused me trouble to inspect the value. Thanks. Pedro.

2 1

[asio] New feature: timeout for poll()
by Max Che 13 Sep '12

13 Sep '12

Hello. My previous letter contained errors. Here is another letter. I want to use win_iocp_io_service::poll() with timeout. poll() + timeout => poll() functional and free waitable timer! GetQueuedCompletionStatus() (and epoll(), kqueue()) allows to use that. Can anyone add (restore) this feature?

1 0

[shared_ptr] Patch adding weak_use_count and weak_from_this
by Brent Lewis 12 Sep '12

12 Sep '12

These are useful for debugging, similarly to shared_ptr::use_count. Specifically, you can check for dangling pointers by replacing ordinary pointers with weak pointers, and checking the count inside a destructor. The patch is for boost 1.49 and is attached.

1 0

[build] 1.49 unable to bootstrap boost
by yuri kilochek 12 Sep '12

12 Sep '12

Not sure if this goes here. On Windows 7, when I try to do bootstrap on a freshly unzipped boost 1.49 at the root directory, I get the following output: Building Boost.Build engine But that is as far as it gets before os terminates whatever it is doing with this (roughly translated from russian): **** STACK SIZE EXCEEDED **** **** WHILE PERFORMING RECURSION IN BATCH MODE **** Recursion depth=654, Stack usage=90 percent. **** BATCH PROCESSING ABORTED **** Is there a way to build boost bypassing this?

4 3

[context] Linux x64 / printf
by Daniel Larimer 12 Sep '12

12 Sep '12

I modified the 'jump.cpp' example and added the line marked CRASH in f1() #include <cstdlib> #include <cstring> #include <iostream> #include <vector> #include <boost/assert.hpp> #include <boost/context/all.hpp> namespace ctx = boost::ctx; ctx::fcontext_t fcm, fc1, fc2; void f1( intptr_t) { std::cout<<"hello "<<0; // WORKS printf( "hello %d", 0 ); // <<< CRASH std::cout << "f1: entered" << std::endl; std::cout << "f1: call jump_fcontext( & fc1, & fc2, 0)" << std::endl; ctx::jump_fcontext( & fc1, & fc2, 0); std::cout << "f1: return" << std::endl; ctx::jump_fcontext( & fc1, & fcm, 0); } void f2( intptr_t) { std::cout << "f2: entered" << std::endl; std::cout << "f2: call jump_fcontext( & fc2, & fc1, 0)" << std::endl; ctx::jump_fcontext( & fc2, & fc1, 0); BOOST_ASSERT( false && ! "f2: never returns"); } int main( int argc, char * argv[]) { ctx::stack_allocator alloc1, alloc2; fc1.fc_stack.base = alloc1.allocate(ctx::minimum_stacksize()); fc1.fc_stack.limit = static_cast< char * >( fc1.fc_stack.base) - ctx::minimum_stacksize(); ctx::make_fcontext( & fc1, f1); fc2.fc_stack.base = alloc2.allocate(ctx::minimum_stacksize()); fc2.fc_stack.limit = static_cast< char * >( fc2.fc_stack.base) - ctx::minimum_stacksize(); ctx::make_fcontext( & fc2, f2); std::cout << "main: call start_fcontext( & fcm, & fc1, 0)" << std::endl; ctx::jump_fcontext( & fcm, & fc1, 0); std::cout << "main: done" << std::endl; return EXIT_SUCCESS; }

4 9

[mpi] scatterv, gatherv and Boost.MPI status
by Alain O Miniussi 11 Sep '12

11 Sep '12

Hi, Despite the fact that https://svn.boost.org/trac/boost/ticket/5292 has been sitting there for some time, the documentations still states that MPI_Allgatherv => most uses supported by all_gather (from 1.51.1). It seems the ticket wasn't commited nor refused. Is there a reason why a c++ MPI_gatherv equivalent is useless in Boost.MPI ? Overall, there seems to be a few other tickets in the same situation in the mpi lib. Which raises another question: what is the exact status of Boost.MPI ? is it still maintained ? is it worth submitting tickets or proposing patches to it or is it safer to move back to the C API ? Best regards Alain

1 0

FW: [Review] Coroutine review starts today, September 3rd, ends September 12th
by Hartmut Kaiser 11 Sep '12

11 Sep '12

This is just a reminder that the review of Oliver's Boost.Coroutine is ending tomorrow (see below for the initial announcement). Please get your reviews in as soon as possible. If you need more time, please let me know. Regards Hartmut --------------- http://boost-spirit.com http://stellar.cct.lsu.edu > -----Original Message----- > From: Hartmut Kaiser [mailto:hartmut.kaiser@gmail.com] > Sent: Monday, September 03, 2012 6:46 AM > To: boost(a)lists.boost.org > Subject: {Review] Coroutine reviewstarts today, September 3rd > > > Hi all, > > The review of Oliver Kowalke's Boost.Coroutine library starts today, > September 3rd 2012, and will end on September 12th. > I really hope to see your vote and your participation in the discussions > on the Boost mailing lists! > > ----------------------------------------------------- > > About the library: > > Boost.Coroutine provides templates for generalized subroutines > (coroutines) which allow multiple entry points for suspending and resuming > execution at certain locations. It preserves local state/data and allows > re-entering subroutines more than once (useful if state must be kept > across function calls). Coroutines can be viewed as a language-level > construct providing a special kind of control flow. > > You can download the library and the view documentation here: > > docs: http://ok73.ok.funpic.de/boost/libs/coroutine/doc/html/ > src: http://ok73.ok.funpic.de/boost.coroutine.zip > > --------------------------------------------------- > > Please always state in your review, whether you think the library should > be accepted as a Boost library! > > Additionally please consider giving feedback on the following general > topics: > > - What is your evaluation of the design? > - What is your evaluation of the implementation? > - What is your evaluation of the documentation? > - What is your evaluation of the potential usefulness of the library? > - Did you try to use the library? With what compiler? Did you have any > problems? > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > - Are you knowledgeable about the problem domain? > > Regards Hartmut > Review Manager

1 0

[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

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

[atomic] ia32/cmpxchg8b fix
by Tim Blechmann 09 Sep '12

09 Sep '12

one of my users reported an issue with atomic on gcc/ia32, related to const-correctness. ok to commit this fix? thanks, tim Index: boost/atomic/detail/gcc-x86.hpp =================================================================== --- boost/atomic/detail/gcc-x86.hpp (revision 80433) +++ boost/atomic/detail/gcc-x86.hpp (working copy) @@ -1556,11 +1556,11 @@ template<typename T> T -platform_load64(volatile T * ptr) +platform_load64(const volatile T * ptr) { T expected = *ptr; do { - } while (!platform_cmpxchg64_strong(expected, expected, ptr)); + } while (!platform_cmpxchg64_strong(expected, expected, const_cast<volatile T*>(ptr))); return expected; }

2 1

Re: [boost] C++ Boost library - passing Shared pointer to a function
by abhishek goswami 09 Sep '12

09 Sep '12

I am looking for a project which is converting c malloc/realloc to shared_ptr. During my Analysis, I found the issue Can anyone provide me some input how to fix below issue typedef boost::shared_ptr<Employee_t> srdpointer; srdpointer ptr((Employee_t*)malloc(sizeof(Employee_t)),std::ptr_fun(free)); I need to pass the shared pointer which will allocate memory Pointed by the ptr. Something like this. void allocateBlocks(int **ptr, int *cnt) { *ptr = (int*)malloc(sizeof(int) * 10); *cnt = 10; /*do something*/ } int main() { int *p = NULL; int count = 0; allocateBlocks(&p, &count); /*do something*/ free(p); } How can I achieve the similar functionality using shared ptr as shown in above code

2 1

[intrusive] patch to resolve compiler error for WinCE
by David Deakins 09 Sep '12

09 Sep '12

Hi Ion, I had a little bit of time to look into the compile error mentioned in ticket 6841 and determine a patch from detail/mpl.hpp that I think should resolve it. The patch is attached to that Trac ticket, although I could also just go ahead and apply it if you like. Thanks, -Dave

2 1