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

Server failing when BOOST_ASIO_ENABLE_HANDLER_TRACKING is active
by Gonzalo Garramuno 22 Jan '14

22 Jan '14

Trying to track down when the socket closes on my program, I turned on asio debugging. Server fails when BOOST_ASIO_ENABLE_HANDLER_TRACKING is active. Its stack trace is: g Scanning dependencies of target mrViewer [ 9%] Building CXX object mrViewer/src/CMakeFiles/mrViewer.dir/core/mrvServer.o Linking CXX executable ../../../bin/mrViewer [100%] Built target mrViewer # gga@gga-laptop1 /media/Linux/code/applications/mrViewer # mar ene 01 10:04 [8] $ mrViewer /media/Linux/movies/Tangled.mov [opengl] Using hardware shader profile: NVidia NV30 [opengl] mrViewer supports YUV images through shaders. [psql] Connected to database 'assets2d_development'. The code: boost::asio::io_service io_service; tcp::endpoint listen_endpoint(tcp::v4(), s->port); server rp(io_service, listen_endpoint, s->ui); io_service.run(); fails with: @asio|1357088683.200673|0|socket@0x7f303d8d2d00.close Got signal 11, faulty address is 0x1, from 0x4d222a [bt] Execution path: [bt] mrViewer(_ZN5boost4asio6detail15task_io_service16shutdown_serviceEv+0x3a) [0x4d222a] [bt] mrViewer(_ZN5boost4asio6detail15task_io_service16shutdown_serviceEv+0x3a) [0x4d222a] [bt] mrViewer() [0x4dd2c9] [bt] mrViewer(_ZN3mrv13server_threadEPKNS_10ServerDataE+0x408) [0x4e0e58] [bt] /usr/lib/libboost_thread.so.1.48.0(+0xdda9) [0x7f304e191da9] [bt] /lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a) [0x7f304f7f0e9a] [bt] /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d) [0x7f304da1ccbd] without the #define the code works reliably except sometimes the socket closes unexpectedly.

4 5

Re: [Boost-users] Interprocess: rbtree_best_fit ABI change from 1.53 to 1.55 ?
by Arunski, Kevin 22 Jan '14

22 Jan '14

> El 22/01/2014 16:14, Arunski, Kevin escribió: > > Hello, I have been using a boost::interprocess::map stored in a > > managed mapped file segment, using the rb_best_fit allocation > > algorithm. > > > > I have observed that starting in boost 1.55, I cannot interoperate > > with instances of this allocator that were created by programs > > compiled by boost 1.53. > > > > It appears that the size of a boost::intrusive multiset object has > > changed, and this changes the representation of the rb_best_fit > > algorithm within the shared memory region. > > Sorry about that. That must be a bug. Can you tell me please the sizes > you get in both versions? Sure. In code compiled with boost 1.53, this type: boost::interprocess::rbtree_best_fit<boost::interprocess::null_mutex_family,boost::interprocess::offset_ptr<void,__int64,unsigned __int64,0>,0> has size = 56 member m_header.m_imultiset has size 32 In code compiled with boost 1.55: the same type has size = 72 member m_header.m_imultiset has size 48

2 1

Interprocess: rbtree_best_fit ABI change from 1.53 to 1.55 ?
by Arunski, Kevin 22 Jan '14

22 Jan '14

Hello, I have been using a boost::interprocess::map stored in a managed mapped file segment, using the rb_best_fit allocation algorithm. I have observed that starting in boost 1.55, I cannot interoperate with instances of this allocator that were created by programs compiled by boost 1.53. It appears that the size of a boost::intrusive multiset object has changed, and this changes the representation of the rb_best_fit algorithm within the shared memory region. The toolchain is unchanged between the two programs, in both cases it is Visual Studio 2012 on x64, linked against the release runtime library. The only change is that one was compiled using boost 1.53, while the other was compiled with boost 1.55. Is this the expected behavior? Is there a way to utilize boost interprocess in this way with reasonable certainty that the shared memory representation of it will not change between boost releases?

2 1

vector clock
by Kenneth Adam Miller 22 Jan '14

22 Jan '14

Does boost have either a vector clock or lamport clock of any kind?

2 1

boost multiprecision & STL map - resubmit
by tridiak＠ihug.co.nz 21 Jan '14

21 Jan '14

Ok. Better framed question. The following is compiled on XCode 5.0.1. Clang : Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn) Target: x86_64-apple-darwin12.5.0 Thread model: posix Boost v 1.55.0. Build 2.0-m12. Not sure how to fix it. map complains about constructor ambiguity and I am not sure how to fix it. I am a casual hobbyist programmer and not a C++ expert. Looking at boost headers confuses me. Any help would be appreciated. //--------------------------------------------------------------------- Header File #ifndef boostTest_test_h #define boostTest_test_h #include #include #include using namespace boost::multiprecision; typedef std::map TestMap; #endif //------------------------------------------------------------------------- C++ file #include #include "test.h" int main(int argc, const char * argv[]) { static TestMap tm; std::string s="hello"; int128_t n=128; tm[n]=s;

3 2

odeint - solving an ODE with time-dependent parameter numerically
by Arijit Hazra 21 Jan '14

21 Jan '14

Hello All, I am trying to solve an ode with time-dependent parameters by using boost. I have just started using boost and I think boost library's odeint library is the best option for my problem. Would anyone please explain me how I can solve a Initial Value Problem --a system of ODE --with a time-dependent parameter. e.g. dy1/dt = a1(t) * y2 -b1(t)* y3 -c1(t) y1; dy2/dt = a2(t) * y1 -b2(t)* y1 -c2(t) y3; dy3/dt = a3(t) * y2 -b3(t)* y3 -c3(t) y1; y(0)=c; My idea so far after going through the manuals and help files. is that for fixed time-step if I form a vector of a,b,c and assume a,b,c to be constant over that time-period I can solve using boost library. But this is mathematically less accurate and computationally expensive as far my understanding .For solving an ODE numerically *y*˙(*t*)=*f*(*y*(*t*), *t*) generally the problem is all about function evaluation for explicit methods and Jacobian evaluation for Implicit methods at specific points in *t* and *y*. e.g a step of explicit Euler is *yn*+1=*yn*+(*tn*+1−*tn*)⋅*f*(*yn*,*tn*). For time-dependent parameter, treating it as part of *f*, the function evaluation (respectively, for implicit methods, also treat it as part of the Jacobian evaluation) is the standard procedure. A similar strategy applies to more complicated methods for solving ODEs (multistage methods such as Runge-Kutta, implicit methods for stiff systems, etc.). This strategy is different and mathematically more accurate than assuming parameters are constant over a time step like a multistage method. Would anyone please help me to solve this problem using boost? Thank you in advance. With Best Regards, Arijit Hazra

4 4

Sort boost composite container
by Uthpal Urubail 21 Jan '14

21 Jan '14

I am having below composite container. I am looking to sort the container by member<CA,std::string,&CA::card> at the end. Can some one help me to achieve this? typedef multi_index_container< CA, indexed_by< ordered_unique< composite_key< CA, member<CA,std::string,&CA::name>, member<CA,std::string,&CA::displayName>, member<CA,std::string,&CA::card> > > > > duplicateBook; Regards, UJ

3 2

[BGL] A* implementation
by Knut Krause 21 Jan '14

21 Jan '14

Hi, I'm still considering to use the BGL for my large scale path finding problem. Sadly I don't fully understand the implementation of A* used in boost. Does it use optimizations like bidirectional A* and so on or can I activate those somehow? I think otherwise I'd have to implement my own version of A*. Regards Knut

1 0

Help regarding how to start
by Mihir Thakkar 21 Jan '14

21 Jan '14

I was having a look at the To-Do list & Challenges of BGL. I found few of them already implemented. I would like to contribute, I would appreciate if someone can help from where to find the things which are not yet implemented, (like if boost has an updated To-Do list) I am interested in GUI, mathematics and general algorithms. Thanks!

1 0

Cross compiling boost Windows -> Arm
by Marius Adrian DOBRESCU 21 Jan '14

21 Jan '14

Hello. I have a problem compiling boost with arm-none-linux-gnueabi-g++ on Windows. Shared library dependencies paths seems to be hard-coded with Windows paths: Example: build\bin.v2\libs\filesystem\build\gcc-arm\release\target-os-linux\threading-multi\... I tried to build with --prefix. Not working. Hardcode-dll-paths not working too. Tried to specify an explicit -rpath. The so shared libraries are compiled with hard-coded paths inside, with backslash \\\ and I cannot use them on linux-arm. On stage directory they are hard-coded too. Any idea how can I disable this behavior and what options should I pass to boost and where? I want simple libraries without full rpaths and the build must be done on Windows with gcc-gnueabi. Thanks. Adrian

2 3