- Boost - lists.boost.org

[chrono] patches for Windows CE support
by David Deakins 24 Feb '11

24 Feb '11

Hi Vincente, I went ahead and committed the fixes for VC9 and closed the ticket. Now on to the next item... =) Attached is a collection of patches that allow Boost.Chrono to build correctly for Windows CE / Windows Mobile. Mostly they relate to WinCE lacking functions such as GetSystemTimeAsFileTime or GetProcessTimes. Take a look at the changes and let me know if they seem ok to commit. I opened Trac ticket 5218 for this item. Thanks, -Dave

2 1

[chrono] patch for VC9 duration conversions
by David Deakins 23 Feb '11

23 Feb '11

Currently the enable_if expressions that restrict implicit duration type conversion to only conversions that will not reduce resolution are disabled on VC9 because they trigger a compiler error. I have come up with a slight adjustment to the expression that VC9 appears to be able to digest more favorably. Attached is a patch. I also opened ticket 5214 in Trac with this information. Vincent, if the patch looks good, let me know if you want to apply it or if you would like me to. -Dave

2 3

Inter-domain interaction - Question and bug ?
by Joel Falcou 23 Feb '11

23 Feb '11

Hi, while adding function to my SIMD library built on proto. I stumbled into this problem: http://codepad.org/dd5WB8Xu I have a template grammar/generator/domain that helps me not mixing vector of different type/cardinal. However some functions are designed to take vector of float and turn them into vector of int. I wrote one there (exponenbits) by just forcing the domain to be the one from int. When I call it alone, it works. But if I do exponentbits( some_float ) + some_int doesnt work. The error is just : /Users/joelfalcou/nt2/sandbox/proto.cpp:161:46: error: no match for 'operator+' in 'nt2::simd::exponentbits(((const nt2::simd::pack<float, 4ul>&)((const nt2::simd::pack<float, 4ul>*)(& x)))) + y' With none of the usual 'no proto_grammar in not_a_domain' error I got when I mix element of different grammar with each other. Now, if i turn the grammar into: //////////////////////////////////////////////////////////////////////////////// // the template grammar //////////////////////////////////////////////////////////////////////////////// template<class T, class C> struct grammar : boost::proto ::or_ < boost::proto::terminal< data<T,C> > , boost::proto::unary_expr<exponentbits_, grammar<boost::proto::_,C> > , boost::proto:: and_< boost::proto:: nary_expr < boost::proto::_ , boost::proto::vararg< grammar<T,C> > > , boost::proto:: not_< boost::proto::or_ < boost::proto:: address_of< grammar<T,C> > , boost::proto:: dereference< grammar<T,C> > , boost::proto:: comma < grammar<T,C> , grammar<T,C> > > > > > {}; It works. Alas, I have a potentially high and extensible set of such function (some being binary or ternary or w/e) and so I want some way to accept such constructs without an explicit list of supported function. nt2 currently has something like 17 such cross domain function. My question is why building such an expression: - make an error. Once I wrapped a terminal of domain Foo in domain Bar, it should be composable with other element of Bar domain - if this is an error, why dont I get the usual error of mixing wrong element with each other ? Mixing element from unrelated domain through such domain wrapping is a very valauble techniaues in EDSL in my opinion as it allows efficient operations to be done. nt2 has a vector and covector class in different domain and transposing a vector yields a covector, and vice versa. Being able to just have somehting that wraps the vector terminal and change its semantic this way is very valuable. Thansk for any pointers or discussion on this.

1 0

Small contribution to algorithm library: clamp function
by Тимофей Игнатьич 23 Feb '11

23 Feb '11

I wasn't able to find a clamp function in boost so i submitted my version for discussion and refinement here: http://www.boostpro.com/vault/index.php?&direction=0&order=&directory=Algor… (file clamp.hpp) Summary: clamp(a, x, b) Effect: if (x < a) returns a, otherwise if (b < x) returns b, otherwise returns x. clamp(a, x, b, comp) clamp<comp>(a, x, b) Effect: if comp(x, a) returns a, otherwise if comp(b, x) returns b, otherwise returns x. Let me know what you think. Maybe i was wrong and such function does already exist within boost?

3 2

[config] C++0X Compiler doesn't support classes with constructors in unions
by Vicente Botet 23 Feb '11

23 Feb '11

Hi, is there a macro that can be tested to know if a compiler doesn't support classes with constructors in unions? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/config-C-0X-Compiler-doesn-t-support-cla… Sent from the Boost - Dev mailing list archive at Nabble.com.

4 5

[1.46.0][fusion] fusion compare is broken
by MURAKAMI Genya 23 Feb '11

23 Feb '11

I try compiled use Boost.Fusion, but compilation error by include, in VC7.1 and VC8. #include <boost/fusion/sequence/comparison/less_equal.hpp> // error! int main() {} This problem was fixed by rev.68358, but unfortunately was not in 1.46.0 release branch. Therefore, I think that the Boost.Fusion user using a VC7.1 or VC8 cannot introduce 1.46.0.

4 3

[interprocess] sharing memory between 32 bit and 64 bit Windows processes
by Arno Schödl 23 Feb '11

23 Feb '11

Hello Ion, I also need this functionality badly. Is there any chance of you implementing it? Basically, using unsigned int instead of size_t and int instead of ptrdiff_t, so the binary layout of shared memory is always like in 32 bit, would in practice do the trick. If we implement it ourselves, would you support getting this into boost? I cannot promise complete support. I already saw that rbtree_best_fit has a problem because the ring list containing the memory blocks needs to wrap around from the last block to the first. Would porting Doug Lea's allocator be an option? It will be hard to beat something that has been so thoroughly used and improved. Cheers, Arno -- Dr. Arno Schödl | aschoedl(a)think-cell.com Technical Director think-cell Software GmbH | Chausseestr. 8/E | 10115 Berlin | Germany http://www.think-cell.com | phone +49 30 666473-10 | US phone +1 800 891 8091 Amtsgericht Berlin-Charlottenburg, HRB 85229 | European Union VAT Id DE813474306 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl

2 7

Subject: Formal Review of Proposed Boost.Process library starts tomorrow
by Marshall Clow 23 Feb '11

23 Feb '11

It's my pleasure to announce that the review of Boris Schäling's Process library starts tomorrow, February 7th and lasts until February 20, 2011, unless an extension occurs. What is it? =========== Boost.Process is a library to manage system processes. It can be used to: • create child processes • run shell commands • setup environment variables for child processes • setup standard streams for child processes (and other streams on POSIX platforms) • communicate with child processes through standard streams (synchronously or asynchronously) • wait for processes to exit (synchronously or asynchronously) • terminate processes Getting the library =================== The library is available at: http://www.highscore.de/boost/gsoc2010/process.zip with documentation at: http://www.highscore.de/boost/gsoc2010/ There was a quite involved "informal review" on the mailing list this past summer. That thread is archived here: http://thread.gmane.org/gmane.comp.lib.boost.devel/207594 Writing a review ================ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager (me!) Here are some questions you might want to answer in your review: - 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 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. -- Marshall Review Manager for the proposed Boost.Process library

17 63

[1.46] [iostreams] Okay to merge changeset 68779
by Steven Watanabe 22 Feb '11

22 Feb '11

AMDG This fixes a regression in filtering_ostream::flush. It should be safe, as it simply restores the original behavior. I've checked the trunk regression tests and didn't see any issues from this. In Christ, Steven Watanabe

3 2

Re: [boost] [Boost-users] [boost-users][ICL] ICL Compilation errors. Ticket #5207
by Joachim Faulhaber 22 Feb '11

22 Feb '11

2011/2/22 John Reid <j.reid(a)mail.cryst.bbk.ac.uk> > > I have started to use statically bounded intervals > and am finding more compilation issues. For example > with finding elements in a map: > > #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS > #include <boost/icl/interval_map.hpp> > > void f() { > namespace icl = ::boost::icl; > icl::interval_map< float, int >().find( 0 ); > } > > This compiles without the #define but fails on static intervals. This is on purpose. The reason is that we can not represent a single element x using a right-open interval [x,?) of continuous values. right_open_interval is the default for statically bounded intervals, if BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS is defined. In order to use find on an interval_map we have to construct an interval that represents a single element (internally). This is not possible in the logic of the ICL so this code won't compile. interval_map::find is a pretty late addition to ITL/ICL, because using find in the STL way makes little sense on interval containers most of the time. We can not "find" an large interval in an icl::interval_set of small intervals. {[0,2),[5,7)}.find([0,9)) The generalization of find is intersection. And the following function calls compile for statically bounded right-open intervals of continuous types: #define BOOST_ICL_USE_STATIC_BOUNDED_INTERVALS #include <boost/icl/interval_map.hpp> { icl::interval_map< float, int> iclmap; icl::interval_map< float, int> found; add_intersection(found, iclmap, right_open_interval<float>(0,1)); add_intersection(found, icl::interval_map< float, int>(), right_open_interval<float>(0,1)); found = iclmap & right_open_interval<float>(0,1); found = icl::interval_map< float, int>() & right_open_interval<float>(0,1); } > This makes me think it might be worth having tests for > every possible combination that is listed in the function > synopsis for both static and for dynamic intervals: > http://www.boost.org/doc/libs/1_46_0/libs/icl/doc/html/boost_icl/interface/… I am working on it. But as you see from this example, not every function overload works for dynamically bounded and statically bounded intervals in the same way. I think the documentation can be improved here. > I can keep you up-to-date with any further problems I find please do. > but I'm just wondering whether it would be easier to fix them all in one go. Currently it's no problem for me to fix them as they are detected. Cheers, Joachim -- Interval Container Library [Boost.Icl] http://www.joachim-faulhaber.de

1 0