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

map of ranges?
by Sven Bauhan 24 Apr '12

24 Apr '12

Hi, i was thinking of something like a map of ranges, but i did not get the range concept in boost yet. So what i want is something like: typedef map< range<time_duration>, Color> AgeColorMap; Is it possible to use something like that with the boost library? Thanks, Sven

2 2

Please tell me how to add PKG-CONFIG Support in bjam ?
by Baba Prasad 24 Apr '12

24 Apr '12

Dear friends, Please tell me how to set the pkg-config in bjam. please see like this I am using while compiling the using gcc and make command 1) gcc -g - o `pkg-config --cflags glib-2.0 dbus-glib-1 --libs glib-2.0 dbus-glib-1` main main.c but I don't know how to add this option in bajm and I don't know where to add this option in either jamfile or boost-build.jam. because you might get doubt why do you want use glib and dbus means I using dbus api's in my program. If it should be add in boost-build.jam file means it is already have the following boost-build /home/kaka/Documents/seamo/boost_1_49_0/tools/build/v2 ; so how to and where to add is my big confusion , please if any one knows could help me get out of this problem. Best Regards BaBu -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

passing compiler directives
by Matt Priest 23 Apr '12

23 Apr '12

Hello, In advance, please excuse this newbie question. I am trying to build boost_1_48_0 and it is going well for all but 4 targets, two of which are the disclaimed <iostreams> failures relating to the bzip targets. However, I'm getting errors when trying to build : boost_1_48_0/libs/filesystem/v3/src/unique_path.cpp Here's the error (there's a nearly duplicate error for the statically linked target): gcc.compile.c++ /users/mpriest/Docs/Boost/build/boost/bin.v2/libs/filesystem/build/gcc-4.7.0/release/threading-multi/v3/src/unique_path.o libs/filesystem/v3/src/unique_path.cpp: In function 'void {anonymous}::system_crypt_random(void*, std::size_t, boost::system::error_code*)': libs/filesystem/v3/src/unique_path.cpp:68:49: error: 'read' was not declared in this scope libs/filesystem/v3/src/unique_path.cpp:71:17: error: 'close' was not declared in this scope libs/filesystem/v3/src/unique_path.cpp:79:13: error: 'close' was not declared in this scope "gcc" -ftemplate-depth-128 -O3 -finline-functions -Wno-inline -Wall -m64 -pthread -fPIC -DBOOST_ALL_NO_LIB=1 -DBOOST_FILESYSTEM_DYN_LINK=1 -DBOOST_SYSTEM_DYN_LINK=1 -DNDEBUG -I"." -c -o "/users/mpriest/Docs/Boost/build/boost/bin.v2/libs/filesystem/build/gcc-4.7.0/release/threading-multi/v3/src/unique_path.o" "libs/filesystem/v3/src/unique_path.cpp" ...failed gcc.compile.c++ /users/mpriest/Docs/Boost/build/boost/bin.v2/libs/filesystem/build/gcc-4.7.0/release/threading-multi/v3/src/unique_path.o... It seems like a simple include file availability issue or a pre-processor define issue, but I can't seem to affect a change in that compiler command through the user-config.jam file edits. When I run b2 with --debug-configuration option, I clearly see that change the -L and -I options in the user-config.jam file is reflected in the output, but still only see the -I"." option as shown above. It seems to me that those functions, read and close, should be made available through including the usual <fcntl.h>, and I think it's a bit curious that no other targets fail from the lack of "read" and "close". Any insight would be appreciated... thank you. Matt

1 0

[serialization] Serializing a byte*
by Sean Farrow 23 Apr '12

23 Apr '12

Hi: I have a function in another library that outputs a byte*. Can I safely just serialize this with boost.serialization, or should I be doing something else to make this work. Any help appreciated. Cheers Sean.

2 1

PKG-CONFIG Support in bjam is how
by Baba Prasad 23 Apr '12

23 Apr '12

Dear friends, Please tell me how to set the pkg-config in bjam. please see like this I am using while compiling the using gcc and make command 1) gcc -g - o `pkg-config --cflags glib-2.0 dbus-glib-1 --libs glib-2.0 dbus-glib-1` main main.c but I don't know how to add this option in bajm and I don't know where to add this option in either jamfile or boost-build.jam. because you might get doubt why do you want use glib and dbus means I using dbus api's in my program. If it should be add in boost-build.jam file means it is already have the following boost-build /home/kaka/Documents/seamo/boost_1_49_0/tools/build/v2 ; so how to and where to add is my big confusion , please if any one knows could help me get out of this problem. Best Regards BaBu -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

1 0

Subject: [Property Tree] Insert child node at the top of ptree
by johnnyturbo3 23 Apr '12

23 Apr '12

Hello all, I'm trying to find a way to write a child node to the top of a ptree, instead of the bottom as default. I've tried a number of things but for something that should be so simple I've had no luck. The reason I want to write a node to the top of the structure is because when I use ptree::get_child(), it fetches the first node match in the tree i.e. the oldest node written, not the latest written. I've posted the question on stackoverflow.com, it may explain some more detail: http://stackoverflow.com/questions/10272371/add-child-node-to-top-of-xml-st… I hope I've explained my problem clearly. Thanks in advance! Nathan

2 1

Boost.Atomic documentation, Reference Counting
by Václav Zeman 23 Apr '12

23 Apr '12

Hello. Your documentation to Boost.Atomic ([1]) has been given me as an answer to my StackOverflow ([2]) question. Here is a snippet from the documentation: friend void intrusive_ptr_release(const X * x) { if (x->refcount_.fetch_sub(1, boost::memory_order_release) == 1) { boost::atomic_thread_fence(boost::memory_order_acquire); delete x; } } And your rationale: "It is important to enforce any possible access to the object in one thread (through an existing reference) to happen before deleting the object in a different thread. This is achieved by a "release" operation after dropping a reference (any access to the object through this reference must obviously happened before), and an "acquire" operation before deleting the object." I wonder why this would not work well if it looked like this instead: friend void intrusive_ptr_release(const X * x) { if (x->refcount_.fetch_sub(1, boost::memory_order_relaxed) == 1) { boost::atomic_thread_fence(boost::memory_order_acq_rel); delete x; } } [1] <http://www.chaoticmind.net/~hcb/projects/boost.atomic/doc/atomic/usage_exam…> [2] <http://stackoverflow.com/questions/10268737/c11-atomics-and-intrusive-share…> -- VZ

2 2

[multi_index] A multi_index where one index is a subset of the whole collection
by Philipp Moeller 22 Apr '12

22 Apr '12

Hi, I've asked this question [1] two days ago on stackoverflow.com but haven't gotten any answer on it, yet. So I'll try it here. [1] http://stackoverflow.com/questions/10217601/a-multi-index-where-one-index-i… If this is not possible out of the box, can I write my own indices for multi_index that would allow such functionality? Cheers, Philipp Moeller GeometryFactory

2 1

[thread] safe portable static mutex initialization
by Serge Skorokhodov 22 Apr '12

22 Apr '12

Hello, I've read Anthony Williams' articles and documentation but still have no definite answer. Thus two questions: 1. Is it safe to use a block level static boost::mutex on Unix and Windows? 2. Is it safe to use a file/class level static boost::mutex on Unix and Windows? TIA -- The fish that is singing in Ucayali river...

7 12

Re: [Boost-users] boost::filesystem::path operator/= is broken for char[1] in 1.48 (Nat Linden)
by ZNV 21 Apr '12

21 Apr '12

Hi Nat, >> I believe the current operator =/ behavior is outright dangerous and > >> should be fixed. > > Nope, sorry. If you pass a fixed-length array, a proper C++ library > *should* be sensitive to its max. Anything else is unsafe and should > be discouraged. > What if I pass fixed-length array without actually knowing that? There are many C libraries out there assuming char * and char [] are interchangeable. These libraries are well documented. You won't check the source code beforehand if you have the docs, will you? The fact that we're still dealing with legacy C-style APIs is not a > good reason for a modern C++ library to blithely run past the declared > end of a char array. C++ tries very hard to bring type-safety to the > party. It is far more important to try to keep new code from crashing > than it is to accommodate such misleading APIs. > I totally agree with you – type safety is an important C++ feature. It is supposed to help a programmer by eliminating more errors early. But you've achieved just the opposite result with your creative abuse of C++ type system. I would've agreed with your resolution if appending char[1] to boost::filesystem::path resulted in a static_assert. This would allow to apply the proposed workaround immediately (cast to char *). Unfortunately boost::filesystem have chosen to break my code silently instead. I had to hunt the bug in debugger – the same very thing the type safety was supposed to prevent, is not it? So yes technically my program did not crash. But I totally believe that it is not only preventing new code from crashing which is important. Eliminating obscure pitfalls the new code is suffering from is equally important. Every engineering problem is a quest for a better tradeoff. Concerning appending fixed-length array of length one or less to a boost::filesystem::path we are facing the following choices 1) silently treat the operation as a no-op (current) 2) treat it the same way as char * 3) static_assert In my opinion (1) is the worst possible choice since it breaks the code silently in a non-obvious way. When you know you're dealing with code that willfully lies to the > compiler -- even if it's been frozen into an OS API -- use Ovanes's > workaround to pass char* rather than char[size]. > See above.

2 1