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

pure virtuals on multiple hierarchy levels
by Igor R 12 Jun '14

12 Jun '14

Hello, What's the right way to wrap the following, when exposing this hierarchy to Python: sturct base { virtual void func1() = 0; }; struct intermediate : base { virtual void func2() = 0; }; struct derived : intermediate { void func1(); void func2(); }; Thanks.

1 0

[BGL]
by Pablo Madoery 11 Jun '14

11 Jun '14

Hello, I Have 2 graphs: graph1 and graph2, and two sets of edge descriptors. One set is associated to edges of graph1 and another set associated to edges of graph2. I don't understand why is it possible to access information about edges of graph2 by using graph1 and the edge descriptors of graph2. I realized of that because of an own mistake when using graphs. What I would like to know is why is that possible to do and if it should be an exception that can handle this situation. I send the code I was using to test this: #include <iostream> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/graphviz.hpp> #include <fstream> #include "GraphInfo.h" using namespace std; using namespace boost; typedef adjacency_list<setS, vecS, bidirectionalS, VertexInfo, EdgeInfo> Graph; void printGraph(Graph graph, string file) { ofstream ofs(file.c_str()); dynamic_properties dp; dp.property("node_id", get(vertex_index, graph)); dp.property("label", get(&EdgeInfo::weight, graph)); write_graphviz_dp(ofs, graph, dp); } int main() { Graph graph1; Graph::vertex_descriptor a1 = add_vertex(graph1); Graph::vertex_descriptor b1 = add_vertex(graph1); Graph::vertex_descriptor c1 = add_vertex(graph1); Graph::edge_descriptor e1 = (add_edge(a1, b1, graph1)).first; Graph::edge_descriptor e2 = (add_edge(b1, a1, graph1)).first; graph1[a1].id = 10; graph1[b1].id = 20; graph1[c1].id = 30; graph1[e1].weight = 1; graph1[e2].weight = 2; Graph graph2; Graph::vertex_descriptor a2 = add_vertex(graph2); Graph::vertex_descriptor b2 = add_vertex(graph2); Graph::vertex_descriptor c2 = add_vertex(graph2); Graph::vertex_descriptor d2 = add_vertex(graph2); Graph::edge_descriptor e4 = (add_edge(c2, b2, graph2)).first; Graph::edge_descriptor e5 = (add_edge(b2, c2, graph2)).first; Graph::edge_descriptor e6 = (add_edge(d2, a2, graph2)).first; Graph::edge_descriptor e7 = (add_edge(a2, d2, graph2)).first; graph2[a2].id = 10; graph2[b2].id = 20; graph2[c2].id = 30; graph2[e4].weight = 13; graph2[e5].weight = 14; graph2[e6].weight = 15; graph2[e7].weight = 16; // WHY IS THIS POSSIBLE TO DO // IT IS ASKING FOR AN EDGE OF GRAPH2 BUT USING GRAPH1 ??? double weight = graph1[e7].weight; cout<<"weight: "<<weight<<endl; printGraph(graph1, "graph1.dot"); printGraph(graph2, "graph2.dot"); cout << "end" << endl; return 0; } Thank you very much

2 1

Fwd: Lexical cast between narrow and wide strings
by Andrew Marlow 11 Jun '14

11 Jun '14

I hope this is the right place to post my question. I expected to be able to convert between narrow and wide strings using boost lexical cast but it fails to compile. I suppose that conversion is not supplied or supported. It would be really useful to me if it was. I am developing on win32 for wince and on wince there seeem to be many places where wide strings are required, especially when using the win32 API. Is there any chance this could be added to boost? I checked using boost 1.55.0 -- Regards, Andrew Marlow http://www.andrewpetermarlow.co.uk

5 6

Is boost asio appropriate for this use case ?
by Aaron Boxer 10 Jun '14

10 Jun '14

I am decoding an image file: the file has tagged header info mixed with 4K pixel code blocks. Platform is primarily windows, but could be osx or linux. Once I read in a code block, I can launch (asynchronously) my decode routine on this block, while continuing to read the file for header info and code blocks. Currently, I do synchronous reads using fread(...). Is is worthwhile to switch to boost asio to asynchronously read in the code blocks? The read callback could trigger my decode routine. But I wouldn't have to wait for the read before I carry on to the next code block. If so, can anyone point me to a reference/tutorial covering boost::asio asynch reads from disk?

3 3

[boost] [pimpl] Boost.Pimpl review canceled
by Glen Fernandes 09 Jun '14

09 Jun '14

Hi everyone, Vladimir has elected to withdraw Boost.Pimpl submission and cancel the formal review. On behalf of Vladimir, thank you for the feedback provided in response to the pre-view announcement mail: it was especially useful to him. Best, Glen

1 0

memory mapped file thread safety
by Aaron Boxer 09 Jun '14

09 Jun '14

Simple question: If I call get_address() on a region, can I pass this pointer to another thread and have this thread access the memory ? Thanks!

2 2

Boost Build
by skk 09 Jun '14

09 Jun '14

I am building Boost for MSVS10.0. I have generated the bjam.exe file and run it with the command line: bjam toolset=msvc10.0 variant=debug,release threading=multi link=static Looking at the libraries built, there are no sgd libs and the linker wants: libboost_regex-vc100-mt-sgd-1_55.lib Don't know how to get the sgd libs. Thanks -- View this message in context: http://boost.2283326.n4.nabble.com/Boost-Build-tp4663758.html Sent from the Boost - Users mailing list archive at Nabble.com.

3 2

[Filesystem] remove and recursive_directory_iterator
by gast128 09 Jun '14

09 Jun '14

I couldn't find a description of the iterator stability of recursive_directory_iterator but it gives problems when you remove the directory which is being iterated even when that directory is empty. For example if you want to remove all empty directories, the following code will throw an exception in ++it after the 'remove' call: fs::path pthDirectory = ...; fs::recursive_directory_iterator itEnd; for (fs::recursive_directory_iterator it(pthDirectory); it != itEnd; ++it) { boost::system::error_code ec; const fs::path& rPath = it->path(); if (fs::is_directory(rPath, ec)) { if (fs::is_empty(rPath, ec)) { fs::remove(rPath, ec); } } } It seems solvable with the way one erases a map (i.e. using while (it != itEnd) and using the equivalent of map.erase(it++)). Maybe add a note to the documentation or did I overlook something?

1 0

Writing a dynamic string into a shared memory using Boost Library
by Hany Assasa 09 Jun '14

09 Jun '14

I want to share a dynamic array of characters between two processes using Boost Shared Memory. I use the following two pieces of code to do that: *Producer Process:* char *data;unsigned int share_length;unsigned int offset; std::string data_to_share(data + offset, data + offset + share_length); boost::interprocess::managed_shared_memory managed_shm(boost::interprocess::create_only, "SomeName", 1024*1024);typedef boost::interprocess::allocator<char, boost::interprocess::managed_shared_memory::segment_manager> CharAllocator;typedef boost::interprocess::basic_string<char, std::char_traits<char>, CharAllocator> my_string; managed_shm.construct<my_string>("DataToShare")(data_to_share.c_str(), managed_shm.get_segment_manager()); *Consumer Process:* boost::interprocess::managed_shared_memory managed_shm(boost::interprocess::open_read_only, "SomeName");typedef boost::interprocess::allocator<char, boost::interprocess::managed_shared_memory::segment_manager> CharAllocator;typedef boost::interprocess::basic_string<char, std::char_traits<char>, CharAllocator> my_string; std::pair<my_string *, size_t > data = managed_shm.find<my_string>("DataToShare"); cout << "Data Size=" << data.first->length() << endl; The problem is when I try to print the length of the DataToShare in the Consumer Process it is wrong, so what is the problem in my code, is it in the Producer Part since I am doing data_to_share.c_str()which is a std::string type instead of of my_string type? *Possible Answer:* I believe the answer to my question is, converting std::string into my_string type. so can anyone tell me how to do that?

2 1

[mpl] Cannot open include file
by Christian Henning 09 Jun '14

09 Jun '14

I have the following error when using Visual Studio 2013 on the boost master branch: 1>c:\boost\boost\mpl\vector\aux_\include_preprocessed.hpp(49): fatal error C1083: Cannot open include file: 'boost/mpl/vector/aux_/preprocessed/plain/vector10.hpp': No such file or directory I have run "b2 headers". Here is the code I'm trying to compile: // cpp_test.cpp : Defines the entry point for the console application. // #include "stdafx.h" #include <boost/mpl/vector_c.hpp> int _tmain(int argc, _TCHAR* argv[]) { return 0; } Manually I can find vector10.hpp in C:\boost\boost\mpl\vector but I don't have the folder c:/boost/mpl/vector/aux_/preprocessed/plain/ Any ideas? Thanks, Christian Regards, Christian

2 1

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