December 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

[beast] Request for Discussion
by Vinnie Falco 12 Jun '17

12 Jun '17

Beast provides low level HTTP and WebSocket interfaces built on Boost.Asio, the project is here: https://github.com/vinniefalco/Beast The plan is to solicit feedback from the Boost community before submitting a request for a formal review. First a brief update: I have attended CppCon 2016 and provided a 15 minute Lightning Talk on the library. There should be a video up at some point with all the talks, including mine. I spread the word about Beast and discovered that there are several folks in the wild already using the library and happy with it. There are also a couple of commercial products that are using it. One point brought up during the conference is that Beast does not offer sufficient higher level HTTP functionality. This omission is intentional. It is my idea to offer the building blocks (serializing and deserializing HTTP/1 messages, in synchronous and asynchronous flavors, and a universal HTTP message model), upon which other developers more knowledgeable than me could build those interfaces. The higher level pubic operations requested were: 1. Perform HTTP GET or POST and receive the response. Presumably this would handle both plain and TLS connections, handle redirects, and handle HEAD requests. Not sure about traversing proxies. 2. Expose an asynchronous HTTP server class which callers can instantiate with some sort of handler that returns the HTTP response given a request. It should be possible, in a minimal number of lines, to quickly get a server up and running. The requestor informed me that this functionality did not need to provide every possible feature or handle every use case. It just needed to handle the common use-cases. For the record, I am against this higher level functionality for a number of reasons. The higher the level of functionality, the more contentious the feature becomes, and the harder it is to satisfy a quorum of reviewers. No one would dispute that we need the ability to read a complete HTTP message from a socket. But not everyone will agree that a HTTP server needs an option to allow multiple listening sockets with different level of permissions. Another problem with offering higher level functionality is that it could be less likely to be approved for standardization in the C++ standard library. For example, the attributes of ease of use and fully functional oppose each other. If the functionality offered by a hypothetical std::http::client is not sufficient, a developer would be forced to write their own with little possibility to reuse parts of the implementation from the stdlib. I doubt the committee would approve of such a thing. I know I wouldn't. Admittedly I have little experience or knowledge on what would or would not get approved. A point was raised that a low-level-only HTTP implementation in Boost has the potential to discourage new users that need to perform simple operations like HTTP GET from using Boost in the future, given that robustly handling such operations would require the developer to write a significant amount of code. I can see some validity here. On the other hand, if Boost.Asio was submitted for a formal review today, would those same points be raised? Would Asio get rejected because it doesn't offer public interfaces for doing simple tasks like requesting an object from a web server? I wonder if perhaps the Boost formal review process has become defective. For reference here is what the current API offers: Example program that performs HTTP GET, then receives and prints the response: https://github.com/vinniefalco/Beast/blob/master/examples/http_example.cpp This is a high performance asynchronous HTTP server that serves local files as static pages. It is not an official API, it is part of the examples. Users who want a server need to copy the source code and modify it to suit their needs: https://github.com/vinniefalco/Beast/blob/master/examples/http_async_server… My initial purpose for requesting this discussion is two-fold: 1. Determine the level of consensus on the issue that Beast needs to do more for HTTP than the lowest level of functionality (reading and writing messages). I'm open to hearing all arguments for and against. 2. Get feedback on what official public interfaces to higher level functionality might look like. Specifically, a client that handles GET and POST, and a generic asynchronous server. And what features those interfaces would support. For example, is traversing a proxy a necessary feature for an official client interface? The best answers would provide function signatures or class declarations using the existing Beast HTTP types. In case its not clear, I am asking stakeholders and reviewers to help design the library. I'll open a discourse on the HTTP client to illustrate the proposed style of discussion: We want to provide a HTTP client implementation that lets users perform simple tasks like fetch a resource from a remote host. Calling code should be compact, letting people get their job done without getting mired in boilerplate. Here's a possible signature with example use: response_v1<string_body> get(std::string const& url, error_code& ec); error_code ec; auto res = get("http://boost.org", ec); if(! ec) std::cout << res; else std::cerr << ec.message() << '\n'; The get function would automatically perform the name resolution, connect the socket, request the resource with uri "/", and return the result. There's a problem here though, the caller is forced to use a message with std::string as the container for the body. An obvious fix is to add a template parameter: template<class Body = string_body> response_v1<Body> get(std::string const& url, error_code& ec); Better, but what if the body is not DefaultConstructible? We can add some parameters to forward to the Body constructor: template<class Body = string_body, Args&&... args> response_v1<Body> get(std::string const& url, error_code& ec, Args&&... args); We're getting somewhere now. Most users will use the default body, while an option exists for advanced users. But the implementation of get now has a complication. If an error occurs, it still has to construct a return value. This problem is likely surmountable but lets table it and start a new line of reasoning. What if the URI indicates https, e.g. "https://boost.org"? We can hide that under the hood by using a separate code path that uses asio::ssl::stream instead of ip::tcp::socket. But how does the caller provide the root CA certificates? How does the caller provide a client certificate? We are left with a client that satisfies two thirds of users but is unusable for the remaining one third. Is this Boost worthy? Is this std-lib worthy? I think not. Lets revisit the SSL issues later and think about a new problem. What happens to the socket when the request is done? In the proposed interface, the socket is destroyed. This means you can only make one request on a connection. At this point, I think its clear that the current interface is a non-starter. Here's a better idea. Lets define a class called client and make get a member function. Now we can have state, including configurable settings with reasonable defaults. class client { public: template<class Option> void set_option(Option&&); template<class Body = string_body, Args&&... args> response_v1<Body> get(std::string const& url, error_code& ec, Args&&... args); }; client c; error_code ec; auto res = c.get("http://boost.org", ec); if(! ec) std::cout << res; else std::cerr << ec.message() << '\n'; We still have some of the original problems, but other problems are solved. The class can keep the socket around, so that a subsequent call to get with the same server will use the already-open socket. The caller can set options on the client object instance before invoking get, such as any TLS certificates. Unfortunately we have new problems. Where is the io_service? If the class creates it for you, how many threads? How do I use my existing io_service, or is that even necessary? The class interface allows the connection to be kept alive but what if now the caller wants to close it (i.e. specify "Connection: close" in the request)? And there are some problems which are applicable to any interface. How does the caller adjust the parser options, for example change the limit on the size of the body? What if the caller wants the request made using a specific HTTP version? How does this handle basic authentication? How can the caller adjust the headers in the request? etc... This is why I think that offering a HTTP client is a rabbit hole which can only lead to a rejected formal review. Or maybe I am overthinking this? I'd love to hear proposed solutions to the issues (which could be just to say "forget about those features"). Despite my objection I have started work on these features anyway. Here are the beginnings of a HTTP client: https://github.com/vinniefalco/Beast/blob/88b485df7e6216282842f40cf99cc75de… Here is some work on a generic server: https://github.com/vinniefalco/Beast/blob/server/extras/beast/http/async_se… Please reply to this thread instead of starting a new thread, and keep the subject line prefix (e.g. "Re: [boost] [beast] ...") Thank you

21 58

[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

[stacktrace] review
by Artyom Beilis 10 Mar '17

10 Mar '17

Hello, This is my review of stacktrace library: Note that I have experience with the subject as I developed a similar library for the CppCMS framework [1] > - What is your evaluation of the design? > The design is straight forward and I don't see any major issues with the API. Also I have several suggestions in handling backtrace with catch from } catch (const traced& e) { std::cerr << e.what() << '\n'; if (e.trace) { std::cerr << "Backtrace:\n" << e.trace << '\n'; } } catch (const std::exception& e) { std::cerr << e.what() << '\n'; } In my library I use much simpler approach in terms of API [2] catch(std::exception const &e) { std::cerr << e.what() << std::endl; std::cerr << booster::trace(e); } Where booster::trace is a manipulator that prints strack trace if "e" contains backtrace information - much shorted code without additional catch. I find it very easy to use. Just a suggestion. I also like with_trace templated class idea. > - What is your evaluation of the implementation? Most of my > personal concerns with this library are with the implementation and I > would hugely appreciate feedback from others with substantial > experience of using stacktracing "in anger" in non-trivial use case > scenarios. I mostly reviewed the backend. Linux: ========= 1st of all: I recommend mentioning in the documentation the option -rdynamic/-export-dynamic as otherwise dladdr would likely to fail - it is critical as many may miss one. Regarding use of add2line utility: 1. Failing to calling an external program in case of dladdr fails is bad idea. This behaviour is unexpected by the user. I understand the advantage of this as you can use debug information but should be done only per user specific request (i.e. compilation option) and not by default. 2. If you call add2line - use it for ALL addresses in backtrace at once and not for each single one! My recommendation is to provide alternative backed that uses other way to extract information not involving forking. Maybe try to analyze debug data or so - or require preparing initial map using nm tool and than loading it from file or something like that. Additionally calling the backed linux is bad - as same approach with slight modifications works on *BSD, Mac OS X and Solaris (RIP). Windows: ======== I have a question why you used COM instead of SymFromAddr functions? I understand thread safety issues but simple mutex can solve them. My concerns are regarding MinGW compilers. Have you tested it on MinGW compiler? It wouldn't work as it used MSVC debug information in general so maybe it is good idea to provide an alternative backend that extracts only address and DLL name so you can analyse the stacktrace later (using addr2line utility for example) Take a look on my code [1] regarding non-msvc windows compilers - it provides at least some useful information. > - What is your evaluation of the documentation? The documentation is ok in general and straight forward as the library itself. What I do lack is the documentation of underlying backends - how do they work. 1. use of -rdynamic/-export-dynamic should be noted in "bold face" regarding the use of the library. 2. please do not call it "POSIX backend" - as there none of the stuff you use is actually POSIX... Also you'll probably need different backends for MINGW and mention it. > - What is your evaluation of the potential usefulness of the > library? Very Very useful. > - Did you try to use the library? With what compiler? Did you have any problems? No I didn't - I mostly read the documentation and the backend code. > - How much effort did you put into your evaluation? A glance? A > quick reading? In-depth study? 3-4 hours > - Are you knowledgeable about the problem domain? Yes I am. I have written similar library for CppCMS project [1] - FINAL VOTE: Yes, Conditionally Conditions: Use of addr2line must not be enabled by default. [1] https://sourceforge.net/p/cppcms/code/HEAD/tree/framework/trunk/booster/boo… https://sourceforge.net/p/cppcms/code/HEAD/tree/framework/trunk/booster/lib… [2] https://sourceforge.net/p/cppcms/code/HEAD/tree/framework/trunk/booster/boo… Best Regards, Artyom Beilis

4 5

[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

Variadic append for std::string
by Olaf van der Spek 19 Feb '17

19 Feb '17

Hi, One frequently needs to append stuff to strings, but the standard way (s += "A" + "B" + to_string(42)) isn't optimal due to temporaries. A variadic append() for std::string seems like the obvious solution. It could support string_view (boost and std), integers, maybe floats but without formatting options.. It could even be extensible by calling append(s, t); append(s, "A", "B", 42); Would this be useful for the Boost String Algo lib? -- Olaf

16 104

[teeks] Missing winerror.h for MSVC-9
by Andrey Semashev 17 Feb '17

17 Feb '17

Hi, I see lots of tests failing on teeks99-09b-win2012R2-64on64, MSVC-9.0 because winerror.h is missing. Here's an example: http://www.boost.org/development/tests/develop/developer/output/teeks99-09b… I can see that the file is present in Windows SDK 6.0A, which is supposed to be used with this compiler. The tests are passing on my machine. Could this be a tester configuration issue? Also, all MSVC-15 tests are failing on teeks99-09o-win2012R2-64on64 with the error of 'cl' not being found.

3 14

[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

bad boost_1_63_0.tar.bz2 sha256sum
by jack nade 03 Jan '17

03 Jan '17

Expect beae2529f759f6b3bf3f4969a19c2e9d6f0c503edcb2de4a61d1428519fcb3b0 for https://sourceforge.net/projects/boost/files/boost/1.63.0/boost_1_63_0.tar.… Get a9eec759dd97798b06eb258a1c6ad4a39ff43b483594a22298ccdfae8116ce16

3 3

[trac] Boost v1.64 in the milestones?
by Raffi Enficiaud 03 Jan '17

03 Jan '17

Dear all, Since 1.63 is (almost) out, would it be possible to have 1.64 in the milestones of trac? Thanks, Raffi

7 15

Review quality (was: [stacktrace] review (changing vote to NO))
by Andrey Semashev 03 Jan '17

03 Jan '17

On Mon, Dec 26, 2016 at 3:58 AM, Vladimir Batov <Vladimir.Batov(a)constrainttec.com> wrote: > On 2016-12-26 10:41, Andrey Semashev wrote: >> >> Acknowledging the need for a particular functionality is not the same >> as accepting a particular implementation. > > Put bluntly users do not care about implementation. Please, don't speak for others. I, personally, very much care about implementation, and I can see other reviewers did take a look at the implementation as well. I think, making judgment on the library quality without regard to the implementation quality is irresponsible and short sighted. That kind of approach tend to result in "5 minute hack" solutions of obviously poor quality. But that's just my opinion. > They care about > functionality provided. I advocate giving the lib a "foot in the door". That > and far better feedback from the users will be a strong incentive for the > author to keep working and improving the lib. You seem to prefer > all-or-nothing approach. I believe it's unrealistic and bad. You might > disagree. First, nowhere in my message I advocated for "all-or-nothing approach". What I advocated for is a fair review, outlining all ups and downs of the library, and if the reviewer feels downs are significant enough, he would be right to vote for rejection. Second, it's not like the library does not exist before it is accepted. Users and the author have every opportunity to try the library in the field, if they want to. There is blincubator.com as well. >> By >> turning a blind eye on a design flaw of a presented library you're >> doing a disservice to the library author and the library users. >> Instead, by giving constructive feedback (positive and negative), >> especially if supported by real world experience, you help the library >> improvement. In fact, this (the feedback) is the most valuable reward >> for the author from the review. And let me say, there's nothing >> humiliating in having a library rejected during a review. > > Well, I do not get scolded often these days. So, it is quite "refreshing" to > learn that I am "turning a blind eye on a design" and "doing a disservice". > I thought I was merely expressing my humble opinion... but probably I got it > all wrong. Well, maybe you shouldn't have taken my message personally then. It wasn't meant to scold anyone. If anything, it was written with the intent to provide another (mine) perspective on what a review is and object to your notion of library review as being a humiliation. The last part, actually, was kind of offending from your side and what triggered my reply in the first place. > As for the feedback, then I do not see voting something useful "no" to be > much of a feedback. Indeed, the author does get initial feedback during a > review. However, not all of that feedback is constructive. Some valid, some > subjective, some capricious. After it's voted out the feedback is no more. The review entails a discussion. Some reviewers get convinced. Some review points get refined, and the author gets convinced. Sometimes review votes get changed. And it's not like the votes are final - the actual decision is taken by the review manager, and he can weigh the points made in reviews and discussion at his discretion. And it's not like the library disappears after the review. If it's interesting and useful, it'll have its users, and they will no doubt provide feedback. > Real valuable feedback will come when the lib is in Boost. People'll start > using the lib (I would) in their real projects asking for this and that. Real world usage produces valuable feedback, no doubt about that. But Boost acceptance is not a pre-requisite for real world usage. >> There are things that can be fixed post-review. >> ... >> There are other things that cannot be fixed easily and would probably >> require changing library design. Those changes often affect library >> API and usage patterns, which warrants the need of a new review of the >> reworked library. > > Yes, all that sounds wonderful... on paper. In real life as a user I'll take > what's available first. Then, if that is improved in the next version, I'll > take it gladly. If design changes and gives me more or fixes something, I'll > accept that. I doubt you'd be so easy to accept the changes if that required you to rewrite half of your code. :) > I do not remember Spirit transitioning from V1 to not > backward-compatible V2 being re-reviewed. I can be wrong though. I don't remember the review either. But Spirit v2 was added in addition to Spirit Classic (aka v1), which is still available in Boost. It was more like a new library was added. Should it have been reviewed? In my opinion, at least a mini-review should have been performed. Luckily, Boost.Spirit dev team has rich experteese in the domain and a lot of experience gained with v1, so v2 was a success. >> In those cases it's better to reject the library so >> that the new, improved version is presented later. > > Again, wonderful.. in theory. The reality IMO is different because 1) > "improving" is better with real user feedback that you deny to the author by > voting "no"; 2) "later" might never come as the review process is quite > exhausting/draining; not everyone wants to experience it again; you might > say "too bad for him"; I'll say it's bad for the user as well as they end up > with your good intentions and no library; 3) "later" might be too late as by > that time the user'll have something else in place. Again, it's not like the library doesn't exist outside Boost. If it fits you, go right ahead, so 1 is not true. But Boost does set a certain bar of quality, and the review process exists precisely to maintain that bar. And I'll take your 2 and 3 any time if it results in a high quality library in Boost. >> Consider also that whenever a library is accepted into Boost, the >> matter of backward compatibility appears. If the accepted library is >> somehow seriously flawed, that flaw may be difficult and painful to >> fix in the future. > > "difficult", "painful", "backward compatibility"... Come on. I am sure > you've been in the industry for a while, have "survived" many > upgrades/updates, etc. We all know it's not an issue. We update, adjust, > move on. Let's just say it can be an issue. On Mon, Dec 26, 2016 at 3:54 AM, Robert Ramey <ramey(a)rrsd.com> wrote: > On 12/25/16 3:41 PM, Andrey Semashev wrote: >> >> Consider also that whenever a library is accepted into Boost, the >> matter of backward compatibility appears. > > How so? Certainly there is no requirement that boost libraries support older > versions of C++ and/or compilers - and indeed many don't. I don't think I > see what you're referring to here. I think you misunderstood. I wasn't speaking of C++ versions backward compatibility. I was speaking of the library backward compatibility. AFAIK, making backward incompatible changes is still considered an undesirable practice. >> If the accepted library is somehow seriously flawed, > > Then of course it should be rejected. Of course reaching a concensus as to > whether it's flawed might not be so easy. Right, that was my point. >> [1]: http://www.boost.org/community/reviews.html > > I checked this page and don't see where it says anything relevent to your > points. Maybe you missed this section: http://www.boost.org/community/reviews.html#Comments <quote> Your comments may be brief or lengthy, but basically the Review Manager needs your evaluation of the library. If you identify problems along the way, please note if they are minor, serious, or showstoppers. The goal of a Boost library review is to improve the library through constructive criticism, and at the end a decision must be made: is the library good enough at this point to accept into Boost? If not, we hope to have provided enough constructive criticism for it to be improved and accepted at a later time. The Serialization library is a good example of how constructive criticism resulted in revisions resulting in an excellent library that was accepted in its second review. </quote>

8 16

Re: [boost] documentation 1.63 not up to date
by Oliver Kowalke 02 Jan '17

02 Jan '17

Hello Daniel, I'm referring to http://www.boost.org/doc/libs/1_63_0/libs/fiber/doc/html/fiber/performance.… . The page should contain three tables (the one related to threads is missing) - my modification s date from end of November. Oliver Am 27.12.2016 1:35 nachm. schrieb "Daniel James" <dnljms(a)gmail.com>: On 27 December 2016 at 08:59, Oliver Kowalke <oliver.kowalke(a)gmail.com> wrote: > Hi, > could you update the documentation of boost-1.63 please - it is not up to > date. > For instance in boost.fiber commit 648de6a66544c5d03e5595cb25ed76 5ee0cd40d2 > (17.12.2016) is missing. > Thank you in advance, > Oliver The documentation on the website should just be whatever is in the release. It's a bit hard to know without a link to the page where that change is meant to be. I think what you're seeing on the website are the html files that are checked into git. I guess the documentation build isn't replacing them. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

3 4

Re: [boost] [Bulk] Voronoi
by ayse 30 Dec '16

30 Dec '16

Thank you, I will watch it. Belowing code gives "floating point divide by zero" error std::vector<Segment>segments; segments.push_back(Segment(40, 0, 40, 100)); segments.push_back(Segment(40, 0, 100, 0)); segments.push_back(Segment(40, 100, 100, 100)); segments.push_back(Segment(100, 0, 100, 30)); segments.push_back(Segment(70, 30, 100, 30)); segments.push_back(Segment(70, 30, 70, 70)); segments.push_back(Segment(70, 70, 100, 70)); segments.push_back(Segment(100, 70, 100, 100)); // Construction of the Voronoi Diagram. voronoi_diagram<double>vd; * construct_voronoi(segments.begin(), segments.end(), &vd); // it gives floating point divide by zero error* My drawing, [image: Inline image 2]

1 1