- Boost - lists.boost.org

[thread] possible raise in future?
by Oliver Kowalke 03 Feb '13

03 Feb '13

Hello Vicente, after analyzing the code of future<> from boost.thread I think the code might contain raise condition. future.hpp:226: future_object_base defined 'bool done'. future_object_base::mark_finished_internal() sets 'done' tot true (line 308) and future_object_base::wait_internal() reads it (line 347). Shouldn't 'done' be of type atomic<bool >? I believe that the compiler can reorder the usage of 'done' and two threads (writer thread calling make_finished_internal() and reader calling wait_internal()) might see different values. At least I think it might be possible that some thread will always be waiting in waiters.wait() (line 349), because the write r thread sets done=true and call waiters.notify_all() and a reader thread calls later wait_internal() but does not see that done is true because of memory reordering etc. and will be blocked in waiters.wait()forever. What do you think? best regards, Oliver

2 3

Re: [boost] [thread] possible raise in future
by Oliver Kowalke 03 Feb '13

03 Feb '13

hmm - both functions are called by other member-fn of future_object_base, locking the same mutex before. But might reordering (of var done' inlined code) still be possible? I'm asking because l've some experimental code using future<> which sometimes blocks (I assume inside future<>::wait()).

1 0

Writing documentation
by Borislav Stanimirov 03 Feb '13

03 Feb '13

Hello, I'm developing a project for boost (discussion can be found here: http://lists.boost.org/Archives/boost/2013/01/200598.php) I was wondering how one writes documentation. I did find some templates here, but they seem outdated (ot at least different), compared to the documentation files that already exist for the libraries. So, are there any new templates? Is there a html generation tool I should use? -- Borislav

5 10

[auto_index] segfault during boostbook xml processing
by Alexey Kutumov 03 Feb '13

03 Feb '13

Hi! Recently i started to port boost documentation building to CMake ( https://github.com/boost-cmake/) with ryppl-dev community, and i have some issues with auto_index. According to documentation ( http://www.boost.org/doc/libs/1_52_0/tools/auto_index/doc/html/boost_autoin…) this tool supports boostbook XML, however when i started to process XML with auto_index it crashes. I created ticket (https://svn.boost.org/trac/boost/ticket/7967) and added example for reproducing ( https://svn.boost.org/trac/boost/attachment/ticket/7967/autoindex_issue.zip ). Also i have a question: is it legal to use auto_index with boostbook XML, because i have same issue for some others projects?

2 1

new proposal: order statistics tree
by Szymon Wojciechowski 03 Feb '13

03 Feb '13

Hi, I would like to propose to add new data structure - order statistics tree. Briefly, it is container which allows logarithmic inserting, searching and erasing as in set, but additionally it permits to access elements via numerical value - key order. I have some ready implementation with all appropriate functions (without their all overloaded forms) with gtest regression list, but the code isn't boostified. The regression passes on gcc 4.6.3 and vs2010. Is there anybody interested in? Best regards, Szymon Wojciechowski

7 21

Ok to commit to trunk?
by Christian Henning 03 Feb '13

03 Feb '13

Hi there, I'm planning to commit some changes and add the toolbox to gil on the trunk ( not the release branch! ). Is it OK to commit? Thanks! Christian

3 4

[fixed_point] Request for interest in a binary fixed point library
by Vicente J. Botet Escriba 02 Feb '13

02 Feb '13

Hi, the recent discussion on the MultiplePrecission Arithmetic library has show that some people has its ow fixed point library. Is there an interest in a Boost library having as base http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3352.html? I have started a prototype http://svn.boost.org/svn/boost/sandbox/fixed_point (there is no doc yet but the basic goal is quite close to the N3352 C++ proposal). This prototype should allow you to play a little bit with. If yes, what would you like to be changed, added or improved in n3352? Next follows some design decisions that IMO need to be decided before hand. * Should integers and reals be represented by separated classes? * Should signed and unsigned be represented by separated classes? * Should the library use a specific representation for signed numbers (separated sign, 2-complement? Let the user choose? * Should the library provide arbitrary range and resolution and allocators? * Should the library be open to overflow and rounding or just implement some of the possible policies? and in this case which ones? * Should fixed_point be convertible to/from integer/float/double? * Could the result of an arithmetic operation have more range and resolution than his arguments? * Is there a need for a specific I/O? * is there a need for radix other than 2 (binary)? * Should the library implement the basic functions, or should it imperatively implement the C++11 math functions? Could a first version just forward to the c++11 math functions? * Should the library support just one of the know ways to name a fixed-point, a U(a,b), nQm, ...? Provide some ways to move from one to another? * Could expect the same/better performances respect to hand written code? * What should be the size used by a fixed_point instance? _fast? _least? Should the user be able to decide which approach is better for his needs? * Which should be the namespace? boost? boost/fixed_point? boost/binary_fixed_point? boost/bfp? ... * others you can think of. Please, replay if you are interested, have some experience in the domain, good ideas, .. Best regards, Vicente

6 44

[1.53.0] Release candidates available
by Marshall Clow 02 Feb '13

02 Feb '13

Release candidate files for 1.53.0 are available at http://boost.cowic.de/rc/ As always, the release managers would appreciate it if you download the candidate of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. This helps ensure the candidates build OK before we push them out to SourceForge. The files (and associated md5s) are: 57a9e2047c0f511c4dfcf00eb5eb2fbb *boost_1_53_0_rc1.tar.gz a00d22605d5dbcfb4c9936a9b35bc4c2 *boost_1_53_0_rc1.tar.bz2 c618e030fd4882e4dbacf54baf824544 *boost_1_53_0_rc1.zip cc680cab53a5405ca102a10d43b92b88 *boost_1_53_0_rc1.7z Thanks! -- The release managers

9 10

Re: [boost] Is there any interest in static constructors?
by Alexander Stoyan 01 Feb '13

01 Feb '13

Hello Mathias, I'm afraid you didn't get the point. Let me explain. >> The object will only be constructed when instance() is called Technically, yes, the instance will be create once singleton::instance is called for the first time, but in order to make it constructed BEFORE main, singleton::instance has to be called during static data initialization, and static_init GUARANTIES that this static initialization will be performed before main WITH NO additional calls. >> If the constructor of the object depends on >> other singletons, then instance() of those other singletons >> will naturally be called before, and therefore they >> will end up being constructed before. You're right, if you refer to singleton A's before creating singleton B's instance, to order of initialization would be correct. But let's no limit this case to singletons only, where initialization is achieved in just one call. There can many many different situation when you have to perform some additional data initialization and manipulation before creating singleton instance. Where would you put this code? Would you make singleton constructor or instance access method dependent on all this data when it naturally should not be? Anyway it doesn't solve the problem for the first call to a singleton if it has to be initialized before main. Unless you create a global static variable and make the first call to singleton during this variable initialization, but then you still need to refer to this variable from the code somewhere in order to make sure your compiler does not eliminate it due to optimization reasons, and this way you will introduce unnecessary dependency. 3. There is no construction recursion. If you did notice it somewhere, please point to exact place. 4. Static data construction order is undefined by C++ standard fixing it requires either changing the standard or getting rid of class and global static data. So, again, to make the idea crystal clear, the initial goal was: 1. Guarantee that static constructor method is called before main is executed 2. No additional calls in either global or any local scope should precede static constructor invocation in order not to introduce extra dependencies and eliminating a situation when initialization invocation code does not get called for any reason. 3. Provide a way to control the order of static constructors calls. No recursions are allowed. The described approach fully satisfies the three simple requirements. If anybody sees possible errors or ways to improve it, feedbacks are very appreciated. Thank you. ______________________________ With best regards, Alexander Stoyan

3 2

Building 1.52.0 with g++ 4.7.2
by Richard Hadsell 01 Feb '13

01 Feb '13

I am having trouble building Boost 1.52.0 libraries with g++ 4.7.2 on Linux Fedora 14. I was able to build it with 4.7.1, and I think our Systems guys configured 4.7.2 the same as 4.7.1, so I need help. This is in my user-config: using gcc : 4.7.2 : /opt/gcc-4.7.2/bin/g++ :<compileflags>"-fPIC -fno-strict-aliasing -fno-tree-ccp"<linkflags>"-fPIC -fno-strict-aliasing -fno-tree-ccp" ; This is my command line: bin/bjam --user-config=user-config.LINUX_INTF14X threading=multi instruction-set=core2 address-model=64 variant=release link=static,shared --stagedir=stageF14X And this is the result (snipped out redundant info): Building the Boost C++ Libraries. Performing configuration checks - x86 : no - power : no - arm : no - mips1 : no error: No best alternative for libs/context/build/asm_context_sources next alternative: required properties:<abi>aapcs<architecture>arm<binary-format>elf<toolset>gcc not matched next alternative: required properties:<abi>aapcs<architecture>arm<binary-format>elf<toolset>qcc not matched [snip] next alternative: required properties:<abi>ms<address-model>64<architecture>x86<binary-format>pe<target-os>windows not matched - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - iconv (libc) : no - iconv (separate) : no - icu : no - icu (lib64) : no - Boost.Locale needs either iconv or ICU library to be built. [snip] - Boost.Locale needs either iconv or ICU library to be built. - gcc visibility : no - long double support : no warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. error: No best alternative for libs/context/build/asm_context_sources next alternative: required properties:<abi>aapcs<architecture>arm<binary-format>elf<toolset>gcc not matched [snip] -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

2 2