- Boost-users - lists.preview.boost.org

[unordered] Iterator default constructor usage
by andpar83＠gmail.com 26 Nov '11

26 Nov '11

Hi all. Is it a correct usage of default constructor of iterators? Are any gurantees that it will always equals to the iterator returned by end()? : typedef boost::unordered_map<std::string, int> map; map x; x["one"] = 1; assert(x.find("missing") == x.end()); assert(x.find("missing") == map::iterator()); assert(map::iterator() == x.end()); Andrey

3 4

Help needed with boost::shared_mutex
by Kelvin Chung 26 Nov '11

26 Nov '11

I need assistance on how to properly use boost::shared_mutex. Suppose I have this routine, which I want to make thread-safe: class FunctionEvaluationCache { // Assume singleton std::unordered_map<Function, std::map<Input, int>> cache; // cache of results to Function::evaluate() } class Function { // Copyable bool operator==(const Function& fn2); // All Functions that operator==() share a cache entry int evaluate(const Input& in) { // Expensive operation, hence the cache if (cache.count(*this) == 0 || cache[*this].count(in) == 0) { // Not in cache, do expensive operation // Add result to cache cache[*this][in] = result; } return cache[*this][in]; } } Clearly, the big obstacle to a threadsafe version of Function::evaluate() is this cache. I believe that I will need a boost::shared_mutex for cache, as well as each cache entry. I'm not sure on how to use boost::shared_mutex, however: the straightforward way would be to expose the boost::shared_mutex instances publicly and modify evaluate() to get the proper locks, while the other line of thinking is that I should not expose the boost::shared_mutex instances at all and have a series of methods that evaluate() can use. But what I would like to do is not modify evaluate() in any way. Is it possible to do this?

2 3

Problems of cross compiling: ar and ranlib tools naming
by Iron Bug 26 Nov '11

26 Nov '11

I'm trying to build full cross compiled toolchain and boost is almost ok, except of some details in static libs. The problem is that it uses patterns like $(command-string) -print-prog-name=ar (and ranlib as well) for getting the ar and ranlib for the toolset. But due to some bug in i686-w64-mingw32 and a whole bunch of similar instruments (on debian, ubuntu, etc) the XXX-gcc -print-prog-name=ar returns simply "ar", without tool prefix. Same about ranlib. And they seem not being apt to fix it: http://groups.google.com/group/linux.debian.bugs.dist/browse_thread/thread/… I saw an old bug ticket about this problem in old boost archives: https://svn.boost.org/trac/boost/ticket/3373 It's marked as fixed. I added some strings to my project-config.jam like: using gcc : : i686-w64-mingw32-gcc : <rc>i686-w64-mingw32-windres <archiver>i686-w64-mingw32-ar <ranlib>i686-w64-mingw32-ranlib But it evidently had no effect, by some reason: in output I still see strings like "/usr/bin/ar", "usr/bin/ranlib" and the librarian error ("could not read symbols: Archive has no index; run ranlib to add one") is still there when trying to use the libraries. I found the place in gcc.jam tool script where ar-tool name is defined: # - The archive builder. local archiver = [ common.get-invocation-command gcc : [ NORMALIZE_PATH [ MATCH "(.*)[$(nl)]+" : [ SHELL "$(command-string) -print-prog-name=ar" ] ] ] : [ feature.get-values <archiver> : $(options) ] : $(bin) : search-path ] ; toolset.flags gcc.archive .AR $(condition) : $(archiver[1]) ; if $(.debug-configuration) { ECHO notice: using gcc archiver :: $(condition) :: $(archiver[1]) ; } ranlib is similar, windres is kind of case of some variants. I'm not that smart in boost build scripts but it looks like it tries to get the name from -print-prog-name (that is buggy). Am I correct? Maybe I'm just setting parameters in some wrong way? I would like to get some hints how I could make it take my options from project-config.jam and take the -print-prog-name by default. To get the resulting tools strings like i686-w64-mingw32-ar, etc, be it a parameters setting or patch for tools jam file, whatever that solves the problem. Sincerely, Yana A. Kireyonok

2 1

[thread] Stress testers sought for a new "Recursive MRSW" locking class TCLock
by U.Mutlu 25 Nov '11

25 Nov '11

Today I wrote a locking class for the "many readers/single writer, with recursion (MRSW-R)" - problem (ie. shared recursive locking). The current version is for Linux/Unix like systems only. Anybody seriously interessted in stress testing / performance testing it drop me a note. This locker has automatic "Upgrade" (and also "Downgrade") feature built-in, ie. nothing sepereate needed (see examples below). It's just a small mutex class and one locker class which can do both read and write locking (ie. just pass the kind via ctor-param...). (of course one can derive seperate classes for Read and Write) Of course it uses boost (especially atomic primitives like atomic_inc32(), atomic_dec32() etc.) Examples: TCLockVar LV; // this is our special mtx var void f() // called from many threads { TCLock L(LV); // a Read-Lock ... } void g() // called from many threads { TCLock L(LV, true); // a Write-Lock ... } void h() // called from many threads { TCLock L(LV); // a Read-Lock ... if (fNeedToUpdate) { TCLock L(LV, true); // a Write-Lock within a Read-Lock; that's OK! :-) ... } ... } Just drop me an email if interessted in stress testing TCLock. -- U.Mutlu www.mutluit.com

1 0

Problems using mpl::if_ and function_types::result_type
by Allan Nielsen 25 Nov '11

25 Nov '11

Hi I'm new to the boost::mpl library, and have some "beginners-problems" template < typename F > struct A { typedef boost::function_types::parameter_types<F> P; typedef typename boost::function_types::result_type<F>::type R; typedef typename boost::mpl::if_< boost::is_same< R, void >, boost::function< void ( void ) > , boost::function< void ( R ) > >::type TTT; A() { } }; int main(int argc, const char *argv[]) { A<int(int, float)> ok; // working A<void(int, float)> compile_error; // non-working return 0; } xxx.cxx: In instantiation of ‘A<void(int, float)>’: xxx.cxx:108:25: instantiated from here xxx.cxx:100:77: error: invalid parameter type ‘boost::mpl::aux::wrapped_type<boost::mpl::aux::type_wrapper<void> >::type’ xxx.cxx:100:77: error: in declaration ‘A<F>::TTT’ What is the problem here, and how can I solve it. To my understanding only the selected part of mpl::if_ should be evaluated by the compiler.... Regards Allan W. Nielsen

3 3

Why does CMake use relative linking when I replace a shared object?
by Mathias Gaunard 25 Nov '11

25 Nov '11

There is some strange CMake behaviour I don't quite understand. In the project attached, I build a shared library for which I want to specify a custom build command; to do this I generate a dummy library which I then replace by another file in a POST_BUILD command (alternatives involving imported libraries do not work properly across different scopes). If I do not replace the library, then the executable correctly links against libtest.so. If I do, it links instead with ../baz/libtest.so (sic), which of course, fails when trying to run the program. Why is it putting a relative path into my executable? Why is it different depending on whether I replace the .so by another one or not? Thank you very much for any insight on what's happening.

1 1

Is it possible to set DSCP (DiffServ code point) on a network connection?
by Morgan Lindqvist 25 Nov '11

25 Nov '11

Hi, I have been reading the documentation and searched this discussion forum but I can not find any information on how to set a DiffServ code point on the network connection. I need to set this to enable QoS on the UDP data I send but I can not find out how to do it. All pointer are appreciated. Best Regards, Morgan

3 2

Subject: Re: Building Boost 1.48 using Intel compiler (Message 2, Nov 19, 2011)
by Yana A Kireyonok (aka Iron Bug) 25 Nov '11

25 Nov '11

>> After examining Boost.Regex and Boost.Locale Jamfiles, it's seems that both libraries perform the same has_icu check and both fail to detect ICU on Windows if the Intel compiler is used. This is not exactly about building with ICC, but maybe somebody would like this hint: I managed to build boost 1.48.0 with ICU 4.8.1.1 adding this to bjam build command: -sHAVE_ICU=1 -sICU_PATH=path_to_the_ICU_dir -sICU_LINK="-L%ICU_PATH%/lib -licuuc48 -licuin48 -licudt48" (-sICU_LINK="-L$ICU_PATH/lib -licuuc48 -licuin48 -licudt48" for crosscompiling on Linux) This allows bjam to compile ICU correctly and works for all Windows target OS configurations. As a fact, I succeeded to build boost 1.48.0 with ICU 4.8.1.1 on Windows with msvc-10.0, mingw and also mingw crosscompiled on Linux for Windows target-os. That works. I think, that must do with ICC as well. Little note: in MinGW configurations threading=multi is needed, due to a bug in configuring scripts, that was written about in "Trouble building boost-1.48.0 with mingw 4.5.2" theme. Sincerely, Yana A. Kireyonok

1 0

fusion quesion
by Robert Ramey 25 Nov '11

25 Nov '11

Fusion includes a number of binary functions such as join, equal, less, etc. Looking at the code suggests that they just work element by element in sequential order. But what about associative tuples? For example struct account {}; struce amount {}; typedef boost::fusion::set< account, amount > debit; typedef boost::fusion::set< amount, account > debit2. clearly the types are meant to be the "same" so I would expect boost::fusion::join(debit, debit2) to function and return one type. I'm thinking it doesn't do that. Any observations/suggestions that any Fusion guru would like to share would be appreciated. Robert Ramey

2 3

Re: [Boost-users] Scope exit with no capture
by Bruno Martinez 24 Nov '11

24 Nov '11

>> It seems scope exit is abandoned. > > Not abandoned but carefully looked after. I'm happy to hear this. > Scroll down the post > you're refering to to this line: >> #define this(x) (this(x)) > > Check the code in > http://lists.boost.org/Archives/boost/2009/05/151353.php > Do we want to go that far? What do you mean? Note that the limitation that's bothering me is having an empty capture list, not capturing this. > Also, there are some limitations (a) "this" must be first in a > capture list and (b) there is no way you can use "this" inside > a body if you use C++03 compiler. > > So, rather than raising a learning curve for no clear benefit, > I prefer being explicit and write: > > YourClass *this_ = this; BOOST_SCOPE_EXIT((this_)... > or > YourClass& self = *this; BOOST_SCOPE_EXIT((self)... I've not bumped into the this limitation yet. I want a clean way to run code at exit that needs no access to local variable and captures nothing. Since my compiler supports lambda, I've adopted the old scopeguard from loki. It would be great if scope_exit supported & and = capture for all needed variables as hinted in the documentation as a possibility, or better yet, reimplement scope_guard, which has better syntax. Bruno

2 1