April 2013 - Boost - lists.preview.boost.org

[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

[trac] Add component for Boost.Log
by Andrey Semashev 09 May '13

09 May '13

Hi, Not sure whom to ask, but could someone create a component "log" for Boost.Log in Trac? I (andysem) am the maintainer. Thanks.

2 2

[gsoc 2013] draft proposal for chrono::date
by Anurag Kalia 07 May '13

07 May '13

Hi, I mistakenly sent this draft as a reply to personal email of Vicente. I am sorry! Here it is again, verbatim. One related question though. I still haven't got the hang of a Mailing List. Is there a software takes the pain away from it. For example, I use outlook.com and '>' get appended in front of only the start of paragraph making it wholly unreadable. Thanks, Anurag Kalia. ---------------------------------------- > Date: Sat, 27 Apr 2013 18:14:09 +0200 > From: vicente.botet(a)wanadoo.fr > CC: anurag.kalia(a)outlook.com > Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date > > Le 27/04/13 16:58, Anurag Kalia a écrit : > >> I understand that you want to design your own library, I did the same, > >> but getting a coherent design would take you some time. > >> I suggest you to start with the H. Hinnant proposal as a reference and > >> state what you want to added, changed or removes. State clearly why do > >> you want these changes, what would be improved/solved. > >> > >> Don't forget to inspect the threads/discussion related to the H.Hinnant > >> proposal, and the paper N3344 Toward a Standard C++ 'Date' Class > >> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3344.pdf > > Hi Vicente, > > > > Thanks a lot for the exhaustive reply! I will get back to you after going through all the things you pointed out and also the paper you forwarded. But I have one quick question for now, from where can I start my search for the threads and discussions around this date proposal? > > > > > > > Hi, > > There were some interesting exchanges in > https://groups.google.com/forum/?fromgroups=#!forum/kona-date-lib > > I guess that if you request to the administrator s/he will be able to > give you read access to the existing threads (there are not too much). > > Best, > Vicente > I have finally implemented some representative functions in date class and calendar to get a better idea of the proposal. I have dropped the JDN storage for another implementation that I thought of in the middle of the night. I think it is a hybrid approach between serial and field-based implementations. Off the top of my head, without any alternative implementations at hand and benchmarks too, I can't think of something inherently wrong in it. I would really like to hear its gotchas, if any. I have overhauled my proposal on the basis of it. It doesn't contain other headings like about me etc for today. I have tried to incorporate all the previous points you noted before and have also tried to keep naming consistent. I did use uppercase constants in there but they are meant to be private. Is that okay? I knew little about the benchmarks before you sent me that paper. From what I got, they just iterate over a significant period of time and note the start and ending time. Is it more than that? And should I make them before or after I have multiple implementations in hand. I could get hold of your and Howard Hinnant's implementations for them, but then the APIs would have to line up, wouldn't they? Hope you find my proposal better this time around. With an open ear, Anurag Kalia.

9 95

[config/multiprecision/units/general] Do we have a policy for user-defined-literals?
by John Maddock 06 May '13

06 May '13

Folks, I've been experimenting with the new C++11 feature "user-defined-literals", and they're pretty impressive ;-) So far I've been able to write code such as: auto i = 0x1234567890abcdef1234567890abcdef_cppi; and generate value i as a signed 128-bit integer. It's particulary remarkable because: * It actually works ;-) * The value is generated as a constexpr - all evaluation and initialization of the multiprecision integer is done at compile time. * The actual meta-code is remarkably short and concise once you've figured out how on earth to get started! Note however my code is limited to hexadecimal constants, because it can't do compile time radix conversion - that would require a huge meta-program for each constant :-( This is obviously useful to the multiprecision library, and I'm sure for Units as well, but that leaves a couple of questions: 1) We have no config macro for this new feature (I've only tested with GCC, and suspect Clang is the only other compiler with support at present). What should it be called? Would everyone be happy with BOOST_NO_CXX11_USER_DEFINED_LITERALS ? 2) How should libraries handle these user defined suffixes? The essencial problem is that they have to be in current scope at point of use, you can never explicitly qualify them. So I suggest we use: namespace boost{ namespace mylib{ namespace literals{ mytype operator "" _mysuffix(args...); }}} Then users can import the whole namespace easily into current scope right at point of use: int main() { using namespace boost::mylib::literals; boost::mylib::mytype t = 1234_mysuffix; } 3) How should the suffixes be named? There is an obvious possibility for clashes here - for example the units lib would probably want to use _s for seconds, but no doubt other users might use it for strings and such like. We could insist that all such names added to a boost lib are suitably mangled, so "_bu_s" for boost.units.seconds, but I'm not convinced by that. Seems to make the feature much less useful? Many thanks in advance for your thoughts, John.

6 12

[operators] The Dangling Reference Polarization
by Daniel Frey 05 May '13

05 May '13

I see some good discussion going on, thanks to everyone participating! Rest assured that I value both side's contributions, it is important for me (and those agreeing with my perspective) to be able to defend this position and also to keep looking for improvements. If our side can not be defended, it's probably not good enough :) That said, here's what I hope can serve as a first summary, let's first look at it from a technical perspective: If an operator returns an rvalue reference (T&&), it is safe for all use-cases except binding the result to an rvalue- or const-lvalue-reference: T r = a + b + c; // no problem const T r = a + b + c; // no problem T& r = a + b + c; // compile-time error const T& r = a + b + c; // problem (P1) T&& r = a + b + c; // problem (P2) It seems that this is consistent behavior across at least GCC, Clang and VC++. If a compiler shows a different behavior, its likely a compiler-bug. Technically, there is no doubt that the above is a bug, but that doesn't answer the question of whether this is a bug of the user who wrote the above code or if it's a bug of the operator to return an rvalue reference instead of an rvalue. This is where we leave the technical-aspects-land and enter the minefield of opinions, expectations and decisions. I am of the opinion that the above problematic use-cases are a bug on the users side, my line-of-thoughts and my arguments are: a) The above code is explicit, you can spot it in the users code. It's not something that happens silently. b) The above code always looked suspicious to me anyways, it has a code-smell that I just don't like. c) It rely's on the fact that it extends the lifetime of a returned temporary value. The rules of the C++ standard that allow this are quite clear, and hence it's the users responsibility to make sure that there actually is a temporary value whose lifetime can be extended. It has always been an error if the expression returned a reference and not a value. Consider const std::string& oops = std::vector<std::string>(1, "hello, world" ).front(); This compiles are creates a dangling reference, as the standard says that front() returns a reference and not a value. It's not 100% comparable as in this case the standard guarantees a bug, but the main point for C++ has always been which guarantees are given and not about a certain expectation one might have. As an example: static_assert( std::is_empty< std::tuple<> >::value, "Expectation 1 broken" ); static_assert( std::is_empty< std::array< T, 0 > >::value, "Expectation 2 broken" ); // with any valid T The first case is certainly a reasonable expectation and it currently works for all implementations of std::tuple that I know of, but it is not guaranteed! If your code relies on it and it breaks in the future, you can not blame the person who modified std::tuple. The second case is also a reasonable expectation, but it breaks everywhere and AFAIK there is no standard-conforming way to implement std::array so that std::array<T,0> is empty. For the curious, here's the StackOverflow question I asked about it: <http://stackoverflow.com/q/15512827/2073257>. Another example about how to properly handle expectations vs. guarantees: <http://stackoverflow.com/q/14882588/2073257>. d) I fail to see any valid use-case for binding the result of the expression to a reference. Can someone please provide a convincing example of why (P1) or (P2) are needed/useful? Keep in mind that in the context of operator+ (or any other operator in question), we already require that the type T is copy-/moveable and that copy-elision most likely takes place if you use "T r = …" instead of "const T& r = …". e) The alternative needs to prove its claimed/theoretical efficiency in practice. Too often I have heard about "sufficiently smart compilers", but I'm more the prove-it-in-the-real-world type. So summarizing it once again: For a) and b), this is just an observation and my personal opinion. c) means it's important to talk about guarantees, not just about expectations (no matter how reasonable they are). d) poses the question if we loose something if we don't guarantee that (P1) and (P2) are allowed. I currently have several ideas/option of how we could improve Boost.Operators, some of which I already mentioned, some which only recently occurred to me. Before I will discuss these, I'd like to resolve (if possible) the Dangling Reference Polarization and gather more opinions/feedback. So far, I found the discussion both challenging and very helpful, again thanks to everyone participating! Best regards, Daniel

5 13

[gsoc] Boost.Multiprecision Proposal
by Saurav 04 May '13

04 May '13

Hi, I have attached my proposal for the Boost.Multiprecision project. It has been provided in PDF format for better readability. Please have a look and give your feedback. Best regards, Saurav

3 4

Live read-only GIT mirrors of Boost trunk SVN
by Niall Douglas 04 May '13

04 May '13

The live GIT mirrors of Boost trunk SVN have become a bit stale in recent months: https://github.com/ryppl/boost-svn, long time favourite of many, now 4 months stale. https://github.com/Beman/boost-trunk-git-svn is now 2 months stale. https://github.com/alexanderkjeldaas/boost-mirror is fresh, but has no branches nor tags. They all generally use git-svn, which tends to be brittle and not translate commits perfectly unfortunately e.g. SVN eol properties and other such metadata. So I decided to try out a new Subversion <=> Git mirroring tool, SubGit v2.0 EAP (http://subgit.com/eap/) whose author very kindly gave me a free open source licence and the result is at: https://github.com/ned14/boost-trunk All branches and tags, as far as I can tell, are mirrored correctly. I've set a cron job every 24 hours. Theoretically if we had an authors mapping file it would work in the opposite direction too i.e. be read-write. My next task is to live mirror a github repo into Boost Sandbox. Currently SubGit segfaults on this due to the complex SVN properties auto-translation which requires a specially marked up .gitattributes, but the author is very keen to fix the problem. In theory then it ought to just work. Any mistakes in my Boost mirror, or any problems, or even thoughts are gratefully received. Niall

4 6

Specific-Width Floating-Point Typedefs
by Paul A. Bristow 04 May '13

04 May '13

There has recently been some discussion on improving portability of programs using floating-point. Drawing on the benefits from definition of typedefs for int32_t, int64_t, int128_t . we have drawn up a proposal to add similar typedefs for floating-point. Our draft document (in both html and pdf) is at https://svn.boost.org/svn/boost/sandbox/precision/libs/precision/doc/html/i… https://svn.boost.org/svn/boost/sandbox/precision/libs/precision/doc/precis… We hope to propose this to the SG6 Numerics subgroup of WG21 ISO C++ standards body. But would welcome comments from Boosters to help us improve this proposal. Thank you. Paul --- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow(a)hetp.u-net.com

8 17

GSoC 2013 Bernoulli Numbers
by David Joy 03 May '13

03 May '13

Hi, I'm an Open University student completing my Open degree this summer (CompSci / Pure- & Applied Maths / Classical History) and am very interested in the Bernoulli numbers project for the Google Summer of Code. As well as the OU I've done quite a bit of mathematics elsewhere (Durham and KCL). Enclosed is my (naive) response to your challenge to implement the Akiyama–Tanigawa algorithm. I use the Boost framework for rational numbers, so as not to lose precision (though haven't yet adapted the solution for arbitrary precision numbers). [It would be more aesthetically pleasing if I could write the main algorithm in a STL-style so that it iterates of the vector, rather than explicitly using an index.] I have yet to get to grips with Boost.Test, but the enclosed shell script can generate a list of results, which matches the table found on the Bernoulli Number Page <http://www.bernoulli.org/> out to B_20. All code criticism gratefully accepted, David Bernoulli.cpp <http://boost.2283326.n4.nabble.com/file/n4646219/Bernoulli.cpp> Bernoulli_test.sh <http://boost.2283326.n4.nabble.com/file/n4646219/Bernoulli_test.sh> -- View this message in context: http://boost.2283326.n4.nabble.com/GSoC-2013-Bernoulli-Numbers-tp4646219.ht… Sent from the Boost - Dev mailing list archive at Nabble.com.

2 4