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

Sexpr Parser example of utree compiles error--function and symbol cannot be resolved
by 风在漂 27 Nov '11

27 Nov '11

Hi, I am new to the boost, I download the boost 1.49.0 and try to build the utree example – Sexpr Parser(environment: eclipse +CDT + gcc4.5.2), but It failed and I got the error info about the “sexpr_gemerator.hpp” as follows: Function ‘attr_cast’ could not be resolved Function ‘call’ could not be resolved Symbol ‘boo_policies’ could not be resolved Symbol ‘String_inserter’ could not be resolved Actually, I check the header, It already has ‘#include <boost/spirit/include/karma.hpp>’ which will finally include ‘#include <boost/spirit/home/karma/numeric/bool.hpp>’, where karma::attr_cast is defined Does anyone know the reason? how can I make the example run successfully? thanks By the way, I can build other exmple like “mini-xml parser” in the doc library. Best, Feng

2 1

Re: [Boost-users] Problems of cross compiling: ar and ranlib tools naming ((Mark Brand)
by Iron Bug 26 Nov '11

26 Nov '11

> You might want to look at mingw-cross-env [1] which includes boost. It > doesn't have 64-bit support yet though. > > There's a link there to browse the development version. Look for file > src/boost.mk if you want to see the boost recipe. > > Mark Thanks a lot! That's really useful set of scripts. Exactly what I was doing manually for many years, building numerous libraries for different cross compilation variants. They use SED's in boost case. Seems, there's no other way to make it generate the right library format for cross compilation. I thought a good idea about names was chrooting to special /bin with links to proper toolset, but even in this case the format of libraries would need correction. So now I've got the idea and can adopt the scripts for my needs. I will recommend the tools for other programmers, that use cross compiling. Sincerely, Yana A. Kireyonok

1 0

[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