March 2011 - Boost - lists.boost.org

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

Why no non-null smart pointers?
by Ross MacGregor 29 Apr '14

29 Apr '14

I just created a very small smart pointer libary for our project. It will contain two types of shared pointers: SharedHandle and NullableSharedHandle. SharedHandle will be a shared pointer that cannot be null by ensuring a non-null construction while NullableSharedHandle will basically be a typedef for boost::shared_ptr. I firmly believe that code can be made more reliable by minimizing the use of nullable pointers. To this end, I think it is important that we start using non-null pointer types. Ideally the compiler would be able to understand a non-null pointer and catch bugs at compile time, but I think we can still improve things with a few runtime checks. If we make sure that a shared pointer is constructed with a non-null pointer and ban any reset() type methods, we guarentee that it points to something. This can be beneficial for the following reasons: 1. Any function that uses this type will no longer be burdened with precondition checks to make sure variables of this type are not null. 2. It's type is simply more explicit and better explains its function. 3. Moving the non-null check to the creation phase will reduce the possibility of encountering null pointer exceptions at runtime (assuming there are many more pointer references than constructor calls). So my little pointer library seems to make a lot of sense, but if so why hasn't this simple smart pointer variation made it into boost yet? Has this been discussed somewhere already? My search on non-null smart pointers is not revealing much discussion on the topic. Regards, Ross

9 16

[mpl] integral_c [type_traits] integral_constant limits
by vicente.botet 21 Oct '13

21 Oct '13

Hi, I was testing Boost.Ratio with gcc-4.6 c++0x and I get some compile errors when instantiating std::cout << boost::mpl::integral_c< boost::intmax_t, boost::integer_traits<boost::intmax_t>::const_max >::value ; ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<long long int, 0x7fffffffffffffffll>': ratio_io\ratio_io.pass.cpp:24:6: instantiated from here ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: warning: integer overflow in expression [-Woverflow] ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: error: '-0x8000000000000000ll' is not a valid template argument for type 'long long int' because it is a non-constant expression ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: error: '-0x8000000000000000ll' is not a constant expression integral_wrapper.hpp:72 contains typedef AUX_WRAPPER_INST( BOOST_MPL_AUX_STATIC_CAST(AUX_WRAPPER_VALUE_TYPE, (value + 1)) ) next; The same line pass with gcc-4.6, gcc-4.5 and gcc-4.5 c++0x with just a warning. ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp: In instantiation of 'mpl_::integral_c<long long int, 0x7fffffffffffffffll>': ratio_io\ratio_io.pass.cpp:23:6: instantiated from here ..\..\..\../boost/mpl/aux_/integral_wrapper.hpp:72:96: warning: integer overflow in expression [-Woverflow] integral_c is by integral_constant, but integral_constant doesn't needs next a prior types. This means that with the current implementation we can not use integral_constant with the max value of the type. Do you think this is a bug in integral_constant? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

5 7

De Bruijn Bind (alternate bind syntax) Interest?
by David Sankel 24 Jun '13

24 Jun '13

Hello all, I've been working on an alternate bind syntax based on De Bruijn indices[1]. The syntax is very simple, yet the terms are very powerful. Here is an example of a function const that takes in an argument c and returns another function that, for all input, returns c: //λx.λy.x = λλ1 with De Bruijn indices. auto const_ = abs<1>( abs<1>( var<1,0>() ) ); More examples, further explanation, and an implementation are available here[2]. I'm thinking that this library could also be useful as a core for more syntax heavy bind variations. David [1] http://en.wikipedia.org/wiki/De_Bruijn_index [2] http://bitbucket.org/camior/de-bruijn-bind/ -- David Sankel Sankel Software www.sankelsoftware.com 585 617 4748 (Office)

11 73

[config] consexpr workaround
by vicente.botet 21 Mar '13

21 Mar '13

Hi, in order to make easier the introduction of constexpr in a portable way I would like we add a Boost Config workarround. We can define some macros depending on whether BOOST_NO_CONSTEXPR is defined or not. #if defined(BOOST_NO_CONSTEXPR) #define BOOST_CONSTEXPR #define BOOST_CONSTEXPR_OR_CONST const #else #define BOOST_CONSTEXPR constexpr #define BOOST_CONSTEXPR_OR_CONST constexpr #endif For most of the constexpr functions or constructors BOOST_CONSTEXPR will work. constexpr tuple(); =versus= BOOST_CONSTEXPR tuple(); When used for static constants BOOST_CONSTEXPR_OR_CONST is needed as we need to preserv the const keyword when consexpr is not available. static constexpr UIntType xor_mask = a; =versus= static BOOST_CONSTEXPR_OR_CONST UIntType xor_mask = a; We could also add a STATIC_CONSTEXPR macro #define BOOST_STATIC_CONSTEXPR static BOOST_CONSTEXPR_OR_CONST static constexpr UIntType xor_mask = a; =versus= BOOST_STATIC_CONSTEXPR UIntType xor_mask = a; For this case the existing macro BOOST_STATIC_CONSTANT could be modified to use BOOST_CONSTEXPR_OR_CONST when static const was used. static constexpr UIntType xor_mask = a; =versus= BOOST_STATIC_CONSTANT(UIntType, xor_mask = a); Can we introduce this workaround? Best regards, Vicente _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

6 17

[parameter] std proposal
by Lorenzo Caminiti 07 Jan '13

07 Jan '13

Hello all, Is there a C++ standard proposal for named parameter addition? I am looking for an "N-paper" for named parameters similar to N2081 for concepts, or N1962 for contracts. Thank you. -- Sent from my mobile device Lorenzo

6 8

[#pragma once]
by Sid Sacek 18 Nov '12

18 Nov '12

I've worked with the MSVC, Sun and GCC compilers. Each one of them supports #pragma once. Is there any reason to wrap this pragma within #ifdefs? Are there any compilers out there today that don't support this #pragma? #if defined( _MSC_VER ) && ( _MSC_VER >= 1020 ) # pragma once #endif Could we change this coding pattern so that it no longer looks like MSVC is being selfish? -Sid Sacek

17 20

[config] explicit call of operator templates / msvc bug workaround
by Stefan Strasser 10 Oct '12

10 Oct '12

Hi, is there already a macro in Boost.Config that allows you to insert the "template" keyword in the following code for those compilers that require it? struct functor{ template<class T> void operator()(); }; template<class F> void g(F f){ f.template operator()<int>(); //(1) works with GCC and comeau f.operator()<int>(); //(2) works with MSVC } this apparently only applies to operator calls. MSVC accepts both (1) and (2) for regular functions. (instantiating the operator template with an object of type T as argument, like mpl::for_each does, is not an option. I can't construct T.) thanks, Stefan

6 10

status of sp_counted_base_solaris.hpp
by Graham Bennett 07 Jun '12

07 Jun '12

Hi all, I'm interested in getting boost::shared_ptr to use atomic ops on Solaris. I notice there is an implementation using the OS-provided atomics in boost/detail/sp_counted_base_solaris.hpp, but it doesn't seem to be included. According to this thread: http://lists.boost.org/Archives/boost/2006/07/107144.php, it seems the reason might be that it wasn't possible to come up with a proper preprocessor condition to include it on the right versions of Solaris. I'm considering modifying my boost installation to include this header on Solaris - does anyone know of any issues with the code, or can they confirm that it has been well tested? Are there any other reasons for its omission? Thanks, Graham -- Graham Bennett

4 7

[interprocess] message_queue hangs when another process dies
by Sergei Politov 03 Nov '11

03 Nov '11

Hi, I have found the following problem with message_queue on win32 (MSVC 2008 + Windows Vista). Suppose we have 2 processes, one sends messages to queue, another reads them. When reading process dies (for instance using End process) during message_queue.receive the another process hangs in send. As I found during investigation, it tries to lock interprocess mutex, but it is already locked by dead process. So this message queue instance becomes unusable. I attached the example. Steps to reproduce: 1) Start "mq.exe s" (i.e. with argument s) It outs: sender: $PID 2) Start mq.exe without arguments. It outs: receiver: $PID 0 1 2 3 4 This time sender outs: send done: 3) At this point the message queue is empty and receiver waits for messages. End it with Task Manager. 4) Enter some number in sender console and press Enter. 5) The sender hangs in message_queue.send Best Regards, Sergei

6 13

Build trunk 1.46 libraries problems
by Paul A. Bristow 04 Oct '11

04 Oct '11

I've just updated trunk, and note that version.hpp has been updated to 1.46. When I try to link previous tests, I get messages like LINK : fatal error LNK1104: cannot open file 'libboost_test_exec_monitor-vc100-mt-sgd-1_46.lib' But when I try to rebuild the libraries, they are all still *1.45.* :-( my log file is attached. I also note some config failures that suggest something else may be wrong? ...updating 1 target... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_gcc_visibility.obj has_gcc_visibility.cpp libs\math\config\has_gcc_visibility.cpp(7) : fatal error C1189: #error : "This is a GCC specific test case". call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-mul ti\has_gcc_visibility.obj.rsp" ...failed compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_gcc_visibility.obj... ...failed updating 1 target... Performing configuration checks - ../config//has_gcc_visibility builds : no ...found 47 targets... ...updating 1 target... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\math\config\msvc-10.0\debug\threading-multi \has_long_double_support.obj has_long_double_support.cpp ...updated 1 target... - ../config//has_long_double_support builds : yes ...found 15 targets... ...updating 4 targets... compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-multi \has_icu_test.obj has_icu_test.cpp libs\regex\build\has_icu_test.cpp(12) : fatal error C1083: Cannot open include file: 'unicode/uversion.h': No such file or directory call "C:\Program Files\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86 >nul cl /Zm800 -nologo @"i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti\has_icu_test.obj.rsp" ...failed compile-c-c++ i:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-multi \has_icu_test.obj... ...skipped <pi:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti>has_icu.exe for lack of <pi:\boost-trunk\boost\bin.v2\libs\regex\build\msvc-10.0\debug\threading-mul ti>has_icu_test.obj... ...failed updating 1 target... I've tried changing boost_root and boost-build environment variables to 1.46 but makes no difference. Suggestions. Thanks. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

4 7

[serialization] or [spirit] JSON Archives
by Fernando Pelliccioni 08 Sep '11

08 Sep '11

Hi, After experimenting with Spirit.Qi to make a JSON parser, I had the need for a serializer. First, I thought I could serialize my model of JSON (json:: value, json: object, etc.), but that was not compatible with boost::serialization. I am currently writing a ARCHIVE for Boost Serialization, but I'm finding some problems in order to implement JSON correctly. The question is, does anyone know about some files to Boost Serialization already finished? I've seen the Archive made by Esteve Fernandez, but do not serve my purpose, because I just need JSON. I would like to develop a JSON parser which in turn is a compatible Boost Serialization serializer . Any ideas? Thanks and regards, Fernando Pelliccioni.

5 6

[Opaque] Request for interest in Opaque typedefs library emulation
by vicente.botet 27 Jul '11

27 Jul '11

Hi, I have started to play with a class to define opaque typedefs on funcdamental types. It is based on the C++ proposal " Progress toward Opaque Typedefs for C++0X" by Walter E. Brown http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1891.pdf and http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1706.pdf Please take a look on the preceding links to understand the motivation. Boost.Sericalization provide a BOOST_STRONG_TYPEDEF already, but in my opinon the implementation is not complete,as only the order operators are defined (But maybe I'm wrong). Evidently it can not provide everything we can have with a language approach, but IMO this could yet be useful. The library include two class templates (CRTP) to define opaque types: * public_opaque_type<OT,UT> : implicit conversion from OT to UT * private_opaque_type<OT,UT> : no conversion from OT to UT An opaque type (OT) is a new type, different from the underlying type (UT) and other OT. It defines explicit constructor from the UT, and defines all the operators the UT support but this time applied to the OT. To define a new OT with this mixin classes struct serial_number: public_opaque_type<serial_number, unsigned> { BOOST_OPAQUE_PUPLIC_FORWARD_CONSTRUCTORS(serial_number,unsigned); }; struct game_score: private_opaque_type<game_score, unsigned> { BOOST_OPAQUE_PRIVATE_FORWARD_CONSTRUCTORS(game_score,unsigned); }; In addition, defines macros that make this simpler BOOST_OPAQUE_PUBLIC_TYPEDEF(unsigned, serial_number); BOOST_OPAQUE_PRIVATE_TYPEDEF(unsigned, game_score); Next follows the definition of the public_opaque_type template <typename Final, typename T> class public_opaque_type : boost::totally_ordered< Final , boost::integer_arithmetic< Final , boost::bitwise< Final , boost::unit_steppable< Final , boost::totally_ordered< T, Final // public specific conversions , boost::integer_arithmetic< T, Final // public specific conversions , boost::bitwise< T, Final // public specific conversions > > > > > > > { protected: T val_; typedef public_opaque_type opaque_type; public: typedef T underlying_type; explicit public_opaque_type(const T v) : val_(v) {}; public_opaque_type() {}; public_opaque_type(const opaque_type & rhs) : val_(rhs.val_) {} public_opaque_type & operator=(const opaque_type & rhs) { val_ = rhs.val_; return *this; } public_opaque_type & operator=(const T rhs) { val_ = rhs; return *this; } T const& underlying() const { return val_; } T& underlying() { return val_; } operator const T & () const { return val_; } operator T & () { return val_; } #if 0 bool operator==(const opaque_type & rhs) const { return val_ == rhs.val_; } #endif bool operator<(const Final & rhs) const { return val_ < rhs.val_; } Final& operator+=(const Final & rhs) { val_ += rhs.val_; return static_cast<Final&>(*this); } Final& operator-=(const Final & rhs) { val_ -= rhs.val_; return static_cast<Final&>(*this); } ... }; I have started to make some tests and it works well for the moment. Limitations: * As we can not specialize the behaviour of static_cast/dynamic_cast the library sould provide two specific casts opaque_static_cast and opaque_dynamic_static_cast (Not yet implemented). * As operator.() can not be overloaded, it works transparently only for underlying types that don't defines member functions (C++ fundamental types, as int, char, ...). For the others an explicit use of the underlying() member function is needed :( * Others I have not catched yet :( Do you think it is worth continuing? Please, let me know if you see a error on the design. _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

4 8

[filesystem] home_directory_path
by Jeff Flinn 24 Jul '11

24 Jul '11

In looking at implementing a portable home_directory_path function a few questions arise. Based on http://en.wikipedia.org/wiki/Home_directory, POSIX and other UNIX flavors 'appear' to be a straight forward use of the "HOME" environment variable. Does anyone have any experience where the "HOME" variable is not the proper source of the user's home directory? Windows NT and above have the "USERPROFILE" environment variable. Using this would be the easiest to use. But I've seen discussion that this may not always be properly defined, in particular if the user has reset their home directory to a non-system drive. I haven't tracked down it's availability on WinCE. Does anyone have experience with this platform? There is the windows GetUserProfileDirectory api function also available since NT4. This is in the Userenv.lib/dll, obviously adding a link dependancy. How are these sorts of system link dependencies handled? Through bjam? Or is it acceptable/better to use #pragma comment(lib,"Userenv.lib")? In looking at some client code using home_directory_path, I see that they generally are looking for the user's Desktop directory(Mac & Windows). Obviously this only makes sense on GUI platforms. The issue with merely getting this path via home_directory_path() / "Desktop" is IIRC, that at least on windows "Desktop" is localized and may not exist with that name on non-english localized systems. Windows has the SHGetFolderPath api. I need to look into Mac's native support. Any thoughts on the general usefulness of a portable desktop_directory_path? Thanks, Jeff

16 60

[BGL] Contribute to the Boost Graph Library
by Camillo Anania 15 Jul '11

15 Jul '11

Hi all, I used BGL for around 6 months for my thesis (write a routing algorithm). I highly appreciate the BGL and I'm glad someone did it and generously gives their time to maintain/improve it. So now I would like to contribute to the development of the library and so give back something. Just a brief introduction to my profile: - a bachelor and a master in Computer Engineering - six months of experience using the BGL - good knowledge of C++ - great wish to improve my programming skills and master generic programming technique Can you please indicate me the steps I should do to start to actively help the development process? Thanks Camillo Anania

3 4

[mpl] string to type conversion
by Bartosz Marcinkiewicz 19 Jun '11

19 Jun '11

Hello, I would like to have a macro which could be used like this: STRING_TO_TYPE( MyType ) which would yield: typedef mpl::string<'M','y','T','y','p','e'> MyType_id_t; Any ideas how to implement something like that? Thanks for any help, bma. -- Bartosz Marcinkiewicz tel. (+48) 516 034 243 e-mail: bma(a)epcon.pl, bartosz.marcinkiewicz(a)epcon.pl EPCON Sp. z o.o. www.epcon.pl adres: 53-407 Wrocław, ul. Gajowicka 114/116 tel. (+48) 71 361 75 55 ext.36 fax (+48) 71 361 74 44 NIP PL 899-24-92-498 KRS 0000190187 REGON 932963731 Kapitał zakładowy: 500 000 PLN

4 4

[Config] Big changes in C++0x detection...
by John Maddock 31 May '11

31 May '11

Just a heads up, that the latest Boost.Config changes: * Remove the concept related macros. * Tighten up most of the C++0x related tests, with the result that some C++0x features that were previously enabled are no longer - this may also cause the Boost.Config tests to fail on some platforms. * Some C++0x features that were not previously enabled are now - because they were passing the Boost.Config tests - there's at least one case where this is causing regressions in other libraries - if any more pop up please let me know ASAP! Thanks for your patience! John.

9 34

boost-test, why is there no DOUBLES_EQUAL?
by Sebastian Nowozin 31 May '11

31 May '11

Hello, I am a regular user of the boost test library, having used CPPunit before. I miss the following macro: BOOST_CHECK_DOUBLES_EQUAL(first, second, absolute_tolerance); which would check whether "std::fabs(first-second) <= absolute_tolerance" is true. It seems the boost test library does not support it, and instead forces/encourages users to use BOOST_CHECK_CLOSE(first, second, percent_relative_tolerance); The above macro does not really make sense in my application, I really need to check for absolute tolerances, irrespectively of the magnitude of the numbers. CPPunit has this feature as DOUBLES_EQUAL. Would you consider adding this? Thanks, Sebastian

9 16

Re: [boost] [date_time] Time zone improvements
by Rutger ter Borg 25 May '11

25 May '11

Jeff Garland wrote: > Very cool :-) One question -- is there a portable solution where a user > could deploy a files onto a Windows system or is it a Unix only solution? > I'm fine with incorporating a *nix only solution because what your > suggesting will be a nice solution for *nix platforms, but it will need to > be clear that it's not portable. I don't see why it wouldn't be possible to deploy the (big-endian) binary files to any platform. Getting it into this binary form (using zone info compiler zic) may be harder to do cross-platform, but cygwin may help here. [snip] > As the primary maintainer of Boost date-time I can say with certainty that > there is interest in this functionality -- it's long been on my todo list > and I haven't had time to get to it. You can email me privately and we > can discuss all the details of how to get your code incorporated. I'll do! Regards, Rutger

5 9

[Review] Type Traits Extension by Frederic Bron - Review summary and decision
by Joel Falcou 23 May '11

23 May '11

Hello all, Frederic Bron's type traits extension proposal review ended up last week. In so far, we received SEVEN reviews which are all voting YES for the inclusion of Type Traits extension in Boost. So the result is that the Type Traits Extension is ACCEPTED into Boost. Suggestions include: - some clean-up in the implementation like "Renam[ing] the detail classes inside the specific namespace without using number, i.e. with a clear meaning. The use of tag, tag 2 could be renamed check_pass, check_fail or something like that." - Sensibility on cv-ref qualifiers in traits call is important. This is being addressed by Frederic. - Frederic is OK to keep the detection of void as a valid return type by using some dont_check type as default. - small comprehensive example of some of the traits like a "maybe_print function, which prints a value if the appropriate operator<< ostream overload exists, else prints "<NOT PRINTABLE>". [...] a small example like this would show a practical use of the library, and how to make use of enable_if, or some other overload method." - The main recurring suggestions found was the choice of name for the operator traits with respect to the standard naming, naming in proto and other boost libraries. This topic is still hot and alive. An alternative to the naming scheme consensus was proposed in the form of alias of commonly used operator traits. This issue is I think beyond bikeshed-color argumentation and I think it is a good point if Frederic could step up and provide a definite and rationalized answer to this point. The current status is : * the namespace options is out casue the standard didnt choose this way; * Frederic and a few other seems to favor the proto naming scheme (more or less the negate issue and the pre/post operator) * the question of a common prefix is still open * the std:: like naming seems limited as not all operators are there. Thanks to all reviewers and people participating to the discussions. Thanks to Frederic for his work.

18 67

Boost.Log status
by Vicente BOTET 23 May '11

23 May '11

Hi, what is going on Boost.Log? The library was accepted provisionally on March 2010 * Log - accepted provisionally March 2010; author: Andrey Semashev. Best, Vicente

7 18

[boostcon][proto] Suggestion for LIAW session: fixed-point numbers
by Ravi 19 May '11

19 May '11

Hi, Are there any proto-based ideas for the library-in-a-week sessions? If not, would building a fixed-point data type be of interest? The domain is narrow enough that something useful can be accomplished in 4 sessions, but of large enough scope to present opportunities for exploring proto in depth. A fairly simple design follows representing a number: fixed_number<int width, int ulp, // 2^{ulp} is the smallest increment possible bool signed, template assigner<first, last, signed> > 'assigner' handles rounding/truncation/wrapping/etc when assigning another number (floating-point or fixed-point) to the current one. Internally, each fixed-point number would be represented by a boost::uint64_t or a boost::int64_t (limiting the maximum precision allowed). As an example, fixed_number<5, -3, false> would represent a data type that would go from 0 to 3.875 in steps of 0.125. Proto would be used for creating all arithmetic operations since the return type of a+b could be different from the type of either a or b. A bonus would involve getting the fixed-point data type to play well with std::complex (and, yes, I am aware that std::complex is not designed to work with anything other than double and float, and will require specialization in the std namespace). If there is sufficient interest, I could even provide a starting point with +,-,* implemented; / would take more time. The design above is intended as a starting point for discussion and I am most definitely not wedded to it. I am a tyro when it comes to proto, and hence would need someone with more proto expertise to guide the discussion. Regards, Ravi

8 24

[local] Help for the Alternatives section
by Lorenzo Caminiti 12 May '11

12 May '11

Hello all, I am updating Boost.Local docs and I could use a some help in getting the Alternatives section right http://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loca… . How can I program the following code (its local function and `factor` constant binding) using Boost.Phoenix, Boost.Lambda, and C++0x lambda functions? If you know, can you please reply with the actual code? #include <boost/local/function.hpp> #include <iostream> #include <vector> #include <algorithm> int main() { double sum = 0.0; int factor = 10; void BOOST_LOCAL_FUNCTION_PARAMS(double num, // Variable `factor` bound as constant. bind& sum, const bind& factor) { sum += factor * num; std::cout << "Summed: " << sum << std::endl; } BOOST_LOCAL_FUNCTION_NAME(add) std::vector<double> v(3); v[0] = 1.0; v[1] = 2.0; v[2] = 3.0; // Local function `add` passed as template parameter. std::for_each(v.begin(), v.end(), add); return 0; } Thank you very much! -- Lorenzo

14 82

[atomic] Status?
by vicente.botet 04 May '11

04 May '11

Hi, There are some libraries that would prefer to be reviewed after Boost.Atomic is reviewed, otherwise them should move the library as an internal detail of the implementation. Could the people working on Boost.Atomic tell us what is the state of the library? Which platforms have been handled? Which part of the standard has been implemented? Could others having knowledge in assembler participate in this project? When we can expect the library to be ready for review? Best, Vicente

10 20

accurate sum accumulator (kahan)
by Gaetano Mendola 27 Apr '11

27 Apr '11

Hi all, I had to implement in terms of boost accumulators the Kahan summation algorithm. I will paste at the end of this message the accumulator, the feature and the extractor source code. This accumulator reduces the numerical error obtained with standard sequential sum, as example the sum of 1e6f elements equal to 1e-6f should give 1.0f, this is the results obtained with sum and sum_kahan: tag::sum: 1.009038925 tag::sum_kahan: 1.000000000 I'm not sure if that sum_kahan is worth to be inserted in the accumulators provided with boost, I'm not an expert of boost:accumulators (I just followed the guide to make this new accumulator) so not sure if you prefer to have a fast_sum and an accurate_sum instead of sum and sum_kahan. Regards Gaetano Mendola // File kahan_sum.hpp #ifndef KAHAN_SUM #define KAHAN_SUM #include <boost/accumulators/framework/accumulator_base.hpp> #include <boost/accumulators/framework/parameters/sample.hpp> #include <boost/numeric/conversion/cast.hpp> namespace boost { namespace accumulators { namespace impl { template<typename Sample> struct sum_kahan_accumulator : accumulator_base { typedef Sample result_type; template<typename Args> sum_kahan_accumulator(Args const & args) : sum(args[sample | Sample()]), compensation(boost::numeric_cast<Sample>(0.0)) { } template<typename Args> void operator ()(Args const & args) { const Sample myTemp1 = args[sample] - this->compensation; const Sample myTemp2 = this->sum + myTemp1; this->compensation = (myTemp2 - this->sum) - myTemp1; this->sum = myTemp2; } result_type result(dont_care) const { return this->sum; } private: Sample sum; Sample compensation; }; }}} namespace boost { namespace accumulators { namespace tag { struct sum_kahan : depends_on< > { typedef impl::sum_kahan_accumulator< mpl::_1 > impl; }; }}} namespace boost { namespace accumulators { namespace extract { extractor< tag::sum_kahan > const sum_kahan = {}; } using extract::sum_kahan; }} #endif

21 68