November 2011 - Boost - lists.preview.boost.org

Re: [boost] [optional] std::tr2::optional
by Andrzej Krzemienski 19 Nov '11

19 Nov '11

> > 3. T is neither copyable nor moveable -- it is like a scope guard, or > > boost::scoped_ptr. In this case optional<T> still provides assignment by > > making a "pseudo destructor call" followed by a call to placement new. -- > > but this gives only basic guarantee. > The guarantee is strong if the placement delete/new are marked > noexcept, isn't it? What I meant by "a >>pseudo destructor call<< followed by a call to placement new." is a call to destructor w/o releasing the memory and then a call to constructor w/o allocating memory: ob.~T(); new (&ob) T( std::forward<Args>(args)... ); This trick will provide a strong guarantee if destructor and the constructor are nothrow. While destructors usually are non-throwing, it is rather unlikely that constructors would not throw: it is the constructors that we often expect to throw in case of initialization failure. Regards, &rzej

1 0

[inteprocess] Using named_mutex on Windows 7
by Edward Diener 19 Nov '11

19 Nov '11

I wrote a program more than 3 years ago where I used boost::interprocess_named_mutex to protect more than one instance of the same process from running the same sequence of code at the same time. The program appears to run fine under Windows XP and Windows Vista but occasionally locks up waiting for the locked mutex to unlock on Windows 7. The code looks like this: ------------------------------------------------------------------- boost::interprocess::named_mutex cmutex(boost::interprocess::open_or_create_t(),"MyMutexName"); { boost::interprocess::scoped_lock<boost::interprocess::named_mutex> cscoped(cmutex); // Code here which must be run one at a time. } ------------------------------------------------------------------- Under Windows 7 the code occasionally hangs on the scoped_lock instantiation, which of course I can not have. I notice there is a file in the temporary directory ( TMP or TEMP environment variable ) which is being used by interprocess, and after that file is manually deleted, the program no longer hangs on the scoped_lock instantiation. Is there a reason for this problem on Windows 7 ? I know that Windows 7 has global and local named mutexes and only by prefacing a named mutex name with global\ is the mutex truly global. I do not know if this is causing the problem on Windows 7. It does seem as if something in the file in the temporary directory is telling inteprocess that "MyMutexName" is still locked when the hangup occurs, but I would have expected that when acoped_lock goes out of scope, it handles resetting that file to the correct state. I wonder if this has something to do with UAC/file permissions in Windows 7, where the process somehow can no longer write to the file in the temporary directory afte creating it. Is this a known interprocess problem, perhaps fixed in a later release ? I wrote my code before Windows 7 even came out, recompiled it for Windows 7, but did not update the version of Boost I was using for the program ( Boost 1.35 ). Maybe I need to do that ? I would certainly be willing to do that if I knew that this was a problem with interprocess in Boost 1.35 that has subsequently been fixed in a later version of Boost.

1 0

[signals] Compiler error
by "Claas H. Köhler" 18 Nov '11

18 Nov '11

Hi everybody! When compiling boost 1.48.0 using gcc-4.6 and the "--std=c+0x" option, I get the following error message: libs/signals/src/named_slot_map.cpp: In member function ‘void boost::signals::detail::named_slot_map::disconnect(const boost::signals::detail::stored_group&)’: libs/signals/src/named_slot_map.cpp:99:48: error: conversion from ‘std::list<boost::signals::detail::connection_slot_pair>::const_iterator {aka std::_List_const_iterator<boost::signals::detail::connection_slot_pair>}’ to non-scalar type ‘boost::signals::detail::slot_pair_iterator {aka std::_List_iterator<boost::signals::detail::connection_slot_pair>}’ requested The reason seems to be that std::map's erase function expects a std::map::iterator in the old standard (according to cplusplus.com) while c++11 seemingly requires a std::map::const_iterator as argument (see section 23.4.4.1). Thus replacing line 105 OLD groups.erase(group); NEW groups.erase( static_cast<const_group_iterator>(group) ); and line 128 OLD if (empty(g)) groups.erase(g++); NEW if (empty(g)) groups.erase( static_cast<const_group_iterator>(g++); solves the problem for me. Is it intended to have all boost libraries conforming with C++11? Regards Claas

1 0

date_time using CPU performance counter
by Kenneth Porter 18 Nov '11

18 Nov '11

I need high precision under Windows XP but don't need long-term date accuracy. To that end, I think it would be useful to have a microsec_clock implemented in terms of the Windows QueryPerformanceCounter API (which wraps a CPU register query) instead of the GetSystemTimeAsFileTime API (which is only good to 15 msecs and almost guarantees a context switch). Has anyone attempted this? How hard is it to code up a new clock source to fit into the Boost date_time design?

3 3

multi_array and concept check
by Ivan Sorokin 17 Nov '11

17 Nov '11

Hello! Currently it is not possible to pass shape() of one multi_array into constuctor of another: boost::multi_array<float, 2> a; boost::multi_array<float, 2> b(a.shape()); This is because shape() returns size_t const* and multi_array check in constructor that ExtendList satisfy CollectionConcept. size_t const* don't satisfy this concept. I'm going to allow constructor of multi_array to get both size_t const* and size_t const[]. So I'm going to replace extents.begin() with boost::begin(extents). What should I do with concept check?

1 0

Boost.Local Review
by Pierre Morcello 17 Nov '11

17 Nov '11

Hello Boost community, Here is my review of the local function library. - What is your evaluation of the design? The design is clear. Several iterations were done already to come to what it is today. Of course no one is particularly fond of macros, but a huge work was done to reduce the potential problems and on the other hand the library can really help a lot. - What is your evaluation of the implementation? I did not get too much into the current implementation. I dug it almost one year ago, but there were changes since then. The implementation is correct given the features of the library (use of 'this', functor,, name,...). If there were less features, then some optimisations would have been possible (example : not use a virtual function, not use a functor). But the library would in that case have fewer cases of use. I know how the first verion of Lorenzo worked but I did not check the latest. Given the current features, I don't see how to do even better than what Lorenzo did. So I am happy with the implementation. - What is your evaluation of the documentation? I really appreciate the detailled documentation. On a 'merchandising note', the first page is too big. I think this could 'afraid' some new readers. Introduction + an 8-line motivating example should be enough to appeal (or not) the new reader. I am happy to review a submitted library with a complete documentation (that does not always happen). - What is your evaluation of the potential usefulness of the library? This library is filling a few strong needs. Several users including myself needed local function and const block. I am lazy when it comes to functors, I also find this library is pretty nice to make them quick. C++11 will on that last part change it , but const block are a must have in my opinion which are not available in C++11. The local function can greatly reduce the presence of internal functions in ".h", and thus make the interfaces much better in some cases. - Did you try to use the library? With what compiler? Did you have any problems? I use regularly this library on VC9, but mostly for local function. As I don't try to push the limits, I did not come into problems. - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I have followed Lorenzo work since his proposition. At the beginning I followed it much more closely, but right now I dont' have the time to redo an in depth study. I use a previous version of Lorenzo library regularly. So for the review, I simply had a glance. But I already read the documentation in detail several month ago. - Are you knowledgeable about the problem domain? I implemented a my own version of local functions for boost almost 2 years ago I think. - Boost.Local's local exits provide the same functionality (and then some) as Boost.ScopeExit. Does this duplication of functionality need to be dealt with, and if so, how? I think it's important to check if the author are ok with merging or not. Obviously Lorenzo is very motivated and gives great feedback on his works with boost. Just make sure this won't hurt his motivation ? Because then there are the question of maintening the libraries which is not always the easiest. I am ok if one replace the other. - Do you vote for the library? Yes, I vote for its admission. I also want to add that I am amazed by the overall results in term of quality that Lorenzo was able to get with this library. Lorenzo is constently gathering the users needs and updating his library in that way. Like a marathonian. Very inspiring! Best regards, Pierre Morcello -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Local-Review-tp4078276p4078276.html Sent from the Boost - Dev mailing list archive at Nabble.com.

4 5

[context] update
by Oliver Kowalke 17 Nov '11

17 Nov '11

Hi, a new updated version is available. src: http://github.com/olk/boost.context docu: http://ok73.ok.funpic.de/boost/libs/context/doc/html/index.html next step mini-review? so long, Oliver

1 0

Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)
by Jeffrey Lee Hellrung, Jr. 17 Nov '11

17 Nov '11

Hi all, It is time! The review of Lorenzo Caminiti's proposed Boost.Local library begins tomorrow, ***November 10, 2011***, and ends on ***November 19, 2011***. Boost.Local implements local functions, local blocks, and local exits for the C++ programming language. It allows one to define a function at any declarative scope, including function scope; bind variables from the enclosing scope; and pass this function to templated STL-style algorithms. Please see the Introduction of the documentation for a longer but still brief overview. -------- The code and documentation are available from the Boost sandbox ( https://svn.boost.org/svn/boost/sandbox/) https://svn.boost.org/svn/boost/sandbox/local/ [everything] https://svn.boost.org/svn/boost/sandbox/local/boost/ [code] https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/index.htm… -------- Please state clearly whether you think this library should be accepted as a Boost library. Other questions you may want to consider: - 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? Please also consider the following issues and proposals specific to Boost.Local. Your opinion is welcome on any or all of these. - Boost.Local's local exits provide the same functionality (and then some) as Boost.ScopeExit. Does this duplication of functionality need to be dealt with, and if so, how? - Lorenzo is proposing to add boost::local::function::overload to Boost.Function as boost::function::overload. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to boost/utility. See https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… -------- Lastly, please note that Boost.Local has included a copy of the Variadic Macro Data (VMD) library in boost/detail/preprocessor/variadic_macro_data. Since then, VMD has been modified and integrated into Boost.Preprocessor. After the review has concluded, Lorenzo will remove this local copy of the VMD library and replace its usage within Boost.Local with the Boost.Preprocessor variadic extensions. -------- Thanks in advance to all who participate in the review discussion; I'm looking forward to it! - Jeffrey Hellrung (Review Manager) - Gregory Crosswhite (Review Assistant)

7 21

Alternative implementation for BOOST_PP_VARIADIC_SIZE
by Gennadiy Rozental 17 Nov '11

17 Nov '11

Hi, Current implementation of subject macro have a very serious shortcoming - it does not work for empty __VA_ARGS__. After googling around a bit for some ideas I came up with the following alternative: #include <boost/preprocessor/arithmetic/mul.hpp> #include <boost/preprocessor/arithmetic/sub.hpp> #include <boost/preprocessor/punctuation/comma.hpp> #define MY_VA_ARG_N( \ _1, _2, _3, _4, _5, _6, _7, _8, _9,_10, \ _11,_12,_13,_14,_15,_16,_17,_18,_19,_20, \ _21,_22,_23,_24,_25,_26,_27,_28,_29,_30, \ _31,_32,_33,_34,_35,_36,_37,_38,_39,_40, \ _41,_42,_43,_44,_45,_46,_47,_48,_49,_50, \ _51,_52,_53,_54,_55,_56,_57,_58,_59,_60, \ _61,_62,_63, N, ...) N #define MY_VA_RSEQ_N() \ 63,62,61,60, \ 59,58,57,56,55,54,53,52,51,50, \ 49,48,47,46,45,44,43,42,41,40, \ 39,38,37,36,35,34,33,32,31,30, \ 29,28,27,26,25,24,23,22,21,20, \ 19,18,17,16,15,14,13,12,11,10, \ 9, 8, 7, 6, 5, 4, 3, 2, 1, 0 #define MY_DO_VA_NARG2(...) MY_VA_ARG_N __VA_ARGS__ #define MY_DO_VA_NARG(...) MY_DO_VA_NARG2(( __VA_ARGS__ )) // this version produces incorrect value (1) for empty __VA_ARGS__ #define MY_VA_NARG_(...) MY_DO_VA_NARG(__VA_ARGS__, MY_VA_RSEQ_N()) // this version fixes it #define MY_VA_NARG(...) BOOST_PP_SUB( BOOST_PP_MUL( MY_VA_NARG_( __VA_ARGS__ ), 2 ), MY_VA_NARG_( BOOST_PP_COMMA __VA_ARGS__ () ) ) This version work for zero sized __VA_ARGS__ and also works for MSVC-9,10 , gcc-4.1 gcc 3.2 (did not test with other compilers). Does it make sense to improve trunk version? Regards, Gennadiy

7 39

[1.48.0] Can't build any PDF docs
by John Maddock 16 Nov '11

16 Nov '11

I'm trying to build the PDF docs for 1.48 but all attempts to build PDF's on both Trunk and release branches fails with errors such as: bjam pdf M:/data/boost/trunk/tools/build/v2/tools\boostbook.jam:649: in object(boostbook-generator)(a)49.run from module object(boostbook-generator)@49 error: Cannot build documentation type 'pdf' M:/data/boost/trunk/tools/build/v2/build\generators.jam:1004: in try-one-generator-really from module generators M:/data/boost/trunk/tools/build/v2/build\generators.jam:1066: in try-one-generator from module generators M:/data/boost/trunk/tools/build/v2/build\generators.jam:1282: in construct-really from module generators M:/data/boost/trunk/tools/build/v2/build\generators.jam:1366: in generators.construct from module generators M:/data/boost/trunk/tools/build/v2/build\targets.jam:1495: in construct from module object(typed-target)@776 M:/data/boost/trunk/tools/build/v2/build\targets.jam:1297: in object(typed-target)(a)776.generate from module object(typed-target)@776 M:/data/boost/trunk/tools/build/v2/build\targets.jam:732: in generate-really from module object(main-target)@782 M:/data/boost/trunk/tools/build/v2/build\targets.jam:704: in object(main-target)(a)782.generate from module object(main-target)@782 M:/data/boost/trunk/tools/build/v2/build\targets.jam:258: in object(project-target)(a)772.generate from module object(project-target)@772 M:/data/boost/trunk/tools/build/v2\build-system.jam:736: in load from module build-system M:\data\boost\trunk\tools\build\v2/kernel\modules.jam:283: in import from module modules M:\data\boost\trunk\tools\build\v2\kernel\bootstrap.jam:142: in boost-build from module M:\data\boost\trunk\boost-build.jam:17: in module scope from module Nothing has changed in my user-config.jam, and I've updated to the latest bjam executable. Any ideas on what broke? Thanks, John.

2 3

Boost.Random.uniform_01 gives different number sequence in Boost 1.37 and Boost 1.45
by Martin.Sovik＠Emerson.com 16 Nov '11

16 Nov '11

Hi. It seems that uniform_01 generates different number sequences in version 1.37 and 1.45 Is this intentional, or is it a bug? This short program #include <iostream> #include "boost/random/mersenne_twister.hpp" #include "boost/random/uniform_01.hpp" int main() { boost::mt19937 random_generator(4315); boost::uniform_01< boost::mt19937, double > uniform_generator(random_generator); std::cout<<"Generating uniform distribution using Boost 1.45"<<std::endl; for (int i=0; i<10;++i) { std::cout<<uniform_generator()<<std::endl; } return 0; } Compiled with the two versions, gives the respective output: D:\dev\test_bed>uniform_dist_boost_1_37 Generating uniform distribution using Boost 1.37 0.239136 0.920749 0.889477 0.208172 0.169688 0.636659 0.78322 0.915117 0.25697 0.358218 D:\dev\\test_bed>uniform_dist_boost_1_45 Generating uniform distribution using Boost 1.45 0.306389 0.511291 0.496429 0.156168 0.910315 0.644836 0.331514 0.558632 0.723934 0.998796 As far as I can tell, Boost.mt19937 gives the same number sequence in both cases, but the output from Boost.uniform_01 differs. This topic has been briefly touched in the thread [boost] Random numbers question<154235.php> Anant Rao (2009-07-24 18:47:31) Where it seems like Rao got different numbers even between Boost 1.38 and Boost 1.39 We use Boost 1.37 in the previous release of our software, and Boost 1.45 in the current, and we have received a bug report from one of our clients that our current release has different behaviour. Is there any way to fix this, other than use the 1.37 version of Boost.uniform_01? Thanks, Martin Søvik

2 1

Re: [boost] [1.48.0] Release candidates available
by Tom Kent 16 Nov '11

16 Nov '11

> Release candidate files for 1.48.0 are available at http://boost.cowic.de/rc/ > > md5sum on the originals: > > 7dd95e71c43ddd35997d9f2346e7f567 *boost_1_48_0.7z > d1e9a7a7f532bb031a3c175d86688d95 *boost_1_48_0.tar.bz2 > 313a11e97eb56eb7efd18325354631be *boost_1_48_0.tar.gz > b08fda829eec96b4f1071ce2ea6831f5 *boost_1_48_0.zip > > 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. > > Thanks, > > --The release managers On a windows 7 - 32 bit VM, I built: msvc-8.0 msvc-8.0 - address-model=64 msvc-9.0 msvc-9.0 - address-model=64 msvc-10.0 msvc-10.0 - address-model=64 All builds were successful. I was able to smoothly link and run with the binaries on windows 7 32 or 64 (depending on the library build). Tom Kent

1 0

[program_options] Improving error text in exceptions
by Leo Goodstadt 16 Nov '11

16 Nov '11

On 15 November 2011 09:08, Vladimir Prus <vladimir(a)codesourcery.com wrote: > > Leo Goodstadt wrote: > > I would very much like to make the error messages in program_options > > exceptions more consistent and informative. > > I've looked over the error messages you have proposed, and I think it's > an overall improvement. I would appreciate patch to make this change. > Thanks! Cool. Will do that. The error messages meant for programmers I shall leave alone. This exercise is so tedious that I doubt anyone else is going to do more than tinker with the message text so I am keen to do an exhaustive job. As I mentioned, for command line messages, <option '--foo_bar' is ambiguous> seems much clearer than than <option 'foo_bar' is ambiguous>. However, it would be inappropriate to add "--" to config file and dos style options. The easiest thing would be to add a "prefix" parameter to the set_option_name() functions in errors.hpp These are called inside store() in variables_map.cpp. To add "--" or "/" prefixes as appropriate, is it sufficient to look at basic_option::original_tokens and basic_option::string_key? A) Use no prefix if original_tokens[0] is unprefixed, B) Use the parsed prefix (original_tokens[0]) if basic_option::string_key.length() = 1 C) Prefer "--" for long option names The same logic would apply to 1) exceptions thrown from cmdline::finish_option() in cmdline.cpp 2) options_description::find() (in options_description.cpp) called from store() (in variables_map.cpp) 3) options_description::find_nothrow() (in options_description.cpp) called from cmdline::run(), cmdline::finish_option(), parse_short_option(), and parse_disguised_long_option() (in cmdline.cpp) (Despite its name, find_nothrow() can throw()!) The difficult case is supporting the correct prefix for "required_option" in variables_map::notify() (variables_map.cpp). I propose that where missing options can be specified in both configuration file and on the command line, the command line should take precedence, and "--option_name" displayed in the error message. To support this, "basic_parsed_options" needs an extra prefix field, which would be set appropriately by basic_command_line_parser<charT>::run(). Does this make sense? Thanks, Leo -- Leo Goodstadt University of Oxford, UK

2 1

[1.48.0] Release candidates available
by Beman Dawes 16 Nov '11

16 Nov '11

Release candidate files for 1.48.0 are available at http://boost.cowic.de/rc/ md5sum on the originals: 7dd95e71c43ddd35997d9f2346e7f567 *boost_1_48_0.7z d1e9a7a7f532bb031a3c175d86688d95 *boost_1_48_0.tar.bz2 313a11e97eb56eb7efd18325354631be *boost_1_48_0.tar.gz b08fda829eec96b4f1071ce2ea6831f5 *boost_1_48_0.zip 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. Thanks, --The release managers

13 17

Re: [boost] Boost.Local Review - comments by Andrzej
by Andrzej Krzemienski 15 Nov '11

15 Nov '11

> > One suggestion for the future, although I am not sure how useful it would > > turn out in practice is to have something like local expression, or even > > not necessarily a local one. This would be a function whose body consists > > of a single expression. The benefit you get is that the programmer does not > > need to specify a return type for it (you can use BOOST_TYPEOF for that), > > or doesn't even have to type keyword 'return', but this may be too much off > > topic. > Can you clarify with an example? In C++11 lambdas do not require specifying the return type, provided that the body of the function is a single return statement: because it is easy to deduce the type from such single return statement. Similarly, for Boost.Local if a function body consists of a single return statement you could (I guess) provide a more simple syntax. Instead of BOOST_TYPEOF(sum) & BOOST_LOCAL_FUNCTION_PARAMS( double num, const bind factor, bind& sum ) { return sum += factor * num; } BOOST_LOCAL_FUNCTION_NAME(add); I could write: BOOST_LOCAL_EXPRESSION_PARAMS( double num, const bind factor, bind& sum ) BOOST_LOCAL_EXPRESSION_END( add, sum += factor * num ); You save me typing the return type and 'return' keyword. But now that I have written it down I do not think it is particularly useful. > I think in a nutshell the conclusion (which I will detail in the rest > of my comments below) was that Boost.Local is handy but on compilers > with C++11 lambdas you'd just use lambdas. At the same time, > Boost.Local allows you to write local functions that work also on > C++03 compilers and that have the same compile-time and run-time > performances of lambdas on C++11 compilers. So the /main/ audience > would be someone (like myself) that wants to do local function stuff > and expects lambda-like performances on C++11 but also has to deal > with C++03 compilers. There are other benefits like const& binding > which is not supported by C++11 lambdas (so how can I bind by const a > variable that has a very expensive copy constructor using C++11 > lambdas?) and improve scope exit (i.e., local exit) but these other > benefits are probably minor in the general domain (they can be very > important or even essential is a specific and narrow domain like > Contract Programming but not critical in the general case). OK Lorenzo, I am convinced. Can we trade? I will vote 'yes', and you will add a motivation section in the documentation which will stress that the primary motivation of the library is to provide a uniform (in terms of syntax) support for local functions: fast and 'native' for C++11 compilers, and acceptable (using tricks) in older compilers. The library can be used directly or be a foundation for higher level libraries like Boost.Concept. Review Managers, I am not really trading, I vote YES for the Boost.Local and just request the motivation section in the documentation. I think the situation of Boost.Local is similar to that of Boost.Move, and the latter was accepted into Boost. Also, having a library in Boost whose primary purpose is to serve as the foundation for other Boost libraries is not a precedent (I mean Boost.Proto and now Boost.Context). Regards, &rzej

3 2

Re: [boost] Boost.Local Review - comments by Andrzej
by Andrzej Krzemienski 15 Nov '11

15 Nov '11

Just one more thought. I was not participating in the design discussion for Boost.Local when it was probably a better time to mention this. So I am just mentioning it for reference. Functions that take parameters and bind existing objects are called closures: http://en.wikipedia.org/wiki/Closure_%28computer_science%29.<http://en.wikipedia.org/wiki/Closure_%28computer_science%29> This could have been an alternative name for BOOST_LOCAL_FUNCTION: BOOST_SCOPE_CLOSURE... Regards, &rzej

2 1

[1.48.0] Status?
by Beman Dawes 15 Nov '11

15 Nov '11

Are there any 1.48.0 showstoppers outstanding? We are scheduled to release right now. There are still a lot of release branch regression test failures. It is very uncomfortable to see failures for popular compilers such as VC++ 10 and GCC: accumulators (most or all compilers) assign flyweight (most or all compilers) graph ublas pool (all Windows compilers) ptr_container (most or all compilers) python spirit/repository (most or all compilers) tr1 (most or all compilers) wave (all Windows compilers) See http://beta.boost.org/development/tests/release/developer/summary.html Do we really want to release with this many failures? Worried, --Beman

12 33

[property_tree] Assign and Lua parser
by Renato Florentino Garcia 15 Nov '11

15 Nov '11

In my use of Boost Property Tree library I have coded some extensions, which are in a GitHub repository (http://github.com/renatoGarcia/boost-extensions) I would like to know if there are any interest in make any of then part of Boost Property Tree itself, probably after a suggest improvement. The more useful in my view is a Boost Assign Property Tree alike. Code: http://github.com/renatoGarcia/boost-extensions/blob/master/property_tree/i… For instance, to build in C++ code a ptree like: key1 value1 key2 { key3 12345 { key4 "value4 with spaces" } key5 value5 "" 10 "" 11 "" 12 } Instead the current: ptree pt; pt.add("key1", "value1"); ptree tmpPt1; tmpPt1.add("key3", 12345); ptree tmpPt2; tmpPt2.add("key4", "value4 with spaces"); tmpPt1.push_back(std::make_pair("", tmpPt2)); tmpPt1.add("key5", "value5"); ptree tmpPt3; tmpPt3.put_value(10); tmpPt1.push_back(std::make_pair("", tmpPt3)); ptree tmpPt4; tmpPt4.put_value(11); tmpPt1.push_back(std::make_pair("", tmpPt4)); ptree tmpPt5; tmpPt5.put_value(12); tmpPt1.push_back(std::make_pair("", tmpPt5)); pt.add_child("key2", tmpPt1); Would be a code like: ptree pt = tree() ("key1", "value1") ("key2", tree() ("key3", 12345) (tree() ("key4", "value4 with spaces")) ("key5", "value5") (10)(11)(12)); Another extension is a Lua parser, like the XML or JSON. But in this case I don't think that is desirable include it in the Boost, because of the needed of Lua libraries (at least not in a mandatory way). Code: http://github.com/renatoGarcia/boost-extensions/blob/master/property_tree/i… Regards, Renato Garcia

2 1

Boost.Local Review - comments by Andrzej
by Andrzej Krzemienski 15 Nov '11

15 Nov '11

Hi Lorenzo, I would like to provide some comments on Boost.Local. > Please state clearly whether you think this library should be accepted > as a Boost library. I am unable to give a yes/no answer. This is mostly because I am not clear who is the intended audience of the library. I explain this in detail below. I am impressed with the library documentation. It is very informative with lots of examples, benchmarks, comparisons, rationale, and layered design (overview, and then details). This is how a Boost library's documentation (and every documentation, IMO) should look like. Yet, one thing that I am missing is what practical problems (that are not already solved) this library is trying to solve. I am not saying that it doesn't solve any. I am just saying I cannot figure it out. A typical story for a Boost library is that there is a common problem that many developers face fairly often, and at some point someone decides to fix this problem comprehensively and ultimately. This is the impression that I had, for example, with Boost.Optional. When I read about it I thought "Yes! This is what I was missing for a long time". I cannot see this in Boost.Local. Perhaps I am not the intended audience of the library, but it would help me if it was clear who the audience is. (I provide examples of what I mean below.) Documentation clearly separates three parts: local functions, local scopes and local exits. Also my impression is different on the three parts. This suggests to me that they could be three separate libraries. What do they have in common? The syntax, I guess. And the fact that you declare them inside functions. But is that enough to bundle them together? Consequently, I divide my comments into three parts. LOCAL FUNCTIONS Why would I want to use it? Personally, I have one compiler that does support local classes as template parameters. All my other compilers support lambdas. So I guess local functions are not for me. So who will use them? Someone that does not have too new compiler (because they have superior - in terms of performance - alternatives: lambdas, local classes). Someone that does not have a too old compiler, because we read in the documentation that "The implementation of this library uses preprocessor and template metaprogramming (as supported by Boost.Preprocessor<http://www.boost.org/doc/libs/release/libs/preprocessor/doc/index.html>and Boost.MPL <http://www.boost.org/doc/libs/release/libs/mpl/doc/index.html>), templates with partial specializations and function pointers (similarly to Boost.Function<http://www.boost.org/doc/libs/release/doc/html/function.html>). As a consequence, this library is fairly demanding on compilers' compliance with the C++03 <http://www.open-std.org/JTC1/SC22/WG21/docs/standards>standard." Further someone who does not mind compile-time and run-time performance overhead. And someone,who prefers the new syntax to creating a functor class non-locally. I am not sure how many users that would be? The documentation mentions proposal N2511<http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2511.html>, which says that even though with lambdas and local classes we already have a good tool, we still want to have a normal function syntax for local functions. Boost.LocalFunction does not enable a normal function syntax either, so it is no better an alternative than lambdas or local classes. Except for "const binding" which I find hard to appreciate. And except for compilers that don't support C++11 features, but than again, working only with the new compilers I may not be the right person to review the library. Is this supposed to provide a seamless migration of the code from compilers w/o lambdas to those that do support lambdas? I am not comfortable with the syntax: we first specify parameters, then function body and last, we specify the function name. I am not comfortable that the other Lorenzo's library (that I await impatiently) - Boost.Contract - will provide a different function syntax than Local Functions. This will render the situation where every library will require of me to learn different function declaration syntax. On the other hand, the documentation clearly says why this syntax is necessary, so I am not saying "change the syntax". I am suspicious about the local function overloading. While I can imagine writing a local function; writing a bunch of them inside another function would be likely be some error in my design. LOCAL BLOCKS Again, why would I need them? The example with assertion does not convince me. That is, I face the practical tradeoff: additional enforcement on assertions at the cost of slower build, slower execution time and less readable syntax. I will choose not to use the blocks. The only application that I can think of is a "temporary usage" while refactoring. If I work with the code where functions are 1000-line-long, I would like to divide them into blocks and check which parts reference what variables. In this case, as one of the footnotes in documentation suggests, allowing "return;" inside blocks would be a dangerous thing. But again, if I had a luxury of lambdas, I would choose lambdas for that purpose, because they allow specifying the default binding ( [&], [=] ). It looks like local blocks are only a syntax sugar over local functions. Am I right? LOCAL EXITS While exception specifications for locals blocks seam strange, I find allowing exception specifications for local exits an error. Local exits should be subject to the same restrictions as destructors (they are implemented as destructor calls anyways): you must not throw from them. And I expect the library documentation to say it explicitly. I find this "warning" missing from Boost.ScopeExit. So I suggest to disallow (if possible) specifying exceptions in local exit, and adding a section in documentation that warns against potential throws from an exit. I do not see anything against having two libraries for the same purpose. This is pretty much the same what we already have in Boost in case of state machines. But since we have two, it is useful to ask why I would choose local exit over scope exit. My answer is: 1. Local Exit allows me to specify an empty parameter list (I cannot do it with ScopeExit). - this is a practical problem I faced 2. I can bind to "this". I do not find const binding a practical advantage. Typically for short functions it is hardly a real problem that I confuse = with ==. And exits would typically be one-liners in my code. On the other hand there are reasons why I would prefer ScopeExit to LocalExit: it spells shorter. In LocalExit I have to type word 'bind' for every single parameter even though it is obvious I need to bind them all (because scope guards do not accept normal parameters). The same argument goes for blocks, obviously. I also like ScopeExit's potential to be implemented with lambdas, which might result in performance benefits, and allow the 'default binding'. On the other hand LocalExit cannot be implemented with a lambda, if not for any other reason, then due to the const binding. It is really nice that i can bind to variable of the name 'bind'; although I cannot use type 'bind' in local functions. GENERAL THOUGHTS I am really impressed with the usage of macros. It looks like thanks to Lorenzo we are reaching a new level of preprocessor programming. Who knows how far we can go. I do not think they are overused, given the difficult task. On the other hand, error messages that I encountered give me no clue on what I have typed wrong. Decsriptions in the documentation, and the rationale clearly indicates the very detailed knowledge of many C++ aspects. One suggestion for the future, although I am not sure how useful it would turn out in practice is to have something like local expression, or even not necessarily a local one. This would be a function whose body consists of a single expression. The benefit you get is that the programmer does not need to specify a return type for it (you can use BOOST_TYPEOF for that), or doesn't even have to type keyword 'return', but this may be too much off topic. Term 'C99 <http://www.open-std.org/jtc1/sc22/wg14/www/projects#9899> and later compilers' may be a bit of an overuse for C++ compilers. I suggest 'compilers supporting variadic macros'. Also, in reply to particular review questions: > What is your evaluation of the design? It is clear. Some macros are difficult to read, e.g. Function arguments first, function name second, but I guess this is a necessity given the domain. > What is your evaluation of the implementation? The impressive macro magic is beyond my cognitive capabilities > What is your evaluation of the documentation? It is very good. It meets Boost's and my personal criteria for a good documentation. > What is your evaluation of the potential usefulness of the library? > Are you knowledgeable about the problem domain? This is the part where I have problems. I am not sure about the scope and intended audience of the library. > Did you try to use the library? With what compiler? Did you have any problems? I tried to use the library (basic examples) with VC++8 and VC++10 and Boost 1.42. I found that it does not compile if I use compiler option /ZI (Debug Information Format: Program Database for Edit & Continue) on either compiler. > How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? I spent one evening on reading the documentation and playing with the basic examples. For the last remark, I believe that the criterion for accepting or rejecting a library is that if it addresses a real-life problems and if it is well designed. Boost.Local is well designed, but the intended audience and primary motivation is not clearly stated, so I find it hard to assess if the first criterion is met. All in all, Boost.Local is an impressive piece of work. Regards, &rzej

2 1

Determining interest: C++11 parser generator library
by Gene Bushuyev 15 Nov '11

15 Nov '11

Sorry if it turns out to be a duplicate, it looks my original post was lost in cyberspace, so I'm re-posting this request. I'm trying to determine if there is a sufficient interest for including AXE C++11 recursive descent parser generator library in Boost. The zipped sources and documentation are here: http://www.gbresearch.com/axe/axe.zip - Gene Bushuyev

4 7

[program_options] Improving error text in exceptions
by Leo Goodstadt 15 Nov '11

15 Nov '11

As a long time fan of boost::program_options, I would very much like to make the error messages in program_options exceptions more consistent and informative. Exception text is usually aimed at the developer as a diagnostic for rare errors. If the exception needs to be propagated to the end-user, it can be caught, and a more appropriate message substituted. This is not true for program_options: Exceptions from invalid program arguments are the common (and normal) reason for early program termination. It would be nice if, out of the box, exception text could be clear enough to present to the end user more or less as is. This would allow a single try/catch(exception) in main() cerr << "Error: " << e.what() << "\n"; return 1; >From the attached list of error messages, there are many, many different exception types which are thrown. The usual practice of repackaging / reformatting exceptions to be more user-friendly would be tedious or impractical. I grep-ed "boost::throw_exception" to get a list of all the exceptions and messages. I suggested revisions for all but 5. These I have set them aside at the end. I have modelled some of the proposed text on GNU genparse examples (i.e. the behaviour of "ls" and "cat" etc.). These, by dint of their frequent use / hammering by the huge linux user base, are probably good examples of the sort of friendlier clarity I would hope for. In some cases, I have tried to understand the exception text from the code but might have misunderstood the original intent. If this is useful, I shall painstaking go through the code and submit a patch. Leo Goodstadt P.S. I realise there are pitfalls to do with option prefix styles "--" and "/" but the addition of option prefixes to the exception text makes the message a lot clearer. P.P.S. I have kept the current style of starting the text in lower case even though my own preference would be for a capitalised sentence ending in a full stop. ======================================================= Original (CURRENT) and revised (CHANGED) text resulting from exception.what() ======================================================= CURRENT: <ambiguous option option_name> CHANGED: <option '--option_name' is ambiguous and matches options "--aa"," --b" and "--c".> // abbreviated instead of long/short because // length might imply too many/few letters CURRENT: <style disallows parameters for long options> CHANGED: <arguments are not allowed for unabbreviated option names> CURRENT: <style disallows parameters for short options> CHANGED: <arguments are not allowed for abbreviated option names> CURRENT: <style disallows all characters for short options> CHANGED: <abbreviated option names are not valid> CURRENT: <adjacent parameter is empty> CHANGED: <Invalid command line syntax: each option with an equal sign must be followed immediately by its argument.> CURRENT: <parameters adjacent to long options not allowed> CHANGED: <arguments are not allowed for unabbreviated options> CURRENT: <required parameter is missing in 'option_name'> CHANGED: <option '--option_name' requires an argument> CURRENT: <in option 'option_name': invalid option value> CHANGED: <invalid argument for option '--option_name'> CURRENT: <unrecognised line in 'DODGY LINE'> CHANGED: <options configuration file contained an invalid line: 'DODGY LINE'> CURRENT: <multiple occurrences> CHANGED: <option '--option_name' cannot be specified more than once> CURRENT: <can not read file NON_EXISTENT_FILE_NAME> CHANGED: <cannot read options configuration file 'FILE_NAME'> CURRENT: <missing required option required_option> CHANGED: <option '--option_name' is required> CURRENT: <too many positional options> CHANGED: <too many positional arguments have been specified> CURRENT: <unknown option unknown_option> CHANGED: <unrecognised option 'option_name'> CURRENT: <in option 'invalid_option': invalid bool value> CHANGED: <at least one argument is required for option '--option_name> CURRENT: <in option 'option_name': invalid bool value> CHANGED: <invalid argument for option '--option_name'. Valid arguments are 'on|off', 'yes|no', '1|0' and 'true|false'> CURRENT: <in option 'option_name': multiple values not allowed> CHANGED: <option '--option_name' only takes a single argument> Not sure what these mean and have left them alone. libs/program_options/src/parsers.cpp:112: boost::throw_exception(error("long name required for config file")); libs/program_options/src/config_file.cpp:60: boost::throw_exception(error("bad prefixes")); libs/program_options/src/value_semantic.cpp:102: boost::throw_exception(multiple_values()); libs/program_options/src/convert.cpp:66: boost::throw_exception(std::logic_error("character conversion failed")); libs/program_options/src/convert.cpp:74: boost::throw_exception(std::logic_error("character conversion failed")); libs/program_options/src/value_semantic.cpp:33: boost::throw_exception(std::runtime_error("UTF-8 conversion not supported.")); -- Dr. Leo Goodstadt University of Oxford United Kingdom

2 1

[Serialization] Proposal for TR2
by Ruediger Berlich 15 Nov '11

15 Nov '11

Dear Robert, dear all. from what I understand, Boost.ASIO has been proposed for TR2 quite a while ago. Since I use ASIO and Boost.Serialization quite a bit and feel that both strongly benefit from each other (and not only ASIO -- see e.g. Boost.MPI), are there any efforts to make Boost.Serialization part of TR2 ? We live in the era of cloud computing and networked execution. Without this facility, C++ will have a hard time to compete. And Boost.Serialization is established and mature (thanks, Robert!). Best, Ruediger

3 2

[context] ready
by Oliver Kowalke 14 Nov '11

14 Nov '11

Hi, https://github.com/olk/boost.context.git contains the new version of boost.context (docu at http://ok73.ok.funpic.de/boost/libs/context/doc/html/index.html) Any comments are welcome - in the meantime I'm awaiting Giovanni's OK for the mini-review. regards, Oliver

8 15

Boost.Local Review (Nov 10, 2011 to Nov 19, 2011) by Krzysztof Czaiński
by Krzysztof Czainski 14 Nov '11

14 Nov '11

Hello, About me: I write C++ apps and RTS, mostly for embedded devices. I often use complicated C++ structures, and of course boost. Boost.Local caught my interest, so I decided to review it. I intend to try to use this library on MinGW-4.5, and on a Texas Instruments/DSP compiler, however I can't do that this week, so I won't make it until the end of this review. I studied the docs in depth. I state my comments below. Each of my comments is numbered in the style (0), so they can be referenced. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… : Variable Binding: [quote] programmers might want to bind variables of complex types by (constant) reference instead than by value [/qoute] (1) s/instead than/instead of/ Binding the Object this: [quote] It is also possible to bind the object this when it is in scope (e.g., from an enclosing non-static member function). This is done by using this as the name of the variable to bind in the local function declaration and by using the special symbol this_ (instead of this) to access the object within the local function body. [/qoute] (2) Why not use this_ in both places? Local Blocks: (3) How is a Local Block better then just an ordinary C++ block: {}? So far, I have an idea of what such a Local Block is for, but a reference to a rationale at this point in the tutorial would be nice. Local Exits: [qoute]The execution of the local exit body code is guaranteed only if the program does not terminate because of an uncaught exception. [16] [/qoute] (4) To me this note requires more explanation. Consider three examples: (4a) [code] int main() { BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END throw 0; } // Local exit executed here. [/code] (4b) [code] int main() { try { BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END throw 0; } catch ( ... ) {} } // Local exit executed here. [/code] (4c) [code] int main() { try { throw 0; BOOST_LOCAL_EXIT( (void) ) { // Local exit. cout << "hello" << endl; } BOOST_LOCAL_EXIT_END } catch ( ... ) {} } // Local exit executed here. [/code] I which of the abouve examples is printing "hello" guaranteed? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… : Assigning Local Functions: (5) In the example, variables named "l" (lowercase L) are used, which is easy to confuse with "1" (one), and therefore the example is hard to read. I suggest renaming that variable. Deducing Bound Types (concepts, etc): [qoute] it will also be a reference is the variable is bound by reference [/qoute] (6) typo: is -> if Inlining Local Functions [qoute]On C++03 compliant compilers, inlined local functions always have a run-time comparable to their equivalent implementation that uses local functors (see the Alternatives section). However, inlined local functions have the limitation that they cannot be assigned to other functors (like boost::function) and they cannot be passed as template parameters. [21] On C++11 compilers, inline has no effect because this library will automatically generate code that usesC++11 specific features to inline the local function calls whenever possible even if the local function is not declared inlined (unless the BOOST_LOCAL_CONFIG_COMPLIANT configuration macro is defined). Furthermore, non C++11local functions can always be passes as template parameters even when they are declared inlined.[/quote] (7) I read this paragraph four time, and still don't get it. Please rephrase is somehow ;-) (8) After reading the Introduction, Getting started, Tutorial and Advanced topics I still don't have an overview of the overhead, memory allocations, and exceptions that Local constructs can cause. Please add this information. Right now, I can deduce this information from the Implementation section. However, could things like lack of memory allocations or not emitting exceptions be promised in the public interface? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [qoute]As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics). [/quote] (9)What are: the overhead, possible memory allocations, and exceptions, that Local constructs can cause? https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [quote]If programmers leave this configuration macro undefined, its default value is to be left not defined.[/qoute] (10) What does it mean "its default value is to be left not defined"? Does it mean, that whether it's defined or not depends on the library, which tries to guess if the compiler supports variadic macros? [quote]If this macro is defined, variadic macros and empty macro parameters are not used by this library. Using variadic macros and empty macro parameters allows this library to provide the variadic macro and empty macro syntaxes which some programmers might find more readable than the sequencing macro syntax (see the Tutorial section, BOOST_LOCAL_FUNCTION_PARAMS, BOOST_LOCAL_BLOCK, and BOOST_LOCAL_EXIT). If this configuration macro is defined then only the sequencing macro syntax is allowed (regardless of whether the compiler supports variadic and empty macros or not).[/quote] (11)This paragraph is a bit unclear: first it says what happens if this macro is defined, then it says why variadic macros are useful, and lastly is says again what happens when this macro is defined. I suggest to make two paragraphs: first: state clearly what this macro does - disables the use of variadic macros, and second: comment on why variadic macros are useful. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [qoute]The execution of the local exit body code is guaranteed only if the program does not terminate because of an uncaught exception. As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics).[/qoute] (12) Notes (4) and (9) apply here as well. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: [qoute]As usual, exceptions specifications can be optionally programmed before the body code block (but the specifications will only apply the body code and not to the library code automatically generated by the macro expansion, see Advanced Topics).[/quote] (13) Note (9) applies here as well. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_LOC… : Description: (14) What about the typename keyword inside templates? I think i remember from the previous sections, that typename is not required, but that information is missing here. https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… Description: [qoute]For example, if the expression type is know (and contains no commas)[/quote] (15) typo: know -> known This concludes my study of the docs, and I won't be able to try to use this library before the end of this review, so I state my conclusions now. 2011/11/10 Jeffrey Lee Hellrung, Jr. <jeffrey.hellrung(a)gmail.com> > Please state clearly whether you think this library should be accepted as a > Boost library. > Yes. Other questions you may want to consider: > > - What is your evaluation of the design? > I like it. > - What is your evaluation of the documentation? > I enjoyed reading it, and I think it gave me a pretty good idea about the library. > - What is your evaluation of the implementation? > >From what I read in the Implementation section of the docs, looks reasonable. > - What is your evaluation of the potential usefulness of the library? > I can imagine it would improve readability of some of my code. > - Did you try to use the library? With what compiler? Did you have any > problems? > No. I intend to, but not until the end of this review. > - How much effort did you put into your evaluation? A glance? A quick > reading? In-depth study? > In-depth study of the docs. > - Are you knowledgeable about the problem domain? > Hmm... I'll just say, I miss something like this for most of my 3-year experience of C++ programming. Please also consider the following issues and proposals specific to > Boost.Local. Your opinion is welcome on any or all of these. > > - Boost.Local's local exits provide the same functionality (and then some) > as Boost.ScopeExit. Does this duplication of functionality need to be > dealt with, and if so, how? I haven't used ScopeExit, so I don't have an opinion on this. - Lorenzo is proposing to add boost::local::function::overload to > Boost.Function as boost::function::overload. See > > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost/loc… I don't remember missing such a utility in my experience, but it seems reasonable to add it to boost function. However, I don't understand, how can it be added as boost::function::overload, when boost::function is a class template? > - Lorenzo is proposing to add BOOST_IDENTITY_TYPE to boost/utility. See > > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… > - Likewise, Lorenzo is proposing to add BOOST_IDENTITY_VALUE to > boost/utility. See > > https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/BOOST_IDE… > I don't remember missing any of the above in my experience. One of "more readable alternatives" described in the docs have sufficed. Thanks in advance to all who participate in the review discussion; I'm > looking forward to it! > > - Jeffrey Hellrung (Review Manager) > - Gregory Crosswhite (Review Assistant) This was my first review, and I hope it's useful ;-) Regards, Kris

3 3

Need for BOOST_PP_VARIADIC_POP_FRONT
by Gennadiy Rozental 14 Nov '11

14 Nov '11

Hi, I consider using Boost.PP variadic macros support, but I seems to be missing subject macro (with support for zero arguments). Any chance we can one? I'd hate to reinvent the wheel. Regards, Gennadiy

4 16

1.48 is another release without the logger
by Jeff Graham 14 Nov '11

14 Nov '11

Hello, Any progress on the logger?

2 1

Re: [boost] Boost.Local Review (Nov 10, 2011 to Nov 19, 2011)
by Lorenzo Caminiti 14 Nov '11

14 Nov '11

Hello all, I have received a couple of questions on Boost.Local and I will answer them on the ML. On Mon, Nov 14, 2011 at 4:20 AM, Andrzej Krzemienski <akrzemi1(a)gmail.com> wrote: > 1. Can Boost.Local be used to create global functions? No, Boost.Local macros need to be used at local scope. If it were important to use the functionality of Boost.Local at global scope, it _might_ be possible to do so but another set of macros (BOOST_GLOBAL_?) will have to be defined for that. Does anyone see a need to use LOCAL_EXIT, LOCAL_BLOCK, or LOCAL_FUNCTION at global scope? If so, why? > 2. For Local Exits, is it possible not to bind any variable (because I will > only be calling global functions): > > int runCommand() { > ::DisplayWaitCursor(); > BOOST_LOCAL_EXIT( /*nothing*/ ) { > ::DisplayNormalCursor(); > } BOOST_LOCAL_EXIT_END; > > DoALongLastingOperation(); > } Yes, you can do this. However, the most portable syntax is to use void for the empty parameter list: https://svn.boost.org/svn/boost/sandbox/local/libs/local/doc/html/boost_loc… For example: #include <boost/local/exit.hpp> #include <iostream> void f() { std::cout << "f" << std::endl; } int main() { ::f(); BOOST_LOCAL_EXIT(void) { ::f(); } BOOST_LOCAL_EXIT_END return 0; }; This compiles and it prints "f" twice (at main entry and exit). HTH, --Lorenzo

1 0

[1.48][flyweight] regression in release branch
by JOAQUIN M. LOPEZ MUÑOZ 13 Nov '11

13 Nov '11

Hi, Sorry for not having tracked this before. There's a trivial regression in Boost.Flyweight due to a change of namespace name in Boost.Interprocess: https://svn.boost.org/trac/boost/changeset/75464 OK to commit to branch? Joaquín M López Muñoz Telefónica Digital ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at. http://www.tid.es/ES/PAGINAS/disclaimer.aspx

2 2

[iostreams][io_state_savers] Request for interest in some ios_base basic utilities
by Vicente J. Botet Escriba 12 Nov '11

12 Nov '11

Hi, I'm a beginner of the standard IOStream library. While restructuring Boost.Chrono I/O I have find some classes that could be of general use (if the design is correct, of course). The first one is quite simple, is used to define manipulators with parameters. Instead of defining a class and the correspondent stream inserters and extractors the manip template class do all this at once. It can be used as follows class mendl: public manip<mendl> { public: explicit mendl(size_t how_many) : count(how_many) {} template <typename out_stream> void operator()(out_stream &out) const { for (size_t line = 0; line < count; ++line) { out.put(out.widen('\n')); } out.flush(); } private: size_t count; }; Now mendl can be use to insert n new lines at once as follows cout << mendl(3); The second one is an ios specific smart pointer ios_base_state_ptr (based on the use of ios_base::pword and ios_base::xalloc). The class ios_base_state is a ios_base_state_ptr that can not be null. It can be used like struct MyData { std::string time_fmt; std::string duration_fmt; }; std::string get_time_fmt(std::ios_base & ios) { return ios_base_state<MyData>(ios)->time_fmt; } ios_base_state stores a new MyData in the ios if not already stored and provides an smart pointer interface to it. The 3rd one (ios_base_flags) uses the ios_base::iword and xalloc to provide access to specific ios flags. It can be used as follows: class fmt_masks : ios_base_flags<fmt_masks> { typedef ios_base_flags<fmt_masks> base_type; public: fmt_masks(std::ios_base& ios): base_type(ios) {} enum type { uses_symbol = 1 << 0, uses_local = 1 << 1 }; }; Usage of this class can be duration_style::type get_duration_style(std::ios_base& ios) { return (fmt_masks(ios).flags() & fmt_masks::uses_symbol) ? duration_style::symbol : duration_style::prefix; } The interface and the implementation of these classes is attached. Do you see a design flag on these classes? If not, do you think these kind of utilities could be added to boost? If yes, could these be merged with Boost.io_state_savers or Boost.IOStreams to form a larger io utilities libraries? Best, Vicente

3 14

Are some of the trunk regression tests running in C++0x mode when they shouldn't be?
by Richard Webb 11 Nov '11

11 Nov '11

Looking at the Trunk regression tests, it appears that some of the GCC tests are running in C++0x mode when they shouldn't be. for example: Large numbers of the Sandia-gcc-3.4.6 tests are failing with the error: unrecognized command line option "-std=c++0x" If you look at the test results for assign, there are rvalue-reference related errors in toolsets which shouldn't have them. Looks like -std=c++0x is being specified when it shouldn't for some reason? Is something broken, or am i imagining it? Thanks, Richard Webb

7 10

leak in win32 detail::basic_condition_variable
by Kenneth Porter 10 Nov '11

10 Nov '11

I'm finding that an element in the CV's generation_list is left orphaned sometimes when the CV is destroyed. I'm running Visual Leak Detector and it gives this stack dump of the allocation point of the leaked object: c:\devel\boost\boost_1_46_1\boost\thread\win32\condition_variable.hpp (172): boost::detail::basic_condition_variable::get_wait_entry c:\devel\boost\boost_1_46_1\boost\thread\win32\condition_variable.hpp (211): boost::detail::basic_condition_variable::do_wait<boost::unique_lock <boost::mutex> > + 0xC bytes c:\devel\boost\boost_1_46_1\boost\thread\win32\condition_variable.hpp (369): boost::condition_variable_any::wait<boost::unique_lock<boost::mutex> > c:\devel\boost\boost_1_46_1\boost\thread\win32\condition_variable.hpp (374): boost::condition_variable_any::wait<boost::unique_lock <boost::mutex>,boost::_bi::bind_t<bool,boost::_mfi::cmf0 <bool,bounded_buffer<Axis::Report> >,boost::_bi::list1<boost::_bi::value <bounded_buffer<Axis: + 0x1B bytes I compared the source file against trunk and it hasn't changed.

1 0

asio ipv6 anycast
by Julian Faude 10 Nov '11

10 Nov '11

Hi, I am working on a project which depends on IPv6 anycast. In linux IPv6 anycast is available through a socket options called IPV6_JOIN_ANYCAST and IPV6_LEAVE_ANYCAST. Like the multicast option it's based on the ipv6_mreq struct. If I'm not mistaken there is no ipv6 anycast socket option in asio. Am I right? Is anybody working on it? Best, Julian

2 1

[Test] Darwin Intel 11.1
by Belcourt, K. Noel 09 Nov '11

09 Nov '11

Hi, I've attached a patch that appears to fix problems with about 20 Boost libraries on trunk that depend on Boost.Test. This patch simply removes an argument to format_report(). The trunk tests (http://www.boost.org/development/tests/trunk/developer/summary.html ) currently reflect this patch. I've added this patch to the nightly trunk testing patch script until such time as we get this committed to trunk. -- Noel

1 0

Fw: [atomic] review results
by Peter Dimov 08 Nov '11

08 Nov '11

-----Original Message----- From: Peter Dimov Sent: Monday, November 07, 2011 22:38 To: Helge Bahmann Subject: Re: [boost] [atomic] review results Helge Bahmann wrote: > yes makes sense -- there was a concern raised by Andrey Semashev that the > spinlock pool as implemented and used by shared_ptr presently may fail on > Windows due to the pool being non-unique (not had a chance to test this > yet), > and I have found a way to produce a similar failure using dlopen, atomics > private to shared libraries and RTLD_LOCAL -- currently I am therefore > leaning on creating a shared library just for the spinlock pool, but since > you wrote the initial implementation maybe you could comment as well? This is a problem in principle, but requiring all users of shared_ptr to link to a shared library is a non-starter. I wouldn't use such a shared_ptr, and I doubt many others will. And I wouldn't be surprised if this sentiment applies to Boost.Atomic as well.

5 35

[parameter] type requirement compiler error
by lcaminiti 08 Nov '11

08 Nov '11

Hello all, The following parameter type requirement: (required (graph, *) ) (optional (root_vertex, (typename boost::graph_traits<graph_type>::vertex_descriptor), *boost::vertices(graph).first) ) Generates a GCC error: dfs.05.cpp:40: error: ‘graph_type’ was not declared in this scope Detailed code and error below. In fact, if I look at the code after pp, I can see that graph_type is define only after the type requirement is checked... why? What am I doing wrong? Thanks a lot! --Lorenzo #include <boost/graph/adjacency_list.hpp> #include <boost/graph/depth_first_search.hpp> #include <boost/range/irange.hpp> #include <boost/pending/indirect_cmp.hpp> #include <boost/parameter.hpp> #include <iostream> namespace graphs { BOOST_PARAMETER_NAME(graph) BOOST_PARAMETER_NAME(visitor) BOOST_PARAMETER_NAME(root_vertex) BOOST_PARAMETER_NAME(index_map) BOOST_PARAMETER_NAME(color_map) template< typename Size, typename IndexMap > boost::iterator_property_map<boost::default_color_type*, IndexMap, boost::default_color_type, boost::default_color_type&> default_color_map ( Size const& num_vertices, IndexMap const& index_map ) { std::vector<boost::default_color_type> colors(num_vertices); return &colors[0]; } BOOST_PARAMETER_FUNCTION( (void), depth_first_search, tag, (required (graph, *)) (optional (visitor, *, boost::dfs_visitor<>()) (root_vertex, (typename boost::graph_traits<graph_type>::vertex_descriptor), *boost::vertices(graph).first) (index_map, *, boost::get(boost::vertex_index, graph)) (in_out(color_map), *, default_color_map(boost::num_vertices(graph), index_map)) ) ) { std::cout << "here\n"; boost::depth_first_search(graph, boost::visitor(visitor). color_map(color_map).root_vertex(root_vertex). vertex_index_map(index_map)); } } // namespace graphs template< typename TimeMap > class dfs_time_visitor : public boost::default_dfs_visitor { typedef typename boost::property_traits< TimeMap >::value_type T; public: dfs_time_visitor(TimeMap dmap, TimeMap fmap, T& t) : dmap_(dmap), fmap_(fmap), time_(t) {} template< typename V, typename G > void discover_vertex ( V u, G const& g ) const { put(dmap_, u, time_++); } template< typename V, typename G > void finish_vertex ( V u, G const& g ) const { put(fmap_, u, time_++); } TimeMap dmap_; TimeMap fmap_; T& time_; }; using namespace boost; int main ( ) { typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS> G; typedef boost::graph_traits<G>::vertices_size_type size_type; enum {u, v, w, x, y, z, N}; char names[] = {'u', 'v', 'w', 'x', 'y', 'z'}; typedef std::pair<int, int> E; E edges[] = {E(u, v), E(u, x), E(x, v), E(y, x), E(v, y), E(w, y), E(w, z), E(z, z)}; G g(edges, edges + sizeof(edges) / sizeof(E), N); std::vector<size_type> dtime(boost::num_vertices(g)); std::vector<size_type> ftime(boost::num_vertices(g)); size_type t = 0; dfs_time_visitor<size_type*> vis(&dtime[0], &ftime[0], t); graphs::depth_first_search(g, vis); std::vector<size_type> dorder(N); boost::integer_range<size_type> r(0, N); std::copy(r.begin(), r.end(), dorder.begin()); std::sort(dorder.begin(), dorder.end(), boost::indirect_cmp<size_type*, std::less<size_type> >(&dtime[0])); std::cout << "order of discovery: "; for(int i = 0; i < N; ++i) std::cout << names[dorder[i]] << " "; std::cout << std::endl; std::vector<size_type> forder(N); std::copy(r.begin(), r.end(), forder.begin()); std::sort(forder.begin(), forder.end(), boost::indirect_cmp<size_type*, std::less<size_type> >(&ftime[0])); std::cout << "order of finish: "; for(int i = 0; i < N; ++i) std::cout << names[forder[i]] << " "; std::cout << std::endl; return 0; } $ g++ -Wall -I../../../../../boost-trunk.cygwin dfs.05.cpp dfs.05.cpp:40: error: ‘graph_type’ was not declared in this scope dfs.05.cpp:40: error: template argument 1 is invalid dfs.05.cpp:40: error: expected `::' before ‘,’ token dfs.05.cpp:40: error: expected identifier before ‘,’ token dfs.05.cpp:40: error: template argument 3 is invalid dfs.05.cpp:40: error: expected `::' before ‘{’ token dfs.05.cpp:40: error: expected class-name before ‘{’ token ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp: In instantiation of ‘boost::parameter::aux::argument_pack<graphs::boost_param_params_40depth_first_search<int>, const boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>, const dfs_time_visitor<main::size_type*>, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>’: dfs.05.cpp:88: instantiated from here ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp:157: error: no type named ‘parameter_spec0’ in ‘struct graphs::boost_param_params_40depth_first_search<int>’ ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp:158: error: no type named ‘parameter_spec0’ in ‘struct graphs::boost_param_params_40depth_first_search<int>’ ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp: In instantiation of ‘boost::parameter::aux::argument_pack<graphs::boost_param_params_40depth_first_search<int>, const boost::adjacency_list<boost::vecS, boost::vecS, boost::directedS, boost::no_property, boost::no_property, boost::no_property, boost::listS>, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_, boost::parameter::void_>’: dfs.05.cpp:88: instantiated from here ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp:157: error: no type named ‘parameter_spec0’ in ‘struct graphs::boost_param_params_40depth_first_search<int>’ ../../../../../boost-trunk.cygwin/boost/parameter/preprocessor.hpp:158: error: no type named ‘parameter_spec0’ in ‘struct graphs::boost_param_params_40depth_first_search<int>’ dfs.05.cpp: In function ‘int main()’: dfs.05.cpp:88: error: no matching function for call to ‘depth_first_search(main()::G&, dfs_time_visitor<size_type*>&)’ -- View this message in context: http://boost.2283326.n4.nabble.com/boost-parameter-type-requirement-compile… Sent from the Boost - Dev mailing list archive at Nabble.com.

6 14

[1.48 lexical_cast] Illegal Derefence
by Olaf van der Spek 08 Nov '11

08 Nov '11

Hi, This does an illegal dereference in boost\lexical_cast.hpp(1357): if ( Traits::eq(minus,*start) ) #include <boost/lexical_cast.hpp> #include <boost/range/iterator_range.hpp> int main() { boost::iterator_range<const char*> v; boost::lexical_cast<int>(v); } -- Olaf

3 10

Boost interprocess: Segmentation fault
by thuannv 08 Nov '11

08 Nov '11

Hi everybody, I am beginner to develop with boost library. I am working with shared memory (boost.interprocess). So, I got error in executing and could anyone help me solve this problem? My problem is: - I wrote 2 process named SHMWriter and SHMReader. + SHMWwriter: write a map (int, int) into the SHM. + SHMReader: read the map value from SHM. - I executed the SHMWriter then SHMReader. - SHMWriter successfully executed. But, SHMWriter always executed failed (error: Segmentation fault). - The sources code are listed below: //SHMWriter: -------------------------------------------- typedef std::pair<int, int> MapValue; typedef allocator<MapValue, managed_shared_memory::segment_manager> MapAllocator; typedef map<int, int, std::less&lt;int>, MapAllocator> IntegerMap; const char* segName = "MAPSEGMENT"; const char* mapName = "MAPNAME"; int main() { shared_memory_object::remove(segName); managed_shared_memory segment(create_only, segName, 1000); MapAllocator allocator(segment.get_segment_manager()); IntegerMap* pOffsetMap = segment.construct<IntegerMap>(mapName)(std::less<int>(), allocator ); int key = 1; int ivalue = 10; MapValue value(key, ivalue); pOffsetMap->insert(value); return 0; } //SHMReader ----------------------------- typedef std::pair<int, int> MapValue; typedef allocator<MapValue, managed_shared_memory::segment_manager> MapAllocator; typedef map<int, int, std::less&lt;int>, MapAllocator> IntegerMap; const char* segName = "MAPSEGMENT"; const char* mapName = "MAPNAME"; int main() { try { managed_shared_memory segment(open_only, "MAPSEGMENT"); IntegerMap* pMap = segment.find_no_lock<IntegerMap>(mapName).first; int key = 1; int value = pMap->at(key); std::cout << value << std::endl; } catch(interprocess_exception& ie) { std::cout << ie.what() << std::endl; } catch(std::exception& stde) { std::cout << stde.what() << std::endl; } return 0; } -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-interprocess-Segmentation-fault-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

[Range] Confusing result of iterator_range::size()
by Sergey Voropaev 08 Nov '11

08 Nov '11

Hi, I try use boost::iterator_range as replacement for some standard container in my code. The function iterator_range::size() has non standart declaration: difference_type size() const; but not: size_type size() const When I compile code in VC++ 2010 I have a some warning and error. For example: #include <boost/range.hpp> #include <vector> #include <algorithm> int main() { int aaa[10] ={1,2,3,4,5,6,7,8,9,10}; std::vector<int> bbb(20); boost::iterator_range<int*> arr(aaa); if(bbb.size() > arr.size()) //warning C4018: '>' : signed/unsigned mismatch { } const size_t lng = std::min(bbb.size(), arr.size()); //error C2780: 'const _Ty &std::min(const _Ty &,const _Ty &,_Pr)' : expects 3 arguments - 2 provided //error C2782: 'const _Ty &std::min(const _Ty &,const _Ty &)' : template parameter '_Ty' is ambiguous // const size_t lng = std::min(bbb.size(), (size_t)arr.size()); //OK for(size_t i = 0; i < lng; ++i) { bbb[i] = arr[i]; } return 0; } I think declaration of boost::iterator_range must be fixed. Or there was some reason for this non standard declaration?

8 29

Boost.Build is broken?
by Gennadiy Rozental 08 Nov '11

08 Nov '11

Hi, Frankly I do not know who supports Boost.Build, but how long it'll stay broken? I can't say when it started, but ever since I started working on Boost.Test changes I experience constant problems. I can't believe I am the only one. 1. When you take boost trunk and go into Boost.Test build or test directory and try building using any toolset it immediately fails with: ..\..\..\libs\test\build\Jamfile.v2:110: in modules.load rule boost-install unknown in module Jamfile</.../trunk/libs/test/build>. .../trunk/tools/build/v2/build\project.jam:314: in load-jamfile .../trunk/tools/build/v2/build\project.jam:62: in project.load .../trunk/tools/build/v2/build\project.jam:766: in project.use .../trunk/tools/build/v2/build\project.jam:89: in load-used-projects .../trunk/tools/build/v2/build\project.jam:73: in load .../trunk/tools/build/v2/build\project.jam:115: in load-parent .../trunk/tools/build/v2/build\project.jam:464: in initialize .../trunk/tools/build/v2/build\project.jam:309: in load-jamfile .../trunk/tools/build/v2/build\project.jam:62: in load .../trunk/tools/build/v2/build\project.jam:115: in load-parent .../trunk/tools/build/v2/build\project.jam:464: in initialize .../trunk/tools/build/v2/build\project.jam:309: in load-jamfile .../trunk/tools/build/v2/build\project.jam:62: in load .../trunk/tools/build/v2/build\project.jam:168: in project.find .../trunk/tools/build/v2\build-system.jam:570: in load .../trunk\tools\build\v2/kernel\modules.jam:283: in import .../trunk\tools\build\v2\kernel\bootstrap.jam:142: in boost-build .../trunk\boost-build.jam:17: in module scope 2. Once I remove boost-install from Boost.Test Jamfile, I get bun of errors like this: ..\..\..\libs\test\src\compiler_log_formatter.cpp(16) : fatal error C1083: Cannot open include file: 'boost/test/impl/compiler_log_formatter.ipp': No such file or directory Essentially boost home directory is missing from include path. How come? 3. Once I add "<include>../../.." into requirements section I can build with msvc toolsets. Now I am trying to use gcc toolset on Windows. I have latest cygwin installation and I am getting these errors (lots of them): gcc.compile.c++ ..\..\..\libs\test\build\bin\gcc\debug\link-static\compiler_log_formatter.o "g++" ... # compilation line here Access is denied. Apparently g++ is not an executable anymore with cygwin. I am able to workaround this by adding using gcc : 4.5.3 : g++-4.exe ; into user-config.jam, but why Boost.Build can't figure this out and do I need to support this file now myself? 4. After the fix I am able to build dll based tests, but when I attempt to use static library version of Boost.Test I am getting: gcc.archive ..\..\..\libs\test\build\bin\gcc-4.5.3\ debug\link-static\libboost_unit_test_framework.a "/usr/i686-pc-cygwin/bin/ar.exe" rc .... # list of object files here "/usr/i686-pc-cygwin/bin/ranlib.exe" ... # lib here The system cannot find the path specified. The system cannot find the path specified. This one I do not know how to fix. So the situation is that I cannot test any static library based unit tests (as a side note, this inability was the cause of crashes which interrupted trunk testing month ago). I addition whenever I want to check in my local changes to Jamfile (excluding hacks which I actually do not want to check in) it is rather annoying process. Any help would be appreciated, Gennadiy

3 4

[atomic] review results
by Tim Blechmann 07 Nov '11

07 Nov '11

hi all, unfortunately only few reviews of boost.atomic arrived in time, however i count 3 YES and no NO, so i am happy to say: Helge Bahmann's boost.atomic library is ACCEPTED. since the library is an implementation of a c++11 feature for c++03, design, API and semantics are mostly fixed. many comments are going into details of the implementation, so i won't sum them all up ... iac, helge already said he wants to address the raised issues, the main points are summarized below. full implementation of the c++11 interface: the library currently only implements a subset of the c++11 library. it lacks the functional interface for integral atomic types and the ATOMIC_VAR_INIT / ATOMIC_FLAG_INIT macro. quickly consulting the latest draft that i currently have at hand the following two functions are missing as well: template <class T> T kill_dependency(T y); void atomic_signal_fence(memory_order); i encourage helge to provide a full implementation of the interface. documentation: the documentation is currently lacking a good API reference. i would therefore encourage helge to provide a doxygen-generated reference section. there were some concerns that it assumes that readers will have to be familiar with concurrency. maybe it is a good idea to point to some literature/tutorials about concurrent programming and/or to c++11 atomics. the section of real-world examples could probably include a link to shavit/herlihy's book `the art of multiprocessor programming'. it would also be helpful to have a detailed specification, if a platform/compiler combination supports a specific type natively (with run-time dispatching or specific compiler flags) ... maybe in form of a table. shared memory support/multi-module support: in multi-module applications and when using shared memory, the blocking emulation of atomics can cause troubles. for multi-module applications this can be resolved by placing the spinlock pool inside a shared library. shared- memory support could be realized by associating a (spin)lock with each blocking atomic<> instead of using a pool of spinlocks. boost should definitely provide atomics which support shared memory, either by default or by an additional implementation which is placed in the boost::interprocess namespace. i would like to thank helge for implementing boost.atomic and submitting it to boost and everyone who participated in the review. cheers, tim review manager

4 4

[smart_ptr] Please merge 5327
by Steve M. Robbins 07 Nov '11

07 Nov '11

Peter Dimov, When you have a moment, could you merge the patch in ticket https://svn.boost.org/trac/boost/ticket/5327 It should be safe enough; Debian has been using this since August 2009. Thanks, -Steve

2 1

[parameter] named template parameters
by Lorenzo Caminiti 07 Nov '11

07 Nov '11

Hello all (and especially Boost.Parameter's authors), The Boost.Parameter docs suggest to implement parameter-enabled class templates using a series of typedes for the argument pack and the actual argument types. I think it is best to define extra template parameters with default values to old the argument pack Args and named template parameters ClassType, etc as shown below. This allows to use the named template parameters within the class declaration for example in a base class (boost::python::class_<ClassType, ...>) instead that just in the class definition. Do you see any problem in using extra template parameter to define the argument pack and named template parameters? #include <boost/parameter.hpp>#include <boost/python/class.hpp>#include <boost/type_traits/is_class.hpp>#include <boost/type_traits/is_base_and_derived.hpp>#include <boost/mpl/is_sequence.hpp>#include <boost/mpl/placeholders.hpp>#include <boost/mpl/not.hpp>#include <boost/mpl/and.hpp>#include <boost/noncopyable.hpp>#include <boost/shared_ptr.hpp> namespace py { namespace detail { struct bases_tag {}; } template< class B0 = void, class B1 = void, class B2 = void >struct bases : detail::bases_tag {}; BOOST_PARAMETER_TEMPLATE_KEYWORD(ClassType) BOOST_PARAMETER_TEMPLATE_KEYWORD(BaseList)BOOST_PARAMETER_TEMPLATE_KEYWORD(HeldType)BOOST_PARAMETER_TEMPLATE_KEYWORD(Copyable) template< typename Arg123X0 , typename Arg123X1 = boost::parameter::void_ , typename Arg123X2 = boost::parameter::void_ , typename Arg123X3 = boost::parameter::void_ , typename Args123 = typename boost::parameter::parameters< // IF(IS_EMPTY(DEFAULT(p)), required, optional) boost::parameter::required< tag::ClassType , boost::is_class<boost::mpl::_> > , boost::parameter::optional< // IF(IS_DEDUCED(p), deduced<tag::NAME(p)>, tag::NAME(p)) boost::parameter::deduced<tag::BaseList> // COMMA_IF(COMPL(IS_EMPTY(REQUIRES(p)))) REQUIRES(p) , boost::is_base_and_derived<detail::bases_tag, boost::mpl::_> > , boost::parameter::optional< boost::parameter::deduced<tag::HeldType> , boost::mpl::not_< boost::mpl::or_< boost::is_base_and_derived<detail::bases_tag, boost::mpl::_> , boost::is_same<boost::noncopyable, boost::mpl::_> > > > , boost::parameter::optional< boost::parameter::deduced<tag::Copyable> , boost::is_same<boost::noncopyable, boost::mpl::_> > >::bind<Arg123X0, Arg123X1, Arg123X2, Arg123X3>::type , typename ClassType = typename boost::parameter::value_type< Args123, tag::ClassType >::type , typename BaseList = typename boost::parameter::value_type< // ... COMMA_IF(COMPL(IS_EMPTY(DEFAULT(p)))) DEFAULT(p) >::type Args123, tag::BaseList, bases<> >::type , typename HeldType = typename boost::parameter::value_type< Args123, tag::HeldType, ClassType >::type , typename Copyable = typename boost::parameter::value_type< Args123, tag::Copyable, void >::type>struct class_ : boost::python::class_<ClassType, BaseList, HeldType, Copyable>{ typedef ClassType class_type; typedef BaseList base_list; typedef HeldType held_type; typedef Copyable copyable;}; } // namespace py struct b { virtual ~b() = 0; }; struct d : b { ~d() {} }; // Named parameters.typedef py::class_< py::ClassType<b>, py::Copyable<boost::noncopyable> > x1;typedef py::class_< d, py::HeldType< boost::shared_ptr<d> >, py::BaseList< py::bases<b> > > x2;// Deduced parameters.typedef py::class_< b, boost::noncopyable > y1;typedef py::class_< d, boost::shared_ptr<d>, py::bases<b> > y2; A couple more things: 1) I thing that BOOST_PARAMETER_TEMPLATE_KEYWORD(ClassType) macro should define a symbol _ClassType to be used for the named parameter so to be consistent with the BOOST_PARAMETER_NAME(x) which defined _x to be used for the named function parameter. However, ClassType is defined without the leading _. What is the reason for this asymmetry? 2) I'd expect a macro that allows to specify tag and passing argument name for template parameters BOOST_PARAMETER_TEMPLATE_KEYWORD((PassClassType, mytag) ClassType) as for BOOST_PARAMETER_NAME((pass_x, mytag) x) does for function parameters. Why is such a usage of BOOST_PARAMETER_TEMPLATE_KEYWORD not supported? Thanks a lot. --Lorenzo

4 10

[smart_ptr] scoped_array / shared_array (size_t) constructor
by Olaf van der Spek 07 Nov '11

07 Nov '11

Hi, Currently, one has to manually allocate the array and pass the ptr to the constructor of scoped_array / shared_array. boost::scoped_array<unsigned char> A(new unsigned char[100]); boost::shared_array<unsigned char> B(new unsigned char[100]); This requires one to repeat the type and shared_array requires two allocations (one extra for the control block). std::vector has a constructor from size_t and one can write: std::vector<unsigned char> V(100); This avoids the type duplication and it'd allow shared_array to do only a single allocation. A few choices have to be made: 1. Should "new T[sz]" or "new T[sz]()" be used? 2. What should happen when size = 0? Should it call new T[0] or should it just use NULL? https://svn.boost.org/trac/boost/ticket/4637 -- Olaf

10 46

[python] Please apply and merge 2208
by Steve M. Robbins 07 Nov '11

07 Nov '11

Hi, The patch has been used in Debian since August 2008 so it should be safe to apply. Thanks, -Steve

1 0

[units] spatial coordinates, vectors, x, y, z, something like that
by Janek Kozicki 06 Nov '11

06 Nov '11

Hi, I want to use boost::units to calculate diffraction & interference patterns and wave propagation in 3D. I need some way to represent points in spatial 3D space with 'length' dimension. What do you guys use for that? I need them to work with 'frequency' & 'speed' dimensions also. Don't tell me that I need to write my own 'vector' class ? best regards -- Janek Kozicki http://janek.kozicki.pl/ |

2 2

Interest in bounded (Top-Bounded) Range adaptor.
by Fernando Pelliccioni 06 Nov '11

06 Nov '11

Is there interest in adding a Top-Bounded adaptor into Boost.Range ? Example: using namespace boost::adaptors; using namespace boost::assign; std::vector<int> input; input += 1,2,3,4,5,6,7,8,9; boost::copy( input | bounded(0), std::ostream_iterator<int>(std::cout, ",")); // prints nothing boost::copy( input | bounded(1), std::ostream_iterator<int>(std::cout, ",")); // prints 1, boost::copy( input | bounded(2), std::ostream_iterator<int>(std::cout, ",")); // prints 1,2, boost::copy( input | bounded(8), std::ostream_iterator<int>(std::cout, ",")); // prints 1,2,3,4,5,7,8, The above example is similar in behavior to ... boost::copy_n( input, 0, std::ostream_iterator<int>(std::cout, ",")); boost::copy_n( input, 1, std::ostream_iterator<int>(std::cout, ",")); boost::copy_n( input, 2, std::ostream_iterator<int>(std::cout, ",")); boost::copy_n( input, 8, std::ostream_iterator<int>(std::cout, ",")); The difference is that *copy_n* algorithm doesn't check for begin(range) != end(range) In the following line, an error occurs at runtime... boost::copy_n( input, 9, std::ostream_iterator<int>(std::cout, ",")); Unlike the following that runs ok... boost::copy( input | bounded(9), std::ostream_iterator<int>(std::cout, ",")); // prints 1,2,3,4,5,7,8,9, This behavior could be equated using *sliced(0, X)*, but sliced requires *RandomAccessRange*, unlike bounded that requires *SinglePassRange*. *bounded* code is based on *indexed* adaptor code, I think it is more efficient than *sliced* ( that uses *make_iterator_range* --> std::advance ). I don't know if this behavior can be achieved using other adapters, if so, please let me know. Is there interest in this for Boost? Regards, Fernando.

5 12

[parameter] aux_/void.hpp: potential undefined behavior
by Krzysztof Czainski 05 Nov '11

05 Nov '11

Hello, Here's boost/aux_/void.hpp contents, without include quards and license note, where I marked a line with a comment to refer to it below. [code] namespace boost { namespace parameter { // A placemarker for "no argument passed." // MAINTAINER NOTE: Do not make this into a metafunction struct void_ {}; namespace aux { inline void_& void_reference() { static void_ instance; // (1) return instance; } } // namespace aux }} // namespace boost::parameter [/code] My question is: is it allowed to use an instance of an uninitialized empty struct? The struct void_ is empty. On line (1) a static uninitialized instance of struct void_ is defined, and it is then returned. Does the standard allow this? I can't imagine any real problems with this, but I'm curious if this has defined behavior according to the standard. A natural and simple solution to my concern is of course to change the line (1) to: static void_ instance = {}; I'd be happy to create a ticket with a patch, if my concern is valid. Regards, Kris

3 5

[lockfree] review
by Gordon Woodhull 05 Nov '11

05 Nov '11

Hi Tim, Hopefully I'll have at least a partial review. I only know enough about the subject to be a little dangerous. (One course in concurrent data structures, one successfully implemented lockfree hash table - except for the memory reclamation. Unspecified barriers and ABA problems. :p ) Considering the difficulty of the subject, you seem to have carefully chosen a small set of algorithms where at least there is consensus that the sources you are using have solved the problem correctly. I apologize if this has already been covered, but I don't see anything in the documentation about which platforms and compilers this has been tested on. These algorithms are extremely susceptible to compiler and processor optimizations. Anyway, I thought I would try to run the tests, and maybe try changing the testing methodology a little, but I got a few compiler errors, below. Defining uint fixed most of these, but bench_1.cpp also appears to be out of date? Of course I also have my lack of understanding of boost build library linking to contend with. Hope to try again later. Cheers, Gordon ~/lib/boost_lockfree/libs/lockfree/test ~/src/boost-trunk grodo-mcwoohu:test gordon$ bjam ...found 141 targets... ...updating 21 targets... darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi/bench_1.o g++: unrecognized option '-no-cpp-precomp' bench_1.cpp: In function 'void test_fifo_pop()': bench_1.cpp:67:23: error: no matching function for call to 'boost::lockfree::fifo<long int>::dequeue(long int*)' ../../../boost/lockfree/fifo.hpp:214:10: note: candidate is: bool boost::lockfree::detail::fifo<T, freelist_t, Alloc>::dequeue(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] bench_1.cpp: In function 'void test_fifo_pop_unsafe()': bench_1.cpp:77:30: error: no matching function for call to 'boost::lockfree::fifo<long int>::dequeue_unsafe(long int*)' ../../../boost/lockfree/fifo.hpp:255:10: note: candidate is: bool boost::lockfree::detail::fifo<T, freelist_t, Alloc>::dequeue_unsafe(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] bench_1.cpp: In function 'void test_stack_pop()': bench_1.cpp:87:19: error: no matching function for call to 'boost::lockfree::stack<long int>::pop(long int*)' ../../../boost/lockfree/stack.hpp:179:10: note: candidate is: bool boost::lockfree::stack<T, freelist_t, Alloc>::pop(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] bench_1.cpp: In function 'void test_stack_pop_unsafe()': bench_1.cpp:97:26: error: no matching function for call to 'boost::lockfree::stack<long int>::pop_unsafe(long int*)' ../../../boost/lockfree/stack.hpp:207:10: note: candidate is: bool boost::lockfree::stack<T, freelist_t, Alloc>::pop_unsafe(T&) [with T = long int, freelist_t = boost::lockfree::caching_freelist_t, Alloc = std::allocator<long int>] "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -dynamic -no-cpp-precomp -gdwarf-2 -fexceptions -fPIC -I"../../.." -c -o "../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi/bench_1.o" "bench_1.cpp" ...failed darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi/bench_1.o... ...skipped <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1 for lack of <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1.o... ...skipped <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1.run for lack of <p../../../bin.v2/libs/lockfree/test/bench_1.test/darwin-4.5.3/debug/threading-multi>bench_1... darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi/fifo_test.o g++: unrecognized option '-no-cpp-precomp' fifo_test.cpp:103:18: error: 'uint' does not name a type fifo_test.cpp: In member function 'void fifo_tester<freelist_t>::add()': fifo_test.cpp:116:14: error: 'uint' was not declared in this scope fifo_test.cpp:116:19: error: expected ';' before 'i' fifo_test.cpp:116:26: error: 'i' was not declared in this scope fifo_test.cpp:116:31: error: 'nodes_per_thread' was not declared in this scope fifo_test.cpp: In member function 'void fifo_tester<freelist_t>::run()': fifo_test.cpp:187:1: error: 'nodes_per_thread' was not declared in this scope "g++" -ftemplate-depth-128 -O0 -fno-inline -Wall -g -dynamic -no-cpp-precomp -gdwarf-2 -fexceptions -fPIC -I"../../.." -c -o "../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi/fifo_test.o" "fifo_test.cpp" ...failed darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi/fifo_test.o... ...skipped <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test for lack of <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test.o... ...skipped <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test.run for lack of <p../../../bin.v2/libs/lockfree/test/fifo_test.test/darwin-4.5.3/debug/threading-multi>fifo_test... darwin.link ../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test ld: library not found for -lboost_thread collect2: ld returned 1 exit status "g++" -o "../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test" "../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test.o" -lboost_thread -lboost_unit_test_framework -g ...failed darwin.link ../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi/freelist_test... ...skipped <p../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi>freelist_test.run for lack of <p../../../bin.v2/libs/lockfree/test/freelist_test.test/darwin-4.5.3/debug/threading-multi>freelist_test... darwin.compile.c++ ../../../bin.v2/libs/lockfree/test/ringbuffer_test.test/darwin-4.5.3/debug/threading-multi/ringbuffer_test.o g++: unrecognized option '-no-cpp-precomp' ringbuffer_test.cpp:209:14: error: 'uint' does not name a type ringbuffer_test.cpp: In member function 'void ringbuffer_tester::add()': ringbuffer_test.cpp:225:14: error: 'uint' was not declared in this scope ringbuffer_test.cpp:225:19: error: expected ';' before 'i' ringbuffer_test.cpp:225:26: error: 'i' was not declared in this scope ringbuffer_test.cpp:225:31: error: 'nodes_per_thread' was not declared in this scope ringbuffer_test.cpp: In member function 'void ringbuffer_tester::run()': ringbuffer_test.cpp:284:1: error: 'nodes_per_thread' was not declared in this scope ringbuffer_test.cpp: In member function 'void ringbuffer_tester_buffering::add()': ringbuffer_test.cpp:315:14: error: 'uint' was not declared in this scope ringbuffer_test.cpp:315:19: error: expected ';' before 'i' ringbuffer_test.cpp:315:26: error: 'i' was not declared in this scope ringbuffer_test.cpp:315:31: error: 'nodes_per_thread' was not declared in this scope ringbuffer_test.cpp: In member function 'void ringbuffer_tester_buffering::run()': ringbuffer_test.cpp:386:1: error: 'nodes_per_thread' was not declared in this scope

8 63

Re: [boost] [lockfree] review
by Boehm, Hans 05 Nov '11

05 Nov '11

[Dave Abrahams pointed me at this thread.] Alexander Terekhov <terekhov <at> web.de> writes: > > Dave Abrahams wrote: > > > > on Thu Aug 25 2011, Alexander Terekhov <terekhov-AT-web.de> wrote: > > > > > Ilya Sokolov wrote: > > >> > > >> > > >> AFAIK, in the example above another thread can't observe reordering > > >> without introducing UB. > > > > > > I meant "observed" as in "check the sequence of writes in the generated > > > code". > > > > Do we care about what the generated code looks like? IIUC what counts > > is the sequence of memory states that another another thread can see. > > > > > But int can be simply changed to relaxed atomic<int> so that another > > > thread can observe reordering without UB. > > > > Sure. > > I meant that for the example upthread, with an int instead of relaxed > atomic<int>, another thread's code triggering UB does not prevent us > from observing reordered writes in the writing thread's code (in > generated code), by looking at it. > > Changing int to relaxed atomic<int> simply removes UB but does not > change the relevant code in the writing thread. > > regards, > alexander. > I agree with Alexander and most of the recent postings. If I write mx.lock(); x = 1; mx.unlock(); my.lock(); y = 1; my.unlock(); There is nothing to prevent the stores to x and y from becoming visible out of order at the hardware level. Enforcing ordering here would add needless and substantial cost. But a data-race-free program cannot observe such reordering. (One reference for that is Sarita Adve's and my PLDI 08 paper. Unofficial TR version at http://www.hpl.hp.com/techreports/2008/HPL-2008- 56.html. I believe Mark Batty et al have a much more complete and formal proof.) If we change x and y to be atomic variables, and the stores to be memory_order_relaxed, then an observer can tell the difference. I.e. if x and y are initially zero, and another thread does r1 = y; r2 = x; (or the acquire versions), it can see r1 = 1 and r2 = 0, since there are no synchronizes-with relationships between threads, and thus nothing to enforce ordering. If you use memory_order_relaxed, or even the acquire/release forms, things do get MUCH more complicated. The equivalent rules for other languages are an interesting story. I believe Posix implentors assume the above rules. I have a PPoPP 2007 paper that explains why that's not exactly what Posix actually states. OpenMP 3.0 has stricter rules which are also not consistently obeyed, and are somewhat fixed in OpenMP 3.1. (See my MSPC 11 paper for some details.) Java has arguably the same rules as C++ in this respect. In my mind, the main way in which sequential consistency differs from the cheaper acquire/release semantics that Alexander wants is that a) Dekker's algorithm (which by itself isn't that practically interesting), plus a number of real lock-free algorithms (which do matter) don't work. b) In my mind, acquire/release is a far more difficult model to explain to non- experts than the model for C++ with only sequentially consistent atomics. You can no longer reason about interleaving thread actions, either for purposes of determining the existence of a data-race, nor when defining what data-race- free programs mean. This was extensively discussed in C++ meetings starting in about 2005. The current solution with default-sequentially-consistent atomics, but explicit support for weaker ordering, was the resulting committee compromise. Hans

6 19

Determining interest in Delegates submission
by Jared McKee 05 Nov '11

05 Nov '11

I would like to determine interest in a possible library submission. I have written some code which converts a member function and object pointer combination to a free function for use in C style callbacks. It has some limitations which I will describe shortly. The basic idea is to be able to convert: R (B::*)(T0,T1,…) and B* to R (*)(T0,T1,…) Here's an example usage: class foo { int x; int test(int v) {return x + v;} }; foo* a = new foo; a->x = 3; int (*f)(int) = delegate(a, &foo::inc); cout << f(4) << endl; // outputs "7" When I first attempted this I used a technique where I allocated some executable memory in the heap and dynamically created a free function to call the member function for the instance. It was fun attempting that but, as you can imagine, as soon as I used the optimizer flags on my compiler I would get segment faults :) My second approach was to use templates and the Boost Preprocessor library to create appropriate static arrays of pointers to free functions matching the required signatures and then hand those pointers out each time the delegate() function is called. The two downsides to this are: you can only call delegate() for a certain function signature a limited number of times, and it adds a lot of potentially unused code to your executable. Here's the code (I've stripped out error checking for the sake of illustration): #include <boost/preprocessor.hpp> #ifndef _delegate_h_ #define _delegate_h_ #define MAX_DELEGATES 256 #define DELEGATE_PARAMS 0 #include "delegate_template.hpp" #undef DELEGATE_PARAMS #define DELEGATE_PARAMS 1 #include "delegate_template.hpp" #undef DELEGATE_PARAMS // … #endif // delegate_template.hpp #define DELEGATE_STORE BOOST_PP_CAT(DELEGATE_STORE,**DELEGATE_PARAMS) template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > struct DELEGATE_STORE { typedef B* objectPointer; typedef R (B::*memberFunction)( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ); typedef R (*freeFunction)( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ); static int delegateCount; static int delegateMax; static objectPointer delegateObjectPointer[MAX_**DELEGATES]; static memberFunction delegateMemberFunction[MAX_**DELEGATES]; template <int i> static R func( BOOST_PP_ENUM_BINARY_PARAMS(**DELEGATE_PARAMS, T, v) ) { return (delegateObjectPointer[i]->***delegateMemberFunction[i])( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, v) ); } static const freeFunction delegateFreeFunction[MAX_**DELEGATES]; static freeFunction getDelegate(objectPointer o, memberFunction m) { int delegateIndex = delegateCount++; delegateObjectPointer[**delegateIndex] = o; delegateMemberFunction[**delegateIndex] = m; return delegateFreeFunction[**delegateIndex]; } }; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > int DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::delegateCount = 0; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > int DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::delegateMax = MAX_DELEGATES; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > typename DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::memberFunction DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) > ::delegateMemberFunction[MAX_**DELEGATES] = {0}; > template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > typename DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::objectPointer DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) > ::delegateObjectPointer[MAX_**DELEGATES] = {0}; > #define FUNC_POINTER(z, n, params) &DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::template func< n >, template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > const typename DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::freeFunction DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) > ::delegateFreeFunction[MAX_**DELEGATES] = { > BOOST_PP_REPEAT(MAX_DELEGATES, FUNC_POINTER,) }; template <class B, class R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, class T) > R (*delegate( B* b, R (B::*f)( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ) ))( BOOST_PP_ENUM_PARAMS(DELEGATE_**PARAMS, T) ) { return DELEGATE_STORE<B,R BOOST_PP_ENUM_TRAILING_PARAMS(**DELEGATE_PARAMS, T) >::getDelegate(b, f); } // end Thankyou very much if you managed to read all the way to here! By the way, this is my first active participation in any open source project :) Jared

3 5

[BGL] map_as_graph.hpp
by Shaun Jackman 04 Nov '11

04 Nov '11

Hi, In the spirit of vector_as_graph.hpp, I created map_as_graph.hpp. One useful feature is that the vertex_descriptor can be any user-defined type, such as a string or an arbitrary object. It's not in a form that's ready to be included in Boost, but I have found it occasionally useful. I though I'd post it in the case that someone else found it useful. If someone found it useful enough that he or she where interested in further developing to the point where it could be included in Boost, please be my guest. Cheers, Shaun #ifndef MAP_AS_GRAPH_HPP #define MAP_AS_GRAPH_HPP 1 #include <boost/graph/graph_traits.hpp> #include <cassert> #include <map> #include <utility> // for make_pair namespace boost { /** * A std::map is a model of a directed graph. * @author Shaun Jackman <sjackman(a)gmail.com> */ template <typename V, typename T> struct graph_traits<std::map<V, T> > { // Graph typedef V vertex_descriptor; typedef boost::directed_tag directed_category; struct traversal_category : boost::adjacency_graph_tag, boost::vertex_list_graph_tag { }; typedef boost::disallow_parallel_edge_tag edge_parallel_category; // IncidenceGraph typedef std::pair<vertex_descriptor, vertex_descriptor> edge_descriptor; typedef size_t degree_size_type; /** Iterate through the out edges of a vertex. */ struct out_edge_iterator : std::map<V, typename T::mapped_type>::const_iterator { typedef typename std::map<V, typename T::mapped_type>::const_iterator It; out_edge_iterator(const It& it, vertex_descriptor src) : It(it), m_src(src) { } edge_descriptor operator*() const { return edge_descriptor(m_src, It::operator*().first); } private: vertex_descriptor m_src; }; // BidirectionalGraph typedef void in_edge_iterator; // AdjacencyGraph /** Iterate through the adjacent vertices of a vertex. */ struct adjacency_iterator : std::map<V, typename T::mapped_type>::const_iterator { typedef typename std::map<V, typename T::mapped_type>::const_iterator It; adjacency_iterator(const It& it) : It(it) { } const vertex_descriptor& operator*() const { return It::operator*().first; } }; // VertexListGraph /** Iterate through the vertices of this graph. */ struct vertex_iterator : std::map<V, T>::const_iterator { typedef typename std::map<V, T>::const_iterator It; vertex_iterator(const It& it) : It(it) { } const vertex_descriptor& operator*() const { return It::operator*().first; } }; typedef size_t vertices_size_type; // EdgeListGraph typedef void edge_iterator; typedef void edges_size_type; }; // graph_traits<std::map> // IncidenceGraph template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::out_edge_iterator, typename graph_traits<std::map<V, T> >::out_edge_iterator> out_edges( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typedef typename graph_traits<std::map<V, T> >::out_edge_iterator out_edge_iterator; typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return make_pair( out_edge_iterator(it->second.begin(), u), out_edge_iterator(it->second.end(), u)); } template <typename V, typename T> typename graph_traits<std::map<V, T> >::degree_size_type out_degree( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return it->second.size(); } // AdjacencyGraph template <typename V, typename T> std::pair<typename graph_traits<std::map<V, T> >::adjacency_iterator, typename graph_traits<std::map<V, T> >::adjacency_iterator> adjacent_vertices( typename graph_traits<std::map<V, T> >::vertex_descriptor u, const std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); assert(it != g.end()); return make_pair(it->second.begin(), it->second.end()); } // VertexListGraph template <typename V, typename T> std::pair<typename graph_traits<std::map<V, T> >::vertex_iterator, typename graph_traits<std::map<V, T> >::vertex_iterator> vertices(const std::map<V, T>& g) { return make_pair(g.begin(), g.end()); } // AdjacencyMatrix template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { typename std::map<V, T>::const_iterator it = g.find(u); return std::make_pair(make_pair(u, v), it == g.end() ? false : it->second.count(v) > 0); } // VertexMutableGraph template <typename V, typename T> void remove_vertex( typename graph_traits<std::map<V, T> >::vertex_descriptor u, std::map<V, T>& g) { size_t n = g.erase(u); assert(n == 1); (void)n; } // EdgeMutableGraph template <typename V, typename T> void clear_out_edges( typename graph_traits<std::map<V, T> >::vertex_descriptor u, std::map<V, T>& g) { typename std::map<V, T>::iterator it = g.find(u); assert(it != g.end()); it->second.clear(); } template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> add_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { typename edge_property<std::map<V, T> >::type ep; return make_pair(std::make_pair(u, v), g[u].insert(make_pair(v, ep)).second); } template <typename V, typename T> void remove_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, std::map<V, T>& g) { size_t n = g[u].erase(v); assert(n == 1); (void)n; } // PropertyGraph template <typename V, typename T> no_property get(vertex_bundle_t, const std::map<V, T>&, typename graph_traits<std::map<V, T> >::vertex_descriptor) { return no_property(); } template <typename V, typename T> const typename T::mapped_type& get(edge_bundle_t, const std::map<V, T>& g, typename graph_traits<std::map<V, T> >::edge_descriptor e) { typename std::map<V, T>::const_iterator u = g.find(source(e, g)); assert(u != g.end()); typename T::const_iterator v = u->second.find(target(e, g)); assert(v != u->second.end()); return v->second; } // MutablePropertyGraph namespace boost { template <typename V, typename T> class vertex_property<std::map<V, T> > { public: typedef no_property type; }; template <typename V, typename T> class edge_property<std::map<V, T> > { public: typedef typename T::mapped_type type; }; } template <typename V, typename T> std::pair< typename graph_traits<std::map<V, T> >::edge_descriptor, bool> add_edge( typename graph_traits<std::map<V, T> >::vertex_descriptor u, typename graph_traits<std::map<V, T> >::vertex_descriptor v, typename edge_property<std::map<V, T> >::type ep, std::map<V, T>& g) { return make_pair(std::make_pair(u, v), g[u].insert(std::make_pair(v, ep)).second); } } // namespace boost #endif

1 0

Remembering that T(a) can cause dangerous conversion like a C-style cast
by Kazutoshi Satoda 04 Nov '11

04 Nov '11

An essential question: Should boost::lambda::constructor<int>()("") compiles? It does compile with Boost 1.47.0 . But I think it shouldn't. I have crafted a general replacement of T(a) as a workaround for dangerous conversions caused by T(a) which may happen in some kinds of templates. http://ideone.com/iZE1Z unary_initialized<T>(a).value And I thought of that the above workaround (or something similar) may be suitable to be provided within boost::initialized . Now I want to share the idea and to hear interests or evaluations in the community about such extension and underlying issues, before starting further acts. Here is the background story: A while ago, I had a conversation about dangerous conversion that can be caused by the following expression with variadic templates in C++11. T(std::forward<Args>(args)...) This expression is meant to obtain a prvalue of type T which is direct initialized from any given argument list. But if a single argument was given, this becomes T(std::forward<Arg>(arg)) and further, for example, may become int("") and compiles as reinterpret_cast which is likely unexpected. Here is a relevant quote from the standard 5.2.3 p1: > ... If the expression list is a single expression, the type conversion > expression is equivalent (in definedness, and if defined in meaning) to > the corresponding cast expression (5.4). ... (Note: 5.2.3 describes the behavior of T(a), and 5.4 describes the behavior of (T)a.) To avoid the unexpected conversion, I first proposed use of T{...} . But it is not a perfect solution because it changes the meaning in some cases like std::vector<int> . After that, I crafted a tricky workaround. http://ideone.com/FLoDk pack_initialized<T>(std::forward<Args>(args)...).value The above story was about C++11. But it revealed that similar dangerous conversion can be also formed in C++98, C++03 as T(a) in some kinds of templates. Searching in the boost directory (trunk r75213), I found some occurrences of the problem: boost/lambda/construct.hpp:37: http://www.boost.org/doc/libs/1_47_0/boost/lambda/construct.hpp return T(a1); boost/xpressive/regex_actions.hpp:632: http://www.boost.org/doc/libs/1_47_0/boost/xpressive/regex_actions.hpp return T(a0); As shown in the top of this message, I picked boost::lambda::constructor as a concrete example, and verified that the problem really exists in the wild. Thinking more, I wonder why such dangerous conversion was explicitly injected to T(a) in the first place. I first thought of some C-compatibility issues. But now I think it cannot be, because T(a) is a new construct in C++. Is it possible to remove this dangerous conversion path in a future revision of the standard? Perhaps I should go to comp.std.c++ about the last question. -- k_satoda

2 2

[release][1.48] Several merge requests
by Daniel James 04 Nov '11

04 Nov '11

Hi, Please can I merge the following changes: This prevents standard containers from being forward declared for gcc's 'profile' mode: https://svn.boost.org/trac/boost/changeset/75016 Trivial change to improve a couple of quickbook warnings (obviously not vital, but simple enough): https://svn.boost.org/trac/boost/changeset/75088 In unordered, avoid using a name that clashes with a macro defined by a header included from ASIO: https://svn.boost.org/trac/boost/changeset/75123 Missing html redirect, fixes some links to Boost.Move (documentation change): https://svn.boost.org/trac/boost/changeset/75141 Unordered wasn't working on gcc 4.7 in c++0x mode because of changes to std::pair's constructor. Unfortunately, the gcc 4.7 tester hasn't run since this change and I don't have access to it, so I haven't verified that it fixes the problem. But it does work fine on everything it has been tested with. https://svn.boost.org/trac/boost/changeset/75158 This stops using a hack on Visual C++ which was breaking for certain versions (although it didn't show up on any tester). But this is moving from a hacky implementation to a slightly less capable but more reliable implementation, so I think it's a good change regardless. https://svn.boost.org/trac/boost/changeset/75167 thanks, Daniel

2 1

"Best so far" for C level i/o of Unicode text with Windows console
by Alf P. Steinbach 03 Nov '11

03 Nov '11

This may be of interest to developers of Boost libraries that deal with text. I found that the Visual C++ implementation of the C library i/o generally does not support console input of international characters. It can deal with narrow character input from the current codepage, if that codepage is not UTF-8. For example: <code> #include <stdio.h> int main() { printf( "? " ); char buffer[80]; scanf( "%s", buffer ); printf( "%s\n", buffer ); } </code> <result> d:\dev\test> chcp 1252 Active code page: 1252 d:\dev\test> utf8test ? abcæøå abcæøå d:\dev\test> chcp 65001 Active code page: 65001 d:\dev\test> utf8test ? abcæøå ��, d:\dev\test> _ </result> I placed a comment about this at the blog of Microsoft's Unicode guru Michael Kaplan, http://blogs.msdn.com/b/michkap/archive/2008/03/18/8306597.aspx In particular, with active codepage 65001 (UTF-8), functions such as wscanf just fail outright on non-ASCII characters. The IMO best compromise that I have managed to come up with is a kind of hybrid, where the active input codepage is set to 1252, Windows ANSI Western, because that's a superset of Latin 1 which is a subset of Unicode. Output is converted to UTF-8. Input from e.g. a file accepts UTF-8. This means that e.g. Norwegian text can be input interactively (restricted to Latin 1 character set) or from a pipe or file (as UTF-8) without problems, and can be automatically translated (by the C i/o level) to UTF-16 encoding inside the program. However, I'm guessing that the C level input will garble e.g. Russian text no matter what one does, if one desires some Unicode based encoding inside the program. The Windows and Visual C++ support is just full of bugs -- e.g. as the crash of `more` showed in an earlier thread. Initialization of streams for the compromize scheme: static void msvcCompatibleInit() { struct Fix { static void mode( FILE* f, char const errorText[] ) { int const fileNo = _fileno( f ); bool const isConsoleInput = (f == stdin && _isatty( fileNo )); if( isConsoleInput ) { // Bytes are received as per the active codepage in the console. // Except if that active codepage is 65001, in which case non-ASCII // characters fail. Also, _setmode just causes non-ASCII fail. // // Setting the console codepage to 1252 might be practically helpful, // since cp 1252, Windows ANSI Western, is a superset of Latin 1 // which is a subset of Unicode. However, non-Latin 1 characters will // then be incorrect, just as with web pages in the old days. } else { int const newMode = _setmode( fileNo, _O_U8TEXT ); hopefully( newMode != -1 ) || throwX( errorText ); } } }; Fix::mode( stdin, "_setmode stdin failed" ); Fix::mode( stdout, "_setmode stdout failed" ); Fix::mode( stderr, "_setmode stderr failed" ); } Cheers & hth., - Alf

3 3

[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

[Boost.Endian] Review Results
by joel falcou 03 Nov '11

03 Nov '11

Hi everyone, after some delay, here is the result of the review of Beman Dawes' Boost.Endian library. First, I want to thanks all participants of the review that lead to very deep and interesting discussions on the matter. 5 votes were cast : 2 unconditionally in favor, 3 conditionally in favor after changes made and there is a mini-review. The verdict is that Boost.Endian is **CONDITIONNALY ACCEPTED** Here is what needs to be done to get the library ready for a mini-review: * Common use case scenarios should be developed. * Example programs should be developed for the common use case scenarios. * Documentation should illuminate the differences between endian integer/float type and endian conversion approaches to the common use case scenarios, and provide guidelines for choosing the most appropriate approach in user's applications. * Conversion functions supplying results via return should be provided. * Platform specific performance enhancements such as use of compiler intrinsics or relaxed alignment requirements should be supported. * Endian integer (and floating) types should be implemented via the conversion functions. If that can't be done efficiently, consideration should be given to expanding the conversion function signatures to resolve the inefficiencies. * Benchmarks that measure performance should be provided. It should be possible to compare platform specific performance enhancements against portable base implementations, and to compare endian integer approaches against endian conversion approaches for the common use case scenarios. * Float (32-bits) and double (64-bits) should be supported. IEEE 754 is the primary use case. * Support for user defined types (UDTs) is desirable, and should be provided where there would be no conflict with the other concerns. * There is some concern that endian integer/float arithmetic operations might used inadvertently or inappropriately. The impact of adding an endian_buffer class without arithmetic operations should be investigated. * Stream insertion and extraction of the endian integer/float types should be documented and included in the test coverage. * Binary I/O support that was investigated during development of the Endian library should be put up for mini-review for inclusion in the Boost I/O library. From this point, I will let Beman prepare Endian for the mini-review and I already volunteer to manage the mini-review so informations are not scattered around. Regards

1 0

[tree] more questions (was: [tree] associative containers)
by Cromwell Enage 03 Nov '11

03 Nov '11

From: Erik Erlandson > I'm not entirely sure about the relative merits of that versus defining > a parallel zoology of Hierarchical Containers that is basically > isomorphic to the traditional Container hierarchy, and leaving the > cursor definition more lightweight: perhaps just "iterator plus > parent(), begin() and end()", or alternatively not having a separate > cursor type, and simply having traditional iterators over children at > any given node. I'm curious as to what tree algorithms can take better advantage of the cursor interface as-is. Also: * What are the primary differences between a plain hierarchy and a multiway hierarchy? * Why shouldn't one assume that an on-top cursor is dereferenceable? TIA, Cromwell D. Enage

1 0

[tree] associative containers
by Cromwell Enage 03 Nov '11

03 Nov '11

I've been studying the tree proposal to see how I could write adaptors in my tree_node library (now at version 0.2 in the sandbox) that conform to the current concepts. Is there anything in the proposal that is analogous to a PairAssociativeContainer? My tree_node library defines an AssociativeTreeNode concept and a couple of models that I've found to be useful, e.g. for implementing decision tree learning algorithms. Cromwell D. Enage

2 2

[1.48][math] Permission to merge to release branch
by John Maddock 03 Nov '11

03 Nov '11

I'd like to merge this Clang fix to release if possible: https://svn.boost.org/trac/boost/changeset/75152 The change basically just moves code from one header to another, so it's defined at the point of first use. Thanks, John.

2 2

[BGL] How to provide a vertex_index property for my graph
by ShNaYkHs ShNaYkHs 03 Nov '11

03 Nov '11

Hello, Since my graph use setS as a VertexList, I have to either provide a vertex_index property map for my graph to be able to use some functions requiring a vertex_index (e.g. write_graphviz). My graph is defined as: typedef adjacency_list<setS, setS, undirectedS, NodeData, EdgeData> Graph; Where NodeData and EdgeData are structures. Can you please give me a very simple example of how to provide a vertex_index property map for my graph ? I mean, since an adjacency_list that uses listS or setS as the vertex container does not automatically provide this vertex_id property, how can I add it to the code bellow ? I tried to use an associative_property_map to include index for vertices, but it doesn't work (errors): #include <boost/graph/iteration_macros.hpp> #include <boost/graph/adjacency_list.hpp> using namespace std; using namespace boost; struct NodeData { int label; float influance; /* etc ... */ }; struct EdgeData { int age; /* etc ... */ }; typedef map<vecS, size_t> IndexMap; IndexMap mapIndex; associative_property_map<IndexMap> propmapIndex(mapIndex); typedef adjacency_list<setS, setS, undirectedS, NodeData, EdgeData> Graph; typedef Graph::vertex_descriptor NodeID; typedef Graph::edge_descriptor EdgeID; int main() { Graph g; NodeID n0 = add_vertex(g); g[n0].label = -1; NodeID n1 = add_vertex(g); g[n1].label = -1; EdgeID edge; bool ok; tie(edge, ok) = boost::add_edge(n0, n1, g); if (ok) g[edge].age = 10; int i=0; BGL_FORALL_VERTICES(v, g, Graph) { put(propmapIndex, v, i++); } return 0; } Thanks for answer.

2 3

Boost.Algorithm design question
by Marshall Clow 03 Nov '11

03 Nov '11

So, what do people prefer (and why?): template<typename InputIterator, typename V> bool none_of_equal ( InputIterator first, InputIterator last, V const &val ) { for ( ; first != last; ++first ) if ( val == *first ) return false; return true; } or template<typename InputIterator, > bool none_of_equal ( InputIterator first, InputIterator last, iterator_traits<InputIterator>::value_type const &val ) { for ( ; first != last; ++first ) if ( val == *first ) return false; return true; } In the first case, I think there's (possible) conversion from V to iterator_traits<InputIterator>::value_type each time through the loop. In the second case, there is not. Of course, the (mythical?) smart compiler would do the conversion once and save the result for reuse. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

17 79

[1.48.0 Beta 1][fusion] MacTypes.h conflict with nil
by Jeff Flinn 03 Nov '11

03 Nov '11

reposted from "[1.48.0] Beta 1 is now available from SourceForge" thread for better visibilty. Mac 10.6 Xcode 3.2.6 gcc 4.2: In compiling our application, upgrading from boost_1_44_0 I get conflicts with MacTypes.h define of nil when compiling cons_fwd.hpp from fusion. Any thoughts? Jeff

3 3

Interest in boost.deepcopy
by Allan Johns 02 Nov '11

02 Nov '11

Just gauging initial interest in a boost.deepcopy library, analogous to deepcopy in python. Each type would register deepcopy behaviour with the library (there are similarities to boost.serialize). Boost.deepcopy would supply out-of-the-box registration for pod types, pointer types, arrays, stl containers and common boost containers. Example: template<typename T> void deepcopy(deepcopycontext& ctxt, const T& obj) { ...; } Why not use boost::serialize and serialize into memory then out again I hear you say? That's a great approach, but only when every object requires the same deepcopy behaviour (also, it's not too optimal). The problem is, I need specific behaviour in some types. Specifically, I need copy-on-write behaviour for a Buffer class that I'm using. For example: void deepcopy(deepcopycontext& ctxt, const Buf& b) { if(!ctxt.contains(&b)) { Buf b2(b); // doesn't copy the buf data, just holds a shared ptr internally. Data is only cloned when b/b2 is written to ctxt.insert(&b, b2); } } I attempted to model this a while ago using boost.serialize, but it turned out pretty clunky, I started needing a few decorator classes for special cases, etc. Apologies for the oversimplified examples above, just wanting to get interest in the jist of it. Please let me know if this overlaps with existing boost functionality also (I'm not aware of anything atm). Feedback appreciated. Thx, Allan

9 18

[ratio] Request for permission to merge to release branch
by Vicente J. Botet Escriba 02 Nov '11

02 Nov '11

Hi, I want to merge https://svn.boost.org/trac/boost/changeset/75240 to the release branch. The modifications are minor and correct to tickets: https://svn.boost.org/trac/boost/ticket/5724 and https://svn.boost.org/trac/boost/ticket/6082. Best, Vicente

3 3

[multi_array] Ticket#4874 "multi_array compile errors using Visual C++ 2010 in debug mode"
by Stephan T. Lavavej 02 Nov '11

02 Nov '11

Hi Boost devs, VC10 users are occasionally encountering https://svn.boost.org/trac/boost/ticket/4874 and reporting it to MS. For example, see http://connect.microsoft.com/VisualStudio/feedback/details/687655/compilati… where I've explained what's going on (I wrote this analysis back in Feb 2010 and I believe it's still correct): The problem is that multi_array iterators report themselves as input iterators, which can't be written to (e.g. as the destination of a copy()). Under IDL=0, copy() doesn't actually care how its destination iterator is marked with an iterator category tag, it just tries to write to the destination iterator, and that works. Under IDL > 0, copy() wants to know whether its source and destination iterators are both random-access, in which case it can perform a range check and unwrap the destination iterator for increased performance. It does this by overloading foo(input_iterator_tag, output_iterator_tag) and foo(random_access_iterator_tag, random_access_iterator_tag) and calling foo(category(source), category(destination)). If both source and destination are random-access, both overloads are viable (i.e. callable) and the second overload is preferred, so it's actually called. Otherwise, source is required to be at least an input iterator (maybe stronger) and destination is required to be at least an output iterator (maybe stronger) so the first overload must be viable and the second overload will be non-viable, so the first overload wins by default. However, if the destination is not marked as an output iterator or stronger, then the first overload is non-viable as well as the second, so overload resolution fails and boom. Thanks, Stephan T. Lavavej Visual C++ Libraries Developer

2 1

boost mapped_file issue
by dophine 02 Nov '11

02 Nov '11

Hi all, I try to use memory map file. However, I don't know why the readsome return 0. It is fine if I use getline. int main(int argc,char *argv[]) { boost::iostreams::mapped_file_source source(argv[1]); boost::iostreams::stream<boost::iostreams::mapped_file_source> input(source); while(!input.eof()) { char b[1]; streamsize iRet = input.readsome(b, 1); cout << iRet << endl; cout << b[iRet]; } //std::string line; //while(std::getline(input, line)) { // std::cout << "Line: " << line << std::endl; //} return 1; } -- View this message in context: http://boost.2283326.n4.nabble.com/boost-mapped-file-issue-tp3971495p397149… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 2

[locale] Premission to merge clang bugfix changeset to release tree
by Artyom Beilis 02 Nov '11

02 Nov '11

Hello, I'd like to ask a permission to merge a changeset 75174 from trunk to release tree. It is a fix of build issue under clang-2.9 and clang-3.0. See: https://svn.boost.org/trac/boost/changeset/75174 The changeset itself: ------------------------- Index: /trunk/libs/locale/src/posix/codecvt.cpp =================================================================== --- /trunk/libs/locale/src/posix/codecvt.cpp (revision 73382) +++ /trunk/libs/locale/src/posix/codecvt.cpp (revision 75174) @@ -135,5 +135,5 @@ // maybe illegal or may be double byte - char inseq[3] = {seq0 , begin[1], 0}; + char inseq[3] = { static_cast<char>(seq0) , begin[1], 0}; char *inbuf = inseq; size_t insize = 3; ------------------------- It solves build issues as I can see at trunk tests. Thanks, Artyom Beilis -------------- CppCMS - C++ Web Framework: http://cppcms.sf.net/ CppDB - C++ SQL Connectivity: http://cppcms.sf.net/sql/cppdb/

3 2

[atomic] comments
by Tim Blechmann 01 Nov '11

01 Nov '11

hi helge and others, ... has been rather quiet about the boost.atomic review, so i want to raise a view issues: shared memory support: the fallback implementation relies on the spinlock pool that also used by the smart pointers. however this pool is per-process, so the fallback implementation won't work in shared memory. can this be changed/fixed? atomic::is_lock_free(): is_lock_free is set to either `true' or `false'. however in some cases, there are alignment constraints (iirc, 64bit atomics on ia32/x86_64 require a 64bit alignment). afaict there are not precautions to take care of this, are there? compile-time vs run-time dispatching: some instructions are not available on every CPU of a specific architecture. e.g. cmpxchg8b or cmpxchg16b are not available on all ia32/x86_64 cpus. i would appreciate if these instructions would not be used before performing a CPUID check, whether these instructions are really available (at least in a legacy mode) cmpxchg16b: currently cmpxchg16b doesn't seem to be supported. this instruction is required for some lock-free data structures (e.g. there is a dequeue algorithm, that requires a pair of tagged pointers). maybe this can be a starting point to discuss boost.atomic ... cheers, tim

6 38

Re: [boost] [atomic] comments
by Helge Bahmann 01 Nov '11

01 Nov '11

> > > > > e.g. i would not trust on accessing sockets from a > > > > > real-time thread. > > > > > > > > what makes you believe that message channels in real-time systems > > > > were > > > > designed so dumb as to make them unusable for real-time purposes? > > > > > > life would be so much easier for me, if the users of my software would > > > not run on off-the-shelf operating systems ;) > > > > and what makes you believe that the performance characteristics of > > sockets in off-the-shelf operating systems is unsuitable for real-time, > > while the process scheduling characteristics of process scheduling in > > off-the-shelf operating systems is suitable for real-time? > > i cannot comment on windows, but both osx and linux provide ways to > schedule a thread at a priority that it won't be preempted by any other > thread, so the process scheduler won't interfere. that answers the second part but not the first (and is getting off-topic from atomic operations) > > > > right, but the standard implementation for gcc does not use a > > > > spinlock > > > > per object (see __atomic_flag_for_address) which turns all of this > > > > moot - there is NO guarantee for std::atomic to be safe > > > > interprocess, period> > > > > > > well, i'd say this is a problem of gcc's implementation of std::atomic. > > > this doesn't justify that boost.atomic does not follow the suggestion > > > of the standard. > > > > the standard says "should" not "must" -- the gcc guys have not made this > > decision without good reasons, and I agree with these reasons > > > > note that there is also trouble lurking with run-time selection of > > whether something like atomic<uint64_t> is atomic via cmpxchg8b: do you > > really want to make this at minimum 12 bytes in size (though effectively > > occupying 16 due to alignment) just to save the room for the > > rarely-if-ever used per-object spinlock? same with atomic<128> and > > cmpxchg16b ? > > i don't really care about the size of an atomic<>. but I *do* care and believe it or not there are people writing applications that are memory-bound (doubling the overhead of the reference count in each of several millions of objects is *not* funny) > one other point for > runtime selection is compatibility. e.g. you may have two binaries, one is > compiled with support for double-width CAS, the other one without. with > compile-time dispatching the behavior would be undefined, with run-time > selection, it would be handled gracefully ... I don't quite understand the point -- quite obviously nothing good will happen if the applications do not agree on a protocol, and there is nothing that can be salvaged if they do agree on the objects being lock-free, fine if they do agree on the objects not being lock-free, well then explicit locking is faster anyways and you should use your "locked" reference implementation of the data structure that you surely wrote to run suitable regression tests of your lock-free data structure > > 2. What is wrong with implementing boost::interprocess::atomic<T> that > > specializes to boost::atomic<T> when possible and uses an interprocess > > lock otherwise? > > will you provide an implementation? people were asking for > boost::interprocess support during the boost.lockfree review. the only > missing feature is the atomic<> implementation. no problem Best regards Helge

1 0

[config] clang.hpp is not up-to-date
by Michel Morin 01 Nov '11

01 Nov '11

boost/config/compiler/clang.hpp is not up-to-date. For example, BOOST_NO_AUTO_DECLARATIONS is *always* defined (even if clang supports this feature). Is it worth fixing this on the release branch? P.S. I can make a patch, but before doing that I'd like to confirm whether __has_feature(cxx_auto_type) means that multi-declarator auto is supported or not. The following page says nothing about multi-declarator auto. http://clang.llvm.org/docs/LanguageExtensions.html Doug? Regards, Michel

3 4

Silly Boost.Locale default narrow string encoding in Windows
by Alf P. Steinbach 01 Nov '11

01 Nov '11

When I engage the compiler-in-my-mind to the example given at http://cppcms.sourceforge.net/boost_locale/html/ namely <code> #include <boost/locale.hpp> #include <boost/filesystem/path.hpp> #include <boost/filesystem/fstream.hpp> int main() { // Create and install global locale std::locale::global(boost::locale::generator().generate("")); // Make boost.filesystem use it boost::filesystem::path::imbue(std::locale()); // Now Works perfectly fine with UTF-8! boost::filesystem::ofstream hello("שלום.txt"); } </code> then it fails to work when the literal string is replaced with a `main` argument. A conversion is then necessary and must be added. It breaks the principle of least surprise. It breaks the principle of not paying for what you don't (want to) use. I understand, from discussions elsewhere, that the author(s) have chosen a narrow string encoding that requires inefficient & awkward conversions in all directions, for political/religious reasons. Maybe my understanding of that is faulty, that it's no longer politics & religion but outright war (and maybe that war is even over, with even Luke Skywalker dead or deadly wounded). However, I still ask: why FORCE INEFFICIENCY & AWKWARDNESS on Boost users -- why not just do it right, using the platforms' native encodings. Cheers, - Alf

9 43

[unordered] 1.48 beta1 fails to compile with MSVC 2010 SP 1, error C2027: use of undefined type 'boost::type'
by Johan Lindvall 01 Nov '11

01 Nov '11

After trying out beta 1, I am seeing some failures with unordered containers, see attached file. Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64 The code compiles without problems under 1.47.0. Unfortunately, I cannot yet publish the source code that triggers this problem. Any hints where to start investigating this? -- /Johan.

2 5

[multi_array] typed subarray from raw memory
by Maxim Yanchenko 01 Nov '11

01 Nov '11

Hi, While using multi_array, I found I frequently need a way to view some memory which is a multi-dimensional array and I don't know the type of the element, but I know its size and I know that this element has a member of the type I need (and I know the offset). So I need to be able to write something like struct A { double x, y; }; void* p = mmap(...); size_t el_size = size_of_element_in_p; size_t offset = offset_of_A_inside_element; boost::multi_array_typed_view<A, NumDims> my_view(p, extents, el_size, offset ); and have a standard multi_array-compatible interface. Also, with existing multi_arrays of known types, this feature will give a way to create views of element's members (the closest we have now is a strided view but it only works if the element size is a multiple of the member size). I filed a Feature Request for multi_array (https://svn.boost.org/trac/boost/ticket/6073) but I wonder if there are any other possibilities around, and I'd also like to know what the community think of necessity of this feature. Thanks, Maxim

1 0