September 2009 - Boost - lists.preview.boost.org

14 Sep '09

i'd like to present some kind of micro optimization towards pipelined cpus traditionaly min() has an implementation like template<typename type> inline type min(type a, type b) { return a<b ? a : b; } this function (even if inlined) introduces a branch in a sequence of instructions though branch prediction algorithms do exist they will guess at most 50% of them because routine input is arbitrary since a wrong branch prediction causes pipeline stall i thought that such a … [View More]useful routine like min() MUST have non-stalling (read 'non-branching') implementation i thought hard and in the end recalled a simple implementation which is called LUT (for 'look-up table') here's what i finally got: template<typename type> inline type min(type a, type b) { const type c[2] = {a, b}; return c[b<a]; } intuitively this implementation should work slower than the first one but in real life it runs faster (roughly by a factor of 2 for 4 byte types on core2duo) here's a test code: #include <vector> int main() { typedef int type; const int n = 1000000; std::vector<type> v1(n), v2(n); //filling v1 and v2 somehow type min = BIG_VALUE; for (size_t i = 0; i<n; ++i) a = min(a, min(v1[i], v2[i])); //searching minima of v1 and v2 return 0; } however for 'double' it runs ~2% slower (i think it's because creating a lut for 2 elements 8 bytes each is slower than a branch on c2d) nevertheless i think it's a great approach at least for ints also max() can implemented very similar you may skip the rest example of usage imagine we want to implement a symmetric matrix that stores only half of its elements (say upper triangle) a00 a01 a02 --- a11 a12 --- --- a22 then access requests to the lower triangle elements would be redirected to upper triangle ones here we have a constraint that actually we only have access to elements a(i, j) where i<=j must always be true (look at indices above) if we use a branch like //... return i<=j ? a(i, j) : a(j, i); we get a pipeline stall almost every time we want to access an arbitrary element however if we rewrite it carefully as //... const size_t m = min(i, j); //non-branching min() here return a(m, m + abs(int(i) - int(j))); //abs() is also //non-branching we get rid of branches at all! and we can hope a pipelined cpu will handle it better than the other (branched) implementation -- pavel [View Less]

9 14

Re: [boost] Are warnings acceptable artifacts from builds?
by Vinnie 14 Sep '09

14 Sep '09

>From http://sqlite.org/testing.html#coverage "Static analysis means analyzing code at or before compile-time to check for correctness. Static analysis consists mostly of making sure SQLite compiles without warnings, even when all warnings are enabled. SQLite is developed primarily using GCC and it does compile without warnings on GCC using the -Wall and -Wextra flags. There are occasional reports of warnings coming from VC++, however. Static analysis has not proven to be helpful in … [View More]

16 31

[pool] Thread specific pool allocator
by James Bremner 14 Sep '09

14 Sep '09

I develop code to run on multiple processor machines. Moderate use of the standard template library (STL) containers cause programs to slow down when the work is split between threads running on different processors. This is because the STL default memory allocator is a thread-safe singleton and causes contention between the threads. The memory allocator provided by boost::pool_allocator is also a thread safe singleton. I have coded a thread specific memory allocator based on boost::… [View More]

7 11

[serialization] Calling basic_streambuf::sync in basic_binary_iprimitive destructor
by Andrey Upadyshev 14 Sep '09

14 Sep '09

Hi, All! Anybody knows, does we really need to call std::basic_streambuf::sync in boost::archive::basic_binary_iprimitive destructor? Is it possible to not call it? I ask it because the call of sync with file stream buffer leads to skipping of the unreaded input data. I think it is not good, or al least it must be clear described in documentation, that binary_iarchive when used with file stream skips to the end of a stream. Andrey Upadyshev P.S. Sorry for my English

2 2

Re: [boost] C++ Manifesto
by christophe henry 13 Sep '09

13 Sep '09

> Why is there no Boost.ANTLR? Good question. I mean, if Spirit seems to you such a disservice to the community that you write the xth post about it, why not show how to do it right? I'm sure we would all benefit from it, because right now, I haven't read anything constructive in this post. At least Joel spent lots of time to offer a great library to the C++ community and I think he deserves better than such unconclusive criticism as "I think that it represents a disservice to the C++ … [View More]

2 1

[thread] Obtaining thread id on Windows
by Agustín K-ballo Bergé 13 Sep '09

13 Sep '09

I've found a need to retrieve a thread id rather than a thread handle on Windows. There is no documented way to get it from the handle on XP (see http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/89728ee1-d9d… ). Would it make sense to add a get_native_id member function? Thank you. Agustín K-ballo Bergé.-

2 3

[variadic_templates][mpl]announcement:sandbox now has variadic_templates directory
by Larry Evans 12 Sep '09

12 Sep '09

There is now a sandbox directory for variadic templates: https://svn.boost.org/trac/boost/browser/sandbox/variadic_templates The tests in variadic_templates/libs/mpl/test/Jamfile have all passed. Some of those tests have been slightly modified to accommodate the variadic template version of mpl sequences. BTW, it's important to apply the gcc patch mentioned here: https://svn.boost.org/trac/boost/browser/sandbox/variadic_templates/README.… All sequences have been changed to use a new … [View More]template: foldr_pack whose last argument is a parameter pack. That change also required a new binary template for each sequence: X_item_fold where X is one of: v l s m One reason for that change was to highlight the similarites of the sequences. Some other fold additions were: foldr_iter.hpp foldl_iter.hpp The foldr and foldl correspond roughly to iter_fold and reverse_iter_fold (or the other way around, I can't remember which). The reason for these additions is that they reflect more closely the way foldr and foldl are done in haskell, as indicated by the comments in the .hpp files. One useful application of the pattern expansion mentioned in section 3.6.1 of: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2242.pdf is their use to easily define SEQ_c in terms of SEQ, where SEQ is any sequence. For example: template < typename Integral , Integral... Values > struct list_c : list < integral_c<Integral,Values>... > { typedef Integral value_type; }; Another addition is package_range_c.hpp which can be used to do something similar to range_c. The main motivation for this was the make_indexes on p. 16 of: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n2080.pdf It was used in a prototype tuple implementation in: variadic_templates/libs/mpl/sandbox/tuple_non_recur.package_range_c.cpp Package_range_c was also useful in the implementation of unpack_args. A really interesting application of these pattern expansions might be another implementation of the cross_product template: http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?CPPTM_Answer… The reason I think it would be useful is because the expansion of: integral_c<Integral,Values>... results in: integral_c<Integral,Value1> integral_c<Integral,Value2> ... integral_c<Integral,ValueN> where ValueI is the i-th element in Values... Now this is a cross product of a single element, Integral, with each element in Values...; hence, I would think that it would be a simple matter to just repeat this for any number of elements. IOW, instead of integral_c, there could be: template<typename Left, typename...Rights> struct pair_rights : pair<Left,Rights>... {}; and then that, somehow, could be done for each element in some list of Left's. Would somebody like to try this? Hope somebody else finds this useful. -regards, Larry [View Less]

1 0

[iterators] zip_iterator requires random_access_iterator?
by Dean Michael Berris 12 Sep '09

12 Sep '09

Hi Everyone, According to the documentation (http://www.boost.org/doc/libs/1_40_0/libs/iterator/doc/zip_iterator.html) All iterator types in the argument IteratorTuple shall model Readable Iterator. When I use a BidirectionalIterator (list<...>::iterator) zip_iterator fails to compile, while when I use a RandomAccessIterator (vector<...>) it compiles just fine. I have a nesting like this: make_filter_iterator( filter(), make_zip_iterator( make_tuple( … [View More]

1 0

Build files locations, try 2
by Vladimir Prus 12 Sep '09

12 Sep '09

Some time ago, I have raised the concern that CMakeList.txt files violate directory structure requirements. See: http://thread.gmane.org/gmane.comp.lib.boost.devel/189496/ Back then, the discussion did not lead anywhere, and no further progress was made for 2.5 months. So, let me try to phrase this a bit differently. Is it fine with everybody if I move Jamfiles out of 'build' folder of every library one level higher? Thanks, Volodya

4 4

MSVC decorators still in autoconfig?
by Stephan Menzel 11 Sep '09

11 Sep '09

Hi, I am just about to migrate to 1.40 and I noticed the changed naming scheme. So the TOOLSET and BOOST_LIB_VERSION defines are missing when I build the libs (even when using layout=tagged in bjam) but the autoconfig, specifically auto_link.hpp, still includes this in MSVC's autolink feature. So as far as I can see autolink will not work in Windows, right? At least, it doesn't for me unless I change auto_link.hpp line 312 so skip this. Is this a bug or am I overlooking something important? Cheers, Stephan

3 4

C++ Manifesto
by Christian Schladetsch 11 Sep '09

11 Sep '09

I wrote: A problem seems to be that we are trying to be meta-meta when meta- alone suffices. > The GCC frontend hasn't been integrated into mainline GCC, the LLVM > frontend is beta and similarly lives out of tree. A substantial, > incompatible, rewrite of the language is currently in progress. > The same can be said for C++0x. And LLVM is not in beta w.r.t Apple. > > I've used D for some fun side projects, it is a nicer language than C++. > However, would I suggest … [View More]using it at work, and risking a major, long-living > software project on it? Unfortunatly not yet, and most people I've > personally spoken to agree. > I am speaking out of my backside when I say anything on this matter, as I have not written anything substantial in D. But my original point remains: why not? There are no tablets written in stone stating Thou Shalt Write In C++. Sure, there are many people that are "language lawyers" and understand the finer intricacies of ADL and that is their livelihood. Great for them. Most of us understand (or could understand) most of boost. It isn't that hard - most of the "chicanery" is to do with xplat systems creating code-paths that even the original authors don't understand. The rest of the magic is in Spirit and similar expression-template-based systems that are only hard to understand because of their working domain. If they were written procedurally, they would be fine, or if they were written in ML they would be fine but because they are written in a strange mixture of bastardised C++ they are esoteric and deemed to be "excellent C++". I'm sorry. I don't think that Spirit is excellent C++. I think it is terribly clever C++ and I think that it represents a disservice to the C++ community. Further, I think it has singularly set back language development by years. The damage is untold - if only there was active C++ support for a system like ANTLR for the past few years rather than Spirit then maybe we wouldn't be in the mess we are in now. To be clear, I don't mean any disrespect to Joel or to the Spirit2 code-base per se. I just don't think that the C++ compiler was ever meant to be a language tool. I personally have witnessed at least two groups of coders reject a DSL-based solution because they thought that to do so "correctly" would mean using Boost.Spirit, which was beyond them. Meanwhile, ANTLR has no C++ support. It's a crying shame. Why is there no Boost.ANTLR? The question then stands: why stick with C++ for everything? What can D do in similar circumstances? (I know the immediate answer is "we don't use D" but can we please put that aside for a year). I don't know. I haven't used it. I have nothing to do with Digital Mars or Alex. I care only about writing effective code. I feel that C++?? is becoming just that. It doesn't matter that I can (eventually) understand the latest boost library, or the latest boost technique. What matters is what is the best way to write efficient code? Because I can agree with you, when you think that you are writing a lot of boilerplate nonsense to get basic things done. Move semantics and the problems that Ion is having is a case in point. I don't mean to be a misery-guts, but after having looking deeply at the issues I really don't see a way that it can be done without a language change. C++ is a fine language, but seriously, the authors didn't have any idea on how we'd use it and the differences are compounding exponentially. When C++ is no longer the best way (and yes, that is a "when" not an "if"), I would like to think that I am open-minded enough to be on that wave. Is that time sooner rather than later? Say you want to write a parser/AST walker/executor for a basic language with scoped variables and continuations. Is Boost.Spirit the best way to do so? Is it *really*? Say you want to write an object factory with persistent objects. Is Boost.Serialisation and Boost.Function the best way forward? How will you you store the functions? Say you want automatic resource management. shared_ptr<> doesn't cut it. It is too slow for single-threaded and at the same time doesn't deal with cycles. Say you want to write a geometry library. Ok, stop right there.... Is Boost.Graph the best way to make a basic DAG? I've tried all these systems. They work, there is no doubt. Do they work well, in practice? Has there been any real-world review of the efficacy of boost libraries in general? I'm sure there has, as many here could attest, but this is a biased sample set. I wonder how much and what aspects of boost are used in the wider community? I for one use foreach, shared_ptr, unordered, mpl, some fusion, and other bits and pieces. No-one in my team uses anything other than foreach and shared_ptr - and there is a lot of confusion I have to deal with relating to their use of weak_ptr<> and locking etc with that. It seems that 5 years ago I had to argue that boost was Ok to use, and I still feel like I am saying the same things. I am approaching the stage where I wonder why I continue to apologise for it. What do you use? Which parts of boost are good to use with least impact? This has turned into a manifesto against boost. I didn't mean that to be the case when I started, but so be it. I come from the real world, and there are real programmers that just don't know and don't want to deal with problems they can't solve. As a lead, I have to make technology decisions and I am clearly frustrated with the potential of both boost and C++ in general. Sometimes I think that it would be easier to just change language completely to C#/asm or D/C++/asm. I am in the position now to decide what will be the language for the next game made in company A. I am strongly tempted to make the core in C# with callouts to C++ libs for physics and render. Personally, after 20-odd years and still seeing the likes of Lucanus swing on the rope with his geometry lib, it makes me wonder if C++ is really what the real-time world needs. Regards, Christian. [View Less]

9 10

scoped_allocator_ptr
by Felipe Magno de Almeida 11 Sep '09

11 Sep '09

Hi, Is there an interest in a scoped_ptr that receives a Allocator parameter? I've been needing this in some libraries I've been developing. It could use EBO for the Allocator parameter to have the same size as scoped_ptr for empty Allocators. I need a move_ptr with a Allocator parameter too. But I rather let somebody else write for now. Thanks, -- Felipe Magno de Almeida

3 6

Control of the file location for the boost::interprocess::managed_shared_memory object
by Michael Watkins 11 Sep '09

11 Sep '09

Is it possible to control the exact location of the file that is backing the shared memory created by boost::interprocess::managed_shared_memory? The issue occurs under Windows (it has not been tried yet under Linux). The problem is two processes attempting to connect to the same shared memory segment between two accounts, in specific from a program running as a service (using the system account) and a program running under a user account. The user account is running a program that needs … [View More]

2 4

[multi_index][serialization][Huang-Vista-x86_32_intel] Help with weird test failure
by joaquin＠tid.es 11 Sep '09

11 Sep '09

Huang-Vista-x86_32_intel toolset, which runs Intel 11.1 for Window, has this weird error on the serialization test for Boost.MultiIndex: Running 1 test case... ../libs/multi_index/test/test_serialization_template.hpp(82): error in "test_main_caller( argc, argv )": check all_indices_equal(m,m2) failed unknown location(0): fatal error in "test_main_caller( argc, argv )": std::exception: invalid signature (http://tinyurl.com/nd89x2) What I find weird is the throwing of invalid_signature, a … [View More]

1 0

[warnings] Are warnings acceptable artifacts from builds?
by Sid Sacek 11 Sep '09

11 Sep '09

Just curious, when I use certain libraries, I get compiler warnings. Are these simply acceptable during a build, or should they be reported to somebody ? The latest warning I'm seeing are: Warning 4 warning C4245: 'initializing' : conversion from 'int' to 'const boost::detail::mask_uint_t<8>::least', signed/unsigned mismatch C:\Trunk.3.1\ThirdParty\boost\crc.hpp 377 Warning 5 warning C4245: 'initializing' : conversion from '… [View More]

13 52

[Boost.Breakable] Any interest in a Boost Breakable library?
by Pierre Morcello 11 Sep '09

11 Sep '09

Hello, I propose a set of macros that allow to break anywhere. Example of use of the main macro : // do something... BOOST_BREAKABLE { if (test1) { break; } if (test2) { break; } std::cout<<"this is never reached if test1==true or test2==true. … [View More]

20 44

Re: [boost] non-branching min()
by Phil Endecott 10 Sep '09

10 Sep '09

DE wrote: > template<typename type> inline > type min(type a, type b) > { > const type c[2] = {a, b}; > return c[b<a]; > } How well this performs compared to the conventional ?: implementation will depend on how the arguments are distributed. If the outcome is skewed, then branch prediction will make the conventional implementation faster. If the outcome is 50/50 (and not correlated with some other branch), then your code may do better. … [View More]

1 0

[Test] Memory leak with boost v1.40 under gcc 4.2 for x86_64 in Snow Leopard
by S Roderick 10 Sep '09

10 Sep '09

[First time poster to boost] Compiling for the default x86_64 produces a memory leak in the test framework, but the same program compiled for i386 does not. Mac OS X Snow Leopard gcc 4.2 with macports boost 1.40.0 (same memory leak seen in v1.39 macports also). The memory leak only occurs with multiple test cases or test suites. Set the define in my test program to remove the extra test case, and the leak dissappears. Could not find this problem on the list, nor the 'net. Output … [View More]

1 0

Iterators Must Go (Ahead)
by Andrei Alexandrescu 10 Sep '09

10 Sep '09

Hello, I wrote an article about D's ranges, contrasting them to other iteration idioms. Those who'd be interested in reviewing the article, please send me email. (I may not be able to reply to all requests.) Bear in mind that the article is rather long - about the size of two usual magazine articles. Thanks, Andrei

7 6

[unordered] please don't allocate memory in the default constructor
by Thorsten Ottosen 10 Sep '09

10 Sep '09

Hi Jeremy, I think this a really bad idea to allocate in the default construtor. The user can always call rehash() on the empty container, just like when we call reserve() for vector. Thanks -Thorsten

5 8

[PropertyTree] Help tracking down test failure.
by Sebastian Redl 10 Sep '09

10 Sep '09

Hi, If you look at the PTree regression results: http://www.boost.org/development/tests/trunk/developer/property_tree.html you'll see that the test_property_tree test currently fails on a log of platforms, especially Darwin. An assertion fails. Since I cannot reproduce the error on any of my systems, could someone who can please send me a stack trace, and perhaps a debug print of the two objects involved? Here's the test output of one runner: http://www.boost.org/development/tests/trunk/… [View More]

1 1

[mpl] ForwardIterator concept recursion
by Marcin Zalewski 10 Sep '09

10 Sep '09

I have been trying to implement a concept for mpl ForwardSequence, and besides the lack of const expr requirements in the latest version of concepts I have stumbled across the problem of concept recursion. One example of such recursion is the ForwardIterator [1] concept. The requirement on the next<i>::type type is that it must be a ForwardIterator. One could try to write a concept like that: concept ForwardIteratorStatic<typename I> { typename deref; typename next; requires … [View More]

3 3

Re: [boost] [GIL] image rescale algorithms
by Est 10 Sep '09

10 Sep '09

Hi Nicolas, I used your code in Ramen (http://sourceforge.net/projects/ramenhdr/) It works great. Thank you. And now, some feedback... I think filters should be a small separate GIL extension. They are useful also for other image resampling algorithms. In clamp_channel_fn I added an overload like this: template <typename SrcChannel, typename T, typename S, typename U> void operator()(const SrcChannel& src, scoped_channel_value<T,S,U>& dst) { typedef typename … [View More]

2 1

[sandbox] git?
by k-oli＠gmx.de 09 Sep '09

09 Sep '09

Is a official git-repo available? boost vault uses svn

3 2

[cmake] revision 50756 failed to merge some file properties
by JOAQUIN M. LOPEZ MUÑOZ 09 Sep '09

09 Sep '09

Hi, this is a repost of a message that went unnoticed three months ago: http://lists.boost.org/boost-cmake/2009/06/0592.php and that's causing problems when merging CMake-specific stuff from trunk to release, as discussed at: http://lists.boost.org/Archives/boost/2009/08/154996.php http://lists.boost.org/Archives/boost/2009/08/155003.php CMakeLists.txt and related files in trunk do have a "svn_keywords" property with value "Id", while the counterparts in the release branch are missing … [View More]

6 9