- Boost - lists.boost.org

boost::chrono problem with gcc-4.6.3
by Neo Apostol 27 Nov '12

27 Nov '12

Hello everyone. I use android-ndk (http://www.crystax.net/en/android/ndk/7) with boost-1.49. My code includes boost::chrono, and when I use gcc-4.4.3 everything goes fine, but when I swith on the gcc-4.6.3 (APP_USE_CPP0X := true) so than i get a strange mistake. C/C++ Problem 'u16string' in namespace 'std' does not name a type TestCore line 243, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u16string' in namespace 'std' does not name a type TestCore line 242, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u32string' in namespace 'std' does not name a type TestCore line 250, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u32string' in namespace 'std' does not name a type TestCore line 249, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u16string' in namespace 'std' does not name a type TestCore line 287, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u16string' in namespace 'std' does not name a type TestCore line 286, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u32string' in namespace 'std' does not name a type TestCore line 294, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u32string' in namespace 'std' does not name a type TestCore line 293, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u16string' in namespace 'std' does not name a type TestCore line 331, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u16string' in namespace 'std' does not name a type TestCore line 330, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u32string' in namespace 'std' does not name a type TestCore line 338, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u32string' in namespace 'std' does not name a type TestCore line 337, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u16string' in namespace 'std' does not name a type TestCore line 375, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u16string' in namespace 'std' does not name a type TestCore line 374, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp ............................................... Does somebody can help me?

2 2

[range] iterator_range operators are too greedy
by Gennadiy Rozental 27 Nov '12

27 Nov '12

Hi, iterator_range operators are defined like this: template< class IteratorT, class ForwardRange > inline bool operator==( const ForwardRange& l, const iterator_range<IteratorT>& r ) { return boost::equal( l, r ); } These needs to be restricted with enable_if on type of first argument. I have a scenario where I want to define operator== for my own type and want to be able to use it with iterator_range as second argument. Above definition makes it impossible. Gennadiy

6 12

[boost::context] reusing stacks
by Valentin Milea 27 Nov '12

27 Nov '12

Hi, I'm working on a tiny coroutine library based on boost::context. For performance reasons I'd rather keep a pool of stacks instead allocating/deallocating every time. Is it legal to reuse a stack for a different context? namespace ctx = boost::context; ctx::fcontext_t fcm, *fc; void f1(intptr_t) { std::cout << "f1" << std::endl; ctx::jump_fcontext(fc, &fcm, 0); } void f2(intptr_t) { std::cout << "f2" << std::endl; ctx::jump_fcontext(fc, &fcm, 0); } int main(int argc, char * argv[]) { ctx::guarded_stack_allocator alloc; std::size_t size = ctx::guarded_stack_allocator::default_stacksize(); void *sp = alloc.allocate(size); fc = ctx::make_fcontext(sp, size, f1); std::cout << "main: jump 1" << std::endl; ctx::jump_fcontext(&fcm, fc, 0); fc = ctx::make_fcontext(sp, size, f2); // legal? std::cout << "main: jump 2" << std::endl; ctx::jump_fcontext(&fcm, fc, 0); std::cout << "main: done" << std::endl; return 0; }

2 6

[boost-mpl] -Wall -Werror issue
by Belcourt, Kenneth 27 Nov '12

27 Nov '12

Hi, This code generates sign / unsigned compare warning with -Wall, could this please be cleaned up? enum { n = # if defined(__EDG_VERSION__) aux::dependent_unsigned<T>::value > -1 # else sizeof(T) > -1 # endif }; It appears that sizeof(T) > -1 yields zero for EDG, Gcc and Clang so perhaps this is just older (unused) code? -- Noel Belcourt

2 4

[math] boost::math::isfinite fails with --fast-math
by Gaetano Mendola 26 Nov '12

26 Nov '12

Hi all, I'm wandering if this is to be expected, the following code fails if compiled with --fast-math: //==================================================== #include <boost/math/special_functions/fpclassify.hpp> int main() { const float a = 0.0f/0.0f; assert(not boost::math::isfinite(a)); } //==================================================== Regards Gaetano Mendola

6 13

gcc 4.4.3 + boost optional 1.40 crash
by Gaetano Mendola 26 Nov '12

26 Nov '12

Hi all, after banging my head for an entire day I come out with this test case showing a possible bug in gcc 4.4.3 or in boost optional, the test crashes with a pure virtual method called only if compiled only with -O1, -O2, -O3. The same code in another machine with gcc 4.7.2 and boost 1.49 works fine. Regards Gaetano Mendola #include <boost/optional.hpp> #include <boost/noncopyable.hpp> class B : boost::noncopyable { //if the noncopyable is removed works public: virtual size_t bar() const = 0; }; class D : public B { public: D() :theBar(foo(10)) { } virtual size_t bar() const { return theBar; } private: static size_t foo(const boost::optional<size_t> a) { if (a) { //if this is a.is_initialized() then it works return a.get(); } return 2; } const size_t theBar; }; class Foo { public: Foo(const B& b) :theBar(b.bar() * b.bar()) { } private: const size_t theBar; }; int main() { { //if this section is removed works D d; try { Foo myCompound(d); } catch(...) {} } { D d; try { Foo myCompound(d); } catch(...) {} } }

6 15

[mpi] New dedicated mailing list for Boost.MPI discussions
by Matthias Troyer 25 Nov '12

25 Nov '12

Dear all, We have created a new sub list boost-mpi(a)lists.boost.org for discussion of Boost.MPI development. Those interested can visit http://lists.boost.org/mailman/listinfo.cgi/boost-mpi to sign up. Best regards Matthias

2 2

[Numeric Conversion] Documentation Notes/Questions
by Dave Abrahams 25 Nov '12

25 Nov '12

* First thing to note: the documentation makes this library less approachable than it could be. In order to even begin, one has to bury onesself in terminology (the "Definitions" section). A super-quick "hello, world" example and a very short tutorial at the beginning would help a *lot*. numeric_cast is arguably the most generally-useful interface of the whole library and yet it's not even discussed until the end of the docs. * It's not clear what the purpose of abt(x) is. In expressions, "x" usually means its value. When you introduce a mechanism like this, it would be a good idea to explain why it's needed. Most places, the use of "abstract" just seems to complicate things: "A ulp is a quantity whose abstract magnitude" what's wrong with "A ulp is a quantity whose magnitude" ?? The end of the section on "Range and Precision" begins to explain why you want "abstract," but it takes the reader a long time to get to it. * are next() and prev() always well-defined? Seems to me that an unlimited precision rational number type might not have them. Is that type not numeric? * How do size, width, and density relate to unlimited precision rationals? I imagine: size = infinity width = infinity density = ? * This is slightly ambiguous: "This definition allows for a concise definition of subranged as given in the last section." "final section" would be clearer. A link would help too. * This is unclear: "Abstract intervals are easier to compare and overlap since only boundary values need to be considered." an example would help. How can one kind of thing be "easier to overlap" than another? * Precision has a very non-generic description, being different for types with density 1 and other types. It's hard to see what use such a concept has, and as far as Google can tell it is not used anywhere outside the Definitions section * Description of unsigned types, I think, is wrong: Notice that a numeric type, such as a C++ unsigned type, can define that any V does not overflow by always representing not V itself but the abstract value U = [ V % (abt(h)+1) ], which is always in range. Seems to me that the abstract values represented by an unsigned integer type are not the set of whole numbers, but the set of whole numbers modulo whatever-the-max+1-is. That's a well-defined mathematical abstraction, isn't it? Is there a problem with that, such as multiplication not working properly (I don't think so)? * There seems to be a contradiction here: If V >= abt(l) and V <= abt(h), V is representable (can be represented) in the type T ... Given an abstract value V represented in the type T as v, the roundoff error of the representation is the abstract difference: ( abt(v)-V). If V is not representable in type T, can you write formulae using its representation in type T? Given what I read later, maybe you should have just said "exactly representable" in the first phrase. * s/at most/less than/?: Because a correctly rounded representation is always one of adjacents of the abstract value being represented, the roundoff is guaranteed to be at most 1ulp. * s/cannot be represented/cannot be exactly represented/ ?: The integer number -1 can be exactly represented in Int, Real and Whole, but cannot be represented in Cardinal, yielding negative overflow. * Uh-oh: Floating to Floating conversions are defined only if N is representable; if it is not, the conversion has undefined behavior. in many places you've used "representable" to mean "exactly representable," but I can't believe you mean that here; it would imply most double=>float conversions have undefined behavior. What does this mean, anyway? If an abstract value can be "inexactly representable," aren't all abstract values representable if there's at least one abstract value that's exactly representable? Just convert to that and you're done. I think you need to give some serious thought to the definition of "representable." * s/then/so/: R(X) & R(Y) == R(X), then X->Y is not subranged. Thus, all values of type X are representable in the type Y. (b) Y->X: R(Y) & R(X) == R(Y), then Y->X is not subranged. Thus, all * What's the difference between a policy and a "parameter that defines the conversion" in It can optionally take some policies which can be used to customize its behavior. The Traits parameter is not a policy but the parameter that defines the conversion. ?? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

4 4

[Review] Review results for Coroutines
by Hartmut Kaiser 24 Nov '12

24 Nov '12

All, The review for the Coroutines library written by Oliver Kowalke started September 3rd 2012, and ended on September 12th 2012. I counted 7 votes, none of which were NO. All authors votes YES, some made additional requests. Overall, the verdict of the community was clear: Oliver Kowalke's Coroutines library is ACCEPTED The discussion was lively and it touched on several points. Design ------ The Coroutines library offers enormous potential for programming regimes such as communications software and embedded systems design. Oliver selected a sensible granularity for his design. This granularity allows for fine-tuning the implementations of cooperative scheduling mechanisms while avoiding the prohibitively heavy weight of preemptive scheduling that is found in POSIX and often in implementations of the C++11 thread support library. In particular, the separation of Coroutines from Context allows for porting to other systems with minimal effort and maximum reliability and code re-use. Some suggestion related to the API have been made during the review, most of which (if not all) have already been addressed. Oliver has a full list of things and works on integrating the suggestions. Here is a short list: - allow to specify the allocator to use for memory allocations inside the library - remove 'self' pointer and replace with TLS - add symmetric coroutines API - better support for generator functionality Naming ------ Some of the people participating in the discussions suggested not to use the abbreviated 'namespace coro', but to use the full 'namespace coroutines' instead. This again is not a precondition for acceptance. Documentation ------------- The consensus of almost everybody referring to the documentation was that it is terse but readable and sufficient. People suggested to integrate the docs of the old Coroutines library (written as an GSoC project by Giovanni P. Deretta) into the documentation of the reviewed library. I would like to thank all who participated in the discussions. Regards Hartmut --------------- http://www.cct.lsu.edu/~hkaiser http://stellar.cct.lsu.edu http://boost-spirit.com

1 0

Re: [boost] Countertree
by Leo Goodstadt 23 Nov '12

23 Nov '12

> On Tue, 20 Nov 2012, Vadim Stadnik <vadimstdk(a)gmail.com> wrote: > > On Mon, Nov 19, 2012 at 9:02 PM, Leo Goodstadt <leo.goodstadt(a)llew.org.uk>wrote: > > 1) For counter trees, the median is just the N/2-th value in the > > counter tree, where K is the size of the tree. > > The Nth-percentile can be calculated similarly. > > A rolling median with a fixed size window requires there to be an > > insertion and deletion for each (most!) new value, so I am guessing > > it should run in O(N log K) time, where N = size of data, K = size of > > window > > > > IIUC, it is better to avoid modifying original data (size N), the rolling > window of size K can be represented by a multiset based on an augmented > tree. This method guarantees complexity of obtaining 1st median value for > O(K log K) operations, which is the cost of construction of the rolling > window, every subsequent median value can be obtained for O(log K) > operations, when the window rolls. This approach should be more efficient. > Oops. Careless editing made me mix up my Ks and Ns, hopeless confusing everyone. So given a large data set of size N and we want to calculate medians across a rolling window of size K, we only need to create a counter tree of size K (the window size). The median is the K/2 value in the tree. As you point out, the entire operation runs in O(N log K) time. All sensible approaches to calculating medians I can think of take O(N log K) time. The question comes down to what the constants are. The great advantage of a counter tree is that we are not limited to medians (the 50%ile value). We can collect for example, the values at 25%, 50%, and, 75%, and so on, at only marginally extra cost. I presume that most of the cost lies in balancing the tree after insertions/deletions and updating the counters. The only shortcut is the trivial optimisation that if the value entering the window is the same as the one being removed at the other end, then the median obviously stays the same. Leo

3 4