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

Using a vertex type
by Mads Jensen 09 Jun '14

09 Jun '14

Hi, I'm planning on writing an implementation of the Gomory Hu cut tree algorithm (for learning purposes, and as a side bonus, have some code in open source), but have some initial difficulties. I posted some code at: http://codepad.org/yTt3xNsK I had tried something like: template<class OrdinaryVertex> struct gomory_hu_vertex { std::vector<OrdinaryVertex> vertices; }; and the graph definition: typedef adjacency_list<listS, vecS, undirectedS, GHVertex> GHGraph; but with the insert operation, I get a compiler error. When I get it working, I want to submit it to the boost library. Are there restrictions on what type of features you can use, e.g., anything from C++11 is ruled out? Thank you, Mads

1 0

[serialization] serialize object tree and values
by Daniel Krikun 07 Jun '14

07 Jun '14

Hello, I have an application which creates some objects connected between them using boost::shared_ptr and then executes a main loop. The object graph structure is almost constant over time but primitive member fields of the objects change over time. I would like to serialize the whole object graph *each cycle* saving both the object graph structure and primitive member fields. Currently I don't know how to achieve this: when I try to serialize via pointer only first value is saved. Also, I'm not sure if I should turn object tracking off, because indeed it should be a single instance of each, it just should be modified over time. Thanks!

2 1

Re: [Boost-users] Boost-users Digest, Vol 3819, Issue 2
by David Frank 06 Jun '14

06 Jun '14

Thanks Nat. I'm wondering if there is a powerpc built binary including context to download? On Thursday, June 5, 2014 8:25 AM, "boost-users-request(a)lists.boost.org" <boost-users-request(a)lists.boost.org> wrote: Send Boost-users mailing list submissions to boost-users(a)lists.boost.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.boost.org/mailman/listinfo.cgi/boost-users or, via email, send a message with subject or body 'help' to boost-users-request(a)lists.boost.org You can reach the person managing the list at boost-users-owner(a)lists.boost.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Boost-users digest..." Today's Topics: 1. Re: [Python]compiling python library (Mikl?s T?th) 2. Re: is boost context supported on powerpc?- (Nat Goodspeed) 3. Re: Fwd: Lexical cast between narrow and wide strings (Nat Goodspeed) 4. Re: [Python]compiling python library (Erik H) ---------------------------------------------------------------------- Message: 1 Date: Thu, 5 Jun 2014 13:18:44 +0200 From: Mikl?s T?th <spiralfuzet(a)gmail.com> To: boost-users(a)lists.boost.org Subject: Re: [Boost-users] [Python]compiling python library Message-ID: <CAHsDByksou9LpheA6g-Napu6GPKjbAdtYFZeC2psuRhRCUDivQ(a)mail.gmail.com> Content-Type: text/plain; charset="utf-8" Hi Erik, Unfortunatly Visual Studio is not an option for me. I didn't find this page but as I understand it helps to install python libs (extensions) with mingw. What I try to do is build python from src to get an appropriate static library. I can link it with my Qt toolchain (Mingw 4.6.3) and it compiles without error, but it fails to run. I double check it. All of my libs and tools are 32-bit. Thank you very much for your help. Regards, Mikl?s 2014-06-04 18:50 GMT+02:00 Erik H <ice.rikh(a)gmail.com>: > This is educational for me; to minimize pain, I settled on visual studio + > intel compiler long ago whenever I am coerced into windows development. > > You mentioned that did some surfing; did you encounter this page > <http://www.secker.nl/2012/03/08/setup-python-2-7-2-and-mingw-on-windows-xp/>? > Apparently, mingw should be able to link against the standard, visual > studio compiled python lib. Which would be a blessing for you if it > works... Are you trying to build 32-bit binaries linked against 64-bit > python libs by any chance? > > If you don't get any joy, I'll try setting up an official python binaries > + mingw environment on my windwoes system at home after work today or > tomorrow. Are you strictly targeting 2.7? > > -Erik > > > On Wed, Jun 4, 2014 at 3:07 AM, Mikl?s T?th <spiralfuzet(a)gmail.com> wrote: > >> Hi Erik, >> >> Thanks for the response. >> Yes I'm using makefile but I think the problem is different. >> Here is the gcc command that fails: >> gcc -c -fno-strict-aliasing -g -O2 -DNDEBUG -g -fwrapv -O3 -Wall >> -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o >> Python/asdl.o Python/asdl.c >> It has a -I./Include argument. >> >> So, I surf the Internet (a lot) and I found that at initial there were no >> autotool support for installing python from source. >> Later I found a Python 3.4 page were I could download an src setup for >> mingw installation. Unfortunatly that doesn't work either. >> So I reinstalled my Python and somehow I could link the library to my >> project. (I don't know how this possible, but the latest version of 2.7 >> works with my project. Blind luck I guess.) I could use >> PyRun_SimpleString but the PyRun_SimpleFileEx call crashes for some >> reason. >> Than I tried boost::python and it crashes aswell at the first object >> result = eval("5/2"); call. >> (I didn't forget to call Py_Initialize();). >> >> Any suggestions? >> >> Thanks, >> Mikl?s >> >> >> 2014-06-03 23:18 GMT+02:00 Erik H <ice.rikh(a)gmail.com>: >> >> Hi Mikl?s, >>> >>> Are you using a makefile? If so, it looks like you need to >>> add -I/cygdrive/e/INSTALL/python_src/Python-2.7.6/Include to the Makefile's >>> CFLAGS or CC variable, or somehow ensure that >>> -I/cygdrive/e/INSTALL/python_src/Python-2.7.6/Include is passed to the >>> compiler in any case. >>> >>> Regards, >>> Erik >>> >>> >>> On Mon, Jun 2, 2014 at 3:17 AM, Mikl?s T?th <spiralfuzet(a)gmail.com> >>> wrote: >>> >>>> Hi! >>>> >>>> Any updates on this? >>>> I get the following error: >>>> >>>> /cygdrive/e/INSTALL/python_src/Python-2.7.6 >>>> $ mingw32-make >>>> process_begin: CreateProcess(NULL, /usr/bin/mkdir -p Include, ...) failed. >>>> make (e=2): The system cannot find the file specified. >>>> mingw32-make: *** [Include/graminit.h] Error 2 >>>> >>>> but the corresponding file is there: >>>> >>>> /cygdrive/e/INSTALL/python_src/Python-2.7.6 >>>> $ ls Include/g*Include/genobject.h Include/graminit.h Include/grammar.h >>>> >>>> What am I missing? Any thoughts? >>>> >>>> Thanks, >>>> Mikl?s >>>> >>>> >>>> 2014-05-27 14:06 GMT+02:00 Mikl?s T?th <spiralfuzet(a)gmail.com>: >>>> >>>> Hi All, >>>>> I want to embed python in my c++ code using boost.python library. >>>>> As far as I understand I need python headers and libs. >>>>> So my python27.lib is "incompatible". I want to compile it from code >>>>> but I failed with mingw32. >>>>> Could you give me some advice, or links to achieve my goal? >>>>> I'm using gcc4.6.3 and qt 4.8.2 and boost 1.49 on windows 7. >>>>> Thanks, >>>>> Mikl?s >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Boost-users mailing list >>>> Boost-users(a)lists.boost.org >>>> http://lists.boost.org/mailman/listinfo.cgi/boost-users >>>> >>> >>> >>> _______________________________________________ >>> Boost-users mailing list >>> Boost-users(a)lists.boost.org >>> http://lists.boost.org/mailman/listinfo.cgi/boost-users >>> >> >> >> _______________________________________________ >> Boost-users mailing list >> Boost-users(a)lists.boost.org >> http://lists.boost.org/mailman/listinfo.cgi/boost-users >> > > > _______________________________________________ > Boost-users mailing list > Boost-users(a)lists.boost.org > http://lists.boost.org/mailman/listinfo.cgi/boost-users >

1 0

Boost program_options - is there a way to make abbreviations for short options
by tenspd137 . 06 Jun '14

06 Jun '14

Hi all, I was trying to figure out if there is a way to make the short options use more than one letter to create an abbrieviation. For example: desc.add_options() ("resolution","re","Choose resolution") ("raster-level,"rl","Chhose raster mode") .... I know that by convention and definition, short options are just -(letter), so that when you ask to print help, you get something like: -r [--resolution] arg -r [--raster-level] arg but I would like to find a way to have -re [--resolution] arg -rl [--raster-level] arg Point is, I have some options that start with the same letter, so being able to make short abbreivations or acronyms for them would be helpful. If this is possible, it isn't real clear to me how, and I haven't turned up much in google. Any suggestions? Thanks!

2 1

Boost.Pimpl upcoming formal review (June 15 - June 24)
by Glen Fernandes 05 Jun '14

05 Jun '14

The formal review period of Boost.Pimpl by Vladimir Batov is scheduled to begin later this month, on June 15th, and will conclude on June 24th, and we welcome your participation. Vladimir's library provides a mechanism for implementing this popular, and still very relevant, idiom. To borrow his words from the documentation: [quote] In the domain of commercial large-scale software development the following design principles come to the fore: - component-based, modular and API-centered design, - separation of concerns, - implementation hiding, - minimization of compilation and component dependencies, - consistent and recognizable deployment and implementation patterns, multi-platform support. The Pimpl idiom can help great deal achieving those goals. It is a simple yet robust programming technique to minimize coupling via the separation of public interface and private implementation and then implementation hiding. [/quote] Please feel encouraged to browse the source code, documentation, and tests, before the review commences. Any feedback you have prior to the review period is also very appreciated. Source: https://github.com/yet-another-user/boost.pimpl/ Documentation: http://yet-another-user.github.io/boost.pimpl/ Download: https://github.com/yet-another-user/boost.pimpl/archive/master.zip If you would like to submit a review earlier, please provide your thoughts on the following topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? As well as information on the following questions: - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? And most importantly: - Do you think the library should be accepted as a Boost library? Best, Glen

1 0

is boost context supported on powerpc?-
by David Frank 05 Jun '14

05 Jun '14

Greetings, If it is supported how do I cross compile it from x86 machine, especially the assembler code part? Thanks, Frank

2 1

Sanity check please?: Boost 1_55_0 and building VS2012 static libs?
by g4＠novadsp.com 04 Jun '14

04 Jun '14

Revisiting Boost after a long absence. Any thoughts on the following problem(s)? W7x64 with VS2008,2010,2012 and 2013 installed. VS2012 preferred for regular use. Built with boostrap and b2 b2 -link=static -runtime-link=static -toolset=msvc-11.0. I compile a debug test app with /MTd and attempt to link with libboost_system-vc110-mt-gd-1_55.lib which is the only library close to matching the ABI tag specified here : http://www.boost.org/doc/libs/1_55_0/more/getting_started/windows.html#id46 Ensuing link errors are: 1>libboost_system-vc110-mt-gd-1_55.lib(error_code.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in tcpproxy_server.obj 1>libboost_system-vc110-mt-gd-1_55.lib(error_code.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MT_StaticRelease' in tcpproxy_server.obj 1>LINK : warning LNK4098: defaultlib 'MSVCRTD' conflicts with use of other libs; use /NODEFAULTLIB:library Many thanks.

7 13

Re: [Boost-users] [serialization] deserialized instance empty even though proper serialize methods called [Honeywell Internal]
by Hickman, Steve (AdvTech) 03 Jun '14

03 Jun '14

Classification: Honeywell Internal All serialize methods (except the base class serialize method) have as their first three lines code like this (with the appropriate BOOST_LOG_TRIVIAL(trace) << CLASS_METHOD << " called"; boost::serialization::void_cast_register<derived, base>( static_cast<derived *>(nullptr), static_cast<base *>(nullptr) ); ar & BOOST_SERIALIZATION_BASE_OBJECT_NVP(base); If that's what you're referring to, it didn't fix the problem --- Steve H. ============================================================================================================================================================================================================ This message classified as Honeywell Internal by Hickman, Steve (AdvTech) on Tuesday, June 03, 2014 at 3:34:21 AM. The above classification labels are in accordance with the Honeywell Corporate Classification Policy. The information contained in this electronic message is confidential and intended only for the use of the individual/entity named above, and the information may be privileged. If you, the reader of this message, are not the intended recipient or an employee or agent responsible to deliver this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please immediately notify the sender and delete the original message. ============================================================================================================================================================================================================ From: Robert Ramey [mailto:robertmacleranramey@gmail.com] Sent: Sunday, June 01, 2014 11:22 AM To: boostusers(a)googlegroups.com Cc: robertmacleranramey(a)gmail.com; boost-users(a)lists.boost.org; Hickman, Steve (AdvTech) Subject: Re: [Boost-users] [serialization] deserialized instance empty even though proper serialize methods called On Saturday, May 31, 2014 2:50:35 PM UTC-7, Robert Ramey wrote: I woke up in the middle of the night. The "registration" base/derived pair is a side effect of class Base { virtual~Base(); template<class Archive); void serialize(Archive ar, const unsigned int version); }; class Derived { virtual~Derived(); template<class Archive); void serialize(Archive ar, const unsigned int version); }; template<class Archive); void Derived::serialize(Archive ar, const unsigned int version){ ar & boost::serialization::base_object<Base &>( *this); // side effect void_cast_register(Base, Derived) which updates the table when DLL is loaded } So I'm guessing that you're not calling the base class serialization so the Base/Derived pair isn't being registered. Solution: explicitly declare, define and call the Base class serialization even though it is empty. or explicitly invoke register void_cast::register base/derived - i forget the exact name. I'll be surprised if that doesn't solve your problem. RObert Ramey

1 0

trouble getting older version of boost to build
by David Toth (dtoth) 03 Jun '14

03 Jun '14

Hi. I am trying to build boost 1.41 (I need some of the libraries from it to compile some 3rd party software) and I am having issues. On CentOS 6.5 with the "Software Developer Workstation" installation (which comes with gcc 4.4.7 and g++ 4.4.7), I can build boost simply by running bootstrap.sh followed by running bjam. That creates all the libraries and then I can compile the other software that requires those libraries. Unfortunately, I can't use CentOS on the systems I am using. I reverted to trying it on CentOS just to see if I could get it to work on one version of Linux, thinking that it would be easy to then get it to work on another version. On Ubuntu, Fedora, and Debian (these are the versions of Linux I can use on the systems), I am unable to build the full set of libraries. After running bootstrap.sh and bjam, I am missing these files that were created on CentOS: libboost_thread.a‎ libboost_thread.so‎ libboost_thread.so.1.41.0‎ Without those files, the 3rd party software won't compile. Ubuntu, Fedora, and Debian come with more updated compilers and I read some place online that gcc 4.8 and g++ 4.8 have some issues with the old versions of boost, so I tried installing gcc 4.4.7 and g++ 4.4.7 and changing the symbolic links for gcc and g++ in /usr/bin/ to point to gcc 4.4.7 and g++ 4.4.7. Unfortunately, I am still unable to get the thread library to get created. I know boost 1.41 is old and I *might* be able to get away with using a version as recent as 1.49, but I have the same problems building that (and every version in between 1.41 and 1.49). Any help would be greatly appreciated. Thanks in advance. Dave

3 4

Convert library review manager result
by Edward Diener 01 Jun '14

01 Jun '14

This is my analysis of the 'convert' library review and the result of whether the convert library should be accepted into Boost. Please read the entire analysis to understand my reasoning before reading the result. I would like to thank all of those who took part in the review and made comments. This includes Julian Gonggrip, Rob Stewart, Andrzej Krzemienski, Matus Chochlik, Jeroen Habraken, Erik Nelson, Hartmut Kaiser, Joel De Guzman, Thijs (M.A.) van den Berg, Roland Bock, Gavin Lambert, feverzsj, Paul Bristow, and alex. If I have missed anybody I do apologize. All comments were taken into account and all comments were intelligent and to the point. Naturally I would also like to than Vladimir Batov for patiently answering all comments and explaining and defending his library and his design decisions. For the most part I am going to focus on general issues rather than on the individuals who made them. Documentation issues: The documentation was too focused on explaining the library as it differed from lexical_cast. Vladimir Batov explained why this is so but I also agree that the documentation can be better by simply focusing on what the library provides in terms of functionality. Comments also mentioned that the current converters are not documented as well as the could be, and some commenters reflected that knowledge of how a particular converter works, including possible failures using that converter, is also needed despite the common library interface. The documentation did not provide enough information about the use of locales in the library. The reference section was very limited with not enough explanation. A reference built from doxygen comments in the source files would be better. A better explanation or example in the documentation for writing one's own converter was suggested. Although the Performance section in the documentation was fairly lengthy some commenters wanted to know why some things could not be tested. Others wanted more information about how convert performance compared to other convert-like implementations. In general I think most reviewers found the documentation adequate for understanding how to use the library but lacking in completeness. Vladimir Batov reflected that if the library were accepted into Boost he would then create more complete documentation and the above issues could be addressed. Implementation issues: As in most reviews most commenters did not look very deeply into the actual code but were happy to know how to use the library, and this is understandable for a review. There were a few pertinent comments however and I am just going to enumerate them. All macros should be prefix with BOOST_. My own addition to that is that all macros should be prefixed with BOOST_CONVERT_ to avoid any conflicts with other libraries. There should be a jamfile for running the tests. Also some full-blown examples of using the library in a simple program, along with the appropriate jamfile, would be helpful. Source code should contain spaces, not tabs. This is an easily fixed minor issue. As mentioned before doxygen comments in the public source are the usual Boost way of doing things. The main header file should be convert.hpp instead of api.h. Some includes were missing from the printf converter. Design issues: In the design of the library is where we have the most varying views. The major issue in discussing the design of the library for those who felt it was inadequate were the comments that using the library was too complicated, that the central function for invoking a conversion should be simpler to use. While all suggestions were well-argued I felt that a number of these differences were merely syntactical issues rather than issues that made the functionality easier to use. The main interface for using the library is: convert<output_type>::from(input_value, converter) Vladimir Batov had asserted during the review that this could be simplified further by removing the need for the 'from::' part of the signature which would make the syntax simpler. Some reviewers did not like the name 'convert' and offered substitutions, others wanted the default value, currently specified as '.value_or(default)', to be specified as a direct input parameter, others wanted the converter itself which is an input parameter to be specified via another syntax. All of these are too me syntactical issues and no resolution could possibly please everybody but it is understandable that different reviewers have different syntactical preferences. More to the point were some changes in actual functionality. The three most important involved the return value, type requirements for the output type, and the use of a default converter. Considering each in its turn: 1) The return value is some form of 'optional', with the idea of using boost::optional if it meets all the requirements needed by the 'convert' library. A number of people wanted the actual value returned without having to append .value() to the convert signature to get it. They were also concerned with the performance overhead of having to create an optional value as the immediate return value. It was also suggested that while the current convert syntax might be fine, some alternatives directly returning the value, for those who like maximum simplicity, might be possible. 2) The type requirements for the output type are default constructible and copy constructible. A number of reviewers felt that if a non-const reference were passed to the convert function as an output instance then the type requirements would not have to be met. However the type requirements of some of the underlying converters might be affected by this and the documentation does explain how to work around the default constructible requirement, but I still do understand the reasoning behind this possibility. 3) A number of reviewers wanted a default converter to be used but there was hardly an agreement on what this default converter should be, some favoring lexical_cast, others favoring stringstream, and no doubt others might want something else. Nevertheless providing a default constructor interface, possible with a macro defined a compile time, seems like it might be doable. There was further discussion about the actual callable signature for a plug-in converter. Here there was less contention about the interface, which is currently a callable with a signature of: template<typename TypeOut, typename TypeIn> bool operator()(TypeIn const& value_in, TypeOut& result_out) const; Vladimir Batov did suggest some possible alternatives and there was a discussion with a number of reviewers about alternatives that seem implementable. This also ties into the concern of some reviewers that it should be straightforward to create one's own converters with minimum restrictions on the input and output types, as well as minimum performance overhead. Votes: A number of reviewers made comments but offered no final vote on whether or not the conversion library should be accepted into Boost. Some reviewers offered a Yes vote, but heavily based on changes they want to see. I will attempt to tabulate them here: YES votes: Christopher Kormanyos Paul Bristow Julian Gonggrip ( with some reservations which Vladimir Batove has met or may easily meet ) Andrzej Krzemienski Matus Chochlik YES, conditionally but otherwise NO if conditions are not met, which the current version does not meet] Jeroen Habraken Roland Bock alex NO Rob Stewart Final Decision: Among those who voted YES conditionally but otherwise NO there was a general consensus including Vladimir Batov, the 'convert' library creator, and some of the others that an attempt could be made to satisfy some of the conditions for simplification and/or functionality they desired. My decision, based on the votes as I interpret them, is that the convert library is ACCEPTED into Boost. While a perfect design is impossible I believe that the design of the library is an adequate starting point for a general-purpose conversion framework and that the design could change incrementally enough to satisfy some of the qualms of those who might not find it as initially useful as they have hoped, while still maintaining the central framework which Vladimir Batov has created. Furthermore I believe that others have reflected that a general-purpose conversion library would be very useful if it were flexible enough to support plug-in converters created by programmers, as the 'convert' library does. I realize that what is essentially a 5 to 4 vote in favor of the library is not an overwhelming consensus by any means but I feel that 3 of those 4 NO votes are predicated on wishes for possible changes to the 'convert' library which may yet be met before the library gets officially added to an upcoming Boost release. Since I have accepted the library based on the votes and my interpretation of the issues I would like to encourage those who feel that some alternate designs could be implemented as part of the 'convert' library to work with Vladimir Batov, if he is agreeable, to add those alternatives to the library. Nonetheless it is his library and he would be the final arbiter of any decisions reached. I would like to encourage the view, however, that the current design is what has been voted in by others as the 'convert' library so that any changes made to it as it is added to Boost should be incremental additions which minimally change what others see as an acceptable library.

1 0