- Boost - lists.boost.org

[algorithm] More general purpose algorithms?
by Sai Kiran Talamudupula 10 May '13

10 May '13

Hi, I am new to using boost libraries. I want to contribute to [boost.algorithm]. I see that there is scope for adding more general purpose algorithms in the library now. If I might have some ideas, is this the right place to propose and discuss them? Do I need to follow any procedure and/or address a specific person? Best, Saki.

2 1

Wanted: reviewers for boost.test doc overhaul
by legalize+jeeves＠mail.xmission.com 10 May '13

10 May '13

[Please do not mail me a copy of your followup] As per the "What do we do about boost.test?" thread last year, the biggest complaint seemed to be the documentation. I'm overhauling the documentation using quickbook and I'd appreciate incremental feedback along the way. Any takers? -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

5 4

[TypeErasure] references
by Chapman, Alec 10 May '13

10 May '13

Hi Steven, I have a somewhat-generic type erasure class that I would like to switch to yours. The main difficulty I can see is in the way capturing by reference is handled. The approach I take in my class is to pass a boost::reference_wrapper to the constructor: typedef mpl::vector<copy_constructible<>, type_id_<>, incrementable<> > requirements; int i = 0; any<requirements> x(boost::ref(i)); // capture i by reference ++x; // i == 1 any<requirements> y(x); // makes a copy of i ++y; // i == 1, any_cast<int>(y) == 2 My motivation is that I have a bunch of template functions already written that I often call directly, but in other cases I need to compile them separately by instantiating them with any<...>: ---------------------- module 1 ------------------------- // some long algorithm that I don't want to modify to be aware of any<...> template<class T> void f(T& t) { ++t; T t2 = t; ++t2; // do something with t2 } // make a type-erased version for separate compilation void any_f(any<requirements>& x) { return f(x); } -------------------- module 2 ---------------------------- // provide a thin wrapper that applies type erasure before calling any_f template<class T> void f_fwd(T& t) { any<requirements> x(boost::ref(t)); any_f(x); } // some function that needs to call f void g(int& i) { // do something with i... // then pass it to f f_fwd(i); } Is something like this possible with your method? Are there advantages that I'm not seeing to having the type signature contain information about whether the object is held by reference? Thanks, Alec

3 6

Re: [boost] Git Modularization Ready for Review
by Niall Douglas 09 May '13

09 May '13

> > I'm far more confused as to why? Surely the conventional approach is to > > convert a SVN repo to GIT. > > Good luck with that, given the way SVN "branches" (really directories) > have been used in Boost's history. No automated tool is able to > determine how to map those things properly onto Git branches. You can > see evidence of that in repositories.txt (look at the "build" repository > declarations for example). Me personally I'd just chuck away any unmappable historical information. Chalk it up to a cost of transition. If they really need the history, they can go fetch it from the read-only SVN repo. > You act as though we haven't been thinking about how to do this well and > working on it for years already. We're quite well-aware how submodules > work. The use of submodules by most developers is supposed to be a > temporary transitional measure, since modularization is designed to > allow you to work with only the parts of Boost relevant to your project. You have mistaken my confusion for criticism. I am not criticizing. I am confused. > > Also, how is Boost going to manage dependency breakage across multiple > > submodules? > > What is "dependency breakage?" Generally speaking Git submodules are for loosely coupled relations because of how Git implements submodules. Some of Boost's constituent libraries do meet that definition (BPL, BGL, Math). Some do not, as they are too essential because so many other libraries depend on them (anything likely to enter the standard with TR2, the MPL, the PPL etc). I fear that if modularization is taken to its logical extreme, you could see submodules get out of step with other submodules. You may of course have already anticipated this and have implemented something I haven't realized. As I said, I am confused. > > Are you planning to keep headers in one monolithic repo > > No > > > but keep anything resulting in a DLL/SO in a submodule? Or are you > > planning to break out the headers into submodules too? > > Yes; it's already done, modulo some expected adjustments due to the > review I am requesting. One solution is to require all findable headers to live inside the main Boost repo [1], and only implementation to reside in submodules. That keeps minds focused on dependency management. [1]: By findable I mean that when Boost library users do #include <boost/whatever> they get the main Boost repo version, not the submodule version. I absolutely would expect an automated tool to pull headers from submodules, check them for ABI breakage and push them into the main repo. My point is that some sanity check ought to be there. > > I can see it becoming quite easy for submodules or branches or forks > > thereof to get out of step with one another. > > That's a *good* thing. We're trying to decouple. Most libraries will > be developed against the previous release of their dependencies. > > > I can see the present submodule heavy approach introducing a lot of > > anti-Git workflow because those submodules inside the boostorg > > organization are treated as special compared to other submodules. > > I don't have any idea what you mean here Git generally has you clone the authoritative master repo, you create a branch, make your changes. Once you're finished, you fetch latest master, merge into your branch until it's up to date, then generate a patch or pull request from your branch to authoritative master. Whoever gatekeeps that repo does the merge. Where I'm getting confused - again - is that it would seem that the submodule repos inside the Boost org section on github are the ones to be regression tested and used to assemble releases. So, instead of treating all git repos as one-among-many as say Linux would do, we've got a special "high" gold candidate set of git repos and then all other git repos. This appears to add an extra layer of syncing and merging, because surely Boost admin has the power to modify any of the high gc set of repos. I'm not saying that this choice isn't for very good reasons. It's just that from my experience a submodule heavy git repo with lots of tightly coupled submodules becomes a royal PITA for end users because you get all sorts of weird obtuse breakages for apparently no reason at the time. Maybe of course it's just me, and I have some mental block others don't have. And I absolutely agree that other projects such as KDE have adopted your approach and it seems to work for them. However Boost is not KDE. In my mental model of the world, Boost more resembles the Linux kernel in terms of interdependencies and size. KDE has a vastly more stable intra-module ABI and much more loosely coupled submodules. This interpretation may be a mistake of mine. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

2 1

Re: [boost] The file boost/detail/endian.hpp needs to be set up for your CPU type
by Niall Douglas 09 May '13

09 May '13

> > How does one write a proposal to the C++ committee? > > http://isocpp.org/std/submit-a-proposal > > > I'll do it. This is a > > problem that probably comes up a lot, people then figure out some > > clumsy workaround and then forget about it. These workarounds are > > just that, and they impact the bottom line as programmers try and > > figure out some way of figuring them out. > > > > This should be standard. No workaround required. > > Jonathan hit the nail on the head.The C++ standard is essentially an open source > software project staffed entirely by volunteers. There is no such thing as > something that "should be standard" - there are only things that someone has > written a proposal for, and then gone to the trouble of shepherding through the > standardization process. Also, allocate a minimum of at least one year to achieve a successful shepherding, and that's for an obvious, uncontroversial change. ISO standards has large barriers to entry and for good reason: only those with stamina and the ability to repeatedly rewrite proposals to correctly include feedback will succeed. I'm not saying don't do it, because if there's a problem it should be fixed. I am saying that most of the work in writing a proposal isn't in writing and submitting one as that part is straighforward, it's in the shepherding part as Beman points out. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0

The file boost/detail/endian.hpp needs to be set up for your CPU type
by Adrian_H 09 May '13

09 May '13

I saw this error and was wondering, can the endianness of a compiler not be determined through templates instead of using <endian.h>? Using macros seems to be pretty old-school and if headers are not updated could be just flat out wrong. -- View this message in context: http://boost.2283326.n4.nabble.com/boost-The-file-boost-detail-endian-hpp-n… Sent from the Boost - Dev mailing list archive at Nabble.com.

7 14

Re: [boost] [gsoc-2013] Boost.Thread/ThreadPool project
by Niall Douglas 09 May '13

09 May '13

> IIUC, the question is related to Qt's API for integrating with Qt's event > dispatcher, which (IIUC again:p) is used by QApplication, QCoreApplication and > QThread. > > Apologies if I'm off target here. Correct. I think the gold standard is a thread pool implementation which seamlessly allows Boost.ASIO to be combined with Qt's event dispatcher all in the single implementation. In other words, the thread pool can cope with multiple simultaneous event dispatcher implementations. Niall --- Opinions expressed here are my own and do not necessarily represent those of BlackBerry Inc.

1 0

[log] Is it lock free ?
by adrien courdavault 09 May '13

09 May '13

Hi I'm really interested by the new Log library. I would like to know if there is a part of this API that could be wait free, not the << operator perhaps, but a specific function to log a message without having to worry about a malloc or lock called inside the library. I would like to use this from a time critical thread. thank you

3 5

[predef] Status and review results?
by Rene Rivera 09 May '13

09 May '13

Just a quick message to mention that I've finished all the review related changes to the Predef library. And done some of the future tasks on the library. In particular the addition of endianness definitions and the moving of MinGW as a platform instead of a compiler (and hence the addition of BOOST_PLAT category of macros. And the one question I have is.. When will the review results of the library be decided on? I ask for two reasons. One, the obvious, is just to know if it's accepted or not. And to know if it's not accepted and hence that I should spend time to recreate a "boost/detail/endian.hpp" header that implements the Predef logic for endian detection. Note the project move to Github earlier this year (in preparation for the Boost git move). You can find the project at < https://github.com/grafikrobot/boost-predef>, and browse the current documentation at <http://tinyurl.com/cqqhhev>. -- -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim - grafikrobot/yahoo

8 31

[chrono/date] Two axes for a date design: validity check and representation and an essence date class/factory
by Vicente J. Botet Escriba 09 May '13

09 May '13

Hi, I would like to discuss about some alternatives to take in account the following use case "Reset a date if it resulting date is valid and report if this succeeds" when we have two axes of variation on the date design. Let me add two parameters to the possible date class. * validity: unchecked/checked * representation: serial, ymd(calendar), iso_ordinal, iso_week... date<serial, unchecked> is an unchecked serial date. It corresponds +/- to the N3344 date suggestion. date<ymd, checked> is a checked ymd date. It corresponds +/- to the H.H 2011 date proposal. WARNING !!! I'm not saying that a template class is a good thing, it is just to state clearly the features of the date. N3344 suggest a date::set_if_valid_date function. date<serial, unchecked> ud=...; if (ud.set_if_valid_date(y,m,d)) { // xx } else { // yy } But if we want to do as for the date constructors we will need multiple overloads again for this function :(. As show on this ML serial+unchecked dates validation could have some surprises. We can get the same service building a ymd date that can provide a way to be validated. //------------- // Validity check done when is_valid() is called on ymd_date. date<serial, unchecked> dd=...; date<ymd, unchecked> yd(y,m,d); if (yd.is_valid()) { // CHECK dd = yd; // xx } else { // yy } Instead of using explicitly date<ymd,unchecked> we can use a make_essence() factory that returns some kind of tuple essence_date<year,month,day> that is not a date, but its essence. It contains everything needed to build a date. This essence should be implicitly convertible to any date. The make_essence_date() factory supports all the different orders of parameters. The operator/() expression would also create an essence date. // -------------- //No validity check is done. date<serial, unchecked> ud = make_essence(y,m,d); date<serial, unchecked> ud1 = m/d/y; This essence dates support date validity, that is provides a is_valid() function. // -------------- // Validity check done when is_valid() is called on essence. date<serial, unchecked> ud; auto d = y/m/d; if (d.is_valid()) { // CHECK ud = d; // xx } else { // yy } //-------------- // Validity check done at construction of cd. serial_date<checked> cd = make_essence(m,d,y); //serial_date<checked> cd = m/d/y; Summary: IMO Having checked and unchecked dates with several representations could help to make dates interface more precise and concise. Checked dates are always valid. Dates with a specific representations would provide only, as suggested by Howard, only the functions that are efficient. The use of essence dates factories simplify the interface of all the date classes construction. Only 1 constructor by representation needed independent of the parameters order date(essence<ymd> &&); date(essence<serial> &&); date(essence<iso_ordinal> &&); date(essence<iso_week> &&); Comments welcome, Vicente P.S.The essence date classes and the contextual dates are quite related. I prefer to let this 3rd contextual axe of variation out of the current scope. I will try to integrate it soon.

2 3