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