- Boost - lists.boost.org

[math] potentian bug: iround throws, given double( numeric_limits<int>::min() )
by Krzysztof Czainski 24 Oct '11

24 Oct '11

Hello, The docs of the Rounding Functions say: If the argument v is either non-finite or else outside the range of the result type, then returns the result of rounding_error: by default this throws an instance of boost::math::rounding_error. So the example shown below seems to show a bug, since std::numeric_limits<int>::min() is *not* outside the range of int. Or did I miss something? <code> #include <boost/math/special_functions/round.hpp> #include <cassert> #include <limits> int main() { int const i = std::numeric_limits<int>::min(); double const x = i; assert( i == boost::math::iround(x) ); } </code> Regards Kris

3 16

[gil][io_new] Image Reading and Writing Iterator
by Christian Henning 24 Oct '11

24 Oct '11

Hi there, one of the requirements for the acceptance of io_new as the new io extension for gil is the ability to read and write images in more then one step. For that the current state of an operation has to be cached. I have created some meta functions that give access to io_new's reader and writer classes. Right now, it still is very preliminary. I would like to ask the community how I could create an read_iterator and write_iterator classes which users could use to iterate over very large images. I know there are some specific iterator libs in boost but I'm just clueless in how to use let alone be able to come up with an implementation that will be released by boost. Any help would be very welcome! Thanks, Christian

3 3

[1.48.0] Schedule heads up
by Beman Dawes 24 Oct '11

24 Oct '11

branches/release for 1.48.0 is long since closed for new libraries. October 10: branches/release closed for major code changes. Still open for serious problem fixes and docs changes. October 17: branches/release closed for all library changes except when specific permission given by release manager(s). October 24: Beta target date. Further betas and/or release candidates as feedback dictates. November 7: Release target date View Boost calendar: http://tinyurl.com/4xacpyj --Beman

11 45

[Review] Boost.Atomic review starts today, October 17th 2011
by Tim Blechmann 24 Oct '11

24 Oct '11

Hi all, The review of Helge Bahmann's Boost.Atomic library starts today, October 17th 2011. It will end on October 26th. I encourage everyone to participate the the discussion on the Boost mailing list about this very important library. In addition the code can be reviewed line-by-line in code collaborator (http://demo.smartbear.com/boost/) About Boost.Atomic: Boost.Atomic is a library that provides atomic data types and operations on these data types, as well as memory ordering constraints required for coordinating multiple threads through atomic variables. It implements the interface as defined by the C++11 standard, but makes this feature available for platforms lacking system/compiler support for this particular C++11 feature. Tarball: http://www.chaoticmind.net/~hcb/projects/boost.atomic/boost.atomic.tar.gz Documentation: http://www.chaoticmind.net/~hcb/projects/boost.atomic/doc/index.html Please always state in your review, whether you think the library should be accepted as a boost library! Additionally please consider giving feedback on the following general topics: - 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? On which platform? 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? Cheers, Tim Review Manager

6 11

Re: [boost] [property_tree] include directive for non-info files
by Ivan Le Lann 24 Oct '11

24 Oct '11

----- "Sebastian Redl" <sebastian.redl(a)getdesigned.at> a écrit : > On 29.09.2011 16:18, Ivan Le Lann wrote: > > Hi, > > > > In Boost.PropertyTree, INFO format has the nice #include directive. > > But it seems you cannot include other formats. > > Typically such INFO file, > > > > key > > { > > #include_xml "my.xml" > > } > > > > with "my.xml" :<root><child>kid</child></root> > > > > could give : get<std::string> ("key.root.child") == "kid" > > > > A very quick look at info parser makes me think that > > it would be easy to implement. Any comment ? > > > This is a strange request. What is your use case? > Thanks for your answer and sorry for the delay. Some part of my configuration are XML files given by third parties and, being particularly lazy, I did not want to write the few lines needed to handle the indirection. :-) > I'm rather disinclined to implement it, since it would create > cross-dependencies between the various parsers. > Yeah, I kind of exspected this answer. It probably makes sense. Regards, Ivan

1 0

[Review] Boost.Atomic review period extended
by Tim Blechmann 24 Oct '11

24 Oct '11

Hi all, Since there has been only rather limited discussion about the Boost.Atomic library and only one full review, the review period will be extended until next Sunday, October 30th. I encourage everyone with an interest in this library to participate in the remaining days of the review. If someone wants to do a review, but won't find the time during the review period, please let me know how much time you need. Cheers, Tim Review Manager

1 0

trouble with find() in property_tree
by Bernd Prager 23 Oct '11

23 Oct '11

Hi, I am experiencing trouble with the find() function in boost::property_tree. It doesn't seem to catch nested entries. Statement (1) below finds the child tree, but statement (2) prints unexpectedly "false". That was not what I was expecting. How do I find nested children? Thanks for any help. -- Bernd #include <iostream> #include <boost/property_tree/ptree.hpp> namespace pt = boost::property_tree; int main(void) { pt::ptree props; pt::ptree const empty; props.add("pi", 3.14159); props.put("name.first", "bernd"); std::cout << "find(none): " << (props.find("none") == props.not_found() ? "false" : "true") << std::endl; std::cout << "find(pi): " << (props.find("pi") == props.not_found() ? "false" : "true") << std::endl; std::cout << "find(name): " << (props.find("name") == props.not_found() ? "false" : "true") << std::endl; // (1) std::cout << "find(name.first): " << (props.find("name.first") == props.not_found() ? "false" : "true") << std::endl; // (2) return EXIT_SUCCESS; }

2 1

odeint feedback request
by Karsten Ahnert 23 Oct '11

23 Oct '11

Dear community, odeint is a library for solving ordinary differential equations and has been discussed several times on this list. After successfully fulfilling the GSOC 2011 we continued working on odeint and we published two papers which are available at the arxiv: http://arxiv.org/abs/1110.3397 http://arxiv.org/abs/1110.3233 We would like to request feedback and/or comments on the implementation and the current status of odeint. The library and the documentation are available at the github: https://github.com/headmyshoulder/odeint-v2 http://headmyshoulder.github.com/odeint-v2/doc/index.html Thank you, Mario and Karsten

1 0

[atomic] Initial comments
by Grund, Holger 23 Oct '11

23 Oct '11

Hi everyone, It's been awfully quiet on the list regarding the atomic review. The atomic operations library is an invaluable tool for higher level concurrent data structures and algorithms. While toolchain vendors have already or starting to support <atomic>, many people are stuck on compiler where there is currently no support at all. Building these libraries yourself is tedious and prone to error and errors that are hard to spot. I am in this situation and therefore very much appreciate Helge's effort and think the lack of review comments so far should not be taken as a lack of interest. Now, I haven't had the time to look on things in any detail yet. I ignored the docs (~~) and only locked at the atomic header and some of x86 implementation so far. I haven't tried to build anything, but I intend to do a proper review though it's unlikely I'll manage to get to it on the official time line. I would have put some of the comments of the review tool site, but I can't login right now: - The fallback atomic_thread|signal_fence in boost/atomic.hpp seem to have external linkage, but no inline. Doesn't that give a ODR violation when included from more than on TU? - The copy-assignment operators seem to always return atomic&. IIRC, the earlier working drafts said return value_type. Has this changed? - The primary base_atomic is not aligned at all, AFAICT. I take it because you explicit need to extract bits anyhow and that means a memcpy. Does this have a performance impact? - Inline asm is the preferred way to build instructions. Did you consider intrinsics where available (e.g. ICC and GCC4+)? - atomic_flag is not statically initialized: I guess, there is some tradeoff with uniform-initialization syntax and member functions on most (all?) current production compilers. However, it seems to me that static initialization guarantees are atomic_flag's primary if not sole raison d'etre. Did you consider to make it a statically initializable type? - What's the point of the fences around cmpxchg in x86? - I'm not a GNU inline assembly expert and it's probably fairly unlikely to really affect codegen, but shouldn't clobbered flags be mentioned? Also the EBX handling for 32-bit Linux code may deserve some additional comment. I take it you can't mention ebx in the clobber list because the register allocator would complain for -fPIC, right? Does the impact unwinding? - I seem some of the *LOCK_FREE macros are defined involving sizeof. I've always assumed these macros (or the corresponding standard ones) would be suitable for use in #if processing. Wouldn't that be one of the main use cases? Thanks! -hg Holger Grund, Vice President Morgan Stanley | Cross-Technology Services 25 Cabot Square | Canary Wharf | Floor 03 London, E14 4QA Phone: +44 20 7677-4095 Holger.Grund(a)morganstanley.com -------------------------------------------------------------------------- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinions or views contained herein are not intended to be, and do not constitute, advice within the meaning of Section 975 of the Dodd-Frank Wall Street Reform and Consumer Protection Act. If you have received this communication in error, please destroy all electronic and paper copies and notify the sender immediately. Mistransmission is not intended to waive confidentiality or privilege. Morgan Stanley reserves the right, to the extent permitted under applicable law, to monitor electronic communications. This message is subject to terms available at the following link: http://www.morganstanley.com/disclaimers. If you cannot access these links, please notify us by reply message and we will send the contents to you. By messaging with Morgan Stanley you consent to the foregoing.

2 1

[boost threads] threadid copy constructor
by Jason Newton 21 Oct '11

21 Oct '11

The following patch adds a copy constructor to threadid. There seems to be no reason why they shouldn't be copyable. Comments? -Jason

2 2