May 2014 - Boost - lists.boost.org

A GUI Library
by jinhao 09 Nov '17

09 Nov '17

Hi, all I am developing a GUI library, it takes aim at easy-to-use and portable library for modern C++ methods. The project at http://stdex.sourceforge.net A git repository at http://nanapro.codeplex.com A brief at http://nanaproject.wordpress.com/2011/12/16/preliminary-study-of-nana-c-lib… Is there any interest in this library? Regards Jinhao

8 8

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

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

5 8

[context] msvc /SAFESEH
by Jeff Flinn 12 Aug '15

12 Aug '15

I need to build my application with /SAFESEH which uses boost coroutine which uses context. I'm getting the following link errors: 1>libboost_context-vc100-mt-gd-1_53.lib(jump_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. 1>libboost_context-vc100-mt-gd-1_53.lib(make_i386_ms_pe_masm.obj) : error LNK2026: module unsafe for SAFESEH image. I've built boost static libs with the same MSVC vesion and options (sans /SAFESEH as it's not a compile/lib option) Compiler/linker versions: Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.40219.01 for 80x86 Microsoft (R) Incremental Linker Version 10.00.40219.01 Has anyone run into this and resolved the error? Any insight is appreciated. Thanks, Jeff

3 9

Arguing about names in Boost libraries
by Edward Diener 07 May '15

07 May '15

What is wrong with the people commenting on libraries for Boost who are so concerned about the names being used ? We are talking only about C++ identifiers and yet there are now endless discussions where people disagree on names or argue that some name is not what they want or that they like some other name, with a list of names that they find adequate. This is irrelevant. There is something mentally wrong about all those peoples spending endless amounts of time around this issue. I notice this does not happen nowadays for just one library but for ever single library, or proposed library, which is mentioned on this mailing list. Is this the way all of you people actually work in your daily jobs, or on your own projects, spending hours and days arguing with others about C++ identifiers for every little thing ? Are you not aware of the absurdity of your endless remarks ? Grow up ! Surely there are better things to do than carry on endlessly about some name, that is should be x or y or z or some other inane preferable list. It's time for somebody to say this, so I will do it. A C++ identifier name, as long as it is vaguely about what the functionality entails, is perfectly adequate. It does not have to satisfy everyone in the universe. Period !

9 10

Interactive metaprogramming shells
by Abel Sinkovics 28 Dec '14

28 Dec '14

Hi, I've built interactive shells for preprocessor and template metaprogramming. I've been using them for development and debugging of metaprograms and I think Boost developers could also find them useful. You can type in (metaprogramming) expressions which get evaluated and the result is displayed immediately. For example you can type boost::mpl::push_front<boost::mpl::vector<int, char>, double>::type and you get boost_::mpl::vector<double, int, char> as the result (the boost_ namespace is used because there are some tricks there to make the output more readable). As an example for the preprocessor shell you can type BOOST_PP_REPEAT(3, foo BOOST_PP_TUPLE_EAT(3), ~) and you get foo foo foo as the result. The tools are based on the Boost.Wave library and Clang. You can get them here: Preshell for preprocessor: https://github.com/sabel83/preshell Metashell for template metaprograms: https://github.com/sabel83/metashell You can also try them from your browser here: http://abel.web.elte.hu/shell Feedback is welcome. Regards, Ábel

6 16

IDE for developing Boost
by Jens Müller 20 Dec '14

20 Dec '14

Hi, I am looking for recommendations for developing Boost, especially code in the graph library. At work, most developers (not for Boost, for some commercial software), most developers are using Eclipse. This works quite fine as soon as it has properly auto-discovered include paths etc. But before fiddling around with Eclipse to get all the settings right, I'd wanted to to ask for your recommendations. And maybe there are already settings available to make it "just work", at least initially. Cheers, Jens

16 22

[coroutine] x86 msvc11 stack corruption
by Tobias Loew 12 Dec '14

12 Dec '14

Hi, I use Boost 1.55 uni-directional coroutines to build an x86 MSVC11 application. I have a simple pull-type (boost::coroutines::coroutine<void>::pull_type) that under certain reproducable conditions destroys the stack after returning from the coroutine. Here is the corrupted stack as shown by VS2012 > ebs2000.exe!CScriptMainFrame::DoRun(CPascalEditorDoc * 0x00000000, int 0x00000000, int 0x00000000) Line 3372 C++ ebs2000.exe!CScriptMainFrame::OnDebugStepover() Line 4916 C++ mfc110u.dll!_AfxDispatchCmdMsg(CCmdTarget *, unsigned int, int, void (void) *, void *, unsigned int, AFX_CMDHANDLERINFO *) C++ 00000002() Unknown [Frames below may be incorrect and/or missing] mfc110u.dll!CCmdTarget::OnCmdMsg(unsigned int, int 0x00000000, void *, AFX_CMDHANDLERINFO *) Line 364 C++ mfc110u.dll!CWnd::OnCommand(unsigned int 0x00018263, long 0x00000000) Line 2785 C++ mfc110u.dll!CFrameWnd::OnCommand(unsigned int 0x00018263, long 0x00000000) Line 389 C++ ... This only happens in windows x86 32-bit release-builds when the coroutine finishes upon a user-action that also includes a windows WM_SETFOCUS message on my menu-bar. If at least one of the following is true, the stack-corruption does NOT happen: - debug-build - x64 build - using a different pull-type, e.g. enum status_enum{...}; boost::coroutines::coroutine<status_enum>::pull_type - not returning form the coroutine, but pushing just before the end of the coroutine and swapping the pull-type-variable with a default constructed "not-a-coroutine" Even though I have a lot of workarounds, I still would like to know, why this happens. regards Tobias PS: I had to recompile ml /safeseh /c make_i386_ms_pe_masm.asm ml /safeseh /c jump_i386_ms_pe_masm.asm to get SAFESEH-libraries. -- View this message in context: http://boost.2283326.n4.nabble.com/coroutine-x86-msvc11-stack-corruption-tp… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 3

[testing] Proposal - regression tests results display upgrade
by Adam Wulkiewicz 17 Aug '14

17 Aug '14

Hi, Currently test failures of a new feature are always marked with the yellow color and a word 'fail'. Would it make sense to use some more descriptive color/naming scheme? In particular it would be nice to distinguish between the actual failures and the situations when the compilation of a test took too much time or an output file was too big. Would it make sense to also distinguish between compilation, linking and run failure? E.g. instead of a simple 'fail' use 'fail (c)', 'fail (l)' and 'fail (r)'. E.g. the color for actual failures could be orange and for "others" could stay yellow. Furthermore, currently it's impossible to see the results of compilation if a test passed. Would it make sense to change it? This would allow us to view and fix warnings even if the test was passed. The test passed with warnings could be marked e.g. with 'pass (w)' or the color could be set to some between yellow and this light green. If you directed me where it should be done I could try to change it. I'm guessing it would require modifying some script generating the page and some CSS? Regards, Adam

6 10

[winrt support] Adding support for Windows 8 store/phone to Boost libraries
by stgates 22 Jul '14

22 Jul '14

Hi, I work for Microsoft and we’ve been taking a look at making a some of the libraries in Boost work in the Windows 8 store and phone 8 runtime environment (WinRT). The main issue is use of Win32 desktop APIs that are banned in WinRT. The fixes generally involve updating to a newer non-banned version, like CreateEvent to CreateEventEx, or replace areas that call banned APIs using ifdef macro techniques. Similar to what already exists in some places of Boost when targeting different platforms or operating system versions. Files which do not use any banned APIs are largely unaffected. So far we’ve made the thread, chrono, system, and date_time libraries work in WinRT. To facilitate building and testing, changes are also required to the build and test libraries. Listed at the end of this message is a summary of the major changes made. I’m unfamiliar with the process for contributing back to Boost and would like to know what is the best way to work, to contributing back these changes to each of the individual libraries? I see the documentation for working with the git submodules (https://svn.boost.org/trac/boost/wiki/StartModPatchAndPullReq) Right now the changes for each library are in a forked repository on a new branch called ‘winrt’ from the ‘develop’ branch. For example the changes we've made for the chrono library can be located here: https://github.com/MSOpenTech/chrono/tree/winrt. Is the best way to proceed, or should I to just initiate a pull request to the develop branch on each of the individual libraries? Thanks, Steve Boost Build To support deciding which Windows API to target I added a new feature <windows-api> with values desktop, store, and phone. When utilizing the Visual Studio 2012 on Windows 8 or later the store and phone options are available, otherwise desktop is the default. Most of the changes in msvc.jam are to deal with selecting the correct vcvars setup script since with phone it is in a different location. I also added ARM support to the msvc toolset. For libraries which support the new Windows Runtime they now produce both the desktop and store binaries by default. This is done by calling the supported-windows-api rule I added in toolset.msvc which is called in the default-build section of each library’s Jamfile to indicate if targeting WinRT is supported. When building for the Windows 8 store or phone a new macro is now defined BOOST_WINAPI_FAMILY, set with the same value as WINAPI_FAMILY. This is then used in the individual Boost libraries to detect if targeting the new Windows Runtime and avoid certain banned APIs. To handle running tests against WinRT in an automated fashion that integrates well into the Boost workflow of running tests as part of the build, if windows-api is set to store, the test and all its binary dependencies need to have the APPCONTAINER requirement stripped. This then allows execution outside of the sandboxed Windows store environment. To do this all dependent dlls are copied into the tests executable’s folder, if using <link>shared. This is necessary to avoid modifying the APPCONTAINER flag on the actual product binaries. Just let me know if this needs more explanation, I’ll be glad to go into more detail if necessary. With this change the tests for Windows store run just like the existing Windows tests. I also added a new feature to control whether or not test binaries are actually executed, disable-test-execution. This is used to avoid running the ARM tests when building since Visual Studio 2012 doesn’t install on ARM devices. All these changes are in testing.msvc. Chrono The GetProcessTimes and GetThreadTimes functions doesn’t exist for WinRT and there are no replacements so the thread_clock and process user, system, and cpu clock features are disabled. Only process_real_cpu_clock is supported. Thread For the thread library most of the changes are around the fact that there is no way to directly create a thread in WinRT. To work around this I implemented the boost::thread class itself on top of std::thread. This actually leads to pretty clean code, much cleaner than directly targeting the WRL thread pool like in the C runtime. Other changes include moving from TLS to FLS and basic banned API replacements like WaitForSingleObjectEx for WaitForSingleObject. In general where it makes sense updates were made to utilize new APIs on platforms when available. Test For the Boost test library I added a new macro for turning on/off debugging support (BOOST_TEST_HAS_DEBUG_SUPPORT). WinRT doesn’t support creating processes so attaching a debugger to execution like this is disabled. There also are no APIs for accessing registry keys, so this feature has been disabled as well. -- View this message in context: http://boost.2283326.n4.nabble.com/winrt-support-Adding-support-for-Windows… Sent from the Boost - Dev mailing list archive at Nabble.com.

8 22

Proposal: Vector-like container, which takes O(log(N)) for insert/erase, feedback
by Alexander Kuprijanov 12 Jul '14

12 Jul '14

Hi, everybody! The most important feature of my container is performance. However, other features will appear later. https://github.com/alexkupri/array/blob/master/description/description.txt Today I compared my container with rope. My container outperformed it 10 times. > Date: Thu, 3 Apr 2014 16:39:29 -0700 > From: Glen Fernandes <glen.fernandes(a)gmail.com> > I wasn't sure at first why my name was in parenthesis in the e-mail > subject. :-) > Glen It's my fault, sorry about it. > Date: Fri, 04 Apr 2014 13:41:04 +0200 > From: Adam Wulkiewicz <adam.wulkiewicz(a)gmail.com> > Subject: Re: [boost] Proposal: Vector-like container, which takes > O(log(N)) for insert/erase > AFAIU just like a B-tree can be seen as a generalization of a binary > search tree in that a node can have more than two children, your > container can be seen as a similar generalization of a Rope. Or it can > be seen as an augumented B-tree (not really because the values are no > longer stored in internal nodes and the tree isn't sorted, correct me > if I'm wrong). Your You understood right. > proposal is very similar to Counted B-tree > (http://www.chiark.greenend.org.uk/~sgtatham/algorithms/cbtree.html) > which is a B-tree with random access. The difference is that your > container can't be used to search for a stored value in O(logN) > without sorting and binary search. This may be ok if someone require > only random access, the size of a node is smaller which probably > improves the cacheing. Again, right. There are a lot of situations when only random access is necessary. You probably will not sort characters in string. > > In general, B-tree was introduced to improve the performance of the > access to data stored in persistent memory (lower performance). In > this case it was better to load the whole page into memory (and cache > it) than load many small, scatered parts. But in the case of > RAM-only-access, a binary search tree should be faster. As far as we > don't consider spatial indexing, interval trees, etc. where > values/nodes may "overlap" somehow and we must search in more than one > subtree. Therefore I'm wondering if a classic Rope would be faster > than your container in the use-case you're testing - simple insert and > random It outperformed Rope 10 times. It's expected result. Please visit my link, I added verbose explanation under "ROPE TEST" section. Shortly speaking, four reasons exist: cache, pages, balancing and malloc/free. > access to a in-memory container. Have you test it? I'd perform 2 tests: > 1. Very big number of values + truly random insert/access to prevent > cacheing > 2. insert/access in the same area I've tested with truly random tests. Please see results and code of SingleOperationPerformanceCheck and MultipleOperationsTest functions. Tell me, if I'm wrong. > > IMHO the benefits related to the use of this container should be more > noticable if the persistent storage were used. In memory/cache there are the same relationship as in HD/memory. > > As for the name, it's definietly not an array. I'd call it B-rope. Thanks, your option is accepted. I'll collect more options and we'll vote. I like brope. > > Regards, > Adam > Message: 9 From: Lars Viklund <zao(a)acc.umu.se> > Date: Fri, 4 Apr 2014 14:10:06 +0200 > If it doesn't have contiguous storage, it's not a replacement for > vector, however much you want it to be the universal container that > everyone uses for everything. > It may be a better general-purpose container compared to the > usual default containers, deque and vector, but it isn't a replacement > for either of them. Well, I would see it as first choise container for non-sorted data. It's comparable with vector/deque on small arrays and outperforms them on large sizes. It's more preferrable than list at least in terms of malloc/free calls. And it's probably better for strings. So one should use it by default in all cases with unsorted data and use list, vector, deque and string only if he/she really understands what he/she does. > You use the term 'intrusive' in the documentation, but it doesn't seem > to carry the usual meaning that it requires the types involved to > participate in the container structure. You are right. I've corrected the documentation. Now I call "fat leaves" leaves which contain elements, and "thin leaves" leaves which contain pointers to elements. > Your tests doesn't seem to exercise much else than container<int> > either. Suggest your tests. > I'm not quite sure I like the explicit L/M non-type template parameters > either, considering that it leaks implementation detail into every > single user of the type. Well, you are right in principle. It must have default parameters. But it's platform dependent, they should be chosen so that branch and leaf would take roughly 1 cache line, minus information required for malloc overhead. > As for the Copy-on-Write semantics, isn't the general consensus that CoW > is a horrible horrible thing and is very hard to get right+fast in the > modern world with concurrency? I disagree with your estimation. There are different situations, different machines. Embedded and mobile machines want to save memory. Large machines can also want to save memory, if they amount of data is large. Finally, they can even speed-up by avoiding copying the whole array. Imagine you are writing text editor. (DNA editor, sound editor, etc.) You make backup copy and continue editing, again backup copy and continue editing. And you keep only forward commands (without undo). You can easily rollback to any state you need. Ofcourse, user should decide, whether CoW option is necessary for him/her, because it wastes resources when enabled and not used. > > Message: 11 > Date: Fri, 4 Apr 2014 23:23:09 +1000 > From: Vadim Stadnik <vadimstdk(a)gmail.com> > Could you please provide a figure that shows data association with > nodes in > your data structure? I updated the doc, follow the link above.

7 8

ptr_vector requiring non-const iterator for insert
by Florian Burkart 26 Jun '14

26 Jun '14

Hi, I noticed that ptr_vector requires a non-const iterator for insert. This is inherited from ptr_sequence_adapter, which defines iterator insert( iterator position, T* x ); Under C++11, this differs from std::vector, which, since C++11, is happy to take const_iterators. iterator insert( const_iterator pos, const T& value ); I read somewhere that C++11 was attempting to clear up some confusion in the standard between iterator constness and container constness. Just wondering whether this should be adopted (e.g. changed) in ptr containers. Gave me an error when I switched from vector to ptr_vector in a drop-in fashion. Not sure whether that is already planned, but google didn't find anything. Florian

2 1

[random] new threefry random engine
by Thijs van den Berg 13 Jun '14

13 Jun '14

Hi all, I've completed a nice new random engine that I would like to propose for addition to boost/random. The engine is called "threefry" and it's based on the paper "Parallel random numbers: as easy as 1, 2, 3" by Salmon, John K. and Moraes, Mark A. and Dror, Ron O. and Shaw, David E. I've been using it myself a lot for the last couple of years, and now I've rewritten it so that it will fit in the boost random framework and adhere to the concepts. It has some really nice properties, in particular for large scale parallel computing: * High quality randomness (according to the BigCrush tests) with a cycle length of 2^258 * Fast (comparable to Mersenne Twister) & little memory usage (13x 64 bit integers) * O(1) discard and guarantees for non-overlapping sequences when the (up to 256 bit) seeds are unequal I've uploaded the code, description and tests to https://github.com/sitmo/threefry The actual engine is at https://github.com/sitmo/threefry/blob/master/random/include/boost/random/t… I would really appreciate any feedback about the idea for inclusion and of course comments about the quality of the code,tests,docs kind regards, Thijs Sitmo Consultancy B.V. Financial Modelling & Data Science + 31 6 24110061 thijs(a)sitmo.com P.O. Box 1059, 2600BB, Delft, The Netherlands

10 60

[review] Convert library
by Jeroen Habraken 12 Jun '14

12 Jun '14

Hi, As promised my review of the boost::convert library. Note that the questions were answered in a seemingly random order, thus I hope it all comes together. Secondly, being the author of the boost::coerce library [2][3] I may be a little biased at times, please forgive me. -- What is your evaluation of the design? There are two parts to this, the design of the backend and the design of the interface that the user predominantly sees. I have little to say on the first, the notion of multiple backend converters is a big step forwards and their interface is sane. I'm far less convinced when it comes to the user-facing interface as I believe the simple tasks should be simple and intuitive, whereas the harder tasks may be harder. The most trivial use of boost::convert, and boost::lexical_cast and boost::coerce simply don't compare in my opinion. boost::cstringstream_converter cnv; int i = boost::convert<int>::from("23", cnv).value(); versus int i = boost::lexical_cast<int>("23"); int j = boost::coerce::as<int>("23"); When the convert library makes it into boost I'd want to mentally deprecate lexical_cast as a library I should use, and always use convert instead. This means convert should have a default converter, which may well be backed by lexical_cast with an interface such as: int i = boost::convert<int>::from("23").value(); This still doesn't completely satisfy me as I'd like to write int i = boost::convert<int>::from("23"); but it'd be an improvement in my opinion. Now I'm aware lexical_cast doesn't have a non-throwing interface, and it probably never will, but I've solved the problem as follows in boost::coerce: int i = boost::coerce::as_default<int>("XXX"); int j = boost::coerce::as_default<int>("XXX", tag::hex()); int k = boost::coerce::as_default<int>("XXX", 23); int l = boost::coerce::as_default<int>("XXX", tag::hex(), 23); The former two returning the default-constructed int, 0, the latter two returning 23. That said, I'll be the first to admit the coerce interface isn't perfect, the fact that I need SFINAE to distinguish between as_default calls with two parameters, the second either being a tag (somewhat similar to your converters but not quite) or the default value goes to show just that. However I'd prefer int i = boost::convert<int>::from("23", cnv); int i = boost::convert<int>::from_default("23", cnv, 0); to the current interface using value_or(0). This is subjective though, and quite possibly a matter of taste. In summary, before this turns into too long a rant, I think the current user-facing interface can be improved substantially, but I'm well aware this is subjective. -- What is your evaluation of the implementation? I've only had a quick glance at the code and it still looks fine. The gripe I had two years ago regarding the use of reserved names (include guards prefixed with "__") has been fixed. A few comments though: In the boost::lexical_cast based converter there is a try { } catch (...) { } which I believe to be an overly broad catch as lexical_cast explicitly throws a boost::bad_lexical_cast. If in an unlikely event a std::bad_alloc were to be thrown for example I'd rather not have boost::convert hide it from me. In the std::strtol based converter errno isn't checked, and it must be noted that strtol accepts leading whitespace which may or may not be wanted. I've implemented what I believe to be a correct converter using strtol which checks for the leading whitespace in [0], but it comes with no guarantees as it's quite tricky indeed. The new C++11 wrapper std::stol and friends in [1] may be of use here, but unfortunately they only have a throwing interface. All converters are added to the main boost namespace which is crowded enough as it is -- hi boost::_1 --, and libraries should add their functionality to their own namespaces in my opinion. With the current design it's not possible to add them in the boost::convert namespace but I believe they should be in their own namespace, may I suggest boost::converter. It must be said that the first two comments are minor at best, the last regarding the namespace is more important but potentially quite trivial to fix. -- What is your evaluation of the documentation? I've found it to be very hard to write documentation as the library author as at some point you're so intimately familiar with your library that it's hard to get a feel for what the user needs. Whilst there are some rough edges I think the current documentation is decent enough for it not to pose a problem. Again a few comments: The motivation should probably be addressed first, not near the end. The printf and std::strtol based converters aren't documented, and the converters should probably be grouped into a sub-section along with an explanation of how to write your own. Last of all I'd like to see an examples directory showing the examples from the documentation, you already have a test/encryption.hpp which probably belongs there. -- What is your evaluation of the potential usefulness of the library? In the previous review I've argued the library its functionality should be added to boost::lexical_cast. Whilst I still hold that position for the previous version of the library I believe this is no longer the case for the present version, largely due to the added support for multiple backends. There would be no practical way for lexical_cast to add this, and I believe it to be very useful indeed. -- Did you try to use the library? With what compiler? Did you have any problems? I've tried the library with Clang 3.2 and 3.4, and GCC 4.6 and 4.8 on Mac OS X 10.9.3 and the examples from the documentation using the sstream converter compile and run fine. When I tried the printf_converter something as simple as: #include <boost/convert/api.hpp> #include <boost/convert/converter/printf.hpp> int main(int, char *[]) { return boost::convert<int>::from("23", boost::printf_converter()).value(); } failed to compile. It's missing includes as adding the following to converter/printf.hpp fixes the problem: #include <boost/mpl/find.hpp> #include <boost/mpl/vector.hpp> This probably indicates that you're trying to test too much in a single file, and had the includes included via a different boost library. In the previous review I noticed that boost::convert<int>::from('1', cnv).value() spew a rather long error message. This has since been fixed, the error message is now considerably shorter making it easier -- will it ever be easy with C++ -- to figure out what's going on. I must note here that the error message the latest versions of GCC produced is actually easier to figure out than the one Clang produced. -- How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? Something between a quick reading and an in-depth study, now probably leaning towards the latter. -- Are you knowledgeable about the problem domain? As the author of boost::coerce, which I've admittedly ignored for far too long, I'm familiar with the conversion domain. Consequently I've seen the pitfalls and endured the hardships in designing and implementing such a library, my utmost respect for having it reviewed not once, but twice! And finally: -- Do you think the library should be accepted as a Boost library? In my previous review this was a straight no, stating that the functionality should be added to boost::lexical_cast. With the current design supporting multiple backends this no longer holds true as I've stated in the evaluation of the potential usefulness of the library. Again, the library is quite useful, but, I so strongly disagree with the current user-facing interface that I can't straight-out accept it. Once the library is accepted this interface is set in stone and like marriage it's "speak now or forever hold your peace". As such I'm voting YES, CONDITIONALLY on the interface being simplified for the seemingly simple cases as most of my other comments were minor or quite trivial to fix. With that out of the way I'd like to propose the following if you're interested. Let's have a look at whether it may be possible to merge the functionally of boost::convert and boost::coerce, as they seem to have grown towards each other with the possibility to support multiple backends. Two years ago I'd never have proposed this, but I've mellowed a bit since then. You seem to have focussed on backends primarily backed by std::stringstream and friends whereas I have focussed on a backend backed by boost::spirit. These may end up complementing leading to a single library capable of supporting both, being more generic and powerful to the user when done right. Regardless of whether we end up going this way I'd love to have a discussion on the interface, either on the mailing list or offline as this is currently a major stumbling block for me. Jeroen [0] https://github.com/VeXocide/coerce/blob/master/libs/coerce/example/backend.… [1] http://en.cppreference.com/w/cpp/string/basic_string/stol [2] https://github.com/VeXocide/coerce/ [3] http://vexocide.org/coerce/

15 78

Tick: Trait instrospection library for C++14
by paul Fultz 10 Jun '14

10 Jun '14

Hi, I developed a trait introspection library for C++14 based on Eric Niebler's concept checking, here: https://github.com/pfultz2/Tick So you can build a simple `is_incrementable` trait like this: TICK_TRAIT(is_incrementable) { template<class T> auto requires(T&& x) -> TICK_VALID( x++, ++x ); }; Then use it like this: static_assert(is_incrementable<T>(), "Not incrementable"); Also, you can validate the return of an expressions like this: TICK_TRAIT(is_equality_comparable) { template<class T, class U> auto requires(T&& x, U&& y) -> TICK_VALID( returns<bool>(x == y), returns<bool>(x != y) ); }; You can also match against another trait using placeholder expressions: TICK_TRAIT(is_incrementable) { template<class T> auto requires(T&& x) -> TICK_VALID( return<std::is_integral<_>>(x++), return<std::is_integral<_>>(++x) ); }; Any feedback would be appreciated. Also, I don't knw if there would be any interest in incorporating this into boost. Thanks, Paul

7 13

[modularization] proposal and poll
by Julian Gonggrijp 09 Jun '14

09 Jun '14

Dear Boost mailing list members, I would like to revive the topic of Boost inter-library dependencies, suggest two global changes to Boost and ask whether you agree with the course of action I propose. RATIONALE Boost recently transitioned from a monolithic SVN repository to a "modular" Git repository. One of the potential benefits of this new structure is that it may allow users to copy much less of Boost when they need only a small part of it. I believe that two additional, evolutionary changes are needed to truly unlock that benefit. The currently-standard way to use the new Git repository is to recursively clone the super-project and all its submodules, one for each of the >100 libraries. In order to use Boost in a truly modular way, a developer would rather just clone only the libraries she needs (including dependencies). Unfortunately, there is currently no feasible way to do that [see also 1]: - Manually: this is cumbersome and generally hard because there are many (undocumented) interdependencies between Boost libraries. - Automatically: as far as I know Ryppl is the only existing attempt at providing automated dependency handling for Boost, but it is a very ambitious project that attempts to do much more and it is currently neither finished nor being actively developed. I think there could be a less ambitious but faster way to provide automated dependency handling. It would take no more than some static configuration, to list for each library what other Boost libraries it depends on, combined with a simple script that automatically traverses the dependency graph and clones just the necessary submodules. This script may then be hooked into the bootstrap script. I think I could write the dependency handler, and I would be willing to, though I can't currently provide any indication of when I would be able to start. However, even if we had an automated way to handle dependencies, that would not be a sufficient solution to true modularity. As has been discussed before, the interdependencies between Boost libraries are currently so strong, that even using a single header file may likely require the user to copy a substantial portion of Boost [2]. This is especially the case because there are many cyclical dependencies [3, 4]. Stephen Kelly investigated how the interdependencies between Boost libraries could be reduced, especially the cyclical dependencies. He concluded that most cyclical dependencies could be eliminated and that the dependency graph could be simplified substantially overall. He also described concrete ways to achieve this. [3 and onwards] I believe it would still be worthwhile to reduce interdependencies between Boost libraries in the way Stephen proposed, or with a very similar approach. Stephen told me he is willing to re-analyze the dependencies as many times as needed as he did before and to make recommendations. Together with an automated way to handle dependencies, this should enable users to install only a small portion of Boost if that is all they need. It will also make the Boost super- project more flexible overall. PROPOSAL The following (evolutionary) global changes to Boost should be planned and given priority over any other proposals [e.g. 5], in the following order: 1. Reduction of dependencies between Boost libraries. 2. Simple but effective automation of dependency handling. POLL I think it may be easier for the steering committee to justify any decision on this proposal, if they have hard statistics about the amount of support it receives. Therefore, I invite every opinionated person reading this to reply with a vote, either in favour of the proposal or against it. I invite you to do this even if you do not feel the need or find the time to provide arguments for your position. You can later re-vote if you change your mind. I will count the votes, and when there are more than 30 I will start posting the statistics occasionally. Votes are public so everyone can verify my data when necessary. Anyone, including the steering committee, can then use the numbers however they choose. Thanks in advance, -Julian ____________ [1] http://lists.boost.org/Archives/boost/2014/05/213115.php [2] http://lists.boost.org/Archives/boost/2013/10/207379.php [3] http://lists.boost.org/Archives/boost/2013/10/207384.php [4] http://lists.boost.org/Archives/boost/2013/10/207422.php [5] http://lists.boost.org/Archives/boost/2014/05/213229.php

15 49

[optional] Is detail/none_t.hpp needed?
by Andrey Semashev 06 Jun '14

06 Jun '14

Hi, I've noticed there's boost/detail/none_t.hpp header, which basically reflects boost/none_t.hpp. Worse even, it would cause a conflict if both these headers are included. A search didn't reveal any users of this header. Since it's a detail, could this header be removed?

2 5

[multiprecision] General/design query about which conversions should be implicit/explicit
by John Maddock 04 Jun '14

04 Jun '14

Folks, I have an open bug report https://svn.boost.org/trac/boost/ticket/10082 that requests that conversions from floating point to rational multiprecision-types be made implicit (currently they're explicit). Now on the one hand the bug report is correct: these are non-lossy conversions, so there's no harm in them being implicit. However, it still sort of feels wrong to me, the only arguments against I can come up with are: 1) An implicit conversion lets you assign values such as 0.1 to a rational (which actually leads to 3602879701896397/36028797018963968 not 1/10), where as making the conversion explicit at least forces you to use a cast (or an explicit construction). 2) Floating point values can result in arbitrarily large integer parts to the rational, effectively running the machine out of memory. Arguably the converting constructor should guard against that, though frankly exactly how is less clear :-( Does anyone else have any strong views or insights into this? Thanks in advance, John.

8 8

[GSoC][MPL11] Post C++Now update
by Louis Dionne 04 Jun '14

04 Jun '14

Dear Boost, A lot happened during the past week in Aspen; the goal of this message is to summarize insights, changes and feedback received wrt MPL11. The slides of the presentation are available at [1]. The second part of the presentation is especially relevant to get an overview of the designs considered so far. Merging the MPL and Fusion -------------------------- After discussing the issue several times during the week, I (and others) think it might be possible to merge Fusion and the MPL into a single library. I am currently trying to write a library that does that. Since this constitutes a large reorientation, I created a new repository which is available at [2]. Those with interest should consider subscribing to the repository to be updated as I make progress. Iterator-free design -------------------- I was a bit anxious that people would complain about this, but the contrary happened. Nobody complained and some people expressed support. This design aspect will stay as-is. Request for guinea pigs ----------------------- I am looking for people with hardcore C++1y metaprogramming needs who will be willing to test the library I come up with (MPL11 or MPL + Fusion merge). I also need to see use cases for the library, so please reply even if you are not willing to test. Roadmap ------- Finish exploring the design space. If it turns out that we can merge the MPL and Fusion, then I'll be working on that for a while. If I find that this is not possible or not a good idea, I'll go back to my initial GSoC planning. In both cases, I hope to have a library in the incubator by the end of the summer. Also, this new roadmap is approved by my mentor. Feel free to reply with questions and/or comments. Regards, Louis [1]: http://ldionne.com/mpl11-cppnow-2014 [2]: http://github.com/ldionne/hana

15 34

Proposal: Boost.Core
by Peter Dimov 04 Jun '14

04 Jun '14

I propose the creation of a new module, Boost.Core, a repository of Boost core utilities. The criteria for inclusion into this module would be that the utility component is (a) simple, (b) used by other Boost libraries, (c) does not depend on any headers outside of Core and Config (and perhaps Assert). Its primary purpose would be to break dependencies. It will not serve as a repository of "this might be useful". Based on the interest so far, I volunteer myself, Glen Fernandes and Andrey Semashev as maintainers. The following utilities are immediate candidates for migration into the new module: - addressof - enable_if - boost/pointee.hpp - boost/indirect_reference.hpp - boost/type.hpp In addition, the following can be duplicated inside to reduce dependencies: - mpl::if_, if_c, eval_if - detail/is_incrementable.hpp - remove_cv and so on.

10 51

Boost 1.56 timeframe
by Jonathan Jones 03 Jun '14

03 Jun '14

Hi folks, Is there a timeframe for the release of Boost 1.56? The current 1.56 page simply states that it's at an early stage in its release cycle (but it has said this for months). http://www.boost.org/users/history/version_1_56_0.html I'm asking in the context of Visual Studio 2013. Boost 1.55 is known to have issues with VS2013, which I'm hoping the 1.56 release would address. Sincerely, Jonathan Jones

7 10

github issue
by Christian Henning 02 Jun '14

02 Jun '14

Hi all, I'm cloning boost but something went wrong when trying to get the python submodule. I'm not sure if the problem is related to boost, github, my git setup, or maybe my internet connectivity. Here is a snippet from the console output: ... Cloning into 'libs/proto'... remote: Reusing existing pack: 4233, done. remote: Total 4233 (delta 0), reused 0 (delta 0) Receiving objects: 100% (4233/4233), 1.89 MiB | 893.00 KiB/s, done. Resolving deltas: 100% (2062/2062), done. Checking connectivity... done. Cloning into 'libs/ptr_container'... remote: Reusing existing pack: 2887, done. remote: Total 2887 (delta 0), reused 0 (delta 0)Receiving objects: 98% (2830/28 87), 2.36 MiB | 924.00 KiB/s Receiving objects: 100% (2887/2887), 2.78 MiB | 924.00 KiB/s, done. Resolving deltas: 100% (1839/1839), done. Checking connectivity... done. Cloning into 'libs/python'... ssh: github.com: no address associated with name fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Clone of 'git@github.com:boostorg/python.git' into submodule path 'libs/python' failed I'm using git version 1.9.0.msysgit.0 on Windows 7. Anyone know what's going? Thanks, Christian

2 2

Re: [boost] [modularization] proposal and poll
by Niall Douglas 01 Jun '14

01 Jun '14

I'll top post my reply as Robert's valuable post didn't make it onto the list again. Please do read his reply below, it's worth reading as Robert is one of the lead thinkers on the steering committee about this. Robert, I think you are under a misapprehension about what I mean by "fork". By a fork, I mean forking just a very small part of existing Boost, namely whatever minimal support is necessary to start from scratch with a new *empty* set of C++ 14 only Boost libraries. I don't propose to port *any* of the legacy Boost libraries whatsoever, they stay where there are. If their maintainers - or a sponsor - are willing to do: 1. Make their library entirely C++ 11/14 STL based, porting only the absolute minimum of old Boost. 2. C++ Modules ready i.e. restructured and reorganised to properly fit C++ Modules. 3. Contribute any general utility code to the core utilities library, not duplicating any functionality there, and in a form suitable for entering the C++ 17 STL. 4. Meet the raised unit test and CI soak test and sanitiser/valgrind requirements. Then they have a good chance of their library appearing highly ranked in the list of C++ 14 Boost libraries, where that ranking is generated by a set of clang AST analysers. Does this make sense? I am specifically advocating a structural break, a clean start. I think working on a fresh, empty Boost will get people to volunteer to give up family time to write Boost code again. Right now with the present situation there are few incentives to sacrifice family time. That needs to change for Boost to survive, else the continuing slow decline will continue. Niall On 29 May 2014 at 17:52, Robert Ramey wrote: > > > On Thursday, May 29, 2014 2:17:11 PM UTC-7, Niall Douglas wrote: > > > > On 29 May 2014 at 22:22, Julian Gonggrijp wrote: > > > > If a fork of Boost becomes necessary later this year, > > > LOL - this is not going to be necessary. > > > > The hard part isn't what to do. > > > LOL - not for you! > > > > The hard part is gaining community > > buy in when "their" code gets broken by the necessary changes. I have > > concluded it isn't possible, > > > LOL - you've underestimated the amount of work to convert > everything to C++11 by a factor of .... 1000 ? Basically it's > a whole rewrite of 100 modules. And the gain is ....? > > hence me proposing a fork where such > > "radical" changes won't upset anyone. > > > Your free to do this. And you should if you really believe that > it would benefit anyone or anything. > > > I think it may be easier for the steering committee to justify any > > > decision on this proposal, > > > The steering committee doesn't have anything to decide here. The > "Proposal" is: > > 1. Reduction of dependencies between Boost libraries. > > It's not clear what action is being proposed - but I'm pretty sure > the steering committee won't be doing it. > > 2. Simple but effective automation of dependency handling. > > I'm pretty sure the steering committee won't be doing this either. > If anyone believes that they can implement "simple and > effective" automation of dependency handling - just go ahead > and do it and let us see it. > > > > Decisive and immediate action on this is vital if Boost is to > > survive. I vote yes to both, ASAP. > > > > LOL - There is wide agreement that boost has growing pains and > will have to evolve. But I haven't seen any proposals for > "Decisive and Immediate" which would do anything but make > things worse. > > And since you've got me started - Here is what boost needs go to the next > step. > > a) Make the review process more effective and efficient - we're taking real > practical action to address this now. The jury is still out regarding the > effectiveness of our efforts - but we ARE actually doing something. > > b) Recognize that we now have 4 variants of C++ - C++98, C++03, C++11 > and C++14. Our infrastructure doesn't explicitly address this. The > following > needs to change > 1) for each library we need to explicitly state somewhere what > version(s) of C++ the > library is meant to support. > 2) support running of tests and builds for only those platforms. > > I've suggested that we enhance B2 to address this. So far > no one has responded to this suggestion > > Note that this would have he effect of encouraging libraries to evolve > to later versions of C++ with minimal disruption to both library > authors and users. > > c) Decouple Deployment of Boost Libraries from the Certification > of boost libraries. Beman has noted that what he would like to > see is something like CYGWIN whereby one specifies what one > want's and somehow automagically you get that plush what you > need. I realize that this is more or less what is being suggested here. > But no one has presented credible proposal for making it it happen. > > This would also address the issue of "old" libraries. As they > fall into disuse are become superseded by newer ones, the can > still be in boost even though their frequency of deployment drops off. > > The above constitutes a real path forward. This is what Boost > needs for the next 15 years. > > Robert Ramey > -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/

4 4

throw or boost::throw_exception?
by Andrzej Krzemienski 01 Jun '14

01 Jun '14

Hi, I am not sure where, but I am convinced that I have read that it is recommended for Boost libraries that they not use naked throw expressions but instead call boost::throw_exception. Is that true? If so, it enforces a dependency of more than half Boost libraries on Boost.Exception. Am I right? If so, is this the right recommendation in the context of the discussion about reducing dependencies between the libraries? Regards, &rzej

8 22

[next_generation][modularization] Is the community interested in creating a smooth path to a modularized Boost
by Vicente J. Botet Escriba 31 May '14

31 May '14

Hi, I've started a new thread in response to Julian Gonggrijp post [modularization] proposal and poll, as I would not answer directly to his questions. I'm sure that almost all of us want a modularized Boost. What does this means? It is up to us to define it: * what the user can request as a delivered package for its own needs? * what the authors must state explicitly? * what must be tested/checked? The main problem is how to achieve it ensuring backward compatibility . I'm persuaded that we need a new Boost repository (or whatever we want to name it) that would include libraries that respect the modularization constraints we could define. My question is who would be interested in starting the next generation of a modularized Boost that starts from a repository of ZERO modularized libraries. The idea is to add to the current Boost libraries new ones that respect the modular rules and adapt the current ones to be defined on top of the modularized ones. At the end we could deprecate the old ones. In order to do that we need of course to add new interfaces (a new namespace mod_boost or whatever is preferred) and so the user would need to move to these interfaces smoothly. Before starting we need to * Define the constraints of a modularized system - no cyclic dependencies, .... * Define the tools that can be used to support the modular system - which build system(s), - which test system(s), - which regression system(s), - which doc system(s), ... * Define the rules - who could be able allowed to do the refactoring? - Should the refactoring be reviewed to ensure a improvement on the quality of Boost? - who maintains what?, ... * Setup the infrastructure ( build system, test system, regression system, doc system, ... ) Only then we could * Start from libraries that don't depend on any other library (with possible refactoring) and adaptation of the refactored libraries from which these modular libraries have been extracted. * Deliver them * Build a second layer of libraries that depend only on first layer * Deliver them * ... Of course, in order to check that the rules and tools are the appropriated ones we will need to experiment with some examples. I recognize that this would mean a lot of work, however I hope that the final result would satisfy better the community expectations and the quality of Boost libraries. Best, Vicente

2 2

[gil] Status of gil:: extension:: io
by William Gallafent 31 May '14

31 May '14

Hi all, I noticed that a major update to gil's io extension was accepted into boost in 2011[1]. It disappeared from its own development repository in 2013[2]. It isn't present in boost 1.55[3]. It is present in boost's subversion trunk[4]. There's currently no mention of it in the release notice for boost 1.56[5]. Am I right to say that its presence in boost trunk means that it /will/ be included in boost 1.56, it just needs to be added to the documentation? If so, then great! Is there anything which needs to be fixed before it's ready to ship? I didn't see anything obvious when I searched this list's archives for “[gil]”. Thanks in particular to Christian, everybody else that worked on the io_new extension, and those that reviewed it! It's very useful to me, and I'm looking forward to its integration into boost so I don't have to add it myself from boost trunk :) [1] http://lists.boost.org/boost-announce/2011/01/0281.php [2] https://code.google.com/p/gil-contributions/source/detail?r=795 [3] http://svn.boost.org/svn/boost/tags/release/Boost_1_55_0/boost/gil/extensio… (this is the “old” io extension) [4] http://svn.boost.org/svn/boost/trunk/boost/gil/extension/io/ (and this is the “new” one) [5] http://www.boost.org/users/history/version_1_56_0.html -- Bill Gallafent.

3 6