May 2011 - Boost-users - lists.boost.org

Re: [Boost-users] [unordered_map] Trying to understand some errors
by Craig Longman 04 May '11

04 May '11

On 03/05/2011 4:59 PM, Nat Goodspeed wrote: > > unordered_map< string, uint32_t> xrf1; > > unordered_map< string, uint32_t>::const_iterator& iter = xrf1.find( "hello" ); > > > > This code makes me shudder. Capturing the value returned from a function with a reference variable asserts > that the function is itself returning a reference, not a value - and always will, for the life of the codebase. > > This is far more general than iterators. > > My rule of thumb is: return by value, store returned data by value. Perhaps a bit dramatic, but you're quite right. =) And it is something I'm (normally) aware and careful of. Returning values is getting more and more acceptable as the optimizations get better and better. However, references do have their place, even in return values. I'm actually honestly not sure where I picked that up with iterators, but it worked and I guess it just kinda stuck. I try and use references over copies where appropriate, and as it seemed to work. I didn't think it through properly. > To answer your question, because xrf1 isn't const, its find() returns a non-const iterator. You're trying > to capture a reference to a const_iterator, which isn't what you have in hand. But, the confusion is if I replace unordered_map with std::map, it compiles fine. I guess that means in std::map a const_iterator is just that, a "const iterator", but in unordered_map, the const_iterator is a completely different type, not just a const version of the normal iterator? I was under the impression that const could and would always be implicitly applied if needed, just not the other way round (obviously). Time to dig through some header files I guess. Thanks, -- Craig Longman If it's not *signed* by me, then please don't assume it *is* from me.

2 1

[Spirit] Generating from struct containing single std::vector member
by Vitaly Budovski 04 May '11

04 May '11

Hi, When generating from a struct containing a single std::vector member, +parser or *parser results in an error. If, however, it is followed by an eps, it succeeds. Is this expected behaviour? Please see attached code demonstrating issue.

2 1

Thread Safety of shared_ptr
by Kevin Frey 04 May '11

04 May '11

Hello, I wish to clarify a point on the thread-safety of shared_ptr. I have read the boost documentation on shared_ptr concerning Thread-Safety and amongst other things it gives this example (see http://www.boost.org/doc/libs/1_46_1/libs/smart_ptr/shared_ptr.htm for the full set of examples): shared_ptr<int> p(new int(42)); //--- Example 1 --- // thread A shared_ptr<int> p2(p); // reads p // thread B shared_ptr<int> p3(p); // OK, multiple reads are safe <snip...> //--- Example 4 --- // thread A p3 = p2; // reads p2, writes p3 // thread B // p2 goes out of scope: undefined, the destructor is considered a "write access" Given the nature of how the examples are presented, I have nonetheless presumed the examples are largely independent of one another, as opposed to each example being dependent on the results of the previous example. The specific question I have concerns the implications of the phrase "p2 goes out of scope". I have a situation where I have a shared_ptr< Session > which is initially created by thread A. Many such objects in fact. A separate thread B cleans up periodically (the exact scenario is a .NET finaliser interfacing to native C++ code). It is therefore entirely possible for the following two actions to happen simultaneously: - Thread A is instantiating a new copy of shared_ptr< Session >, copied from an existing shared_ptr< Session >. - Thread B is destroying a shared_ptr< Session >. The above shared_ptrs are all referencing the same reference-counting object. I do not actually know which shared_ptr will be the one that actually destroys the underlying Session object (which is the whole point of me using shared_ptr as my cleanup ends up being non-deterministic with respect to sequence). Example 4 is very important to me in terms of me understanding exactly what limitation they are describing. My possible interpretations are: 1. p2 goes out of scope under any circumstance. Doesn't matter if the shared_count is 1 or > 1 prior to the object going out of scope. 2. p2 goes out of scope, resulting in destruction of the underlying object. In my interpretation of the example, when p2 goes out of scope, it will not result in destruction of the object, because p2 is a copy of p, and p is [presumably] still in scope. The outcome should merely be a decrementing of the reference count. So I'm also at a bit of a loss to understand why an incrementing of a reference count is not considered a "write access" but a potential simple decrementing of a reference count (occurring via the shared_ptr destructor) is considered a "write access". In my example I know I will never have thread A attempting to increment the ref count whilst thread B is potentially destroying the object simultaneously. When I get to my final copy of my object (ie. unique( ) is true), thread A is guaranteed to not be accessing or copying the shared_ptr when thread B commences the destruction of the final copy. Will shared_ptr behave correctly or not in my situation? Because if I take the boost example on simple face value, that I cannot have one shared_ptr going out of scope (and decrementing the ref count) whilst another thread is incrementing the ref count, then I'm feeling at a loss why boost would go to the trouble of a lock-free implementation in the first-place, since I would have thought my example is a pretty common (almost canonical) of why you would want thread-safety for shared_ptr. Now I'll be the first to admit that the boost guys are a lot smarter than me, so I'm hoping my understanding of the capability is simply wrong. (The problem for me is that if shared_ptr does not provide the thread-safety requirements I need, then I must achieve that thread-safety external to shared_ptr with some kind of mutex, which puts me in a conundrum as to where such a mutex would be held. The obvious place would be my Session object since it provides the perfect granularity, but then I have the situation of having an object, which might potentially get deleted [when the last shared_ptr is destroyed], having a mutex referenced within it for the purpose of locking, which is clearly wrong.) Any help will be greatly appreciated. Thanks Kevin

7 15

distributed breadth first search doesn't work properly?
by Mattia Lambertini 04 May '11

04 May '11

Hi, i am new to boost and i'm using the PBGL to write a software that compute some graph analysis. I've installed boost 1.44.0 and openmpi 1.5 I tried to run the breadth first search example located in $BOOST_ROOT/libs/graph_parallel/example with the graph $BOOST_ROOT/libs/graph/test/weighted_graph.gr All went well since i figure out that the result is different if i run the algorithm with a different number of processors. Only with one processor the values are corrected. here's what happens: mpirun -np 1 ./breadth_first_search.out graph g { subgraph cluster_0 { label="p0"; n0[label=0]; n1[label=2]; n2[label=1]; n3[label=2]; n4[label=1]; } n0 -- n2; n1 -- n1; n1 -- n3; n1 -- n4; n2 -- n1; n2 -- n3; n3 -- n4; n4 -- n0; n4 -- n1; } --------------------- mpirun -np 2 ./breadth_first_search.out graph g { subgraph cluster_0 { label="p0"; n0[label=0]; n1[label=1]; n2[label=1]; } n0 -- n2; n1 -- n1; n1 -- n3; n1 -- n4; n2 -- n1; n2 -- n3; subgraph cluster_1 { label="p1"; n3[label=1]; n4[label=0]; } n3 -- n4; n4 -- n0; n4 -- n1; } Is that correct? From the doc i can't figure out why.. -- Cordiali saluti, Mattia Lambertini

2 11

[PBGL] Results of distributed BFS on multiple processors vs. on a single processor
by Cedric Laczny 04 May '11

04 May '11

Hi, it recently came to my mind again that the distributed BFS in the PBGL seems to produce different results when applied to multiple processors as to when applied to a single processor (s. http://lists.boost.org/boost- users/2010/12/64783.php) If this is true, I really would like to know what the reasoning is behind this and it should be noted in the documentation of course to help prevent surprises as in the discussion above. Unfortunately, at that time, no definite answer was given and this question puzzled me again now... Any ideas on that? Best, Cedric

3 6

How to get current state from state machine?
by jusva2010 03 May '11

03 May '11

Hi All, How can I get the current state of the state machine? Currently i am getting in this way.. i would like to know if there any better way statemachine --------------- struct StateMachine:sc::state_machine<StateMachine, Initial> { void setState(string s){ state = s; } string getState() { return state; } private: string state; } //event struct dummyEvent:sc::event<dummyEvent> { } //state struct Initial:sc::simple_state<Initial, StateMachine> { typedef mpl::list<sc::custom_reactions<dummyEvent>> reactions; sc::result react(const dummyEvent&); } In react function of the 'Initial' state sc::result Initial::react(const dummyEvent&) { context <StateMachine>().setState("Initial"); } In my main main() { StateMachine machine; machine.initiate() cout << "Current State "<< machine.getState() << endl; // return me the current state } Thanks in adavance justin ----- justin -- View this message in context: http://boost.2283326.n4.nabble.com/How-to-get-current-state-from-state-mach… Sent from the Boost - Users mailing list archive at Nabble.com.

1 0

BOOST_USE_WINDOWS_H and atomic ops in shared_ptr
by Joseph Lunderville 03 May '11

03 May '11

I've been trying to purge windows.h includes from a project that uses Boost, but I see compile errors when I don't define BOOST_USE_WINDOWS_H (the included prototypes don't match prototypes defined elsewhere). This is building Boost 1.42.0 in VS2010. Is this a known issue? Is it known to be fixed in a more current version? Am I doing something wrong? I worked around the problem by creating an alternate set of #defines for the atomic ops, and including <intrin.h> instead (controlled via a new BOOST_USE_INTRIN_H macro). I can supply a patch if this sounds like a reasonable thing to do. -Joe ________________________________ This message, including any attachments, may contain privileged and/or confidential information. Any distribution or use of this email by anyone other than the intended recipient(s) is strictly prohibited. If you are not the intended recipient, please notify the sender immediately and delete all copies. Thank you.

1 0

weird Link error with XCode 4
by Kumar, Akhilesh 03 May '11

03 May '11

Hi, I am having weird link error during the release build details give below, I was having some problem with the Debug build also but after playing with "InlineMethodHidden and SymbolhiddenbyDefault" flag I was able to build in Debug config, but this trick does not work in Release config. I addition to boost library I am also using JsonSpirit library. Though I have manually copied 10.5 SDK to support 10.5 system but using 10.6 SDK also result in similar looking link error. Boost and Json Spirit was compiled with 3.2 version of Xcode. This code compile and run perfectly fine in Xcode 3.2. Any pointer will be appreciated. Link Error ************** ld: bad codegen, pointer diff in void (anonymous namespace)::throw_error<boost::spirit::classic::multi_pass<std::istream_iterator<wchar_t, wchar_t, std::char_traits<wchar_t>, int>, boost::spirit::classic::multi_pass_policies::input_iterator, boost::spirit::classic::multi_pass_policies::ref_counted, boost::spirit::classic::multi_pass_policies::buf_id_check, boost::spirit::classic::multi_pass_policies::std_deque> >(boost::spirit::classic::multi_pass<std::istream_iterator<wchar_t, wchar_t, std::char_traits<wchar_t>, int>, boost::spirit::classic::multi_pass_policies::input_iterator, boost::spirit::classic::multi_pass_policies::ref_counted, boost::spirit::classic::multi_pass_policies::buf_id_check, boost::spirit::classic::multi_pass_policies::std_deque>, std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)to global weak symbol typeinfo for std::basic_string<char, std::char_traits<char>, std::allocator<char> >for architecture i386 Command /Developer/usr/bin/g++-4.2 failed with exit code 1 GenerateDSYMFile build/Release/libSariManager.dylib.dSYM build/Release/libSariManager.dylib cd /Users/Shared/P4/code/client /Developer/usr/bin/dsymutil /Users/Shared/P4/code/client/build/Release/libSariManager.dylib -o /Users/Shared/P4/code/client/build/Release/libSariManager.dylib.dSYM error: unable to open executable '/Users/Shared/P4/code/client/build/Release/libSariManager.dylib' Akhilesh Kumar

1 0

[msm] EUML and State construction
by Nate Knight 03 May '11

03 May '11

I'm trying to construct some euml states with data at the time of the state machine construction. The below boils down what I'm trying to do and fails to compile. Should I expect this mechanism to work with the euml frontend ? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #include <boost/msm/back/state_machine.hpp> #include <boost/msm/front/euml/euml.hpp> namespace msm = boost::msm; using namespace msm::front::euml; BOOST_MSM_EUML_EVENT(test_event) BOOST_MSM_EUML_DECLARE_STATE((),test_state_t) struct test_state_with_constructor : public test_state_t { test_state_with_constructor() {} test_state_with_constructor(int d) : m_d(d) {} int m_d; }; test_state_with_constructor const test_state; BOOST_MSM_EUML_TRANSITION_TABLE(( test_state + test_event == test_state ), test_table) BOOST_MSM_EUML_DECLARE_STATE_MACHINE (( test_table, init_ << test_state ), test_table_) typedef msm::back::state_machine<test_table_> test_machine_t; int main() { test_machine_t tm( msm::back::states_ << test_state_with_constructor(1) ); } ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ With gcc 4.5 and Boost 1.46.1, I get: simpletest.cpp: In function 'int main()': simpletest.cpp:30:75: error: no match for 'operator<<' in 'boost::msm::back::states_ << test_state_with_constructor(1)' Thanks Nate

1 0

[serialization] pointer to non-constructable object
by Noah Roberts 03 May '11

03 May '11

The problem boils down to something similar to: struct base { virtual ~base() {} base(x_type & obj); }; struct derived { derived() : base(member_x) {} private: x_type member_x; }; ...serialize(...,base &,....) {} ...serialize(..., derived & d, ....) { ar & base_object<base>(d); ar & member_x; } boost::shared_ptr<base> ptr(new derived); ar & ptr; The problem is that base can't be constructed without the reference. It also makes no sense to override the construction stuff because it's simply not how to get that reference. There's no way to construct a base that is sensible outside of during the construction of its derived (it's a funky design I admit, but necessary). Unfortunately the serialization library insists on being able to construct a base, even though I never save one except via derived objects through a pointer to base. I noticed a check for "is_abstract" when debugging a different issue I had (that was totally my fault). So I tried adding a bogus virtual function to the interface and overriding it in derived. This fixes the problem. There must be a way to do so without such trickery though? Can this abstract check be overridden by me?

1 0