- Boost - lists.boost.org

[review] Formal review period for Sort library continuing through November 19
by Edward Diener 20 Nov '14

20 Nov '14

The formal review of the Sort library by Steven Ross, which started November 10 and is scheduled to continue through November 19th, begins its last 5 days today. We have had some great discussions and reviews so far and I would like to thank everybody involved. I would like to encourage all interested programmers, whether Boost developers or Boost users, to comment on and/or review the library. About the Sort library ================== The Sort library is a library which implements hybrid sorting algorithms based on a Spreadsort ( http://en.wikipedia.org/wiki/Spreadsort ), of which the author of the library, Steven Ross, is the inventor. The algorithm provides a sort that is faster than O(n*log(n)). The library provides a generic implementation of high-speed sorting algorithms that outperform those in the C++ standard in both average and worst case performance. These algorithms only work on random access iterators. They are hybrids using both radix and comparison-based sorting, specialized to sorting common data types, such as integers, floats, and strings. These algorithms are encoded in a generic fashion and accept functors, enabling them to sort any object that can be processed like these basic data types. Where to get it =============== The library is available on github at https://github.com/spreadsort/sort. The library is in modular Boost format and can be cloned to libs/sort under your local modular boost directory. I have provided as the review manager online documentation at: http://eldiener.github.io/sort Review guidelines ================= Reviews should be submitted to the developer list (boost(a)lists.boost.org) preferably with '[sort]' in the subject. Or if you don't wish to for some reason or are not subscribed to the developer list you can send them privately to me at 'eldiener at tropicsoft dot com'. If so, please let me know whether or not you'd like your review to be forwarded to the list. For your review you may wish to consider the following questions: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And finally, every review should attempt to answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Even if you do not wish to give a full review any technical comment regarding the library is welcome as part of the review period and will help me as the review manager decide whether the library should be accepted as a Boost library. Any questions about the use of the library are also welcome.

6 18

[optional] How to define boost::none?
by Andrzej Krzemienski 20 Nov '14

20 Nov '14

Hi Everyone. I am puzzled with a tough development task. I wonder if anyone is able to find a good solution. I want to re-implement tag boost::none. The current implementation is using a pointer to member which allows a harmful conversion from literal 0. Try this: boost::optional<boost::rational<int>> orat = 0; // this creates a disengaged optional. I want to rewrite the definition with the following goals in mind: 1. boost::none_t is not implicitly convertible from literal 0; 2. The solution works in C++98 3. The solution is implementable in a header-only library. (defining some member variable in a CPP file is not an option. The only solution I was able to find so far is this: [code] struct none_t { enum creator_t {creator}; none_t(creator_t){} }; namespace { none_t none (none_t::creator); } [/code] It works, but I feel uncomfortable defining boost::none in every translation unit. Any better ideas are welcome. Regards, &rzej

6 14

[BGL] [push_relabel_max_flow] multigraphs ?
by Pablo Madoery 20 Nov '14

20 Nov '14

I was wondering if the push_relabel_max_flow algorithm can be used in multigraphs. I mean, can I have two vertices joined by two edges: one in a direction an the other in the opposite direction with equal capacities ( 1000 for example ). It is clear in the documentation that the reverse edge must exist for each edge in the graph, so there must be 4 edges in the case I am describing. but the question is: does the algorithm works properly for this case ?

1 0

Re: [boost] [library-incubator vs Developer's list] was Ease commenting (Was: [safe_numerics] questioning the basic idea)
by Felix Uhl 19 Nov '14

19 Nov '14

Robert Ramey wrote: >> True, but it doesn't immediately raise a discussion - a message posted >> here gets seen by quite a few people, hopefully some of whom will be >> motivated to respond. > Damn - I just can't win here! As I said in a previous post, this is the problem of the incubator, a lack of community. I know that it would be a lot of work, but your best bet is to build on the large mailing list community that already exists. > a) Boost (I believe) was conceived as a way to support C++ with expanded > libraries > which would eventually enter the standard. > b) It has largely fulfilled that purpose. Making the standard a lot bigger > will make > it every more difficult for vendors to supply a conforming implementation. > So I don't > think the standard library can grow a lot more. Thoughts like that seem to be preliminary to me. We shouldn’t stop thinking about new facilities. But I agree that boost is not the “Soon on std” it was a long time ago, and I think this is the general consensus now. > c) But C++ still needs a lot of help. It needs a lot more libraries most of > which are > too special purpose to be suitable for inclusion in the standard. And the > number of > these libraries is large - on the order of 500. This has to be the goal of > Boost 2.0 This is a huge point of discussion, but probably not suited for this thread. The future of boost is a controversial topic, though. > d) This list can't do this job > 1) 500 libraries would drown this list. I agree that this mailing list is not suited for a larger number of libraries, it is already pretty crowded. I personally like the layout of forums, the ability to subscribe to threads and have subforums for different topics. We already have sublists for larger and more widely used libraries, so that’s something. However, I don’t think the incubator would handle that number of libraries well, either. Something prepared for that scale will probably be hard to implement in wordpress. For a plan this huge, you need to form a team of highly skilled professionals that can envision, plan and execute such a project. > 2) the discussions on the list are extremely useful and should be > preserved in an easily accessible way. Again, forums do that quite nicely. > 3) There needs a way to pay for this development - boost has no way to do > this. I’m not here since a long time, but from what I could tell, boost is not based on voluntary work entirely, is it? Still, you’re probably right in the way that boost encourages high quality libraries which are above the standard of many company-internal code, and that the countless hours of work for a library that is well documented, written and tested should be compensated for. For me, just the knowledge that other programmers, probably even companies, will use my code, is quite satisfying, but I’m only writing a small header-only library, something you could still consider a hobby. > 4) This needs a lot more library writers. > i) But most programmers don't know how to prepare a boost quality > library: code, tests, documentation, etc. I don’t think boost has to nor needs to train new programmers. There are good programmers out there, and some of them may have written code for their work that could become a good boost lib, if they had time to flesh it out. > ii) Most library writer need some hope of compensation to justify the > time spent. Yes. Especially considering that boost has high standards for code quality, you can’t just submit an interesting prototype and call it a boost library. > iii) All libraries need testers, critique, feedback, etc. Boost can > only do that for libraries in review - and we can't review the candidates we > already have. And we don't have a mechanism other than this list for > dealing with this outside of the review. In a nutshell, the developer's > list can't scale the way I think it has to. As noted previously, I agree with you there. --- Felix Uhl PS: Robert, you really like writing lists of stuff, don’t you? ;-)

2 1

[nowide] Add C++ 11 support
by Michael Smith 19 Nov '14

19 Nov '14

This is a library I'd like to see in Boost proper. I plan to use it in a current project. One enhancement that would make it easier to work with is supporting new C++11 interfaces for the adapters it implements. Things like explicit fstream (const string& filename, ios_base::openmode mode = ios_base::in | ios_base::out); Any plans to do that? I'm happy to do the work and share it on Github.

1 0

[fit] please respond
by Andrzej Krzemienski 19 Nov '14

19 Nov '14

Hi, Encouraged by Boost Library Incubator initiative I wanted to make a review of FIT library, but I found I had some questions to Paul - the author. I send my questions also here, in case you are not subscribed for the comments in Boost Library Incubator. Please see my comment here: http://rrsd.com/blincubator.com/bi_library/fit-3/?gform_post_id=1100 Regards, &rzej

1 0

Variant and visitation (was: [optional] Safe optional)
by Nevin Liber 19 Nov '14

19 Nov '14

On 18 November 2014 15:02, Matt Calabrese <rivorus(a)gmail.com> wrote: > > > > For a while I assumed exactly that, but he actually specifically voiced > > > that he does not like visitation on variant and thinks of it as a hack. > > > It's sad :/ > > > > > > > FWIW: I think he is (a) correct, but (b) we have nothing better to > replace > > it, so we still need it. > > > > We should really start a thread about this. I'm very curious to see an > actual objective rationale both for why visitation over a closed set of > types known at compile time is in any way a "hack," It's the inversion of control that people just don't like. > along with a realistic > alternative. As I already said, I don't know of one, and having it is better than not having it. The discussion in Urbana on n4218 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4218.pdf> (variant), which didn't propose visitation, basically amounted to we don't like visitation but we need it unless something better comes along. > It really is a fundamental operation of a discriminated union. > As someone who uses variants pretty much as the "default" for run-time > polymorphism in day-to-day coding, I have never seen an actual explanation > for what someone might consider bad about variant visitation, neither from > Bjarne nor anyone else. > While I don't want to speak for Bjarne, I believe he would rather have some form of Pattern Matching <http://www.stroustrup.com/OpenPatternMatching.pdf> and possibly variant as a language feature. That being said, no one has proposed it. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

5 8

Re: [boost] [optional] Safe optional
by Felix Uhl 18 Nov '14

18 Nov '14

Matt Calabrese wrote: > I know that there are others (Eric?) who prefer to think of optional as a > container of size 0 or 1, so it could also make sense to provide an > accessor to a range. One interesting effect of this is that now > range-based-for sort of becomes a "visit if." There are probably other... > interesting uses of standard algorithms. I don’t know why, but I really like that idea; int f(optional<int> input){ int ret = 0; for(int opt : input){ ret = opt; } return ret; } It somehow seems like a really interesting Syntax, but to be honest, it doesn’t really offer any benefits, does it? You neither have any improvements on performance, nor any on code clarity. --- Felix Uhl Von: Matt Calabrese Gesendet: ‎Montag‎, ‎17‎. ‎November‎ ‎2014 ‎17‎:‎41 An: boost(a)lists.boost.org On Nov 17, 2014 1:25 AM, "Andrzej Krzemienski" <akrzemi1(a)gmail.com> wrote: > No, no exceptions. > The solution is based on the observation that there is a limited number of > things you can do with optional<T> > > optional<int> oi = ...; > > 1: > if (oi) doSomething(*oi); > else doSomethingElse(); // or nothing > > 2: > if (oi) doSomething(*oi); > else doSomething(-1); // use default value > > 3: > if (!oi) oi = (int)getIntByOtherMeans(); > doSomething(*oi); // now it is safe > > Now we simply provide a dedicated interface for each of these three usages: > > 1: > oi.use(&doSomething, &doSomethingElse); // or use lambdas > > 2: > doSomething(oi.value_or(-1)); > > 3: > doSomething(oi.value_or_eval(getIntByOtherMeans)); While I agree that we should be encouraging high order functions/visitation here, my personal experience is simply that many people do not like it. When given the choice to pass a lamda or to use an "if" or a range-based-for over high order function alternatives, programmers will generally opt for not using a lambda. The fact that Bjarne thinks visitation is somehow "bad" doesn't help. I agree that it's safer and I'd be in favor of it, but be aware that not everyone will like it. That said, I'd be in favor of this. If going with this approach, though, I'd say make optional a model of a variant and/or discriminated union concept that it and variant share, along with "expected" if it were to make it into boost (I.E. allow for apply_visitor of T and none, provide a "which"). I'd still like to see the other functions you mention as well for convenience. I know that there are others (Eric?) who prefer to think of optional as a container of size 0 or 1, so it could also make sense to provide an accessor to a range. One interesting effect of this is that now range-based-for sort of becomes a "visit if." There are probably other... interesting uses of standard algorithms. > I would rather not go that way. boost::optional is not unsafe. It is simply > something else than what some people think. Its conceptual model is more > like any value of T, plus one additional value. In this model implicit > conversions make perfect sense and are n fact desirable. I'm not sure I agree. These two templates aren't exactly complimentary in terms of the functionality that they provide, they really would just provide exactly the same functionality with the same internals. All that is different is the interface. Because of that, I say either it replaces optional or it doesn't exit as a part of boost. If people are convinced that this interface is less error prone, then it should be THE interface for optional. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[config] [VC++ 14.0 aka 2015] Removing BOOST_MSVC_ENABLE_2014_JUN_CTP macro requirement.
by Beman Dawes 18 Nov '14

18 Nov '14

As of the moment, the BOOST_MSVC_ENABLE_2014_JUN_CTP macro must be defined to eliminate a bunch of macros that should not apply to the Visual Studio 2015 Preview: BOOST_NO_CXX11_ALIGNAS [no value] BOOST_NO_CXX11_CHAR16_T [no value] BOOST_NO_CXX11_CHAR32_T [no value] BOOST_NO_CXX11_INLINE_NAMESPACES [no value] BOOST_NO_CXX11_NOEXCEPT [no value] BOOST_NO_CXX11_REF_QUALIFIERS [no value] BOOST_NO_CXX11_UNICODE_LITERALS [no value] BOOST_NO_CXX11_USER_DEFINED_LITERALS [no value] In other words, the only CXX11 macros that should be defined are: BOOST_NO_CXX11_ADDRESSOF [no value] BOOST_NO_CXX11_CONSTEXPR [no value] Unless someone objects strongly in the next few hours, I'm going to remove the need for the BOOST_MSVC_ENABLE_2014_JUN_CTP macro; it is just causing confusion at this point. --Beman

6 11

noexcept(true) for ~noncopyable?
by Olaf van der Spek 18 Nov '14

18 Nov '14

Shouldn't ~noncopyable be noexcept? I'm seeing this error: class Cconnection : public Cclient, boost::noncopyable connection.h:5:7: error: looser throw specifier for ‘virtual Cconnection::~Cconnection()’ In file included from connection.h:3:0, from connection.cpp:2: client.h:10:10: error: overriding ‘virtual Cclient::~Cclient() noexcept (true)’ https://svn.boost.org/trac/boost/ticket/10698 -- Olaf

2 3