December 2016 - Boost - lists.preview.boost.org

[Fit] Update: Request for feedback
by Paul Fultz II 06 Feb '17

06 Feb '17

Hi, I have made a lot of updates to the Fit library based on the changes suggested during the review earlier this year. I have also improved the documentation. I have expanded on the introductory materials and have add a lot more cross-referencing. The documentation can be found here: http://fit.readthedocs.io <http://fit.readthedocs.io/> Let me know of any feedback about the library either here on the mailing list or on Github issues. Thanks, Paul

4 9

[regression] Are tests not running?
by Andrey Semashev 31 Jan '17

31 Jan '17

Hi, Looking at the regression tests table, it looks like the latest regression tests were run last Saturday, November 26th. It seems inlikely that all testers decided to stop running 4 days ago or are running tests for that long. Is there some problem with the regression infrastructure?

6 16

Why is this message in Spam?
by Olaf van der Spek 26 Jan '17

26 Jan '17

Hi, > Why is this message in Spam? It has a from address in microsoft.com but has failed microsoft.com's required tests for authentication. Learn more I think this list isn't configured properly.. and this causes some messages to end up in Spam consistently.. Who's responsible for the mailing list infrastructure? Gr, -- Olaf

7 12

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

[program_options] implicit value and non-adjacent tokens
by Vladimir Prus 25 Jan '17

25 Jan '17

Hi, some time ago, program_options was modified so that options with implicit value would only take value from the same token. Previously, one could have: ./program -a foo -b # uses 'foo' as value for 'a' ./program -a -b # uses some default value for 'a' ./program -b # has no value for 'a' Now, the first syntax interprets 'foo' as positional option, and one has two write ./program -a=foo Ever since, I hear concerns from users about this behavior. Maybe not very loud, but quite consistent. Maybe, the new behavior is not very good, indeed, because it now mixes syntax matter (whether value is in the same token) with semantic matter (whether an option has implied value). I am considering reverting this change for next version of Boost. Does anybody have opinions either way? Thanks, Volodya

3 5

Re: [boost] [interprocess] Getting boot-up time is unreliable on Windows
by Ion Gaztañaga 23 Jan '17

23 Jan '17

On 22/12/2016 10:01, Thomas Dahms wrote: > Dear developers, dear Ion, > > We are experiencing issues on Windows where boost::interprocess relies > on a certain event in the system event log to get the system's boot-up > time. This has proven to be unreliable, because that event is not always > present in the log. In that case, initialization of boost::interprocess > fails. > Several bug reports exist for that issue, e.g. [1, 2]. > > Report [1] contains a proposed fix to use GetTickCount64() and there is > an open PR with an alternative fix to fall back to WMI mechanisms [3]. I > understand that the fix [1] would need some polishing, because > GetTickCount64() is not available in pre-Vista. > > Nevertheless, both proposed fixes have been uncommented and unconsidered > for a while now. Is there any chance that the maintainers could look > into this? Thanks for the ping. I don't think GetTickCount64 is very reliable, as other methods also have problems with time correction, hibernation, fast bootup, etc. In [1] one the last bootup log is lost new processes won't be able to communicate with others. The same happens with [3] In http://www.boost.org/doc/libs/1_63_0/doc/html/interprocess/acknowledgements… there are some instructions to give up on kernel persistence and define the directory at compile time or run-time. This is the best workaround so far. I've trying to find a solution with no luck. I tried: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\PrefetchParameters\BootId in modern Windows systems but hybrid shutdown (default since Windows 8) does not seem to update it as kernel is suspended. Searching for a unique bootup id in windows that does not suffer when hibernating or correcting the RTC is really complicated. Any suggestion welcomed. Best, Ion

2 1

[serialization][test] failures in serialization causing regressions
by Barend Gehrels 21 Jan '17

21 Jan '17

Hi, The regression matrix in develop of Boost.Geometry contains many new compilation failures due to: 1) : D:\t08\run\boost_root\boost/serialization/array.hpp(25) : error C2039: 'array' : is not a member of 'std' 2): ../boost/numeric/ublas/storage.hpp: In member function ???void boost::numeric::ublas::unbounded_array<T, ALLOC>::serialize(Archive&, unsigned int)???: ../boost/numeric/ublas/storage.hpp:331:18: error: ???make_array??? is not a member of ???boost::serialization??? ar & serialization::make_array(data_, s);and a The master is still OK. Can this be solved? Regards, Barend

6 9

Generating Boost documentation with pandoc
by Vinícius dos Santos Oliveira 18 Jan '17

18 Jan '17

Has anyone tried to generate Boost-styled documentation using pandoc? I never fully liked PDF documentation because I never actually print documentation. However, a few weeks ago I got an ebook reader and I've been fascinated by the ePUB format. I'm using it to read even the IETF's RFCs and it's very pleasant. I'm using ePUB to read files even on my usual laptop. Anyway, I was wondering how nice would be to have an ePUB file containing the whole Boost documentation. pandoc has docbook support as one of its input formats and is capable of generating great ePUB output. -- Vinícius dos Santos Oliveira https://vinipsmaker.github.io/

7 27

gregorian::date limited to years 1400 - 9999
by Viacheslav Usov 12 Jan '17

12 Jan '17

Conceptual question: why is the Gregorian calendar's time range limited to years 1400 - 9999? If this or any of the below has already discussed in some public forum (which I have failed to found, gmane's rebuild being possibly the culprit), kindly point me it to it. I am specifically interested in 1400. It seems completely arbitrary to me. It predates the time the calendar was introduced by almost two centuries, so that cannot be the reason why it cannot support earlier times. ISO 8601 allows the entire 0 - 9999 range, even though dates earlier than 1582-10-15 are subject to an agreement among the parties involved. Extending the proleptic Gregorian calendar all the way back to year 0 seems like one of the very few things that make sense. So my question is, is there any technical problem in supporting the entire 0 - 9999 range? If not, then my next question would be, what else would speak against supporting the 0 - 9999 range? If you expect some compatibility could be broken by that, then perhaps the low end could become a template parameter with the default at 1400? Cheers, V.

5 7

Re: [boost] [root_ptr] Into consideration by Qt & QtQuickCompiler
by Mathias Gaunard 03 Jan '17

03 Jan '17

On 28 Dec 2016 2:32 pm, "Phil Bouchard" <philippeb8(a)gmail.com> wrote: Greetings, I did my homework and the Qt Project is considering root_ptr despite the fact that there is no paper written on it: http://lists.qt-project.org/pipermail/development/2016-December/028222.html So there is a big demand out there. I am not sure what else is required to find a review manager but everything is on a silver plate now. I don't understand how you can possibly interpret that reply as "big demand".

2 3