August 2016 - Boost - lists.preview.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

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 19 Jun '17

19 Jun '17

Hi Daryle, Any luck on your new setup? Gr, Olaf On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: > I can look at it once I've finished my new setup. > > I had to reset my computer after a partial crash years ago. I never > got around to recreating my programming setup. My computer had been > at its maximum Operating System level back then, which is now 3 > versions behind. For the past few months, I've had my sister's old > laptop, with Windows Vista, and am trying to add a programming setup > to it now. > > > On Tue, Nov 22, 2011 at 7:18 AM, Beman Dawes <bdawes(a)acm.org> wrote: >> Hi Daryle, >> >> This guy has volunteered to take over maintenance of Boost CRC. Should >> we take him up on his offer? > >> ---------- Forwarded message ---------- >> From: >> Date: Wed, Nov 2, 2011 at 7:51 AM >> Subject: [boost] Boost CRC maintainer (Daryle Walker) missing in action? >> To: boost(a)lists.boost.org >> >> >> Hi, >> >> It looks like the Boost CRC maintainer (Daryle Walker) is missing in action? >> >> No response to tickets from the past 3 years. What's the procedure in this case? >> >> https://svn.boost.org/trac/boost/ticket/2492 >> https://svn.boost.org/trac/boost/query?component=crc&col=id&col=summary&col… > > -- > Daryle Walker > Mac, Internet, and Video Game Junkie > darylew AT gmail DOT com -- Olaf

2 2

[msm] [statechart] unmerged PRs
by András Kucsma 23 May '17

23 May '17

Hi Everyone, There are a couple of PRs for msm and statechart by me and others, which didn't get any attention for many months now. Can the maintainers please take a look at them? https://github.com/boostorg/msm/pulls https://github.com/boostorg/statechart/pulls Thank you, Andras

2 2

[clang] clang-cl expansion of macros
by Edward Diener 29 Apr '17

29 Apr '17

You can get clang-cl ( clang-win ) to show its VC++ emulated expansion of macros somewhat by passing the c++ option '-fmacro-backtrace-limit=0' to the compiler. It is still blessedly difficult to see the what and the why of clang's error messages when expanding macro using clang-cl, but at least it gives you a better chance of understanding where clang's emulation of VC++ has gone wrong. I have posted bug 27380 to the llvm/clang bug tracker at https://llvm.org/bugs/show_bug.cgi?id=27380 showing the main failure in VC++ emulation which I see when testing Boost PP with clang-cl.

3 8

[container] moving a pre-built vector into a flat_set
by Sam Kellett 12 Mar '17

12 Mar '17

a common problem i encounter is that i have two stage's w/r/t to a large collection of data: building and querying. vector is obviously the king of building. flat_set is the king of querying. so what i often tend to do is build up a very large vector, sort it then create a flat_set using the flat_set(ordered_unique_t) constructor. however this still copies the entire vector into the flat_set, right? what i would like to be able to do is move the vector straight into the flat_set, something like: std::vector<T> data; flat_set data_set1(std::move(data)) // move vector in and sort it // or: std::sort(data.begin(), data.end()); // sort vector flat_set data_set2(ordered_unique_t, std::move(data)) // and move it in is this doable (am i just being blind?) or is there plans/interest for this?

8 19

[nowide] Library Updates
by Artyom Beilis 04 Mar '17

04 Mar '17

Hello, Disclaimer: --------------- I recently discovered that virtually all e-mails sent from Yahoo account to any mailing lists go to user's spam due to recent Yahoo's DMARC policy. So I'm sending some important stuff from GMail account that almost certainly was missed: What is Boost.Nowide: -------------------------------- Boost.Nowide is a library that make cross platform Unicode aware programming easier. The library provides an implementation of standard C and C++ library functions, such that their inputs are UTF-8 aware on Windows without requiring to use Wide API. It was inspiration and inspired by http://utf8everywhere.org/ development ideas and policy. Some updates regarding Boost.Nowide ------------------------------- 1. Library moved to github and its format is converted to modular boost layout: https://github.com/artyom-beilis/nowide 2. Fixed unsupported std::ios::ate flag by boost::nowide::fstream 3. Added some C++11 interfaces to boost::nowide::fstream 4. Added integration functionality with boost::filesystem: https://github.com/artyom-beilis/nowide/blob/master/include/boost/nowide/in… Note: that the links to the source code on review schedule aren't relevant, it should be: - Code: https://github.com/artyom-beilis/nowide - Documentation: http://cppcms.com/files/nowide/html/ Also the library is still looking for review manager. Artyom Beilis P.S.: I'm sorry if you are getting this as "duplicate"

2 1

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

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

[MPL] A Proposal
by Bruno Dutra 16 Nov '16

16 Nov '16

Dear Community, About a year ago today, there was a proliferation of threads [1][2][3] in this mailing list concerning the future of Boost.MPL, or even whether it had a future at all, and opinions diverged widely on the matter. Many have expressed concerns about the fact Boost.MPL was long outdated and proposed major changes to open path for modernization, while some others argued against it, fearing unexpected and disastrous side-effects could propagate throughout the rest of Boost. A few questioned if it was worth it at all to spend any further resources on Boost.MPL given the fact new alternatives were coming up, such as Boost.Hana, which departed entirely from template metaprogramming, yet some argued TMP remained a competitive alternative for type computations in C++14 as it has been demonstrated by Peter Dimov in his impressive articles [4] on modern TMP. Amidst all this, a proposal by Robert Ramey [5] caught my attention and inspired me to develop what I call Metal [6], a template metaprogramming library designed on the same core principles as Boost.MPL, but written from the very beginning to take full advantage of C++11. Metal was not designed to be a strict drop in replacement for Boost.MPL though, it was rather meant to be regarded as a modern version of Boost.MPL's original API, diverging only where it could really benefit from modern C++ and that essentially means gains of several orders of magnitude in performance** and lower memory consumption. At this point Metal is very close to where I originally intended to bring it and I think it's time I gauge interest from the community on a modest proposal I've been maturing along the past year. As a modern approach to the same task that Boost.MPL was meant to address, I don't believe Boost would benefit at all from yet another TMP library that would essentially compete with Boost.MPL and even Boost.Hana in some cases, specially as maintainers of older code that depends on Boost.MPL would have to go through major refactoring efforts in order to benefit from such an addition to Boost. I would like to propose something different instead. My proposal is to make Metal officially into a new revision of Boost.MPL's API, essentially MPL2 as the original proposal by Robert Ramey put it, merging both into one single TMP library. The idea would be to provide a thin proxy for the current Boost.MPL API which would have two backends configurable by preprocessor switches: the original implementation and a another one based on Metal. This way older code using Boost.MPL could see immediate gains on performance by selecting the newer backend on supported compilers, while at the same time legacy code maintained on older compilers could still rely on Boost.MPL's impressive ability to run virtually anywhere. On the other hand, newer projects interested on pure type computations would have the newer API entirely available to them. This proposal also overcomes the problem of dealing with the maintainability of Boost.MPL, since it provides a way for smooth transition from legacy hacks required by ancient compilers into a cleaner and easier to maintain C++11 codebase, besides avoiding any breaking changes within existing code in the process. Furthermore, should this proposal make it into Boost, I would be naturally willing to take responsibility for the maintenance of Boost.MPL, which AFAIK has been maintained by the CMT for quite some time now, often with limited resources. Comparing Metal and Boost.MPL there are a few noteworthy differences. Metafunction Classes have proven themselves entirely unnecessary and have thus been removed altogether in favour of pure Lambdas (in the Boost.MPL sense). Moreover, iterators make little sense in a functional world, so these too have been removed despite the fact they may easily be emulated in the new design. Moreover Metal develops the concept of optionals, that is, its metafunctions only have a nested ::type defined when they may be successfully computed, what may be safely tested using metal::is_just and may also be used to SFINAE out of miscomputations. Finally I'd like to point out that Metal was designed to be portable across as many compilers as possible and three of the most popular ones are continuously tested using Travis and Appveyor: Clang 3.5+, GCC 4.8+ and MSVC 14 (2015). I hope this is a reasonable proposal and I look forward into your opinions about it. ** Even though I haven't published any benchmarks yet, an example follows just to back my claims regarding performance (just tested on my personal laptop running linux): //Generate a list containing 10 thousand instances of std::integral_constant, from 0 to 9999 using l = metal::enumerate_t<metal::integer<10000>>; // GCC 5.3 ~0.4 s // Clang 3.7 ~0.5 s //Transform a list containing 5 thousand numbers by squaring each element using l1 = metal::enumerate_t<metal::number<long long, 5000>>; using l2 = metal::transform_t<metal::pow<metal::_1, metal::integer<2>>, l1>; // GCC 5.3 ~5.6 s // Clang 3.7 ~3.0 s [1]: http://thread.gmane.org/gmane.comp.lib.boost.devel/257680 [2]: http://thread.gmane.org/gmane.comp.lib.boost.devel/257983 [3]: http://thread.gmane.org/gmane.comp.lib.boost.devel/258843 [4]: http://pdimov.com/cpp2/simple_cxx11_metaprogramming.html [5]: http://rrsd.com/blincubator.com/bi_suggestion/mpl-lite-or-mpl2/ [6]: http://brunocodutra.github.io/metal/ Regards, Bruno Dutra

12 48

Fuzzy string search to the Boost String Algortihm
by Зайцев Александр 19 Sep '16

19 Sep '16

Hello. I want to discuss about some proposals. I am working on Levenshtein distance and Damerau-Levenshtein distance algortihms. I hope, that these implementations will be pulled to the Boost String library. But i think that we can add to the Boost String Library some more algorithms for fuzzy searhing. I mean these algortihms: Levenshtein distance Damerau-Levenshtein distance Bitap algorithm with modifications by Wu and Manber Spell-checker method N-gram method Signature hashing method BK-trees What do you think about this idea? If you think that it can be implemented to the Boost String Algo, i will start work on this list immediately. Best regards, Zaitsev Alexander.

2 2

[release] Boost 1.62.0 Beta 1
by Rene Rivera 14 Sep '16

14 Sep '16

The first beta packages for 1.62.0 beta 1 are now available: <https://sourceforge.net/projects/boost/files/boost/1.61.0.beta.1/> The SHA256 checksums are as follows: f7cc83e6a3b03cd7aa8822992aa3e36422cc2214644d69277ef55a4db51f44bd boost_1_62_0_b1.7z 4057993811e40b1fd4719675e44c2550b6c2379546192da2299c17fec9a3dddf boost_1_62_0_b1.tar.bz2 fb0c10b625c5ec47cc837b54740540e400c59571b2eabf427c00f32bffc6ca70 boost_1_62_0_b1.tar.gz b38ef21c43c5ff814a2144bc23871c134164e7f51c71672d0f49a44636fb50b5 boost_1_62_0_b1.zip As always, the release managers would appreciate it if you download the archive of your choice and give building it a try. Please report both success and failure, and anything else that is noteworthy. Thanks! -- The release managers -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 4

Gmane going away
by Tom Kent 07 Sep '16

07 Sep '16

So it looks like Gmane is under attack and the guy who runs it is thinking about just turning it off (that would be sad). https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/ Anyway, I know a lot of boost users use is as the gnu mailman archive pages are really hard to use. I would like to propose that we (specifically the list owner(s)) mirror the boost mailing lists to the mail-archive.com site. It has good search features and decent thread browse-ability. Thoughts? Tom

8 9

Please add component "dll" to track
by Antony Polukhin 31 Aug '16

31 Aug '16

Subj. Thanks! -- Best regards, Antony Polukhin

1 0

compiling boost using C++11 atomics
by André Draszik 30 Aug '16

30 Aug '16

Hi, Is there any particular reason that boost isn't being compiled with BOOST_AC_USE_STD_ATOMIC and BOOST_SP_USE_STD_ATOMIC (by default) when C++11 support in g++ is available (g++ >= 4.7)? Thanks, Andre'

3 5

[PropertyTree] Pull request removing usage of typeid()
by Chris Glover 29 Aug '16

29 Aug '16

Hi, In February, I submitted a pull request that removes the usage of typeid from property_tree and replaces it with boost.type_index. This allows me to use property_tree with rtti disabled, which I need sometimes. https://github.com/boostorg/property_tree/pull/20 I've had no feedback on the change. Can it be merged? Thanks, -- chris

2 2

[graph] Dinic's algorithm and BGL
by Зайцев Александр 29 Aug '16

29 Aug '16

Hello. In the Boost Graph Library i can't find Dinic's algorithm (https://en.wikipedia.org/wiki/Dinic%27s_algorithm) I think there isn't implementation of this algo in the library. Why? Best regards, Alexander Zaitsev.

2 2

[algorithm] Adding suffix automata, suffix array
by Зайцев Александр 29 Aug '16

29 Aug '16

Hello. I implemented Aho-Corasick to Boost.Algorithm. It's very useful algorithm, but i think that there are more useful algorithms, like suffix automata and suffix array. They can solve a lot of specific task on sequences of values: searching subsequences, count number of different subsequence, etc. Can i start work on it? ----- Best regards, Alexander Zaitsev.

2 3

[Boost.Book] How to go full-bleed on documentation image headers?
by Vinnie Falco 29 Aug '16

29 Aug '16

On the Boost website, the image in documentation headers is full bleed (no white border). For example: http://www.boost.org/doc/libs/1_61_0/doc/html/boost_asio.html How do I achieve this in my own documentation? I have set the image in the Jamfile, but I have no idea how to adjust the border: http://vinniefalco.github.io/beast/index.html The Jamfile and supporting source files are here: https://github.com/vinniefalco/Beast/tree/master/doc Thanks

2 1

[predef] macro to detect OS version on Solaris
by Aparna Kumta 28 Aug '16

28 Aug '16

I looked at the predef documentation and see BOOST_OS_SOLARIS macro to detect the Solaris OS. Is there a way I can detect the Solaris version? Thanks, Aparna | | <http://www.boost.org/doc/libs/1_61_0/libs/predef/doc/html/predef/reference/…>

3 2

[algorithm] Discuss about Aho-Corasick implementation
by Зайцев Александр 28 Aug '16

28 Aug '16

Hello. I implemented Aho-Corasick for Boost.Algorithm. I think that a lot of developers are interested in this and can look through my code and guess some suggestions. You are welcome: https://github.com/ZaMaZaN4iK/algorithm/blob/feature_branch/aho_corasik/inc… -- Best regards, Alexander Zaitsev

1 0

[Root.Ptr] Review Schedule Listing Fix
by Phil Bouchard 27 Aug '16

27 Aug '16

Greetings, In the formal review schedule page: http://www.boost.org/community/review_schedule.html Is it possible for somebody to: - Change the name of the submission "Block Pointer" to "Root Pointer" - Point the source code to: https://github.com/philippeb8/root_ptr - Point the documentation to: http://philippeb8.github.io/root_ptr This way people will at least be able to read something about Root.Ptr! ;) Regards, -Phil

2 2

[test] request to integrate a bugfix to master
by Raffi Enficiaud 26 Aug '16

26 Aug '16

Dear all, Please move boost.test to rev f68df446a4a5a3873e262364b56c5c2446216ae6 as it contains an important bug fix in case header only version of boost.test is used. Thanks and sorry for the noise, Raffi

2 1

[test] All geometry regression tests failing in develop and master
by Rene Rivera 25 Aug '16

25 Aug '16

Tagging subject for visibility. But this obviously needs to get resolved ASAP.. On Wed, Aug 24, 2016 at 3:53 AM, Barend Gehrels <barend(a)xs4all.nl> wrote: > Hi, > > It seems that nearly all regression tests are failing for us in both > develop and master: > > http://www.boost.org/development/tests/master/developer/geometry.html > > With the messages like: > > disjoint.obj : error LNK2001: unresolved external symbol > "public: virtual void __cdecl boost::unit_test::output::juni > t_log_formatter::log_start( > class std::basic_ostream<char,struct std::char_traits<char> > &,unsigned > long)" > (?log_start@junit_log_formatter@output@unit_test@boost@@ > UEAAXAEAV?$basic_ostream@DU?$char_traits@D@std@@@std@@K@Z) > > > We use Boost.Test (header-only), is there something changed there? Do we > need to change our Jam file? (of course we want to keep it header-only). > > The failures are new, before my one-week holiday it was still all OK. > > Regards, Barend -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

3 4

]dynamic_bitset] develop change never merged to master
by Edward Diener 25 Aug '16

25 Aug '16

In going through the CMT libraries for the upcoming release I noticed a longstanding change to dynamic_bitset on the 'develop' branch that added capacity, reserve, and shrink_to_fit functionality which had never been merged to the 'master' branch. The change is purely to add functionality rather than a bug fix, but it has been tested successfully on the 'develop' branch for a long while now. Do we want this functionality in the upcoming release ? If not, this change can be merged to 'master' after the release is out for the next release.

2 2

[release] Boost 1.62 now closed.
by Rene Rivera 25 Aug '16

25 Aug '16

Reminder.. The Boost 1.62 release, i.e. master branches, are now closed. Any change requires approval from a release manager. The release will reopen for bug fixes a week from now after the beta is posted. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

6 8

All geometry regression tests failing in develop and master
by Barend Gehrels 24 Aug '16

24 Aug '16

Hi, It seems that nearly all regression tests are failing for us in both develop and master: http://www.boost.org/development/tests/master/developer/geometry.html With the messages like: disjoint.obj : error LNK2001: unresolved external symbol "public: virtual void __cdecl boost::unit_test::output::junit_log_formatter::log_start( class std::basic_ostream<char,struct std::char_traits<char> > &,unsigned long)" (?log_start@junit_log_formatter@output@unit_test@boost@@UEAAXAEAV?$basic_ostream@DU?$char_traits@D@std@@@std@@K@Z) We use Boost.Test (header-only), is there something changed there? Do we need to change our Jam file? (of course we want to keep it header-only). The failures are new, before my one-week holiday it was still all OK. Regards, Barend

1 0

[Quickbook] Quickbook, SVG, graphviz dot
by Matt Calabrese 23 Aug '16

23 Aug '16

This is something of a stretch, but I'm hoping someone has a simple solution to my problem. I'm using Quickbook and in my docs I'm including an SVG that I generated from a graphviz dot file, which was also automatically generated from code that I'm documenting. Inside each of the nodes in the graph contained in the SVG, I would like to have source code snippets that are formatted in a way that is consistent with code snippets that are embedded in Quickbook files. Ideally, I'd like to even include Quickbook links in that source code, though I think that's likely a bit harder (my Quickbook code snippet files are usually written in a way that compiles in C++ but on the Quickbook end also replaces known functions with links to their corresponding docs -- I'd like to have that even in the nodes of the generated graph). I'm not certain where precisely to start as I'm rather far outside of my usual domain here. I pretty sure that it must be feasible in some way, as I know that SVG can embed links and use css, etc. but I'm not sure precisely how I should try to tackle this. Perhaps I can create some kind of post-process to run on the SVG that was generated from the dot file? Is there something simpler than this? Any ideas are appreciated. -- -Matt Calabrese

1 0

Re: [boost] double_ended - request formal review
by Mathias Gaunard 23 Aug '16

23 Aug '16

On 15 July 2016 at 16:51, Benedek Thaler <thalerbenedek(a)gmail.com> wrote: > Dear Boost, > > I'd like to request the review of the double_ended library. > > Code: https://github.com/erenon/double_ended > Documentation: http://erenon.hu/double_ended > > The library contains two classes. Excerpt from the documentation: > > * `devector` is a hybrid of the standard vector and deque containers, as > well as the small_vector of Boost.Container. It offers cheap (amortized > constant time) insertion at both the front and back ends, while also > providing the regular features of std::vector, in particular the contiguous > underlying memory. In contrast to the standard vector, however, devector > offers greater control over its internals. Like small_vector, it can store > elements internally without dynamically allocating memory. Not related to your request per-se, but I think this occasion is as good as any to discuss the library. devector is an interesting variant of vector, but it gives the illusion that is could be used as a queue. However given the implementation, it seems elements removed from either end will never be reclaimed. I suggest documenting that limitation or having a threshold above which memory is actually freed.

4 5

[CallableTraits] Seeking Review Manager
by Barrett Adair 23 Aug '16

23 Aug '16

Boost Developers, CallableTraits is a C++11/14/17 library for the inspection, synthesis, and decomposition of callable types. CallableTraits aims to be the "complete type manipulation facility for function types" mentioned in the final paragraph of C++17 proposal p0172. Library: https://github.com/badair/callable_traits Docs: http://badair.github.io/callable_traits/doc/html/index.html Boost Library Incubator: http://blincubator.com/bi_library/callabletraits-2/?gform_post_id=1574 Current Version: 1.0.1 I've received some great feedback on the mailing list. I consider the current version to be production-ready, which includes excellent cross-platform test coverage and thorough documentation filled with examples. Does anyone wish to be a review manager for this library? It is not a very large codebase, although the implementation is config-heavy and relatively noisy. The Library Submissions page on the Boost website indicates that a library manager should be found before requesting a formal review, but I noticed that there are many "scheduled reviews" that do not have a library manager. May I request a review as well? Thank you, Barrett

3 3

[release] Boost 1.62 closed for major changes.
by Rene Rivera 19 Aug '16

19 Aug '16

Reminder Boost 1.62, i.e. the master branches, are now closed for major changes. The only changes that should be going in at this time should be bug fixes for serious problems. Any documentation changes are fine to go in. And remember... Boost 1.62 will close for all changes a week from today. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

4 8

[odeint ] Can fix for ticket #12034 be merged into master branch?
by Aparna Kumta 19 Aug '16

19 Aug '16

The fix for Boost ticket #12034 has been in the develop branch for about 6 months now. Could this please be merged into the master branch so it makes it in for Boost 1.62 release? Thanks, Aparna

1 0

[circular_buffer] Synchronize master with develop
by Andrey Semashev 18 Aug '16

18 Aug '16

Hi, I've created this PR to synchronize master with develop for Boost.CircularBuffer: https://github.com/boostorg/circular_buffer/pull/10 Rene has given the permission to merge in the "[boost] [release] Boost 1.62 closed for major changes." thread. I would appreciate if someone with permissions could merge the PR. Thanks.

1 0

Status on Travis
by Raffi Enficiaud 18 Aug '16

18 Aug '16

Hi dear list, Hi Rene, I would like to know more about Travis and its status. From what I understand, a lot of efforts have been made recently for making things running per commit on Travis and have a quick feedback. * Naturally the first question is: is the status given by Travis the "official" one? so we consider the status given by Travis an official source of information, especially wrt. to its competing regression dashboard. * What are the development plans for Travis? Right now I see 3 types of builds, and I do not fully understand what they cover (platform, compiler) nor their differences. * For boost.test, I am testing each feature branch before merging to develop, by 1. cloning boost superproject on develop 2. switching only boost.test to the feature branch This is for preventing the breakages on develop that we observed in the past since several libraries are depending on boost.test. Would it be possible to have that as well on Travis or any continuous CI? That would be per library then. Would it also be possible to have like a template .travis.yml coming from the boost.superproject which can partly be overiden by a library? (if we want to build things slightly differently) * The CI I am using is able to parse the junit files generated by the test framework, and summarizes the information of each build nicely (also tracks the tests history). Is there anything similar in Travis? Right now, apart from looking at the full logs (which is hard), is there any intermediate information than red/green overall status? * I can see many project under the boostorg of Travis https://travis-ci.org/boostorg/ . How do we do that? Thanks, Raffi

3 4

[Beast] Status: HTTP+WebSocket for Boost
by Vinnie Falco 17 Aug '16

17 Aug '16

I’m reporting on the status of Beast, a C++11 header-only library implementing HTTP and WebSocket which is submitted to the boost incubator. The official repository for Beast is at: https://github.com/vinniefalco/Beast It has been a few months since the last update and the number of users measured on GitHub has grown steadily. There is robust, active development with bug fixes and improvements. Unfortunately there hasn’t been much of in terms of attention from the Boost community, no feedback from the incubator was provided. If anyone would like to help out by checking out Beast in the incubator and leaving some comments that would be a tremendous help. Incubator link: http://blincubator.com/bi_library/beast-2/?gform_post_id=1579 The most exciting news is that Beast HTTP and WebSockets have been deployed in the production server environment for the company I work for, Ripple (http://ripple.com) On a side note, my co-worker David Schwartz is giving a CppCon 2016 Keynote speech on the relationship of C++ to public blockchain systems and cryptocurrencies: http://cppcon.org/schwartz-keynote-turner-plenary/ You can see the Beast integration in “rippled”, an open source server application that implements Ripple’s decentralized ledger: https://github.com/ripple/rippled/tree/develop/src/ripple/server/impl I will be doing a 15 minute lightning talk introducing CppCon 2016 conference attendees to Beast. The talk will have 8 minutes of presentation with the remainder of the time allocated for questions (if there are no questions I have additional materials which can be presented). At the conference I would love to meet anyone who is interested in the library or wants to have their questions answered - feel free to reach out to me through my email address vinnie.falco(a)gmail.com (also listed on my GitHub profile) if you’d like to get in contact. Thanks! -- Follow me on Github: https://github.com/vinniefalco/Beast

2 1

[contract] Contracts for constexpr functions
by Lorenzo Caminiti 16 Aug '16

16 Aug '16

Hello all, A couple of the proposals I read on adding Contract Programming to the C++ standard raise the question if contracts should be supported for constexpr functions or not. I tough about this question a bit... but I am still not sure of the answer. I wanted to discuss this topic with this mailing list, especially with respect to what Boost.Contract can currently do. My general impression is that preconditions, postconditions, and class invariants should useful for constexpr functions but noting that: * Probably old values will not be useful in constexpr functions because constexpr prevents its functions from having side-effects (so it seems there will no variable visible outside of the function that the function body can change, and those variables are usually the candidates for making old copies). * Subcontracting will never apply to constexpr functions because they cannot be virtual. For example: struct conststr { // No virtual function so no subcontracting. [[invariant: empty() == (size() == 0)]] // Useful class invariants. [[invariant: data() != nullptr]] template<unsigned N> constexpr conststr(char const (&s)[N]) [[requires: s != nullptr]] // Useful preconditions. : data_(s), size_(N - 1) {} constexpr char back() const [[ensures(result): result == data()[size() - 1]]] // Useful postconditions. // Old values never useful because constexpr has no side-effects? { return data_[size_ - 1]; } constexpr unsigned size() const { return size_; } constexpr bool empty() const { return size_ == 0; } constexpr char const* data() const { return data_; } private: char const* data_; unsigned size_; }; That said, if I understand it correctly, the following are not allowed from within constexpr functions: 1. (Literal) type local variables with non-trivial constexpr destructors (see N3597 and subsequent proposals). 2. Try-catch statements (see N3597 and subsequent proposals). 3. Lambda functions (see N4487). Reading a few proposals, it seems that supporting the above from constexpr functions would be technically possible, but difficult to implement (see N3597 and its subsequent proposals, N4487, etc.). I'm not really familiar with these constexpr restrictions and plans/discussions to relax them in future revisions of the standard... Boost.Contract implementation uses all the above 1-2-3 respectively to: a. Check class invariants and postconditions at function exit (using RAII). b. Catch assertion failures as well as any other exception that might occur while evaluating an asserted conditions and then call the appropriate contract failure handler. c. Conveniently program functors that check pre- and postconditions within the contracted function. Therefore Boost.Contract implementation does not currently support contracts for constexpr functions. --Lorenzo

2 1

'is_palindrome' and 'const char*'
by Зайцев Александр 14 Aug '16

14 Aug '16

Hello. I have some question about some case for 'is_palindrome' algo. 'is_palindrome' algorithm checks a sequence - if sequence is a palindromeor empty, function returns true, in other cases returns false. But in case e.g. "a" (is_palindrome("a")) result is false, because "a" = {'a', '\0'}. And maybe this behaviour is unexpected for users. So... what do you think about it? Should I implement special version for const char* or not? -- Best regards, Zaitsev Alexander

3 4

filesystem 1.61.0 and cygwin: Windows assumed, posix expected
by Frédéric Bron 12 Aug '16

12 Aug '16

Hi, On cygwin, the following program #include <iostream> #include <boost/filesystem.hpp> int main() { auto p = boost::filesystem::path{"foo"}; p /= "bar"; std::cout << p.string() << '\n'; return 0; } outputs: foo\bar but cygwin is a posix system and I expect: foo/bar I read in the doc that "User-defined BOOST_POSIX_API and BOOST_WINDOWS_API macros are no longer supported." So how can I have posix support on cygwin? Thanks, Frédéric

1 1

[graph] Sync develop with master?
by Murray Cumming 12 Aug '16

12 Aug '16

Now that Boost 1.61 is out, it would be great if the various fixes in boost graph's develop branch could be merged/cherry-picked/whatever to master, please. There seem to be a couple of years of fixes that have not appeared in a release. -- Murray Cumming murrayc(a)murrayc.com www.murrayc.com

5 21

[thread][circular_buffer] Unmerged changes for 1.62
by Andrey Semashev 12 Aug '16

12 Aug '16

Hi, There are a couple of my PRs hanging for quite some time that I'd like to be merged before 1.62 is released: https://github.com/boostorg/circular_buffer/pull/9 Changes the default implementation of circular_buffer in debug mode to the thread-safe by default. https://github.com/boostorg/thread/pull/92 Fixes compilation of Boost.Thread with MSVC-8. There is also https://github.com/boostorg/thread/pull/94, which is not mine but it looks like it fixes a genuine problem. Could someone have a look at them and merge? Thanks.

2 3

[interprocess] weirdest bug with offset_ptr equality comparison
by Joaquin M López Muñoz 11 Aug '16

11 Aug '16

The following is a distilled testcase after the ticket reported at https://svn.boost.org/trac/boost/ticket/12367 #include <boost/interprocess/allocators/allocator.hpp> #include <boost/interprocess/managed_shared_memory.hpp> template<typename Allocator> struct node_base { using allocator_type=Allocator; }; template<typename Allocator> struct node_impl { using value_type= typename Allocator::template rebind<node_impl>::other::value_type; }; template<typename Super> struct trampoline:node_impl<typename Super::allocator_type>{}; template<typename Super> struct node:Super,trampoline<Super>{}; int main() { using node_type= node< node< node_base< boost::interprocess::allocator< int, boost::interprocess::managed_shared_memory::segment_manager > > > >; using pointer=boost::interprocess::offset_ptr<node_type>; pointer p=nullptr; bool b=(p==p); // here's the problem } This works fine with GCC. When compiled with Visual Studio 2015, we get: 1>------ Build started: Project: borrame2015, Configuration: Debug x64 ------ 1> sandbox.cpp 1>d:\usr\joaquin\proyectos\boost-repo\trunk\boost\interprocess\detail\mpl.hpp(74): error C2594: 'argument': ambiguous conversions from 'node<node<node_base<boost::interprocess::allocator<int,boost::interprocess::segment_manager<CharType,MemoryAlgorithm,IndexType>>>>> ' to 'node_impl<boost::interprocess::allocator<int,boost::interprocess::segment_manager<CharType,MemoryAlgorithm,IndexType>>> ' 1> with 1> [ 1> CharType=char, 1> MemoryAlgorithm=boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,ptrdiff_t,size_t,0x00>,0x00>, 1> IndexType=boost::interprocess::iset_index 1> ] 1> d:\usr\joaquin\proyectos\borrame2015\sandbox.cpp(39): note: see reference to class template instantiation 'boost::interprocess::ipcdetail::is_convertible<node_type *,PointedType *>' being compiled 1> with 1> [ 1> PointedType=node_impl<boost::interprocess::allocator<int,boost::interprocess::segment_manager<char,boost::interprocess::rbtree_best_fit<boost::interprocess::mutex_family,boost::interprocess::offset_ptr<void,ptrdiff_t,size_t,0x00>,0x00>,boost::interprocess::iset_index>>> 1> ] ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ========== Note that it is the line bool b=(p==p); // here's the problem that triggers the problem; if removed, compilation goes fine. Almost anything in the testcase program is needed for the problem to arise: - using node_type=node<node<...>> --> using node_type=node<...> (just one node level): compilation OK - remove using value_type=... in node_impl: compilation OK - rebind<node_mpl> --> rebind<char>: compilation OK - use std::allocator rather than boost::interprocess::allocator: compilation OK Ion, I'm totally puzzled by this and unable to navigate through the internals of Boost.Interprocess. Totally at your disposal if you need further info or assistance running tests etc. Thank you, Joaquín M López Muñoz

2 3

[contract] noexcept and throwing handlers
by Lorenzo Caminiti 10 Aug '16

10 Aug '16

Hello all, I would like to discuss contracts and exception specifications (e.g., noexcept) specifically with respect to what Boost.Contract does. On one hand, it seems silly to allow a contract failure handler to throw an exception to only translate such an exception into a call to terminate() for noexcept functions. However, noexcept can be considered part of the function contract (namely, the contract that says the function shall not throw) and contract failure handlers should not be allowed to break such contract, not even when they are allowed to throw. For example consider a noexcept function fclose() that is called from a destructor without a try-catch statement (correctly so because fclose is declared noexcept). If fclose() is now allowed to throw when its preconditions fail, that will cause the destructor ~x() to throw as well?! void fclose(file& f) noexcept [[requires: f.is_open()]] ... class x { ~x() noexcept { fclose(f_); // f_ might not be open because of some bug... ... } file f_; }; (A point similar to the above is also made in N4160, in contrast with what argued in N4110.) Functions should honor their exception specifications (noexcept, etc.) even when their contracts fail and contract failure handlers are configured to throw. That is what Boost.Contract does (given that contract checking code appears within the function definition so it is subject to the exception specifications that appear in the enclosing function declaration): void fclose(file& f) noexcept { // This will call terminate()... boost::contract::guard c = boost::contract::function() .precondition([&] { BOOST_CONTRACT_ASSERT(f.is_open()); // ...even if this throws. } ; ... } int main() { boost::contract::set_precondition_failure( [] (boost::contract::from where) { // Re-throw exceptions (assertion_failure, user-defined, etc.). if(where != boost::contract::from_destructor) throw; std::terminate(); // But destructors never throw. } ); ... } Also note that a contract framework that allows to install failure handlers that throw exceptions should also pass some sort of parameter to the handler function to indicate if the contract failure happened in a destructor or not. That is so the failure handlers can choose to never throw for destructors, not even if class invariants (or postconditions) fails when checked by destructors. --Lorenzo

3 4

[release] Continuous release archives.
by Rene Rivera 09 Aug '16

09 Aug '16

Starting with this release the archives for the prospective beta and release candidates are continuously built from the master branch and uploaded to SourceForge [1] (and to Bintray [2]). The release team would really appreciate if authors would download the archives and check the contents. In particular that the archives contain all the content you expect of your library, or libraries. And if you can also try building in your system that would stupendous. The more eyes we have on the final release products the smoother the process will be. And result in more time that the master branch is not blocked. Please report any problems sooner rather than later. So that we can try and address them before it's took late. Thank you, The Release Team [1] <https://sourceforge.net/projects/boost/files/boost/snapshots/master/> [2] <https://bintray.com/boostorg/master/snapshot#files> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

5 7

Feature suggestions for Boost's program_options
by Eyal Rozenberg 09 Aug '16

09 Aug '16

Greetings Boost developers, [ Disclaimer: I'm new to this list - I joined by Vladimir Prus' suggestion that I raise my feature ideas here on the list. I've read the posting guidelines, and I haven't seen any discussion of program_options (at least not by Vladimir himself) for at least a year back in the list archives, so I think my post is legit. ] I've been using Boost's program_options library for several months now. It mostly does the job (that's a compliment...) - but there are some features whose lack is really bugging me. For some of them (especially Feature Idea 1) I actually work around by taking some options as unparsed remainders, sticking them in a string->string map and parsing them myself. Without further ado, and in decreasing order of importance to me: -------------------------------- Feature Idea 1: Support specifying multiple alternative long option names, using comma-separation. Right now we can specify, for example, "include-path,I" - one short form, one long form. Why not allow specifying "include-path,include-dir,headers-path,I" ? Only the first long option name would be printed as part of the usage information, to not complicate things overmuch, and merely tolerate alternative phrasing. Feature Idea 2: Have a (new?) parser which supports taking "semi-parsed command-line options" as input: A map from string keys to string values, or to optional<string> values to represent options without an argument as well. This is actually very close to environment parsing, except that the environment parser gets its "map" from, well, the environment variables. So the implementation might be simply exposing the existing functionality with a slightly richer interface. Feature Idea 3: A facility for pretty-printing parsed options to an std::ostream, in which the option description starts the line, and the option value (not the name used for parsing) is printed after it. There is some pretty-printing for the usage info to the console, so why not this? (Argument against this idea: Choosing a default is a very touchy subject. Counter-argument: ... but that's also somewhat true of printing usage information; and nobody has to use this default, it would be entirely optional.) Feature Idea 4: Support three rather than just two levels of describing options: name, for the command line; short description, for listing values (see Feature Idea 3; long description for the usage info. Feature Idea 5: Create a variant of update_with which doesn't just set the option value, but creates a link of sorts between the variable which the app would use and the variable_map entry. With this in place, further changes to the variable map automagically affect the app variable. -------------------------------- So, - What do you think about these suggestions, in principle? - If you find some of them relevant, can you help estimate the necessary development effort and possible negative implications/caveats to consider? - Assuming a feature idea is both relevant and feasible, is it customary to request implementation by the maintainer? Commit yourself to implementing it vis-a-vis statement of statement of partiality to accepting a patch? Some other practice? Thank you for getting through the long(ish) email and for your hard work, Eyal Rozenberg DB architecture group CWI Amsterdam

3 4

[release] Boost 1.62 closing for new libraries this week
by Rene Rivera 07 Aug '16

07 Aug '16

Hopefully everyone has had a good Summer and has gotten all the new libraries and breaking changes in.. As we are closing the release window for that this week. Please consult the calendar [1] for the full release schedule. And take this as a reminder to merge your changes that you want in the next release as soon as possible. [1] <http://www.boost.org/development/index.html> -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

1 0

[boost-process] Beta & Review
by Klemens Morgenstern 07 Aug '16

07 Aug '16

Hi, boost-process is now in beta, you can check it out here: https://github.com/klemens-morgenstern/boost-process and read the doc here: http://klemens-morgenstern.github.io/process/ It will probably be in review in the beginning of November, Antony Polukhin will be the review manager. I really hope I'll get some feedback before that, so I can work on the weak points and also get more detailed in the documentation. Thanks, Klemens

4 10

[boost-spirit-qi] Support for n-ary operators PR
by Frank Hein 06 Aug '16

06 Aug '16

Hello, some days ago I raised an PR (https://github.com/boostorg/spirit/pull/200) which adds support for a new class of parsers, in particular named n-ary operators. Joel de Guzman reviewed that. The code is ok. Because this addition touches the inner core of qi, the metagrammar, Joel asked me to drum for support in the community. So if you are in qi, may I kindly ask you to review this PR, the code, the discussion so far, and respond, if you want to support this PR or if you think, it's not needed. Thank you very much. I highly appreciate your feedback. The PR description is very detailled, so this mail has not to be. :) Regards, Frank

1 0

Review Schedule and Review Manager for PODs Flat Reflection (ex magic_get)
by Antony Polukhin 05 Aug '16

05 Aug '16

Hello, PODs Flat Reflection (or PFR) is a C++14 library that represents POD structures as tuples and provides tuple-like methods for PODs. Library has a set of predefined operators for PODs and useful functions for everyday use. Works with user-defined types without any macro or boilerplate code. Library: https://github.com/apolukhin/magic_get Docs: http://apolukhin.github.io/magic_get/ Boost Library Incubator: http://blincubator.com/bi_library/pfr-pod-flat-reflection/?gform_post_id=16… Could the PODs Flat Reflection library be put on review schedule? Anyone wishing to become a Review Manager for the library? -- Best regards, Antony Polukhin

6 9

[config] RFC PR 82
by Domagoj Saric 01 Aug '16

01 Aug '16

Hi everyone, I am finally getting back to (trying to) contributing some of my personal projects to Boost. For two of those, Err (https://github.com/psiha/err) and especially Functonoid (a C++11 generalization and rewrite of my previous Boost.Function related work) I need some lower level codegen and/or optimiser control functionality (i.e. portable macros wrapping toolset specific attributes and pragmas) that I've added to my personal fork of Boost.Config and which I've now submitted in the subject PR (https://github.com/boostorg/config/pull/82) I don't expect this PR to be accepted as is/'just like that' so I'm opening this thread where we can discuss which of those changes/macros are welcome, which need more work and which, for some reason, should not be part of Boost.Config (and which, in turn then, I have to move to some 'internal implementation headers' in libraries that will need them). To avoid 'spamming' (and save time;) I'll skip the explanation of the individual macros as I expect them to mostly be self-explanatory (if not from their name then from the minimal Boost.Config documentation additions that are part of th PR). ps. I'll be on the (off) road for the next three weeks so I don't know when I'll be able to respond until I get back... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman

8 31

constexpr, cmath functions and other functions and distributions
by Paul A. Bristow 01 Aug '16

01 Aug '16

After much head scratching (and some head banging) - against a string of "Computer Says No" inscrutable diagnostic messages. I believe that I have now produced a (partial) version of Boost.Math normal_distribution that can be a constexpr using GCC6.1.1. (diagnosis has got to improve if constexprizing existing code is to become popular? ) constexpr normal_distribution<double> n01(0., 1.); producing this code 960 .loc 1 47 0 961 000d 660FEFC0 pxor %xmm0, %xmm0 # tmp89 962 0011 F20F1145 movsd %xmm0, -32(%rbp) # tmp89, n01.m_mean 962 E0 963 0016 F20F1005 movsd .LC1(%rip), %xmm0 #, tmp90 963 80080000 964 001e F20F1145 movsd %xmm0, -24(%rbp) # tmp90, n01.m_sd 964 E8 and more interestingly, a PDF can be calculated at compile-time constexpr double p = pdf(n01, 0.5); 965 .loc 1 56 0 966 0023 F20F1005 movsd .LC2(%rip), %xmm0 #, tmp91 966 88080000 967 002b F20F1145 movsd %xmm0, -8(%rbp) # tmp91, p 967 F8 Perhaps the assembler whizzes can confirm that this looks like a compile-time computation? This relies on lots of C++14 and 17 constexpr features, and Most crucially it relies on being able to use several cmath functions as constexpr. For a couple of trivially simple examples: abs(x) and isfinite(x). constexpr double ax42 = abs(-42.); // Unspecified version of abs. constexpr double ax42g = ::abs(-42.); // C double version? constexpr double ax42b = __builtin_abs(-42.); // builtin GCC only constexpr double ax42s = std::abs(-42.); // std:: version Without most cmath functions it seems to me impossible to write any reasonable (so-called special or not) mathy function or statistical distribution that can be constexpr. At present, only GCC 6.1.1 authors have foreseen this need and provided these so-called built_in_* cmath function versions that are constexpr, see https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html. (Aside on other compilers: · Clang 3.8 has some problem deep inside type_traits that I haven't yet investigated. · VS2015 update 3 still doesn't compile many essential C++17 features from my experiments so far, and doesn't provide any constexpr cmath functions. ) The many potential benefits of compiler-time computations are quite enticing to contemplate :-) * No run-time where possible * Errors caught at compile-time * Improved code readability * Reduce executable footprint and potentially most important * Avoid global initialization order issues * Avoid initialization thread races See · Scott Schurr, C++ Developer, Ripple Labs https://cppnow2015.sched.org/event/2oLK/constexpr-c-at-compile-time · Dietmar Khul Constant Fun https://www.youtube.com/watch?list=PL9hrFapz4dsM1B9bI8VmEE4JJlR0m-dvo <https://www.youtube.com/watch?list=PL9hrFapz4dsM1B9bI8VmEE4JJlR0m-dvo&v=T37…> &v=T37ElKPICvo&app=desktop Is there any support for making std::abs and friends constexpr where possible in future versions of the C++ Standard? Paul PS I can't conceive of any UDT using or providing floating-point without some function like frexp to get and set exponent and significand. I also note that making constexpr frexp and ldexp and other functions passing a pointer to a variable to be updated may be more difficult/impossible, and is very likely to require at least initialization of the to-be-updated variable before calling frexp. I've investigated overcoming this by writing a naïve new constexpr version of frexp returning a std::pair (significand and exponent) but, of course, it can never be a 'drop-in' replacement because it has a different signature, so lots of code changes are inevitable. --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

5 6