- Boost-users - lists.boost.org

how to use boost::shared_ptr?
by young 01 Feb '13

01 Feb '13

I have a class member (boost::shared_ptr): class XYZ { private: boost::shared_ptr<int> m_pBuff; // other member ... public: void func(int n) { m_pBuff.reset(new int[n]); // or m_pBuff = boost::shared_ptr<int>(new int[n]) ...; } // other functions ... } The func(n) will be called many times inside / outside the class. Can I use shared_ptr here like: m_pBuff.reset(new int[n]); or m_pBuff = boost::shared_ptr<int>(new int[n]); I tried both and get error said heap corruption. -- View this message in context: http://boost.2283326.n4.nabble.com/how-to-use-boost-shared-ptr-tp4642120.ht… Sent from the Boost - Users mailing list archive at Nabble.com.

4 6

Re: [Boost-users] [Graph] visitor dijkstra_shortest_paths
by The Maschine 01 Feb '13

01 Feb '13

Thanks a lot, even though I read half of the BGL book I didnt get this difference. I cant say Im good with techniques like that. Best, Tasos > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 31 Jan 2013 11:12:29 -0500 (EST) > From: Jeremiah Willcock <jewillco(a)osl.iu.edu> > To: boost-users(a)lists.boost.org > Subject: Re: [Boost-users] [Graph] visitor dijkstra_shortest_paths > Message-ID: <alpine.LRH.2.03.1301311111140.64740(a)cs.indiana.edu> > Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" > > On Thu, 31 Jan 2013, The Maschine wrote: > > > > > Hi all, > > > > > > Can someone explain me why I get an error with the first one and not the > second? > > > > > > 1) > (error)?boost::dijkstra_shortest_paths(m_ugraph,*vertex_iterator_begin,? ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > > ?boost::distance_map(boost::make_iterator_property_map(dist_map.begin(), > boost::get(boost::vertex_index, > > m_ugraph))), > > > > boost::visitor(dijkstra_vis( *vertex_iterator_begin, superStorage ) )); > > The syntax for named parameters in Boost.Graph requires periods, so all > named arguments show up as a single argument to C++. > > > 2) > (good)?boost::dijkstra_shortest_paths(m_ugraph,*vertex_iterator_begin,? ? ? > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > > ?boost::distance_map(boost::make_iterator_property_map(dist_map.begin(), > boost::get(boost::vertex_index, > > m_ugraph))).visitor(dijkstra_vis( *vertex_iterator_begin, superStorage > ))?); > > > > > > > > Why I need to "." the visitor on the distance_map? > > That's how it was implemented (before Boost.Parameter or variadic > templates existed). > > > > > > > BFS is ok with it: > > > > (good) boost::breadth_first_search(m_ugraph, *vertex_iterator_begin , > boost::visitor(bfs_vis( > > *vertex_iterator_begin, superStorage ) )); > > You only have one named argument there; if you had more, you would need to > use a period between those as well. > > -- Jeremiah Willcock > >

1 0

[Graph] visitor dijkstra_shortest_paths
by The Maschine 31 Jan '13

31 Jan '13

Hi all, Can someone explain me why I get an error with the first one and not the second? 1) (error) boost::dijkstra_shortest_paths(m_ugraph,*vertex_iterator_begin, boost::distance_map(boost::make_iterator_property_map(dist_map.begin(), boost::get(boost::vertex_index, m_ugraph))), boost::visitor(dijkstra_vis( *vertex_iterator_begin, superStorage ) )); 2) (good) boost::dijkstra_shortest_paths(m_ugraph,*vertex_iterator_begin, boost::distance_map(boost:: make_iterator_property_map(dist_map.begin(), boost::get(boost::vertex_index, m_ugraph))).visitor(dijkstra_vis( *vertex_iterator_begin, superStorage )) ); Why I need to "." the visitor on the distance_map? BFS is ok with it: (good) boost::breadth_first_search(m_ugraph, *vertex_iterator_begin , boost ::visitor(bfs_vis( *vertex_iterator_begin, superStorage ) )); Best, Tasos

2 1

[Fusion] Why restrict 'copy' to equal sizes?
by TONGARI 31 Jan '13

31 Jan '13

Hi, As the counterpart of STL copy, I expected the src just need to be <= dst, but it requires equal sizes in Fusion. What's the rationale? Is it OK to loosen the restriction? (it just compiles if I change '==' to '<=') Thanks.

2 3

How to build boost out-of-tree?
by Keitel, Tino (ALC NetworX GmbH) 31 Jan '13

31 Jan '13

Hi, I want to build boost out-of-tree. Usually, this is done like this: $ mkdir /path/to/build $ cd /path/to/build $ /path/to/source/configure $ make The actual source is not modified, all output is written in the build directory. The best I could find was http://www.boost.org/doc/libs/1_52_0/more/getting_started/unix-variants.htm…, but the bootstrap.sh step will still modify the source directory. How can I do a real out-of-tree build of boost? Regards, Tino

1 0

boost linkage problem
by Dave Dyer 30 Jan '13

30 Jan '13

I'm trying to construct a small library of wrappers for boost-using functions. In my test environment that links with this library (a windows executable) everything is fine. The working environment doesn't name any libraries explicitly. In another environment (the one I'm actually interested in) I get a large number of linkage errors, apparently seeking libstdc++ A small sample: 1>sharedmem-debug-x64.lib(sharedmemory.obj) : warning LNK4217: locally defined symbol ??1?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QEAA@XZ (public: __cdecl std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::~basic_string<char,struct std::char_traits<char>,class std::allocator<char> >(void)) imported in function "public: static bool __cdecl boost::interprocess::shared_memory_object::remove(char const *)" (?remove@shared_memory_object@interprocess@boost@@SA_NPEBD@Z) 1>sharedmem-debug-x64.lib(sharedmemory.obj) : warning LNK4217: locally defined symbol ?c_str@?$basic_string@DU?$char_traits@D@std@@V?$allocator@D@2@@std@@QEBAPEBDXZ (public: char const * __cdecl std::basic_string<char,struct std::char_traits<char>,class std::allocator<char> >::c_str(void)const ) imported in function "public: static bool __cdecl boost::interprocess::shared_memory_object::remove(charconst *)" (?remove@shared_memory_object@interprocess@boost@@SA_NPEBD@Z) The non-working link is a complex environment, but I'm stumped why it doesn't link, or how to get it to link.

1 0

[phoenix] segmentation fault with valarray
by Philipp Schwaha 30 Jan '13

30 Jan '13

Hi all! I have worked with phoenix together with valarray and am currently stumbling over a case of segmentation fault. I construct the following phoenix expression boost::phoenix::at_c<0>(arg1) += boost::phoenix::at_c<1>(arg1) / val(mass) * arg2 I then feed a std::tuple<std::valarray<double>, std::valarray<double>> to it. It compiles nicely with gcc (4.6 & 4.7) using boost 1.52 as well as trunk. The resulting executable then proceeds to segfault, however. I have put together a small example (c++11) demonstrating my problem. The valarray's memory should already be reserved from original initialization. Performing the same operations manually with just the valarray not in phoenix seems to work fine. Am I missing something or doing something stupid here? thanks for any help! cheers Philipp

3 4

[threadpool] from your experience, is it safe to use threadpool with recent boost release?
by Frédéric Bron 30 Jan '13

30 Jan '13

Dear community, I found the threadpool library very useful (http://threadpool.sourceforge.net/) Apparently, it was designed for boost 1.37.0 and seemed to target inclusion in boost but probably did never go to a review because its author had not enough time to meet all requirements for boost inclusion, in particular, documentation. However, it is ready to be used with boost as is can just be untared in the boost include directory. I have tried to use it with boost 1.51.0 and it seems to work nicely. Before using it for long term projects, I was wondering if some of you use this library with success together with a rather recent boost release? Do you experience any issue or everything is just fine. Any chance that the latest changes in the thread library (http://thread.gmane.org/gmane.comp.lib.boost.devel/237484) would impact threadpool? Regards, Frédéric

4 6

hey
by Hossein Haeri 30 Jan '13

30 Jan '13

hey have a look http://www.com-im5.net/finance/ Hossein

1 0

[boost 1.47] boost::interprocess::scoped_lock<boost::interprocess::named_recursive_mutex> and fork() (linux)
by Frank Bergemann 30 Jan '13

30 Jan '13

Hello, i have a problem with boost::interprocess::scoped_lock<boost::interprocess::named_recursive_mutex> and using that one recursively in a unix (linux) fork() process environment. I.e. I create the boost::interprocess::named_recursive_mutex in a root process, then fork a number of child processes and those synchronize each other via boost::interprocess::scoped_lock<boost::interprocess::named_recursive_mutex>. When i use the named_recursive_mutex in a recursive way, the 2nd instance of the scoped_lock<> of it hangs (for one of the children, the first one, which tries to do a recursive lock.) I didn't have an issue without recursions (before i just used named_mutex - but i need to protect an application level region on a higher level now). And i didn't have a problem with a test program that does NOT fork(), which i start #10 instances on linux in parallel, and which also uses nested scoped_lock<>'s for each of them. Does anybody know about issue of boost::interprocess::named_recursive_mutex or boost::interprocess::scoped_lock<boost::interprocess::named_recursive_mutex> for unix/linux fork()? Do i have to create my named_recursive_mutex AFTER the fork() for each process instance? (i use m_mutex = boost::interprocess::named_recursive_mutex(boost::interprocess::open_or_create, _shmId.c_str())). I read about this here: http://www.linuxprogrammingblog.com/threads-and-fork-think-twice-before-usi… It talks about need to call |pthread_mutex_init()|. Other pages seems to indicate, that there is only a problem, when i lock a mutex and then fork(), inheriting the lock to parent and child process. - many thanks! best regards, Frank

1 0