- Boost-users - lists.boost.org

ASIO UDP Communication stops working when entering a thread
by Ulf Samuelsson 25 Sep '13

25 Sep '13

Have created a class to allow UDP communication using ASIO // Header class UdpClient { public: UdpClient(); void Open(string ipaddr, string port); void Send(string packet); void Close(); private: bool init; string ipAddress; string Port; udp::endpoint Endpoint; udp::socket *pSocket; udp::socket *s; }; // Part of code void UdpClient::Open(string ipaddr, string port) { ipAddress = ipaddr; Port = port; boost::asio::io_service io_service; udp::resolver resolver(io_service); udp::resolver::query query(udp::v4(), ipaddr,port); Endpoint = *resolver.resolve(query); pSocket = new udp::socket(io_service); pSocket->open(udp::v4()); pSocket->send_to(boost::asio::buffer(first.c_str(), first.size()), Endpoint); std::cout << "Opening port [" + Port + "] on " + ipAddress + "\n"; init = true; } void UdpClient::Send(string packet) { if (init) { pSocket->send_to(boost::asio::buffer(packet.c_str(), packet.size()), Endpoint); } } --------------- Another class implements more advanced communication. // Extracts extern UdpClient endpoint; void UdpDebug::WriteLine(string line) { line = "[" + Clock.Now() + "]" + line; endpoint.Send(line); }; ------------------------ In my main program i declare two global variables. UdpDebug DebugPort; UdpClient endpoint; The I init the UDP communication by calling endpoint.Open(IPAddress, UDPPort); after that I can write to the UDP enpoint by: DebugPort.WriteLine("Debug working!"); Have declared a thread: boost::thread t1(Initialize); void Initialize() { DebugPort.WriteLine("Debug working in the thread"); for (int i = 0; i < MAX; ++i) { wait(1); std::cout << "Thread 1: " << i << std::endl; } } When I do t1.join(); The thread starts printing out "Thread1: <number>" on the terminal but no UDP output is received on the other end. Any clues why this won't work? Are starting two threads, but only one of them is attempting UDP communication. If I put a wait statement inside the main program, and attempt UDP communication after the threads have executed a few seconds, this will still work. Also tried creating a new instance of UdpClient inside the thread. Opened it, and tried to send data, to no avail. Any clues? BR Ulf Samuelsson

1 1

How to solve __imp_Py_NoneStruct error in C++?
by Wenlong Wang 25 Sep '13

25 Sep '13

Hi, All I am trying to run Boost.Python in my IDE. Here is my tools: Microsoft Visual Studio 2012 Express Version (64-bit), Python 2.7 (64-bit), Boost 1.54, Windows7 64-bit. And my code is really simple. I created an empty project, and create a source.cpp as follows: #include <boost\python.hpp> #include <Python.h> using namespace std; void main() { return; } After debugging, an error pops out: "error LNK2001: unresolved external symbol __imp___Py_NoneStruct" May I know where am I wrong? Regards Wenlong Wang Risk Analyst, Capquest Group Ltd Email: wwang(a)capquest.co.uk Fleet 27, Rye Close, Fleet, GU51 2QQ. Website: http://www.capquest.co.uk/ This e-mail is intended solely for the addressee, is strictly confidential and may also be legally privileged. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. E-mail communications cannot be guaranteed to be secure or error free, as information could be intercepted, corrupted, amended, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept liability for any such matters or their consequences. Anyone who communicates with us by e-mail is taken to accept the risks in doing so. Opinions, conclusions and other information in this e-mail and any attachments are solely those of the author and do not represent those of Capquest Group Limited or any of its subsidiaries unless otherwise stated. Capquest Group Limited (registered number 4936030), Capquest Debt Recovery Limited (registered number 3772278), Capquest Investments Limited (registered number 5245825), Capquest Asset Management Limited (registered number 5245829) and Capquest Mortgage Servicing Limited (registered number 05821008) are all limited companies registered in England and Wales with their registered offices at Fleet 27, Rye Close, Fleet, Hampshire, GU51 2QQ. Each company is a separate and independent legal entity. None of the companies have any liability for each other's acts or omissions. Group VAT registration number 844281719. Members of the Capquest group are regulated under the Consumer Credit Act 1974 and are members of the Credit Services Association. This communication is from the company named in the sender's details above.

1 0

BGL (Boost Graph Library) MaxWeightedMatching algorithm
by Pablo Madoery 25 Sep '13

25 Sep '13

Hello, i want to use an algorithm called MaxWeightedMatching : Edmond's blossom shrinking algorithm for calculating maximum weighted matching in general graphs. I note that there is an algorithm in BGL called 1. edmonds_maximum_cardinality_matching<http://www.boost.org/doc/libs/1_54_0/libs/graph/doc/maximum_matching.html> but this is not what I want. I need to take in count the weights. I would like to know if this algorithm can be taken in count in the next version of Boost or if you can tell me some advices to implement it using BGL. The MaxWeightedMatching algorithm is already implemented in LEMON library: http://www.loco.ic.unicamp.br/~msambinelli/lemon_doc/a00537.html. Thanks for your time.

2 1

linking to boost 1.54 w/ windows and visual studio 2013 RC
by Jarrett Chisholm 25 Sep '13

25 Sep '13

Hi all I'm trying to compile my project as a shared library using scons. I'm using Windows 7, and the Visual Studio 2013 RC. In the project, I'm using boost. The project compiles fine. However, when it tries to link, I get the following: /scons: warning: No version of Visual Studio compiler found - C/C++ compilers most likely not set correctly// // //scons: Reading SConscript files ...// //Compiling Glr// //scons: Reading SConscript files ...// //Parsing Shaders into header ShaderData.h// //Done parsing Shaders into header ShaderData.h// //scons: done reading SConscript files.// //scons: Building targets ...// //Using tempfile c:\users\jarrett\appdata\local\temp\tmpecwym3.lnk for command line:// //link /nologo /dll /out:build\glr.dll /implib:build\glr.lib /LIBPATH:build /LIBPATH:src /LIBPATH:C:\Users\Jarrett\projects\angelscript-sdk\angelscript\lib /LIBPATH:C:\Users\Jarrett\projects\sqlite3 /LIBPATH:C:\Users\Jarrett\projects\berkelium-win32\lib /LIBPATH:C:\Users\Jarrett\projects\SFML\lib "/LIBPATH:C:\Program Files\Assimp\lib\x86" "/LIBPATH:C:\Program Files (x86)\Boost\lib" /LIBPATH:C:\Users\Jarrett\projects\FreeImage\Dist "/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib" opengl32.lib glew32.lib berkelium.lib sfml-system.lib sfml-window.lib assimp.lib freeimage.lib libboost_log-vc120-mt-1_54.lib libboost_log_setup-vc120-mt-1_54.lib libboost_date_time-vc120-mt-1_54.lib libboost_thread-vc120-mt-1_54.lib libboost_wave-vc120-mt-1_54.lib libboost_regex-vc120-mt-1_54.lib libboost_filesystem-vc120-mt-1_54.lib libboost_system-vc120-mt-1_54.lib build\BasicSceneManager.obj build\BasicSceneNode.obj build\Camera.obj build\GlrProgram.obj build\GraphicsEngine.obj build\Light.obj build\Window.obj build\common\math\Math.obj build\common\io\File.obj build\BasicSceneManager.obj build\BasicSceneNode.obj build\Camera.obj build\GlrProgram.obj build\GraphicsEngine.obj build\Light.obj build\Window.obj build\exceptions\Exception.obj build\exceptions\FormatException.obj build\exceptions\GlException.obj build\exceptions\IoException.obj build\gui\CallbackParameter.obj build\gui\GUI.obj build\gui\GUIObject.obj build\gui\HtmlGuiComponent.obj build\models\Animation.obj build\models\AssImpLoader.obj build\models\Model.obj build\models\ModelLoader.obj build\models\ModelManager.obj build\glw\Animation.obj build\glw\AnimationManager.obj build\glw\Constants.obj build\glw\Material.obj build\glw\MaterialManager.obj build\glw\Mesh.obj build\glw\MeshManager.obj build\glw\OpenGlDevice.obj build\glw\Texture.obj build\glw\TextureManager.obj build\glw\shaders\CPreProcessor.obj build\glw\shaders\GlrParser.obj build\glw\shaders\GlrPreProcessor.obj build\glw\shaders\GlrShader.obj build\glw\shaders\GlrShaderProgram.obj build\glw\shaders\GlslShader.obj build\glw\shaders\GlslShaderProgram.obj build\glw\shaders\ShaderProgramManager.obj// //link @c:\users\jarrett\appdata\local\temp\tmpecwym3.lnk// //Using tempfile c:\users\jarrett\appdata\local\temp\tmpep9gzl.lnk for command line:// //link /nologo /dll /out:build\glr.dll /implib:build\glr.lib /LIBPATH:build /LIBPATH:src /LIBPATH:C:\Users\Jarrett\projects\angelscript-sdk\angelscript\lib /LIBPATH:C:\Users\Jarrett\projects\sqlite3 /LIBPATH:C:\Users\Jarrett\projects\berkelium-win32\lib /LIBPATH:C:\Users\Jarrett\projects\SFML\lib "/LIBPATH:C:\Program Files\Assimp\lib\x86" "/LIBPATH:C:\Program Files (x86)\Boost\lib" /LIBPATH:C:\Users\Jarrett\projects\FreeImage\Dist "/LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\lib" opengl32.lib glew32.lib berkelium.lib sfml-system.lib sfml-window.lib assimp.lib freeimage.lib libboost_log-vc120-mt-1_54.lib libboost_log_setup-vc120-mt-1_54.lib libboost_date_time-vc120-mt-1_54.lib libboost_thread-vc120-mt-1_54.lib libboost_wave-vc120-mt-1_54.lib libboost_regex-vc120-mt-1_54.lib libboost_filesystem-vc120-mt-1_54.lib libboost_system-vc120-mt-1_54.lib build\BasicSceneManager.obj build\BasicSceneNode.obj build\Camera.obj build\GlrProgram.obj build\GraphicsEngine.obj build\Light.obj build\Window.obj build\common\math\Math.obj build\common\io\File.obj build\BasicSceneManager.obj build\BasicSceneNode.obj build\Camera.obj build\GlrProgram.obj build\GraphicsEngine.obj build\Light.obj build\Window.obj build\exceptions\Exception.obj build\exceptions\FormatException.obj build\exceptions\GlException.obj build\exceptions\IoException.obj build\gui\CallbackParameter.obj build\gui\GUI.obj build\gui\GUIObject.obj build\gui\HtmlGuiComponent.obj build\models\Animation.obj build\models\AssImpLoader.obj build\models\Model.obj build\models\ModelLoader.obj build\models\ModelManager.obj build\glw\Animation.obj build\glw\AnimationManager.obj build\glw\Constants.obj build\glw\Material.obj build\glw\MaterialManager.obj build\glw\Mesh.obj build\glw\MeshManager.obj build\glw\OpenGlDevice.obj build\glw\Texture.obj build\glw\TextureManager.obj build\glw\shaders\CPreProcessor.obj build\glw\shaders\GlrParser.obj build\glw\shaders\GlrPreProcessor.obj build\glw\shaders\GlrShader.obj build\glw\shaders\GlrShaderProgram.obj build\glw\shaders\GlslShader.obj build\glw\shaders\GlslShaderProgram.obj build\glw\shaders\ShaderProgramManager.obj// //build\BasicSceneManager.obj : warning LNK4042: object specified more than once; extras ignored// //build\BasicSceneNode.obj : warning LNK4042: object specified more than once; extras ignored// //build\Camera.obj : warning LNK4042: object specified more than once; extras ignored// //build\GlrProgram.obj : warning LNK4042: object specified more than once; extras ignored// //build\GraphicsEngine.obj : warning LNK4042: object specified more than once; extras ignored// //build\Light.obj : warning LNK4042: object specified more than once; extras ignored// //build\Window.obj : warning LNK4042: object specified more than once; extras ignored// //LINK : fatal error LNK1104: cannot open file 'libboost_log-vc110-mt-1_54.lib'// //scons: building terminated because of errors.// //scons: *** [build/glr.dll] Error 1104/ I'm curious why it's trying to link to `libboost_log-vc110-mt-1_54.lib` instead of `libboost_log-vc120-mt-1_54.lib`, which is what I specified in the link command. Also, as far as I can tell, `vcxxx` is the compiler tag boost uses to tell what version of the compiler built the boost library...so it's almost like `scons` thinks boost was built using Visual Studio 2012, which would be `vc110`...I'm not sure. Any help is appreciated! Cheers Jarrett

4 5

How to correctly run Boost.Python?
by Wenlong Wang 25 Sep '13

25 Sep '13

Hi, All This is my first message at this mailing list, apologies first if I raised some simple question. I am using Microsoft Visual Studio 2012 Express Version, and Python 2.7. My boost version is 1.54.0. I followed the Boost Library instruction at http://www.boost.org/doc/libs/1_54_0/more/getting_started/windows.html#i nstall-boost-build And successfully build Boost in my computer with a message "The Boost C++ Libraries were successfully built!" My Boost path is "C:\local\boost_1_54_0" Then I want to run Boost.Python, and find it requires to be built separately. So, I found Boost.Python Library instructions at http://www.boost.org/doc/libs/1_54_0/libs/python/doc/building.html#basic -procedure In step 3.1 Basic Procedure, the Boost.Python Library instructions lead me back to Boost Library instruction section 5, at where I installed the Boost.Build at "C:\local\boost_1_54_0\BoostBuild". And "C:\local\boost_1_54_0\BoostBuild\bin" has been added to my Path environment variable. So now I am back to the Boost.Python Library instructions at section 3.1.3. I followed the instruction and cd into the "C:\local\boost_1_54_0\libs\python\example\quickstart". The next step, according to the instruction is : Invoke bjam. Replace the "stage" argument from the example invocation from section 5 of the Getting Started Guide <http://www.boost.org/doc/libs/1_54_0/more/getting_started/index.html> with "test," to build all the test targets. Also add the argument "--verbose-test" to see the output generated by the tests when they are run. On Windows, your bjam invocation might look something like: C:\boost_1_34_0\...\quickstart> bjam toolset=msvc --verbose-test test Then I got 135 unresolved external errors. One of them is as follows: exec.obj : error LNK2019: unresolved external symbol __imp__PyEval_GetGlobals referenced in function "class boost::python::api::object __cdecl boost::python::eval(class boost::python::str,class boost::python::api::object,class boost::python::api::object)" (?eval@python@boost@@YA?AVobject@api@12@Vstr@12@V3412@1@Z) ..\..\..\..\bin.v2\libs\python\build\msvc-11.0\debug\boost_python-vc110- gd-1_54.dll : fatal error LNK1120: 135 unresolved externals May I know what am I wrong? How can I fix this? Thank you very much. Regards Long Wenlong Wang Risk Analyst, Capquest Group Ltd Email: wwang(a)capquest.co.uk Fleet 27, Rye Close, Fleet, GU51 2QQ. Website: http://www.capquest.co.uk/ This e-mail is intended solely for the addressee, is strictly confidential and may also be legally privileged. If you are not the addressee please do not read, print, re-transmit, store or act in reliance on it or any attachments. Instead, please email it back to the sender and then immediately permanently delete it. E-mail communications cannot be guaranteed to be secure or error free, as information could be intercepted, corrupted, amended, lost, destroyed, arrive late or incomplete, or contain viruses. We do not accept liability for any such matters or their consequences. Anyone who communicates with us by e-mail is taken to accept the risks in doing so. Opinions, conclusions and other information in this e-mail and any attachments are solely those of the author and do not represent those of Capquest Group Limited or any of its subsidiaries unless otherwise stated. Capquest Group Limited (registered number 4936030), Capquest Debt Recovery Limited (registered number 3772278), Capquest Investments Limited (registered number 5245825), Capquest Asset Management Limited (registered number 5245829) and Capquest Mortgage Servicing Limited (registered number 05821008) are all limited companies registered in England and Wales with their registered offices at Fleet 27, Rye Close, Fleet, Hampshire, GU51 2QQ. Each company is a separate and independent legal entity. None of the companies have any liability for each other's acts or omissions. Group VAT registration number 844281719. Members of the Capquest group are regulated under the Consumer Credit Act 1974 and are members of the Credit Services Association. This communication is from the company named in the sender's details above.

1 0

[BGL] memory leak in graph/r_c_shortest_paths.hpp
by potato_research 24 Sep '13

24 Sep '13

Hello, I'm using BGL in my project and, with some input data, I get - sooner or later, as I run r_c_shortest_paths many times - a segfault. This behaviour is apparently quite random, as I can see by implementing a custom visitor that the last label evaluated before the crash changes all the time. I must also say that the graph I use, while always having the same topological structure, has different properties that affect labelling each time I run the algorithm and these vary quite randomly from one run to the other, as they are generated by a random heuristics. Anyway, with one particular set of input data, I manage to have the program segfault (as I said, sooner or later) 100% of the times. This is far from being an MWE, but it's the best I could produce. I tried to debug the memory leak with valgrind and it turns out that r_c_shortest_paths_dispatch is trying to access memory in a block previously freed by: l_alloc.deallocate( cur_outer_splabel.get(), 1 ); in r_c_shortest_paths.hpp:314. After some debugging I started to believe that the problem doesn't rely with my code, but it might be a bug in r_c_shortest_paths.hpp. If this is actually the case and where the problem lies, though, I haven't been able to figure out with certainty. The output from valgrind can be found here: http://pastebin.com/raw.php?i=WWafwFv3 (output cleaned up and with templates substituted) http://pastebin.com/raw.php?i=cb3p6jzM (raw output intended to facilitate reading and with templates substituted) http://pastebin.com/raw.php?i=qeauBQTm (raw output indented to facilitate reading) http://pastebin.com/raw.php?i=hpppf49c (raw output) My code (the whole project) can be found here: https://github.com/alberto-santini/maritime-vrp In order to run it, one must have a licensed copy of CPLEX and change the include and library paths in the Makefile's accordingly. Unfortunately, without putting the labelling part inside a price-and-branch procedure (that uses CPLEX as a solver for the master problem) I wasn't able to produce input data by hand that would lead me to obtain the segfault. I understand this is not the best way to investigate into a bug and will be happy to provide any further help if requested to. Thanks, AS -- View this message in context: http://boost.2283326.n4.nabble.com/BGL-memory-leak-in-graph-r-c-shortest-pa… Sent from the Boost - Users mailing list archive at Nabble.com.

2 4

BJAM and VS2013RC
by LeMay.Steve 23 Sep '13

23 Sep '13

Has anyone successfully built Boost 1.54 with VS2013RC? Did you have an issue with the build process locating cl ? Steven LeMay Game Platform Engineering International Game Technology 9295 Prototype Way Reno, NV 89521 Office: +1 775.448.8089 Mobile: +1 775.813.6676 steven.lemay(a)igt.com<mailto:steven.lemay@igt.com> This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. Any humorous implications are purely the result of misinterpretations provided by the reader.

6 7

Re: [Boost-users] [boost] cross-compilation x86_64-w64-ming32: undefined reference to `InterlockedIncrement'
by Frédéric Bron 23 Sep '13

23 Sep '13

> I probably missed the original problem, but the patch doesn't look correct > to me. The section guarded with "defined( BOOST_MSVC ) || defined( > BOOST_INTEL_WIN )" is obviously targeted for compilers supporting > interlocked intrinsics, which gcc isn't. MinGW should probably be handled > by the last section of the #if/elif/endif sequence. Anyway, what problem > are you trying to fix? Here is what I get when build an application with boost and mingw-w64 targeting x86_64: /usr/x86_64-w64-mingw32/sys- root/mingw/lib/../lib/libboost_thread-mt.a(thread.o):(.text+0x286): undefined reference to `InterlockedIncrement' /usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libboost_thread-mt.a(thread.o):(.text+0x3e7): undefined reference to `InterlockedDecrement' /usr/lib64/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld: /usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libboost_thread-mt.a(thread.o): bad reloc address 0x8 in section `.data' I have been able to solve this by defining BOOST_USE_WINDOWS_H but this creates issues with Unicode when I also use wxWidgets. The patch proposed solves the issue. I recognise that I say that gcc should be considered as MSVC with regards to these Interlocked things which I do not understand. It may seem strange but it works. What's wrong with it? Basically, I just #include <intrin.h>; what's wrong with that? Frédéric

1 0

Re: [Boost-users] cross-compilation x86_64-w64-ming32: undefined reference to `InterlockedIncrement'
by Frédéric Bron 23 Sep '13

23 Sep '13

So I eventually managed to fix the issue with interlocked.hpp and mingw-w64: both i686 and x86_64 now work. Attached is a patch against 1.54.0. Is it possible to include this in 1.55.0? Regards, Frédéric

1 0

Multiple instance of options
by Ulf Samuelsson 23 Sep '13

23 Sep '13

Need to parse an "ini" file which configures one or more sensors. The sensors can be of the same type and are identified by "name", "type" and an "id" Some configuration items are for all sensors Other configuration tiems are only for some sensors. [sensor] SensorName="Outdoor Temp" SensorType=1 # Temp Sensor SensorID=1000 SerialNumber="12344" Active=1 Device="/dev/ttyUSB01" [sensor] SensorName="Indoor Temp" SensorType=1 # Temp Sensor SensorID=1001 SerialNumber="12345" Active=1 Device="/dev/USB02" [sensor] SensorName="Light" SensorType=2 # Light Sensor SensorID=1002 SerialNumber="12349" Active=1 Device="/dev/ttyUSB02" MaxLumen="500" Is having multiple identical section names possible with boost program options? It is of course possible to do [sensor_1] ... [sensor_2] ... [sensor_3] ... but that is not so nice looking, and you get a hard limit on the number of sensors you can attach. Ideas? BR Ulf Samuelsson

3 3