- Boost - lists.boost.org

devector feedback request
by Benedek Thaler 30 Jul '15

30 Jul '15

Dear Boost, I'm happy to announce the new devector container developed as part of the GSoC programme reached a presentable state. I invite you to take a look and ask for feedback. Main features: - every std::vector feature - front operations with amortized linear complexity - optional small buffer optimization - customizable growth policy (see the docs) - unsafe methods for the brave and performance addicts Documentation: - Intro: http://erenon.hu/container/container/non_standard_containers.html#container… - Usage: http://erenon.hu/container/container/examples.html#container.examples.devec… - API: http://erenon.hu/container/boost/container/devector.html#idp86138944 Code: - Implementation: https://github.com/erenon/container/blob/devector/include/boost/container/d… - Tests: https://github.com/erenon/container/blob/devector/test/devector_test.cpp Thanks, Benedek

6 11

[Log] Running in a separate thread
by Andrew Hundt 29 Jul '15

29 Jul '15

I really only need some of the functionality of BOOST_LOG_TRIVIAL, perhaps plus loving to a file in addition to the console. However, my only true need is that all the work (or as much as possible) must be done in a separate thread so as not to slow the current thread down. Right now when I use BOOST_LOG_TRIVIAL as is it causes latency in my network communications which have soft realtime requirements so I've had to comment all of my logs out. Is there a straightforward non-intrusive solution to having as much of the work as possible for boost.log be done in a separate thread? Thanks for your help! Cheers! Andrew Hundt

3 4

Boost.DLL formal review result
by Vladimir Prus 28 Jul '15

28 Jul '15

The Boost.DLL library is accepted. Congratulations to Antony, and thanks for everybody who reviewed the library! The votes were as follows: - Ralf Globisch - Yes - Klaim - Joël Lamotte - Yes - Niall Douglas - Yes, conditionally - John P Fletcher - Yes - Bjorn Reese - Yes - Edward Diener - Yes - Rodrigo Madera - Yes - Richard - Yes I'd like to also thank Thomas Trummer, Rob Stewart and Ion Gaztañaga for their contribution to review. The key suggestions from the review are listed below. None is critical enough to become a formal prerequisite, or require a mini-review. The library can be added when Antony feels its ready. Naming ----------- There was a concern that "DLL" might sound windows specific, and search for best terminology. This does not seem all that important, as soon as documentation introduces the terminology it uses, and is consistent. OSX support ------------------- The library was found not to work on OSX; I believe this issue was already fixed off-list with help from Rodrigo. Documentation ---------------------- Several people requested improvements. Bjorn and John, in particular, pointed out specific issues. This seems to be the post important change prior to adding the library. Dependencies on Boost and system headers ---------------------------------------------------------------- It was suggested that the library does not depend on other Boost C++ Libraries. While it might be helpful to some users, I find it logically impossible for a Boost formal review to request that dependencies on Boost libraries be removed. It was also mentioned that Boost.DLL is header-only library and includes system headers that can bring a lot of symbols and maybe macros. I don't think an actual problem was reported, though, and there is no way to avoid the problem while staying header-only. It's up to the author to consider these suggestions and do something, or don't do anything. Continuous integration -------------------------------- There was a recommendation from Niall to improve CI of the library, including static analysis, valgrind, Windows CI, showing CI status in documentation and so forth. These are good suggestions. At the same time, they are not specific to Boost.DLL, and it's not the goal of a formal review to create new generic development process requirements. Many existing libraries of indisputably high quality do not have these requested mechanisms. Therefore, the author can act on these suggestions as he sees fit. Thanks, -- Vladimir Prus http://vladimirprus.com

4 3

BGL pull requests
by Mads Jensen 27 Jul '15

27 Jul '15

Hi, There are many quite trivial pull requests on Github for BGL. Can the project responsible please have a look at them? Most of them just fix typos and add more clarity to the documentation. Thank you, -- Med venlig hilsen / Kind regards, Mads Jensen Gunnery Sergeant Hartman: What's your excuse? Private Cowboy: Sir, excuse for what, sir? Gunnery Sergeant Hartman: I'm asking the fucking questions here, private! Do you understand? -- Full Metal Jacket

6 8

[mpl] Problem with VC++14 and boost::mpl::size_t
by Edward Diener 27 Jul '15

27 Jul '15

The just released VC++14 has a problem with the boost::mpl::size_t template. After preprocessing it sees: namespace boost { namespace mpl { template< std::size_t N > struct size_t { static const std::size_t value = N; typedef size_t type; typedef std::size_t value_type; typedef integral_c_tag tag; typedef boost::mpl::size_t< static_cast<std::size_t>((value + 1)) > next; typedef boost::mpl::size_t< static_cast<std::size_t>((value - 1)) > prior; operator std::size_t() const { return static_cast<std::size_t>(this->value); } }; template< std::size_t N > std::size_t const boost::mpl::size_t< N >::value; }} and gives the error message: size_t.cpp(nnn): error C2872: 'size_t': ambiguous symbol predefined C++ types (compiler internal)(16): note: could be 'unsigned int size_t' size_t.cpp(nnn): note: or 'boost::mpl::size_t' pointing to the line after it encounters 'struct size_t' as far as I can make out ( you need to preprocess the size_t.cpp test, comment out the #line directives and run the test against the preprocessed result to see what the compiler is objecting to ). It therefore fails a number of mpl tests which all prior versions of VC++ pass. It flags this error in 5 mpl tests which use the boost::mpl::size_t integral wrapper, among which the easiest to analyze is the size_t.cpp test itself. Anybody have any idea what is going on here with the compiler, or whether it can be fixed somehow in VC++14 for the mpl code ?

9 21

[config] BOOST_NO_CXX11_HDR_CODECVT is not defined for VC14
by Andrey Semashev 27 Jul '15

27 Jul '15

Hi, I see that BOOST_NO_CXX11_HDR_CODECVT is not defined for MSVC-14, although it is known that the codecvt facets are unusable because of linkin errors: https://connect.microsoft.com/VisualStudio/feedback/details/1348277/link-er… You can also see STL mentioning DevDiv#1060849 here: http://blogs.msdn.com/b/vcblog/archive/2014/11/12/visual-studio-2015-previe… and I can see that the problem is not fixed in RTM. This also concerns std::codecvt specializations for char16_t and char32_t. Can we define the BOOST_NO_CXX11_HDR_CODECVT macro for MSVC?

3 6

[predef] Fails on Intel/win
by John Maddock 27 Jul '15

27 Jul '15

BOOST_COMP_INTEL is set to 0, which means that [ predef-require "BOOST_COMP_INTEL" ] fails. __INTEL_COMPILER is set to 1500. BOOST_COMP_INTEL is set to ( (((0)%100)*10000000) + (((0)%100)*100000) + ((0)%100000) ) Thanks, John.

6 17

__NR_eventfd syscall
by Alexey Brodkin 27 Jul '15

27 Jul '15

Hi, When building Boost for ARC architecture we're seeing this failure: --------------------->8--------------------- ./boost/asio/detail/impl/eventfd_select_interrupter.ipp: In member function 'void boost::asio::detail::eventfd_select_interrupter::open_descriptors()': ./boost/asio/detail/impl/eventfd_select_interrupter.ipp:50:50: error: '__NR_eventfd' was not declared in this scope write_descriptor_ = read_descriptor_ = syscall(__NR_eventfd, 0); --------------------->8--------------------- This happens clearly because ARC following Linux kernel's UAPI doesn't define __NR_eventfd syscall. If you look here https://github.com/torvalds/linux/blob/master/include/uapi/asm-generic/unis… you may notice that "eventfd" syscall with some others resides in "#ifdef__ARCH_WANT_SYSCALL_NO_FLAGS". And from what I may see only "score" architecture has this __ARCH_WANT_SYSCALL_NO_FLAGS defined. Most of other arches that don't use unistd.h from "include/uapi/asm-genereic" folder have "eventfd" syscall defined. For example it's true for ARM (both 32 and 64 versions). So I'd say it's not the best way to use directly a syscall that's being obsoleted in "Boost". And so real fix would be to modify Boost's "eventfd_select_interrupter::open_descriptors()" for example with use of really generic "eventfd2" or even better use libc's eventfd() call instead of direct syscall. Any thoughts what would be the best fix here? -Alexey

1 1

[ublas] [1.5.9.0b1] Merge patch for broken boost::numeric::ublas::shallow_array_adaptor since 1.58
by Hugues Malphettes 24 Jul '15

24 Jul '15

Hi everyone, Does somebody knows how to proceed to merge the patch filed here: https://svn.boost.org/trac/boost/ticket/11207 I am forced to remain on 1.57 because of this issue. At the minimum there are 4 projects affected: myself, Mark Moll who filed the issue on track and nasosi and vh4n who filed the same patch here: https://github.com/uBLAS/ublas/pull/30/files I had convinced myself that because it had been merged in github we would be good to go for 1.59. I just tested 1.59.0b1 and it has not been merged. Many thanks for your help! Hugues

1 0

Test Runner Update to vc14.0 - CTP 6
by Tom Kent 23 Jul '15

23 Jul '15

Just a heads up, I have just updated the test runner teeks99-08f-win2012R2-64on64 from vc14.0 - CTP 4 to vc14.0 - CTP 6. The change should show up in the next run of that runner in a few hours. I think some people were waiting to see if MS was fixing some things, so I thought I'd send a message letting people know these results would be available. Tom

7 22