- Boost-users - lists.boost.org

weird problem with mutexes on boost::interprocess
by Hernán Leoni 08 May '13

08 May '13

It seems we found a weird bug with boost interprocess, some internal problem on the scoped_lock is generating a deadlock. A simple correct usage like void foo() { scoped_lock<t_mutex> lock(amutex); ..... } is producing the deadlock when running 100 concurrent processes after changing to void foo() { amutex.lock(); ..... amutex.unlock(); } the problem disappeared the code on scoped_lock looks correct, and works just fine with a lower load, so, I guess this is something coming from the compiler, which is gcc 4.4.7 under linux did anyone get similar problems? thanks

1 0

mpl::c_str<mpl::string<>> compile error
by Olaf Peter 07 May '13

07 May '13

Hello, the code here doesn't compile: #include <boost/mpl/string.hpp> #include <iostream> namespace mpl = boost::mpl; typedef mpl::string<'h','e','l','l','o',' ','w','o','r','l','d'>::type my_hello; int main() { std::cout << mpl::c_str<my_hello>::value << '\n'; std::cout << BOOST_MPL_LIMIT_STRING_SIZE << '\n'; } As usual, the example from docs works. The error is: $ LANG=en g++ t.cpp -o t && ./t t.cpp:6:64: error: wrong number of template arguments (11, should be 8) /usr/local/include/boost/mpl/string.hpp:102:12: error: provided for 'template<int C0, int C1, int C2, int C3, int C4, int C5, int C6, int C7> struct boost::mpl::string' t.cpp:6:72: error: expected initializer before 'my_hello' t.cpp: In function 'int main()': t.cpp:10:26: error: 'my_hello' was not declared in this scope t.cpp:10:34: error: template argument 1 is invalid why does it complain about wrong number of template arguments? BOOST_MPL_LIMIT_STRING_SIZE is 32? $ svn info ... Path: . URL: http://svn.boost.org/svn/boost/trunk Repository Root: http://svn.boost.org/svn/boost Repository UUID: b8fc166d-592f-0410-95f2-cb63ce0dd405 Revision: 83988 ... $ LANG=en g++ --version g++ (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2) ... Thanks, Olaf

2 3

[Graph] undefined trait functions
by Miklós Tóth 07 May '13

07 May '13

Hi! I've a problem, with Boost Graph Library and gcc 4.7. I have a legacy graph representation that i like to wrap with a graph adaptor to access boost graph algorythms. 1: I've created a graph adaptor, that contains my legacy graph. This is a simple struct: struct legacy_graph_adaptor { legacy_graph_adaptor(const legacy_graph& g) : graph(const_cast<legacy_graph& >(g)) { } legacy_graph& graph; }; 2: Next step was a vertex_iterator and an edge_itreator, where I redefined the equal, dereference, increment, etc members. (If it's not necessary i'm not going to copy the code here.) 3: Created traits for adapted graph. I've redefined source, target, out_edge, etc. template <> struct graph_traits<legacy_graph_adaptor> : public detail::traits_base { struct out_edge_iterator : public detail::traits_base::edge_iter_base<out_edge_iterator> { typedef detail::traits_base::edge_iter_base<out_edge_iterator> Base; out_edge_iterator(int legacy_vertex = 0, int* base_to = 0, const legacy_graph* g = 0) : Base(legacy_vertex, base_to, g) { } private: void increment() { advance(); } friend class iterator_core_access; }; }; Originally it was created as a part of a msvc project. Now I try to port it to gcc, and i got the next message (for example): <path_to>\boost\boost_1_53_0\boost\graph\graph_concepts.hpp:94: error: 'out_edges' was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] When I change to gcc 4.6 it compiles well. So my question is: Is this a known bug or I missing something? Thanks for the help. Best regards: Miklos

2 4

Re: [Boost-users] Boost-users Digest, Vol 3438, Issue 1
by John M. Dlugosz 07 May '13

07 May '13

On 5/7/2013 4:09 AM, boost-users-request-at-lists.boost.org |Boost/Allow to home| wrote: > From: Oodini<svdbg___(a)free.fr> > Subject: [Boost-users] Interprocess : appending data > Message-ID: > <2058964480.133622258.1367856611110.JavaMail.root(a)zimbra59-e10.priv.proxad.net> > > Hello, > > I create a shared_memory_object, truncate it to set its size, and then create a mapped_region. > > I would like to know it would be possible to append new data, by applying a new truncation. > > Also, is it possible to have a second name pointing in the same memory, but with an offset ? > > Thanks. In Windows, if you change the size of a mapping you are not guaranteed to get the same address again.

1 0

[Boost.AutoBuffer] discussion
by John M. Dlugosz 07 May '13

07 May '13

On 5/6/2013 9:24 AM, boost-users-request-at-lists.boost.org |Boost/Allow to home| wrote: > Message: 4 > Date: Mon, 06 May 2013 14:28:34 +0200 > From: Thorsten Ottosen<thorsten.ottosen(a)dezide.com> > To:boost-users@lists.boost.org > Subject: Re: [Boost-users] [Boost.AutoBuffer] discussion > > My newer version has more explicit control of the initial constructed > object. > How might I get your current version? —John

2 1

thread crash on windows with icc in Release
by Svetlana Olonetsky 06 May '13

06 May '13

Hello Boost Users, I want to start using boost. The program below crashes for me in Release only. I am running in Visual studio 9.0 with icc 11.1. I compiled boost (1.53/1.52) with: >bootstrap.bat >b2 toolset=intel-11.1 ( + "-sINTEL_BASE_MSVC_TOOLSET=vc-9_0") #include <boost/thread/thread.hpp> void change_count() {} int main(int, char*[]) { boost::thread thread_1(change_count); thread_1.join(); return 0; } Thank you very much, Svetlana

3 8

[Boost.AutoBuffer] discussion
by John M. Dlugosz 06 May '13

06 May '13

> I recall some "detail" code in Boost that does exactly what I want: > allocate a probably-good-enough size on the stack but switch to heap if > needed. But I can't remember where I saw it. > > Looking around, I came across mentions of Boost.AutoBuffer by Thorsten > Ottosen, but all links are dead. >> I have been a bit busy, but I plan to get it going soon. >> >> It seems that there is an unofficial version in >> >> boost/signals2/auto_buffer.hpp >> >> regards >> >> -Thorsten Thanks. I found that copy, and it had your name on it too, so I figure it must be the same code. I like the feature of making an "uninitialized" expansion, too. In particular, for dealing with "out" parameters of OS API calls or legacy code, I want to naturally give my buffer as a vector.data(). But it is annoying to me that it needs to zero out the whole buffer just to pass it to code that is expecting uninitialized area for output, anyway. Making "uninitialized" part of this class is natural since the hopefull stack space is used in the same context. And being your own brand new class, it doesn't fiddle with any standard library code to achieve it. <g>. However, I think the existing public API could be improved a little in this manner. Here is what I ended up doing: auto_buffer<wchar_t> buf; buf.uninitialized_grow (buf.capacity()); // start out with as much as fits on the stack (256 elements). int result= ::GetWindowTextW(hWnd,buf.data(),buf.size()); I had to figure out that capacity was the correct way to get the stack-based size, but that's a documentation thing. I called uninitialized_grow rather than uninitialized_resize because I know it was originally zero; the passing of the delta which looks like the new size too bothers me a little. But my real point is that I can't command an uninitialized size on the constructor. The normal constructor arguments work the same as vector, and can take an initial size and a value that defaults to T(). It would be much clearer and simpler for this use case to say what I want directly on the constructor. I think it would be natural to give a special flag where the value would normally go: auto_buffer<whcar_t> buf1 (500 /*count*/, L' ' /* value */); // same as std::vector auto_buffer<wchar_t> buf2 (500, non_initialized); // looks like a "value", but overloaded ctor. and it would be unambiguous to give the non_initialized flag alone, taking the maximum pre-allocated size. auto_buffer<wchar_t> buf3 (non_initialized); And, as a further trick, it is a cheap failsafe to initialize just the last element with a sentinel value. This is not as inefficient as needlessly initializing the whole buffer, but adds a cheap fallback just in case the call that was supposed to write to the buffer didn't to anything. auto_buffer<wchar_t> buf4 (non_initialized, L'\0'); // the last index is set to zero In general, any signature that takes a T after the special non_initialized_t takes it to be a sentinal initialization, and two such arguments are for last and first index (only). Or, since the same value ought to be used for both, maybe it always does first and last, or uses different special flag names for non_initialized-except-for... With the ctor signature it is clear what is being done, and I don't need to explicitly reference the stack-based size separately from the template argument that gives it. And, it generates simple direct code to set it up that way rather than setting it and changing it around again. I don't think the optimizer would figure out that capacity() at this point means the stack-based size, and then optimize out the large case from the resize code! Meanwhile, should the class support uninitialized sizing ONLY for types that support it? That is, PODs, primitives, classes without destructors, and in general those that are marked as such via a metaprogramming type trait.

2 1

Boost under Linux, invoking bootstrap
by Edward Diener 06 May '13

06 May '13

I am trying to get started using Boost under Linux in order to test my TTI library using the latest trunk. So first I try using bootstrap with: ./bootstrap.sh --prefix=~/bin It completes succesfully but nothing is put in my home bin subdirectory. Did I do something wrong ? Invoking ./b2 --help does seem to work.

4 6

fusion io problem
by Olaf Peter 05 May '13

05 May '13

Hello, I run into the problem to provide ostream operator<< support for spirit's debug facility and for lazyness using fusion's io support: ---8<--- #include <boost/fusion/include/adapt_struct.hpp> #include <boost/fusion/include/io.hpp> #include <iostream> namespace fusion = boost::fusion; namespace client { struct point { int x,y; }; template<typename CharT> std::basic_ostream<CharT>& operator<<(std::basic_ostream<CharT>& os, point const& p) { os << p; return os; } struct arc { int radius; point begin; point end; }; template<typename CharT> std::basic_ostream<CharT>& operator<<(std::basic_ostream<CharT>& os, arc const& a) { os << a; return os; } } BOOST_FUSION_ADAPT_STRUCT( client::point, (int, x) (int, y) ) BOOST_FUSION_ADAPT_STRUCT( client::arc, (int, radius) (client::point, begin) (client::point, end) ) int main() { client::arc arc; std::cout << arc << '\n'; } --->8--- This program crashs, I would assume operator<<(..., arc) calls infinity recursive fusion's operator<< or similar - that's what I would interpret from gdb's backtrace. How to prevent this? I don't like to investigate much effort of formatting to supporting spirit's debug support and conventional debugging by tracing the selective printed output (like printf debugging) since there is support for formatted output of fusion sequences. Thanks, Olaf

2 2

Call for Papers - Meeting C++ 2013
by Jens Weller 05 May '13

05 May '13

1 0