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

[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

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

21 Apr '12

Hello Ovanes, > This over-allocation is pretty much the same as reserving some space at the > end of the data structure to place data together. Am I right? Why isn't it > possible to just write char[128] or char[16] instead of char[1]? I can't change that code because it lives in a system header. > And if > you know that this buffer represents some special case, why don't you pass > it as such to filesystem? &char[0], than boost::filesystem will not assume > it got char[1] and will be looking to '\0' marker... > How would I know that this buffer represents some special case? FTS(3) library documentation says something like that: struct _ftsent { ... char *fts_name; }; But the structure is really defined another way (Linux, Mac OS X): struct _ftsent { ... char fts_name[1]; }; I believe this discrepancy is pretty much negligible anyway. There are huge number of programs utilizing fts(3) APIs and they don't break. Unfortunately boost::filesystem is another story. It does break and it does break silently.

1 0

boost::filesystem::path operator/= is broken for char[1] in 1.48
by Nick Zavaritsky 21 Apr '12

21 Apr '12

Hi! Please consider the code below: === BUG === boost::filesystem::path some_path("first"); char path_component[1]; /* = "second" */ some_path /= path_component; Some_path value is expected to be "first/second" but it is "first". I.e operator /= had no effect. === END BUG === Concerning a longer string in a char[1] buffer. Actually path_component is the *last* field in a heap-allocated structure. The structure is over-allocated to enable storing a longer string in a char[1] buffer. This technique is often used in C code. Here is operator /= callstack. #0 boost::filesystem3::path_traits::empty<char const, 1ul> () at path_traits.hpp:89 #1 0x0000000100001e7e in boost::filesystem3::path::append<char [1]> (this=0x7fff5fbff910, source=@0x100100270, cvt=@0x100100280) at path.hpp:655 #2 0x0000000100001f77 in boost::filesystem3::path::operator/=<char [1]> (this=0x7fff5fbff910, source=@0x100100270) at path.hpp:235 The relevant excerpt from boost::filesystem3::path_traits::empty follows: namespace path_traits { ... template <typename T, size_t N> inline bool empty(T (&)[N]) { return N <= 1; } ... } It appears that boost::filesystem::path treats char[1] as an empty path regardless of the actual content. This is definitely wrong due to so many C libraries storing long strings in char[1] buffers. In particular on Mac OS X fts(3) FTSENT::fts_name is char[1]. I believe the current operator =/ behavior is outright dangerous and should be fixed. By the way the only code currently benifiting from the boost::filesystem::path being overly smart is the code appending "" (empty string literal) to pathes.

4 3

MSM: Separating templatized on_entry/on_exit into cpp/h
by ev_mp 20 Apr '12

20 Apr '12

Hello, I'm trying to modify the Player example and to separate the on_exit/on_entry template function definition from declaration so I can hide the actual implementation details. "My.h" ... namespace myNamespace { ... // Concrete FSM implementation struct player_state_machine : public msm::front::state_machine_def { ... struct Playing : msm::front::state<> { template void on_entry(event const &, player_state_machine & ); // { "My Secret Code } } ...... } } "My.cpp" namespace myNamespace { ... template void myNamespace::player_state_machine::Playing::on_entry(Event const &, player_state_machine & ); { Here I want to put the actual implementation... } Is this feasible ? If not - what are the alternatives ? As I previously said - putting the implementation into the header is not an option. Any help will be appreciated. Evgeni -- View this message in context: http://boost.2283326.n4.nabble.com/MSM-Separating-templatized-on-entry-on-e… Sent from the Boost - Users mailing list archive at Nabble.com.

2 3