February 2009 - Boost - lists.preview.boost.org

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

AMDG The following pairs of files have identical include guards ./boost/concept_check/general.hpp ./boost/concept/detail/msvc.hpp ./boost/concept_check/msvc.hpp ./boost/concept/detail/msvc.hpp ./boost/filesystem/cerrno.hpp ./boost/cerrno.hpp ./boost/interprocess/containers/tree.hpp ./boost/interprocess/containers/detail/tree.hpp ./boost/mpl/min_max.hpp ./boost/mpl/max.hpp ./boost/mpl/vector/aux_/front.hpp ./boost/mpl/list/aux_/front.hpp ./boost/multi_index/identity_fwd.hpp ./boost/multi_index/identity.hpp ./boost/python/pointee.hpp ./boost/python/detail/pointee.hpp ./boost/spirit/phoenix/closures.hpp ./boost/lambda/closures.hpp ./boost/xpressive/proto/v1_/proto_typeof.hpp ./boost/xpressive/proto/proto_typeof.hpp ./libs/config/test/boost_no_dep_nested_class.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_mem_templates.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/config/test/boost_no_std_allocator.ipp ./libs/config/test/boost_has_vc6_mem_templ.ipp ./libs/conversion/test.hpp ./libs/any/test.hpp ./libs/interprocess/example/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/expand_bwd_test_template.hpp ./libs/interprocess/test/allocation_test_template.hpp ./libs/interprocess/test/printcontainer.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/interprocess/test/print_container.hpp ./libs/interprocess/example/printcontainer.hpp ./libs/iostreams/test/detail/utf8_codecvt_facet.hpp ./boost/detail/utf8_codecvt_facet.hpp ./libs/regex/test/regress/test_regex_search.hpp ./libs/regex/test/regress/test_partial_match.hpp ./libs/serialization/test/C.hpp ./libs/serialization/test/A.hpp ./libs/xpressive/perf/regex_comparison.hpp ./libs/regex/performance/regex_comparison.hpp ./tools/inspect/time_string.hpp ./tools/common/time_string.hpp In Christ, Steven Watanabe

5 8

Why no non-null smart pointers?
by Ross MacGregor 29 Apr '14

29 Apr '14

I just created a very small smart pointer libary for our project. It will contain two types of shared pointers: SharedHandle and NullableSharedHandle. SharedHandle will be a shared pointer that cannot be null by ensuring a non-null construction while NullableSharedHandle will basically be a typedef for boost::shared_ptr. I firmly believe that code can be made more reliable by minimizing the use of nullable pointers. To this end, I think it is important that we start using non-null pointer types. Ideally the compiler would be able to understand a non-null pointer and catch bugs at compile time, but I think we can still improve things with a few runtime checks. If we make sure that a shared pointer is constructed with a non-null pointer and ban any reset() type methods, we guarentee that it points to something. This can be beneficial for the following reasons: 1. Any function that uses this type will no longer be burdened with precondition checks to make sure variables of this type are not null. 2. It's type is simply more explicit and better explains its function. 3. Moving the non-null check to the creation phase will reduce the possibility of encountering null pointer exceptions at runtime (assuming there are many more pointer references than constructor calls). So my little pointer library seems to make a lot of sense, but if so why hasn't this simple smart pointer variation made it into boost yet? Has this been discussed somewhere already? My search on non-null smart pointers is not revealing much discussion on the topic. Regards, Ross

9 16

[interprocess] message_queue hangs when another process dies
by Sergei Politov 03 Nov '11

03 Nov '11

Hi, I have found the following problem with message_queue on win32 (MSVC 2008 + Windows Vista). Suppose we have 2 processes, one sends messages to queue, another reads them. When reading process dies (for instance using End process) during message_queue.receive the another process hangs in send. As I found during investigation, it tries to lock interprocess mutex, but it is already locked by dead process. So this message queue instance becomes unusable. I attached the example. Steps to reproduce: 1) Start "mq.exe s" (i.e. with argument s) It outs: sender: $PID 2) Start mq.exe without arguments. It outs: receiver: $PID 0 1 2 3 4 This time sender outs: send done: 3) At this point the message queue is empty and receiver waits for messages. End it with Task Manager. 4) Enter some number in sender console and press Enter. 5) The sender hangs in message_queue.send Best Regards, Sergei

6 13

Re: [boost] [date_time] Time zone improvements
by Rutger ter Borg 25 May '11

25 May '11

Jeff Garland wrote: > Very cool :-) One question -- is there a portable solution where a user > could deploy a files onto a Windows system or is it a Unix only solution? > I'm fine with incorporating a *nix only solution because what your > suggesting will be a nice solution for *nix platforms, but it will need to > be clear that it's not portable. I don't see why it wouldn't be possible to deploy the (big-endian) binary files to any platform. Getting it into this binary form (using zone info compiler zic) may be harder to do cross-platform, but cygwin may help here. [snip] > As the primary maintainer of Boost date-time I can say with certainty that > there is interest in this functionality -- it's long been on my todo list > and I haven't had time to get to it. You can email me privately and we > can discuss all the details of how to get your code incorporated. I'll do! Regards, Rutger

5 9

[serialization] boost/serialization/path.hpp
by Johan Råde 21 Feb '11

21 Feb '11

There is no boost/serialization/path.hpp. I suggest the following: ---------------------------------------------------------------------------------------------------------------- #ifndef BOOST_SERIALIZATION_PATH_HPP #define BOOST_SERIALIZATION_PATH_HPP // MS compatible compilers support #pragma once #if defined(_MSC_VER) && (_MSC_VER >= 1020) #pragma once #endif #include <boost/config.hpp> #include <boost/filesystem/path.hpp> #include <boost/serialization/level.hpp> BOOST_CLASS_IMPLEMENTATION(boost::filesystem::path, boost::serialization::primitive_type) #ifndef BOOST_NO_STD_WSTRING BOOST_CLASS_IMPLEMENTATION(boost::filesystem::wpath, boost::serialization::primitive_type) #endif namespace boost { namespace serialization { template<class Archive, class String, class Traits> void serialize(Archive& ar, boost::filesystem::basic_path<String, Traits>& p, const unsigned int version) { String s; if(Archive::is_saving::value) s = p.string(); ar & boost::serialization::make_nvp("string", s); if(Archive::is_loading::value) p = s; } }} #endif //-------------------------------------------------------------------------------------------------------------- Comments? Any suggested improvements? --Johan Råde

5 11

[process] How to run test cases
by Boris 23 Jan '11

23 Jan '11

As Boost.Process 0.3 has been released it would be great if the test cases are run on various platforms. So far I've tested Boost.Process on WinXP with MSVC 9.0, Cygwin with g++ 3.4.4 and Solaris with g++ 3.4.6 and Sun C++ 5.9. To make it as easy as possible for others to run the test cases here's a short description of how to proceed. Nearly all test cases depend on a program called "helpers". This program is built first and is started by many test cases as a child process. In order to find the program "helpers" the test cases must know its location. As there is no way to get the location at runtime it is hardcoded in the file libs/process/test/misc.hpp. As the location differs depending on what compiler is used YOU MUST CHECK FIRST THE PATH IN libs/process/test/misc.hpp! Otherwise most of the test cases will fail as they look for a program "helpers" in the wrong directory. As of today only those paths are correct and have been tested which are set for Windows, Cygwin and Solaris. Only after you have checked and maybe updated the path in libs/process/test/misc.hpp you should try to build and run the test cases: WinXP/MSVC 9.0 ************** With MSVC 9.0 you only need to open the Visual Studio 2008 Command Prompt, change to the directory with the test cases and run bjam: C:\boost_1_36_0\libs\process\test> ..\..\..\bjam.exe -q Cygwin/GCC 3.4.4 **************** On Cygwin it's important to know if the Boost libraries have been built for the POSIX or Windows API. By default Boost libraries on Cygwin use the Windows API. With the Windows API the Boost.Process test cases are not passed successfully though (there are compiler errors where I'm not sure currently if they are a Boost.Process problem and how they could be fixed). If you want to run the test cases on Cygwin you must (re-)build the Boost libraries to use the POSIX API: $ cd ~/boost_1_36_0 $ ./bjam cxxflags=-DBOOST_POSIX_API Afterwards you can run the test cases: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam cxxflags=-DBOOST_POSIX_API -q Solaris/GCC 3.4.6 ***************** At first you have to put the following line in ~/user-config.jam: using gcc : : : <linker-type>sun ; Then start building the Boost libraries: $ cd ~/boost_1_36_0 $ ./bjam --toolset=gcc cxxflags=-mcpu=ultrasparc For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. Afterwards the test cases can be run: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=gcc cxxflags=-mcpu=ultrasparc -q Solaris/Sun C++ 5.9 ******************* Build the Boost libraries with the sun toolset: $ cd ~/boost_1_36_0 $ ./bjam --toolset=sun stdlib=sun-stlport For the test cases to be passed successfully you must update Boost.Test. Change line 624 in ~/boost_1_36_0/boost/test/impl/execution_monitor.ipp temporarily to: - , m_CHLD_action( SIGCHLD, catch_system_errors, attach_dbg, alt_stack ) + , m_CHLD_action( SIGCHLD, false, attach_dbg, alt_stack ) It is important that the second parameter is false as the signal SIGCHLD should not be handled by the execution monitor and should not be reported as an error. If you run the test cases now you'll get this compiler error for one test case: "../../../boost/asio/detail/socket_ops.hpp", line 218: Error: Cannot assign void* to char*. "../../../boost/asio/detail/socket_ops.hpp", line 229: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 66: Error: Cannot assign void* to char*. "../../../boost/asio/detail/descriptor_ops.hpp", line 72: Error: Cannot assign void* to char*. The bug has been reported to the Boost.Asio mailing list. If you want to build that one test case, too, you need to fix the two files in Boost.Asio 1.36.0 yourself. All the test cases can be built and run with: $ cd ~/boost_1_36_0/libs/process/test $ ../../../bjam --toolset=sun stdlib=sun-stlport -q

4 9

[asio] read_until -- possibly misleading documentation?
by Richard Smith 15 Apr '10

15 Apr '10

The documentation for Boost.ASIO (which is otherwise very comprehensive) says of the boost::asio::read_until set of overloads: | Read data into a streambuf until a delimiter is | encountered. <http://www.boost.org/doc/libs/1_35_0/doc/html/boost_asio/reference/read_unt…> What the function actually does is to read blocks of data into the streambuf, and stop when the delimiter is found. This means that frequently data beyond the delimiter will be read into the streambuf. (And this is elaborated in more detail on the individual function's pages, if a reader looks there.) I appreciate that this behaviour is compatible with the documentation, but someone less familiar with ASIO could easily assume that the function will read as far as the delimiter and no further. (And I have just spent a fair amount of time debugging a piece of code where the author had made this assumption.) Could we change the summary documentation to read something like: | Read data into a streambuf at least until a delimiter is | encountered. The implementation may read beyond the | delimiter, but will not block when doing so. While I'm on the subject of ASIO documentation, I can't see any documentation on whether the service_name parameters to the basic_resolver_query constructors are allowed to be port numbers (e.g. "80") or whether they have to be symbolic names (e.g. "http"). Port numbers work, at least on Linux, but it's not clear whether this is something that I should be relying on. Similarly for IPv4 and IPv6 addresses in the host_name parameter. Richard Smith

3 2

[TypeTraits] is it possible to add something to boost.type_traits?
by frederic.bron＠alcan.com 17 Dec '09

17 Dec '09

Dear boost implementers, TypeTraits is very useful, thanks you. However, recently, I needed something to know if a type is comparable (with operator<) and that was not in the library. Fortunately, somebody forwarded me an earlier post on the users list where I could find what I wanted. The implementation was inspired from boost/detail/is_incrementable.hpp I have written is_less_comparable, is_less_equal_comparable, is_greater_comparable... inspired from the same source and I wonder if it could be possible to add it to the library as I think it could be helpful for others. I give the source code below (if it is useful) but I am not able to make it fully general as it is in boost/type_traits. In particular, I do not understand all the macros that are used. Regards, F. Bron (See attached file: is_comparable.hpp) Avis : Ce message et toute pièce jointe sont la propriété d'Alcan et sont destinés seulement aux personnes ou à l'entité à qui le message est adressé. Si vous avez reçu ce message par erreur, veuillez le détruire et en aviser l'expéditeur par courriel. Si vous n'êtes pas le destinataire du message, vous n'êtes pas autorisé à utiliser, à copier ou à divulguer le contenu du message ou ses pièces jointes en tout ou en partie. Notice: This message and any attachments are the property of Alcan and are intended solely for the named recipients or entity to whom this message is addressed. If you have received this message in error please inform the sender via e-mail and destroy the message. If you are not the intended recipient you are not allowed to use, copy or disclose the contents or attachments in whole or in part.

11 23

Re: [boost] Formal Review Request: Boost.String.Convert
by Vladimir.Batov＠wrsa.com.au 02 Dec '09

02 Dec '09

I understand we'll never manage to please everyone. Apologies. For now I am settling on the boost::convert interface as I very much agree with the arguments Robert's put forward for it and I feel there is the least disagreement around this interface. Surely boost::convert() has issues of its own. However, I feel the path (convert::to_string->convert::to->convert) how I myself arrived to this logical (IMHO) conclusion seemed reasonable. More so, despite its subtle (to some) directionality the interface has proven to work (as it is essentially the same interface as for lexical_cast). You cannot deny that I made considerable sacrifices (my pets "string" namespace and "to/from" are gone, something I was ready to die :-) for yesterday...). I am hoping the others could make some concessions as well and we would settle on boost::convert()... for now. If some other issues pop up that we missed so far, we'll revisit the issue. It is because I would very much like to move forward and start looking at the functionality and implementation. Do you think it is possible or I am rushing things again? I somewhat cleaned up the implementation (removed to/from, etc.). However, before going forward I'd like to discuss one important thing that's been bugging me since Scott brought it up. Namely, all conversions are now implemented as discriminated functions like // string-to-type conversion template<class TypeOut, class StringIn> typename boost::enable_if_c< !is_string<TypeOut>::value && is_string<StringIn>::value, detail::from_string<StringIn, TypeOut> >::type convert(StringIn const& from_str, TypeOut const& default_value =TypeOut()) { return detail::from_string<StringIn, TypeOut>(from_str, default_value); } However, Scott mentioned that and I feel that might be cleaner if we could implement it as namespace boost { template<class TypeOut, class TypeIn, class Enable =void> class convert; } Then for every conversion we'll be able to encapsulate *complete* implementation in the respective specialization class. Like for string-to-type template< class TypeOut, class StringIn, typename boost::enable_if_c< !is_string<TypeOut>::value && is_string<StringIn>::value, void>::type> class convert { convert(StringIn const& from_str, TypeOut const& default_value =TypeOut()); }; The reason I like it is that it eliminates other support/intermediate classes (like something used-to-called boost::string::value<...> and detail::from_string) and we can do int i = convert(str, -1); // Nothing changed. a 'convert' instance created on the stack and converted to 'int'. convert<int, string> checked(str, -1); // named 'convert' is created. convert<int, string> checked = convert(str, -1); // the same but some might like this syntax better. if (checked.good()) success // we can check the success as ussed to with boost::string::value It feels that approach gives us considerably more room for expansion as some special conversions will be able to have methods only specific to that particular conversion. For this approach to work with algorithms we'll need class convert { static TypeOut apply(TypeIn const&); }; and then std::transform( ints.begin(), ints.end(), std::back_inserter(strings), convert<string, int>::apply); Thanks, Vladimir.

9 63

proposal interval container; ITL moved to the boost sandbox
by Joachim Faulhaber 11 Nov '09

11 Nov '09

Dear boosters, after completion of a lot of boostification work I moved my Interval Template Library to the boost sandbox in the boost project centric form: https://svn.boost.org/trac/boost/browser/sandbox/itl itl boost itl [itl_xt] [validate] libs itl [itl_xt] [validate] I have split up the original library into three parts: (1) itl, (2) itl_xt and (3) validate. Core part 1 'ITL' contains all interval container class templates. Only this part will be prepared for a formal submission. Part 2 'itl_xt' contains extended parts of the original library that do not belong to the core interval container data structures and might be proposed for later extensions. Part 3 'validate' contains the sources for the law based test automaton 'LaBatea' that has been used for an automated check of the ITLs correctness. Parts 2 and 3 do not yet conform boost standards and naming conventions and are not yet intended as contributions to boost. On the core ITL-part I have done the following: + Removed all virtual functions via introduction of mixins + Integrated deeper into boost libraries replacing own code by e.g. boost::type_traits and boost::mpl + Minimized the class template interfaces by transforming member functions into non member function templates. + Made interval containers more interoperable by overloading operators and global function templates. + Wrote a test suite using boost unit test tools. Tested for boost-instance types boost::date_time and boost::rational + Provided jamfiles to build and run examples and tests. + All examples and tests have been compiled, linked and run successfully with msvc_9.0 and gcc_3.4.4(cygwin). Next I am going to write boost style html-documentation. >From the boost web page I don't see a clear recommendation for a preferable way of doing that. Handcoded? Generated with BoostBook? Is there a reference library that has an exemplary standard documentation? Cheers Joachim

3 4

RFC: interest in Unicode codecs?
by Cory Nelson 23 Jul '09

23 Jul '09

Is there interest in having a Unicode codec library submitted to Boost? Here is what I have (only tested with GCC 4.3 on Debian, and VC++ 2008): http://svn.int64.org/viewvc/int64/snips/unicode.hpp Right now it is pretty simple to use: transcode<utf8, utf16le>(forwarditerator, forwarditeratorend, outputiterator, traits [, maximum]); transcode<wchar_encoding, utf32be>(inputrange, outputrange, traits [, maximum]); There is also a codecvt facet which supports any-to-any. Supports UTF-8, UTF-16, and UTF-32, in little or big endian. Has a special wchar_encoding that maps to UTF-16 or UTF-32 depending on your platform. A traits class controls error handling. -- Cory Nelson

11 30

Re: [boost] RFC: interest in Unicode codecs?
by Graham 18 Jul '09

18 Jul '09

Dear Phil, >Having said all that, I must say that I actually use the code that I >wrote quite rarely. I now tend to use UTF8 everywhere and treat it as >a sequence of bytes. Because of the properties of UTF8 I find it's >rare to need to identify individual code points. For example, if I'm >scanning for a matching " or ) I can just look for the next matching >byte, without worrying about where the character boundaries are. Using UTF-8 can work well if you are only targeting American and Western Europe for non-literary use. If you need to support the rest of the world you really need to move to UTF-32 due to the large number of characters and the grapheme and glyph handling [e.g. in Urdu you can type 3 characters and they are displayed as a single combined glyph, and the cursor should never be placed between them]. Even in UTF-8 things can get a bit tricky. For example, where do you break the line if you needed in the middle of: joe)jack -> joe) <br> jack joe(jack -> joe <br> (jack joe+jack -> guess which is the standard ! For programmers we don't mind too much, but when you are writing text editors this can be really important. Now think how many characters there are with special rules on whether they can be split before, after, or never split, and you start to touch on the reason for the Unicode standard and why you need character properties. Yours, Graham

5 4

Mark throw_exception as noreturn?
by Andrey Semashev 05 Jul '09

05 Jul '09

Hi, I was wondering why the throw_exception function is not marked as noreturn? This makes it troublesome to use it as a drop-in replacement for throw statements as it starts to flag compiler warnings about missing return statements in non-void functions. I suggest to mark the function as noreturn at least for compilers that support it. GCC has __attribute__((noreturn)), MSVC has __declspec(noreturn).

4 6

[Graph] iterator range splitting
by Tim Keitt 28 Jun '09

28 Jun '09

I've run into some problems with the Graph library as there is a lot of code that splits iterator ranges. An example of this is: (from depth_first_search.hpp) template <class VertexListGraph, class DFSVisitor, class ColorMap> void depth_first_search(const VertexListGraph& g, DFSVisitor vis, ColorMap color) { // // should the below not be: // graph_traits<VertexListGraph>::iterator vi, vend; // tie(vi, vend) = vertices(g); // if ( vi == vend ) ... ??? // or perhaps to be more terse // if ( empty_range(vertices(g)) ) // where empty_range(g) compares first and second // if (vertices(g).first == vertices(g).second) return; depth_first_search(g, vis, color, *vertices(g).first); } This is causing problems in my code where I have defined custom graph classes. In my case out_edges(g) != out_edges(g) because memory is allocated within the out_edges call and successive calls will return different ranges (vertex ranges are not a problem in my case as I use a simple counting iterator). Must out_edges(g) == out_edges(g) for a graph class to meet the Graph library requirements? If not, then a good bit of the code needs to be altered and possibly some of the iterator macros deprecated. Below I've located every instance where the first or second member of an iterator pair is thrown away. These cases are only problematic if the retained iterator is later compared to an iterator from another range. The fix is simple. One only needs to retain both members of the iterator pair. I am willing to provide a patch if it is agreed that the current code is wrong. THK egrep '(vertices|edges)$.*$\.(first|second)' * adjacency_list_io.hpp: for (vi = vertices(graph).first; vi != vertices(graph).second; ++vi){ adjacency_list_io.hpp: for (ei = edges(graph).first; ei != edges(graph).second; ++ei){ adjacency_list_io.hpp: for (vi = vertices(this->graph).first; vi != vertices(this->graph).second; ++vi){ adjacency_matrix.hpp: return *vertices(g).first; adjacency_matrix.hpp: return *vertices(g).first; adj_list_serialize.hpp: for (vi = vertices(graph).first; vi != vertices(graph).second; ++vi) { adj_list_serialize.hpp: for (ei = edges(graph).first; ei != edges(graph).second; ++ei){ bc_clustering.hpp: if (edges(g).first == edges(g).second) return; bc_clustering.hpp: edge_descriptor e = *max_element(edges(g).first, edges(g).second, cmp); bc_clustering.hpp: } while (!is_done && edges(g).first != edges(g).second); cuthill_mckee_ordering.hpp: if (vertices(G).first == vertices(G).second) cuthill_mckee_ordering.hpp: if (vertices(G).first == vertices(G).second) depth_first_search.hpp: if (start_vertex != implicit_cast<Vertex>(*vertices(g).first)){ vis.start_vertex(start_vertex, g); depth_first_search.hpp: if (vertices(g).first == vertices(g).second) depth_first_search.hpp: depth_first_search(g, vis, color, *vertices(g).first); depth_first_search.hpp: if (vertices(g).first == vertices(g).second) depth_first_search.hpp: *vertices(g).first), edge_connectivity.hpp: std::set_difference(vertices(g).first, vertices(g).second, edge_connectivity.hpp: std::set_difference(vertices(g).first, vertices(g).second, fruchterman_reingold.hpp: Dim minX = position[*vertices(g).first].x, maxX = minX; fruchterman_reingold.hpp: Dim minY = position[*vertices(g).first].y, maxY = minY; graph_test.hpp: bgl_first_9 = vertices(g).first, bgl_last_9 = vertices(g).second; graph_test.hpp: bgl_first_9 = vertices(g).first, bgl_last_9 = vertices(g).second; howard_cycle_ratio.hpp: if (boost::out_edges(vd1, m_g).first == boost::out_edges(vd1, m_g).second) throw bad_graph(m_vim[vd1]); howard_cycle_ratio.hpp: mcr_edge_t ed = *boost::out_edges(vd1, m_g).first; howard_cycle_ratio.hpp: good_vertex = boost::target(*boost::out_edges(good_vertex, m_pi_g).first, m_pi_g); howard_cycle_ratio.hpp: pi_edge_t tmp_ed = *(boost::out_edges(vd, m_pi_g).first); howard_cycle_ratio.hpp: remove_edge(*(out_edges(m_g2pi_g_vm[vd], m_pi_g).first), m_pi_g); is_kuratowski_subgraph.hpp: bipartition_start = next(next(next(vertices(K_3_3).first))); is_kuratowski_subgraph.hpp: si = vertices(contracted_graph).first; isomorphism.hpp: for (typename graph_traits<Graph1>::edge_iterator e1 = edges(g1).first; isomorphism.hpp: e1 != edges(g1).second; ++e1) { isomorphism.hpp: for (typename graph_traits<Graph2>::edge_iterator e2 = edges(g2).first; isomorphism.hpp: e2 != edges(g2).second && !found_edge; ++e2) { iteration_macros.hpp: bgl_first_9 = vertices(g).first, bgl_last_9 = vertices(g).second; iteration_macros.hpp: BGL_FIRST(__LINE__) = vertices(GNAME).first, BGL_LAST(__LINE__) = vertices(GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = vertices(GNAME).first, BGL_LAST(__LINE__) = vertices(GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = edges(GNAME).first, BGL_LAST(__LINE__) = edges(GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = edges(GNAME).first, BGL_LAST(__LINE__) = edges(GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = adjacent_vertices(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = adjacent_vertices(UNAME, GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = adjacent_vertices(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = adjacent_vertices(UNAME, GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = out_edges(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = out_edges(UNAME, GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = out_edges(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = out_edges(UNAME, GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = in_edges(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = in_edges(UNAME, GNAME).second; \ iteration_macros.hpp: BGL_FIRST(__LINE__) = in_edges(UNAME, GNAME).first,\ iteration_macros.hpp: BGL_LAST(__LINE__) = in_edges(UNAME, GNAME).second; \ johnson_all_pairs_shortest.hpp: typename Traits2::vertex_descriptor s = *vertices(g2).first; kamada_kawai_spring_layout.hpp: for (vertex_iterator ui = vertices(g).first, end = vertices(g).second; kamada_kawai_spring_layout.hpp: vertex_iterator ui, end = vertices(g).second; kamada_kawai_spring_layout.hpp: for (ui = vertices(g).first; ui != end; ++ui) { kamada_kawai_spring_layout.hpp: vertex_descriptor p = *vertices(g).first; kamada_kawai_spring_layout.hpp: for (ui = vertices(g).first; ui != end; ++ui) { kamada_kawai_spring_layout.hpp: for (ui = vertices(g).first; ui != end; ++ui) { kamada_kawai_spring_layout.hpp: for (ui = vertices(g).first; ui != end; ++ui) { kamada_kawai_spring_layout.hpp: for (ui = vertices(g).first; ui != end; ++ui) { king_ordering.hpp: if (vertices(G).first == vertices(G).second) king_ordering.hpp: if (vertices(G).first == vertices(G).second) metric_tsp_approx.hpp: Vertex v(*vertices(g).first); metric_tsp_approx.hpp: metric_tsp_approx_from_vertex(g, *vertices(g).first, metric_tsp_approx.hpp: metric_tsp_approx_from_vertex(g, *vertices(g).first, metric_tsp_approx.hpp: metric_tsp_approx_from_vertex(g, *vertices(g).first, metric_tsp_approx.hpp: metric_tsp_approx_from_vertex(g, *vertices(g).first, w, metric_tsp_approx.hpp: metric_tsp_approx_from_vertex(g, *vertices(g).first, w, id, vis); metric_tsp_approx.hpp: Tree t(mst, *vertices(mst).first, minimum_degree_ordering.hpp: adj_iter nu = adjacent_vertices(u_node, G).first; planar_canonical_ordering.hpp: vertex_t first_vertex = *vertices(g).first; prim_minimum_spanning_tree.hpp: choose_param(get_param(params, root_vertex_t()), *vertices(g).first), prim_minimum_spanning_tree.hpp: (g, *vertices(g).first, predecessor_map(p_map). property_iter_range.hpp: return std::make_pair(iter(vertices(graph).first, get(tag, graph)), property_iter_range.hpp: iter(vertices(graph).second, get(tag, graph))); property_iter_range.hpp: return std::make_pair(iter(vertices(graph).first, get(tag, graph)), property_iter_range.hpp: iter(vertices(graph).second, get(tag, graph))); property_iter_range.hpp: return std::make_pair(iter(edges(graph).first, get(tag, graph)), property_iter_range.hpp: iter(edges(graph).second, get(tag, graph))); property_iter_range.hpp: return std::make_pair(iter(edges(graph).first, get(tag, graph)), property_iter_range.hpp: iter(edges(graph).second, get(tag, graph))); push_relabel_max_flow.hpp: current(num_vertices(g_), out_edges(*vertices(g_).first, g_).second), push_relabel_max_flow.hpp: current[u] = out_edges(u, g).first; push_relabel_max_flow.hpp: current[v] = out_edges(v, g).first; push_relabel_max_flow.hpp: for (ai = current[u], ai_end = out_edges(u, g).second; push_relabel_max_flow.hpp: current[u] = out_edges(u, g).first; push_relabel_max_flow.hpp: for (; current[u] != out_edges(u, g).second; ++current[u]) { push_relabel_max_flow.hpp: if (current[u] == out_edges(u, g).second) { push_relabel_max_flow.hpp: ai = out_edges(u, g).first; push_relabel_max_flow.hpp: while (excess_flow[u] > 0 && ai != out_edges(u, g).second) { push_relabel_max_flow.hpp: ai = out_edges(u, g).first; random.hpp: i = vertices(g).first; random.hpp: return *vertices(g).first; random.hpp: i = edges(g).first; random.hpp: return *edges(g).first; sloan_ordering.hpp: s = *(vertices(G).first); undirected_dfs.hpp: if (start_vertex != *vertices(g).first){ vis.start_vertex(start_vertex, g); undirected_dfs.hpp: undirected_dfs(g, vis, vertex_color, edge_color, *vertices(g).first); undirected_dfs.hpp: *vertices(g).first), -- Timothy H. Keitt http://www.keittlab.org/

6 16

Proposed addition to the iterator library for iterating over all tuples.
by Alex Mendes da Costa 19 Jun '09

19 Jun '09

Hi folks: I quite often have to write code to do the following: Given N sequences, generate all the N-tuples s.t. the i'th element in each tuple is drawn from the i'th sequence. For example, if sequence S1 is { 1, 2, 3 } and sequence S2 is { 10, 20 }, I need to generate these tuples: (1, 10), (2, 10), (1, 20), (2, 20). I think this problem could be solved elegantly with a iterator similar to zip_iterator. I have some questions: (1) Is there already a way to do this in boost? (2) If not, would this be a worthwhile addition to the iterator library? (3) If so, could I contribute code for this, or must the existing library owners write it? (4) If so, how would I go about getting my code added? Most of the docs seem to be about submitting entire libraries, rather than extensions to existing libraries. Thanks, Alex

4 18

[mpl] is there a or_seq like logical metafunction?
by vicente.botet 17 Jun '09

17 Jun '09

Hello, I needs calculate the mlp::or_ of a sequence of nullary logical metafunction. This seams quite simple. I have do the following: <code> template <typename Seq> struct or_seq; template <typename Seq, long N> struct or_seq_aux : mpl::or_< typename mpl::front<Seq>::type, or_seq<typename mpl::pop_front<Seq>::type> > {}; template <typename Seq> struct or_seq_aux<Seq, 1> : mpl::front<Seq>::type {}; template <typename Seq> struct or_seq : or_seq_aux<Seq, mpl::size<Seq>::value> {}; </code> Is there a boost or_seq like logical metafunction? Is there a better way to do it? I would be extremely interested in any suggestions. Best regards --------------------------- Vicente Juan Botet Escriba

5 34

[New Feature Suggestion] Dynamic exception handlers registration
by Alex Tkachenko 17 May '09

17 May '09

Hello there. A while back I wrote usefull tool for organizing exception handling. The general idea is borrowed from boost::execution_monitor (http://www.boost.org/doc/libs/1_38_0/libs/test/doc/html/execution-monitor.h…) . Similarly, I call this unit "Exception Monitor". It allows to dynamically register exception converters and convert exception objects from any source types to arbitrary target type. For instance, if you write some integration code which uses several external modules, and each of these modules could generate their own tree of exceptions, you would face serious issue trying to implement error diagnostic. One approach is to handle only base exception for each module and to catch them in function main(). Let's assume that all exceptions are inherited from std::exception, so we need to catch single base (std::exception). This approach is convenient but not precise. Even if we want just to output error message using std::exception::what() we have only some general low level error description, moreover this description could be completely wrong. It doesn't reflect actual cause of the error because at the place where the exception is originally generated it couldn't know about context of execution. On the contrary, we can catch low-level exceptions in the place where execution context is more obvious and convert it to some "application" exception which contains more information about current situation. This is the solution for detailed error diagnostic, but it is too tedious. Also such code is unscalable, error prone and hard to support. Look at the following example: /////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////// class app_error: public virtual std::exception { ... }; void foo() { try { ...local state... unit1::foo(...); unit2::foo(...); } catch(const unit1::exception1& ex) { //...convert caught exception to app_error using local state throw app_error(...); } catch(const unit1::exception2& ex) { //...convert caught exception to app_error using local state throw app_error(...); } catch(const unit2::exception& ex) { //...convert caught exception to app_error using local state throw app_error(...); } } int main() { try { foo(); } catch(const app_error& ex) { cout << "Error: " << ex.what() << endl; } catch(const std::exception& ex) { cout << "Unknown error: " << ex.what() << endl; } catch(...) { cout << "Unknown error" << endl; } } The main drawback of this source code is that exception handling is mixed with 'main' code. It would be better if we could write something like this: /////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////// class app_error: public virtual std::exception { ... }; typedef exc::catcher<app_error> app_catcher; //...exception catcher type typedef std::list<app_catcher> app_catchers; //...container for catchers struct convert_unit1_ex1 { const app_error operator()(const unit1::exception1&); }; struct convert_unit1_ex2 { const app_error operator()(const unit1::exception2&); }; struct convert_unit2_ex { const app_error operator()(const unit2::exception&); }; app_catchers excon; void foo() { ...local state... //...register catchers for possible exceptions excon.push_front( app_catcher::create<unit1::exception1>( convert_unit1_ex1(...local state...))); excon.push_front( app_catcher::create<unit1::exception2>( convert_unit1_ex2(...local state...))); excon.push_front( app_catcher::create<unit2::exception>( convert_unit2_ex(...local state...))); //... unit1::foo(); unit2::foo(); //...good idea is to use RAII to register catchers to avoid this //...manual deregistration: excon.pop_front(); excon.pop_front(); excon.pop_front(); } int main() { try { guard(excon, foo()); } catch(const app_error& ex) { cout << "Error: " << ex.what() << endl; } catch(const std::exception& ex) { cout << "Unknown error: " << ex.what() << endl; } catch(...) { cout << "Unknown error" << endl; } } Pluses of this technique: 1) it encourages developer to implement exception handlers code separatly from 'main' code; 2) it provides framework for detailed exception handling; 3) it offers flexible means for structural arrangement of exception handlers' source code. Very interesting feature of Exception Monitor is ability to sort catchers in "proper" order regarding their inheritance. So catcher for std::runtime_error should be earlier then std::exception. This is what functions exc::insert and exc::replace do. Library source code (it's tested it on gcc 4.3.1): #ifndef EXCEPTION_MONITOR_HEADER_GUARD #define EXCEPTION_MONITOR_HEADER_GUARD /* * Exception Monitor: * allowes dynamic exception handlers registration * Author: Alex Tkachenko * 2009.02.10 */ #include <cassert> #include <boost/function.hpp> #include <boost/static_assert.hpp> #include <boost/type_traits/is_base_of.hpp> #include <boost/shared_ptr.hpp> #include <typeinfo> namespace exc { namespace details { class failed_to_catch_exception {}; //... class try_catcher_base { public: virtual ~try_catcher_base() {} virtual void convert() const = 0; virtual void try_throw_self_exception() const = 0; virtual bool try_catch_self_exception( const try_catcher_base& other) const = 0; virtual const std::type_info& type() const = 0; }; template<typename Texception_to, typename Texception_from> class try_catcher: public try_catcher_base { typedef boost::function<const Texception_to (const Texception_from&)> converter_f; public: try_catcher(const converter_f& iconverter): converter(iconverter) { assert(!converter.empty() && "Null converter"); } private: void convert() const { try { throw; } catch(const Texception_from& ex) { throw converter(ex); } catch(...) { throw failed_to_catch_exception(); } } void try_throw_self_exception() const { throw (Texception_from*)0; } bool try_catch_self_exception(const try_catcher_base& other) const { try { other.try_throw_self_exception(); } catch(Texception_from*) { return true; } catch(...) { return false; } } const std::type_info& type() const { return typeid(Texception_from); } //... converter_f converter; }; }//...namespace details template<typename Texception_to> class catcher { typedef boost::shared_ptr<details::try_catcher_base> impl_t; catcher(const impl_t& iimpl): impl(iimpl) { assert(impl && "NULL catcher implementation"); } void convert() const { impl->convert(); } void try_throw_self_exception() const { impl->try_throw_self_exception(); } bool try_catch_self_exception(const catcher& other) const { return impl->try_catch_self_exception(*other.impl); } public: typedef Texception_to Texception_to_type; template<typename Texception_from> static const catcher create( const boost::function<const Texception_to (const Texception_from&)> converter) { //...it's senseless to convert from derived to base exception, //...or convert exception to its own type BOOST_STATIC_ASSERT( (!boost::is_base_of<Texception_to, Texception_from>::value)); return catcher( impl_t( new details::try_catcher<Texception_to, Texception_from>( converter))); } //... const std::type_info& type() const { return impl->type(); } void swap(catcher& rhs) { impl.swap(rhs.impl); } private: template<typename Treturn, typename Tcatchers> friend Treturn guard( const Tcatchers& catchers, const boost::function<Treturn ()>& func); template<typename TcatchersIterator> friend TcatchersIterator find( TcatchersIterator begin, TcatchersIterator end, const typename std::iterator_traits<TcatchersIterator>::value_type& catcher); //... impl_t impl; }; template<typename Treturn, typename Tcatchers> Treturn guard( const Tcatchers& catchers, const boost::function<Treturn ()>& func) { assert(!func.empty() && "Empty function"); typedef typename Tcatchers::value_type::Texception_to_type Texception_to_type; try { return func(); } catch(...) { const typename Tcatchers::const_iterator end(catchers.end()); for(typename Tcatchers::const_iterator iter(catchers.begin()); end != iter; ++iter) { try { iter->convert(); } catch(const Texception_to_type&) { throw; } catch(details::failed_to_catch_exception) { //...try next handler } } throw; } } template<typename Tcatchers> inline void guard( const Tcatchers& catchers, const boost::function<void ()>& func) { guard<void, Tcatchers>(catchers, func); } template<typename Texception_to> inline bool operator==( const catcher<Texception_to>& lhs, const catcher<Texception_to>& rhs) { return lhs.type() == rhs.type(); } template<typename Texception_to> inline bool operator!=( const catcher<Texception_to>& lhs, const catcher<Texception_to>& rhs) { return !(lhs == rhs); } template<typename Texception_to> inline void swap(catcher<Texception_to>& lhs, catcher<Texception_to>& rhs) { lhs.swap(rhs); } template<typename TcatchersIterator> TcatchersIterator find( TcatchersIterator begin, TcatchersIterator end, const typename std::iterator_traits<TcatchersIterator>::value_type& catcher) { for(;end != begin; ++begin) if(begin->try_catch_self_exception(catcher)) return begin; return end; } template<typename Tcatchers> void insert(Tcatchers& catchers, const typename Tcatchers::value_type& catcher) { typename Tcatchers::iterator iter( exc::find(catchers.begin(), catchers.end(), catcher)); catchers.insert(iter, catcher); } template<typename Tcatchers> void replace(Tcatchers& catchers, const typename Tcatchers::value_type& catcher) { typename Tcatchers::iterator iter( exc::find(catchers.begin(), catchers.end(), catcher)); if(catchers.end() == iter) catchers.push_back(catcher); else if(catcher == *iter) *iter = catcher; else catchers.insert(iter, catcher); } } //...namespace exc #endif /*EXCEPTION_MONITOR_HEADER_GUARD*/

2 1

[RFC] thread::access_monitor
by Gregory Petrosyan 14 May '09

14 May '09

I would like to hear your comments on the idea behind access_monitor template, which ensures (at compile-time) that data, protected by it, can be accessed only with associated lock held. It can be useful when you want to expose all the native interface of your data type (STL container, for example): in such a case, using ordinary monitor pattern is almost impossible. Example usage: typedef access_monitor<data_type, mutex_type> data_access_monitor; void f(data_access_monitor const& d) { data_access_monitor::value_type const* data; data_access_monitor::lock_type lock; boost::tie(data, lock) = d.const_lock(); // do something with data here } Code: #include <boost/thread.hpp> #include <boost/tuple/tuple.hpp> template <typename T, typename Lockable> struct access_monitor { typedef T value_type; typedef boost::unique_lock<Lockable> lock_type; private: typedef boost::detail::thread_move_t<lock_type> lock_move_type; public: boost::tuple<value_type const*, lock_move_type> const_lock() const { lock_type lock(mutex_); return boost::make_tuple(&data_, lock.move()); } boost::tuple<value_type*, lock_move_type> lock() { lock_type lock(mutex_); return boost::make_tuple(&data_, lock.move()); } private: // mutex_ is guaranteed to be locked when you access data_ mutable Lockable mutex_; T data_; }; Sorry for draft-quality code (however, something like the above compiles with MSVC 9). Please CC me, because I am not subscribed. Gregory

2 1

[scope_exit] Boost.ScopeExit capturing 'this'
by adam.butcher＠selex-comms.com 11 May '09

11 May '09

I wasn't sure whether I had the correct address for Boost.ScopeExit's author Alexander Nasonov, so I've submitted to this list just in case and to get feedback from other users. I have been playing with BOOST_SCOPE_EXIT -- it it very convenient. One thing I would have liked would be to capture 'this' inside member functions. I have created a patch which adds BOOST_SCOPE_EXIT_THIS to do just that. It provides an operator->() in the generated struct which can be used to access the enclosing class's members. The syntax is: BOOST_SCOPE_EXIT_THIS( (&a) (&b) ) { a; b; // local captures (*this)->member; // member access } BOOST_SCOPE_EXIT_END; and can be BOOST_SCOPE_EXIT_THIS() { (*this)->member; } BOOST_SCOPE_EXIT_END; providing the preprocessor allows for empty parameter lists (which gcc does and vc does albeit after disabling a warning to remove noise). The type pointed to by the result of operator->() is correctly cv qualified. It has been tested on gcc 4.3, gcc 4.2, msvc 7.1 and msvc 9.0. I don't have access to other compilers. Boost.Typeof worked fine on gcc for typeof(this) -- mostly because gcc has a native typeof I guess. On visual studio (vc71 and vc90) it was not so good -- a compiler bug ( http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedba… , http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?Feedba… ) that has been marked as 'Won't fix' means that 'this' cannot be used in expressions within template argument lists -- even if those expressions are innocuous typeid()s or sizeof()s for type-inference. The common workaround (capturing a compile-time integer with an enumerator and using the enumerator in the template parameter list) doesn't work with the vc71-specific implementation of Boost.Typeof since it is based on typeid() -- this cannot be captured in a compile-time expression (or I know of no way to that doesn't involve the expression existing in a template argument list). All is not lost though -- the general-purpose sizeof() based approach for the other VC versions works fine for VC71 for determining the typeof 'this'. As such my patch includes a VC>=1300 specific workaround for typeof 'this' determination. This is unfortunate but I couldn't think of any other non-intrusive way of doing it. Please find the attached patch and let me know what you think -- I'm sure this feature would be useful to users -- it saves having to do: TypeOfMyClassWhichCouldBeTedious* self = this BOOST_SCOPE_EXIT( (&self) ) { self->member; } BOOST_SCOPE_EXIT_END; which removes the convenience of BOOST_SCOPE_EXIT in these contexts since something like: struct at_end { TypeOfMyClassWhichCouldBeTedious* self; ~at_end() { self->member; } } at_end = {this}; can be done without any dependencies to achieve the same result. Regards, Adam. ------------------------------------------------------------ This email and any attached files contains company confidential information which may be legally privileged. It is intended only for the person(s) or entity to which it is addressed and solely for the purposes set forth therein. If you are not the intended recipient or have received this email in error please notify the sender by return, delete it from your system and destroy any local copies. It is strictly forbidden to use the information in this email including any attachment or part thereof including copying, disclosing, distributing, amending or using for any other purpose. In addition the sender excludes all liabilities (whether tortious or common law) for damage or breach arising or related to this email including but not limited to viruses and libel. SELEX Communications Limited is a Private Limited Company registered in England and Wales under Company Number 964533 and whose Registered Office is Lambda House, Christopher Martin Rd, Basildon, SS14 3EL. England.

4 8

Proposed templated integer_sort
by Steven Ross 25 Apr '09

25 Apr '09

Would there be interest in an integer_sort call that is faster than std::sort? Spreadsort is an in-place hybrid radix-based and comparison-based algorithm with better worst-case and average-case (roughly 20-50%) performance than introsort on random integer data. The worst-case advantage is algorithmic, with Spreadsort taking the better of O(n(square_root(bit_sizeof(data) - log(n)))) and O(nlog(n)) time. For 32-bit integers, that's O(n(square_root(32 - log(n)))), so for a log(n) of 16 (65536 items), it's 4n (plus a small constant times n), vs 16n for introsort. For larger n, the advantage vs. pure comparison-based algorithms increases. In effect, Spreadsort smoothly transitions from pure MSB Radix sort to std::sort with its data cut up by a couple iterations of MSB Radix sort (reducing the size of the log(n) factor), depending upon the distribution and size of the data. I could write a templated version of Spreadsort for the Boost library if there is interest. It would work for anything that supports the << and - operators. It could also handle standard floats sorted as integers. Functors supporting << and - could make it more general. Multi-dimensional sorting is also sped up by Spreadsort. I could also write a similar string_sort, that should also be significantly faster than std::sort. This would look much like postal sort, just using introsort after a certain number of iterations. Is this of interest? http://sourceforge.net/projects/spreadsort

15 118

Boost.Process 0.3 released
by Boris 14 Apr '09

14 Apr '09

I've released Boost.Process 0.3. Here's the documentation and a link to download the zip archive: Docs: http://www.highscore.de/boost/process/ Code: http://www.highscore.de/boost/process.zip It's a header-only library and thus pretty easy to use: Just copy the files to your Boost directory. In this release my main goal was to merge various snapshots: * There was my Boost.Process 0.2 version which was based on Boost.Process 0.1 from 2006. * There was a post-0.1 version of Boost.Process in SVN from 2007. * Chris Fairles had modified a Boost.Process snapshot for Unix platforms. * Ion Gaztañaga had also some ideas and bug fixes he sent to this mailing list recently. I just saw that Ilya Sokolov created another snapshot based on Boost.Process in SVN. That means we have again at least two different versions of Boost.Process. :-/ In my Boost.Process 0.3 version I concentrated on merging and overhauling code. I did not change the design but tried to make the code work: All the code which was written since 2006 should become usable. That's why I also concentrated a lot on test cases. There are quite a lot of test cases, and they all can be built and passed successfully on three platforms with four compilers. As it would be great if others run the test cases, too (ideally on new platforms), I'll send another message in a few minutes with a description how to run the test cases yourself. As the documentation was written in 2006 I also updated it. It's not yet really a good documentation: There are some files coming from 2006 while other files I wrote myself only last week. While the documentation can be improved it's at least up-to-date: The examples all work and can be compiled. As the documentation was not my priority for Boost.Process 0.3 it should be ok for now. Boris

9 14

[filesystem] Version 3 request for comments
by Beman Dawes 12 Apr '09

12 Apr '09

A prototype implementation of version 3 of Boost.Filesystem is available for comment. The critical feature of this prototype is the replacement of the class basic_path template with a single class path that supports both narrow and wide character paths. It also supports user supplied types, and will support the new C++0x char16_t and char32_t character types as compiler and standard library support becomes available. There is still a lot of additional work before V3 could be added to the trunk and eventually released. For example, work so far has concentrated on the new functionality, and ignored breaking changes to existing code. But enough stuff is working to make requesting comments useful. See http://svn.boost.org/svn/boost/sandbox/filesystem-v3/libs/filesystem/doc/v3… for a fuller description of the prototype and links to the prototype implementation. I've got some specific issues I'd like opinions on, but would first like to hear comments from anyone interested. --Beman

11 21

Final report of GSOC project 'Spatial Indexes'
by Federico J. Fernández 27 Mar '09

27 Mar '09

Hi List! I'm writing this email as a final report of my Google Summer of Code 2008 project for Boost. My project consist in adding some spatial indexing structures to Boost in the context of the Geometry proposal done by Barend Gehrels. Spatial indexes are data structures optimized for spatial oriented queries. The classic index structures (i.e. a binary tree) aren't spatially enabled, they have different ordering criteria but none of them relates to topological properties. The scope of these structures is really wide, from collision detection for games to geometry indexing for GIS software. The original project goals were: - Build a Quadtree. - Build an rTree. - Integrate some previous work from a former GSoC project of a k-d-tree. - Test and document everything. Both indexes are implemented now and everything is tested and documented. The only task that we didn't complete is the k-d-tree integration, because when we analyzed the code it was not ready, and we didn't have the time to finish it. About the results, we made several tests and benchmarks. We tested both indexes with 230.000 objects from GIS data to check the correctness of the implementation, and we made some benchmarks comparing the quadtree vs. rtree and comparing both of them to existing implementation (like GEOS) with very good results. We describe this benchmarks in the documentation offering this as a guide to choose the best index for each use. The code is still beta (or maybe alpha) and not recommended for production use because it is still not tested enough, but if you want to check the actual status you can find it in the following location: https://svn.boost.org/svn/boost/sandbox/SOC/2008/spacial_indexing/ And the docs are at: https://svn.boost.org/svn/boost/sandbox/SOC/2008/spacial_indexing/libs/spat… The future work now is huge. We have some ideas about integrating this in some way to multindexes, and we want to implement also a 'packed' version of the rtree to improve bulk-loading times among another things. Finally, I would like to thank to Boost for allowing me to be part of this year's SOC. And specially to my mentor Hartmut Kaiser for all his help during the program. -- federico j. fernandez

8 13

[endian] superfluous boost::operators<> ?
by Roland Schwarz 26 Mar '09

26 Mar '09

I discovered, that the following will not compile: unsigned u; ulittle32_t u1; ulittle32_t u2; u = 1; u1 = 1; u2 = u1 + u; The compiler complains about not being able to resolve similar conversions. My guess is, that using boost::operators<> _and_ providing type conversion operators at the same time is causing this. I think it should be enough to define the essential operators in cover_operators template, and omit boost::operators<> at all. At least I am not able to find any problems with this, since the compiler adjusts the arguments (using the provided type conversion operators?) and calls the built in operators, thereby resolving ambiguity. Any thoughts? -- _________________________________________ _ _ | Roland Schwarz |_)(_ | aka. speedsnail | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

2 1

[C++0x] The cpp0x branch has been merged into trunk
by Beman Dawes 21 Mar '09

21 Mar '09

The cpp0x branch has been merged into trunk, enabling a bunch of BOOST_NO_* macros for C++0x feature tests. This should have no impact on existing code, so be sure to let me know if it causes any problems. --Beman

7 19

[fusion] C++0x support?
by Ein Held 17 Mar '09

17 Mar '09

Hello is there any chance for c++0x support (rvalue forwarding for the containers' constructors and operator=s' in particular) for fusion in 1.39? If noone is up to adding support for this to fusion, my collegues and me would love to implement it. Thank you

5 10

Boost.Chrono where we are?
by vicente.botet 16 Mar '09

16 Mar '09

Hi, In November 2008, Beman said: "The Chrono library in the sandbox is now more-or-less feature complete." This library is esential to conform some boost libraries implementing standard libraries as Boost.Thread and Boost.Future as much as possible to the standard. It will be used also on the Boost.ThreasPool library and I would like also to use it on my AsynchronousExecutors library. Can we expect to have Boost.Chrono for review soon? Thanks, Vicente

1 1

request for discussion - yet another approach to automated memory management that solves the cycles problem and is very efficient
by Achilleas Margaritis 16 Mar '09

16 Mar '09

Dear boost members, The file 'mm2.zip' (in boost vault/memory) contains yet another solution for automatic memory management. The solution has the following attributes: 1) it solves the problem of cycles. 2) it releases resources deterministically. 3) it does not scan the graph of objects for reachability. It uses simple numeric values (i.e. keys) to determine if an object can be collected or not. The idea is very simple: pointers obtain keys during their construction (a simple global variable that is incremented). The key remains constant throughout the lifetime of a ptr. During pointer release, the pointers that point to an object are scanned: if there is no pointer that points to the object that has a lower key from the key of the releasing pointer, then the object can be deleted. The pointer semantics are normal C pointer semantics, except for the construction: the solution requires that pointers that are lvalues should obtain a key before the heap object that they will be assigned to. i.e. you can't do this: ptr p1 = new object; You have to do this: ptr p1; p1 = new object; All the operations have O(1) complexity, except the release operation, which has O(N) complexity, whereas N is the number of pointers that point to an object. Practically, the complexity is minimal, because it is rare to have that many different pointers to a single object (I think :-)). I have no idea if it works for all cases. The file 'main2.cpp' contains a lot of tests, which all pass. I have also included the benchmark of the Boehm GC modified to use my special ptr classes. In my machine, an Athlon 64 2.2 GHz, the benchmark is executed, using boost pools, at roughly 1900 milliseconds, whereas the Boehm gc benchmark, using the Boehm gc collector, is executed at roughly 1200 milliseconds (and the Java benchmark at roughly 600 milliseconds). The amazing thing is that it looks like it works, but I am not sure. I am sure there is a catch :-).

9 17

Re: [boost] [Boost-users] Maintenace Guidelines wiki page
by vicente.botet 15 Mar '09

15 Mar '09

----- Original Message ----- From: "Tomas Puverle" <Tomas.Puverle(a)morganstanley.com> To: <boost-users(a)lists.boost.org> Sent: Sunday, November 23, 2008 4:31 AM Subject: Re: [Boost-users] Maintenace Guidelines wiki page > >> I have started the Maintenace Guidelines wiki page. >> >> You can access it directly >> https://svn.boost.org/trac/boost/wiki/Guidelines/MaintenanceGuidelines >> >> or via https://svn.boost.org/trac/boost/wiki >> >> Guidelines >> * Maintenance Guidelines >> >> There page need to be completed and surely reworked but this is an starting >> point. >> >> Please be free to improve the page directly or post your comments or > suggestions to this list. >> >> Hopping this goes on the right direction, > > Vincente, > > A few ideas: How will you evaluate that your proposal is actually successful > and being followed by the boost developers? Hi, First this is proposal for guidelines. So people will be after all free to follow some of them or not. I'm expecting from people like you to improve it so it could be followed by more people. > Also, check out Daniel Walker's idea in the Boost.Range thread on boost.devel > about not having the engineers in charge of their own QA. Daniel Walker's idea " Perhaps a procedural solution that could avert this problem in the future is to quarantine the test cases. Authors can maintain commit privileges to their libraries on trunk, but only a select group of independent guardians have commit privileges to the test cases. That way there is a guarantee that libraries pass the same tests from one release to another. If an author would like to make a change that would break a test case, he or she would need to present the change to the list and submit a patch to the test case sentinels. This would be a fairly simple quality assurance protocol: engineers aren't allowed to do their own QA." This is already considered on the guidelines insome way. "Preserve the test from the preceding versions [author] The test from the preceding versions should not be changed when the author modifies its library. These not changed tests are a probe of compatibility with the preceding version. When these test must be changed they indicate a breaking user code issue. So instead of changing them add new ones stating explicitly on which version they were included. Old tests that should fail can be moved to the compile_fail or run_fail tests on the Jamfile. " The Daniel proposal implies some changes in the writing rights of the authors. I prefer to let this point out of these guidelines. Of course I think that this is a good idea. There is another guideline that could be used by the Boost comunity to check the author has not changed the old test cases. "Inspect announced modifications [author, user, RM] The use of the diff file will help to inspect that the modifications introduced have been correctly included on the documentation and a good test coverage has been done. This will result in a non official mini-review of the library. " I will add to check that the old testcases have not been changed. > Finally, please consider the idea of "core" and "new" release cycles, where the > components in "core" have much more stringent requirements on how and when they > are allowed to change. IMO this is out of the scope of the guidelines. Note that at the end it is up to the author to make the modification he/she consider pertinent. Could you send what you have in mind in the form of guidelines? > Finally, do you think it may have been better to start this thread on > boost.devel? I belived that i did it on both. I'm answering to both each time. Should I start a new thread including the guidelines contents? Vicente

14 46

[geometry] area, length, centroid, behavior
by Barend Gehrels 13 Mar '09

13 Mar '09

I would like to hear the opinion of potential geometry users on the list about the following. For the three geometries, point, linestring (= sequence of points), polygon: What should the generic "area" algorithm return for point and linestring? - 0 (zero) - compiler error (so this function is not defined for them at all) - exception Personally I would feel for 0 (zero) because you can then request the "area" in a generic collection, regardless of what is inside. What should the generic "length" algorithm return for polygon? - 0 (zero) - its perimeter - compiler error - exception What should the generic "centroid" algorithm return for point and linestring? - the point / the average its points - compiler error - exception and for an invalid polygon (e.g. no points at all, or not closed)? - exception - return "false" (if centroid is passed as a reference parameter) - ? (we've not always the compiler error option here because points are usually stored in a runtime collection) Thanks, Barend

15 66

Preview 4 of the Generic Geometry Library (ggl)
by Barend Gehrels 13 Mar '09

13 Mar '09

Dear list, It is a pleasure for us to present the fourth preview of the Generic Geometry Library. This time we've added the library to the SVN repository at boost, https://svn.boost.org/svn/boost/sandbox/ggl To store the library under a proper name, "ggl" is used, which stands for Generic Geometry Library. Before this we called it just Geometry Library, but we think Generic is appropriate from this version on. The first three previews were sent to this list in January, March and October 2008. Since then everything has been revised and reworked again, based on comments from the list. Thanks for all your comments! Concepts are now applied for all geometries. Algorithms now take any geometry fulfilling the concepts, and automatically take the right version of the underlying implementation. Ranges are now used instead of .begin()/end(). Tag dispatching is used instead of SFINAE. Transformations: previously these were just explained as an example, now transformations are included in the library, either to go from one coordinate system to another (for example from spherical to cartesian3D) or to translate/rotate/scale/map points from one Cartesian system to another, or otherwise. Map projections: included is an extensive addition with nearly 100 map projections. Those are not programmed by ourselves but automatically converted from C (PROJ4) into a our template-based approach, fitting with the geometry library, especially in the transformations explained above. License-wise this is possible. We're not sure about if this would fit in the Boost Library Collection, if there is interest in it, or that it might be "too much" for it, so we would be glad to hear your opinions. For more change descriptions, see the page on status and preview from the documentation (link below). The Generic Geometry Library is accessible from Boost SVN, mentioned above, or can be downloaded as well from http://geometrylibrary.geodan.nl Especially the examples, such as the custom point example and custom line string example show nicely how the library handles custom geometries and how they can be used inside the generic algorithms. We welcome any type of comment, opinion, cooperation, merge or join. Barend Gehrels, Amsterdam Bruno Lalande, Paris

3 11

[filesystem][cygwin] Standard conformance for wide characters
by Beman Dawes 11 Mar '09

11 Mar '09

I've decided not to attempt support for Cygwin in the next version of Boost.Filesystem. Cygwin's lack of library support for wchar_t is the problem . For the current Boost.Filesystem version (v2), the necessary workarounds are so pervasive that the implementation code is much harder to read and maintain. Witness the number of bug reports that are Cygwin specific. For v3, currently under development, trying to support Cygwin would be even harder, and would cause a serious delay in development. Plus I'm tired of waiting for the cygwin folks to come into full C++ conformance. IIUC, the reason Cygwin doesn't provide C++ standard library support for wchar_t is that the underlying C library is missing the C wchar_t functions. Perhaps Boosters who care about Cygwin could spearhead an effort to add the missing C support? The needed functionality isn't all that complex; the main problem might be just learning enough about how Cygwin/GCC is configured and built to be able to add a fairy small number of C functions. Thoughts? --Beman

10 29

Request for interest in the new Synchro library
by vicente.botet 10 Mar '09

10 Mar '09

Hi, I would like to know if the Boost community is interested in the Synchro library. Of course there is a lot of work to do, but I think that there is enough material to start a discussion on the approach. I'd appreciate it if people could take a look, test it on their compiler and give me some feedback. The library is available at Boost Sandbox: https://svn.boost.org/svn/boost/sandbox/synchro and Boost Vault: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=synchr… that iIncludes every thing on the Sandbox + Html documentation Some examples use Boost.Interthreads also (available on the vault and the sandbox). This library is a compilation of what I have found in the literature not yet present in Boost. My main concern has been to boostify all these ideas in a coherent way. Next follows an overview of the library features: Boost.Synchro provides: * A uniform usage of Boost.Thread and Boost.Interprocess synchronization mechanisms based on lockables(mutexes) concepts and locker(guards) concepts. o lockables traits and lock generators, o lock adapters of the Boost.Thread and Boost.Interprocess lockable models, o locker adapters of the Boost.Thread and Boost.Interprocess lockers models, o complete them with the corresponding models for single-threaded programs: null_mutex and null_condition classes, o locking families, o semaphore, o condition_lockable lock which put together a lock and its associated conditions. * A coherent exception based timed lock approach, * A rich palette of lockers as o strict_locker, nested_strict_locker, o condition_locker, o reverse_locker, nested_reverse_locker, o locking_ptr, on_dereference_locking_ptr, o externally_locked, * A polymorphic lockable hierarchy. * High-level abstractions for handling more complicated synchronization problems, including o monitor for guaranteeing exclusive access to an object, and o a so-called rendezvous mechanism for handling direct communication between objects concurrent_components via ports using an accept-synchronize protocol based on the design of the concurrency library in the Beta language. On going work * array_locker and tuple_locker locker containers. * A complement to the already present in Boost.Thread lock, try_lock free functions: o lock_until, lock_for, try_lock_until, try_lock_for Best regrads, Vicente Juan Botet Escribá

3 12

wiki.boost.org Ancient
by Joel 09 Mar '09

09 Mar '09

Can wiki.boost.org be redirected to someplace useful? Right now it is an advertisement for crystal clear software. It is a bad advertisement since it is from 2005. Even worse, it has a link to a "boost wiki" that isn't being updated and has spam hidden away in it. It claims not to be official, but if the url is wiki.boost.org, it IS official! Thanks! Joel

4 6

[optional] little addition
by Arno Schödl 07 Mar '09

07 Mar '09

I just started using boost::optional, and this proved to be generically useful, but I believe is currently not in boost::optional: template< class T, class Tcompatible > bool optional_assign( T& t, boost::optional<Tcompatible> const& optt ) { if( optt ) { t=*optt; return true; } else { return false; } } so you can write boost::optional< TMyValue > TryToGetT(); T t; if( !optional_assign( t, TryToGetT () ) { ... other way to get t ... } instead of the more verbose: boost::optional< TMyValue > TryToGetT(); T t; boost::optional< TMyValue > const& optt=TryToGetT(); if( optt ) { t=*optt; } else { ... other way to get t ... } get_optional_value_or is similar, but the alternative must be an expression and is eagerly evaluated, both of which may be undesirable. Arno -- Dr. Arno Schoedl · aschoedl(a)think-cell.com Technical Director think-cell Software GmbH · Invalidenstr. 34 · 10115 Berlin, Germany http://www.think-cell.com · phone +49-30-666473-10 · toll-free (US) +1-800-891-8091 Directors: Dr. Markus Hannebauer, Dr. Arno Schoedl · Amtsgericht Charlottenburg, HRB 85229

4 23

[1.38.0] PDF package of Boost documentation released.
by John Maddock 07 Mar '09

07 Mar '09

Folks, A package containing PDF versions of Boost's documentation is now available for Boost-1.38.0 from the usual sourceforge download site: http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=15971… Please note that due to the diverse range of tools in use within Boost it has not been possible to produce PDF's for all of Boost's libraries, those currently included as PDF's are: accumulators any array asio bimap range complex-tr1 concepts config conversion date_time foreach function hash interprocess intrusive iterator math-gcd math mpi octonion optional phoenix program_options proto python_tutorial quaternion ref regex scope_exit signals static_assert string_algo thread tr1 tribool type_traits typeof units unordered variant xpressive Documentation for the following tools are also included in this package: bjam boost_build boostbook quickbook Regards, John Maddock.

6 9

Formal Review: Boost.RangeEx
by Thorsten Ottosen 06 Mar '09

06 Mar '09

Dear Developers and Users, It's my pleasure to announce that the review of Neil Groves' RangeEx library starts today and lasts until March 3, 2009. What is it? +++++++++++ The library provide two very useful extensions to the range library 1. Range-based algorithms. E.g. boost::sort( rng ); which is a convenient wrapper of instead of std::sort( boost::begin(rng), boost::end(rng) ); But the new interface also allows for more expressive code because (on the fly) composition of algorithms suddenly is possible. 2. Range adaptors. E.g. std::vector<int> vec = ...; boost::copy( vec | boost::adaptors::reversed, std::ostream_iterator<int>( std::cout ) ); where the expression "vec | boost::adaptors::reversed" wraps the iterators of the range on the left in reverse iterators. The library provides a wide range (no pun intended) of Range adaptors, and they are a powerful way to create ranges on the fly and pass them to algorithms. Getting the library +++++++++++++++++++ The library may be downloaded from http://www.cs.aau.dk/~nesotto/boost/range_ex.zip or from the Boost vault under "Algorithms". The docs may be browsed online here http://www.cs.aau.dk/~nesotto/boost/libs/range/ Please note that the documentation is integrated with the current Range ilbrary. Therefore the relevant sections for the review is http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/adaptors.html and http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/algorithms.html The code may be browsed here: http://www.cs.aau.dk/~nesotto/boost/boost/range/ Notice the library is header only (exception: the adaptor tokenized() depends on Boost.Regex). Writing a review ++++++++++++++++ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. Here are some questions you might want to answer in your review: - 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? - 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 finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Special considerations ++++++++++++++++++++++ Various RangeEx like libraries have been implemented in the past. You might want to compare with those libraries when you form your oppinion: 1. John Torjo's range lib http://rangelib.synesis.com.au/libs/boost-rangelib-20040913.zip http://torjo.com/rangelib/index.html 2. Adobe's ASL libraries include range-based algorithms: http://stlab.adobe.com/group__algorithm.html I'm looking forward to your review. best regards Thorsten, Review Manager

18 101

BGL question about districting
by Barend Gehrels 06 Mar '09

06 Mar '09

Hi, We're about an automated districting tool. We want to create Y districts from X polygons, all having a specific value (e.g. area or inhabitants), where the total value of each district is as similar as possible and each district is also as similar as possible. Let's call the value the "potential". Of course this problem is NP-hard so we're glad with the first solution or e.g. the first ten solutions. We thought to implement this by the Boost Graph Library. First we detect neighbour relations with our own Geometry Library (using the still-to-build "touches" relationship). We've a graph then and can divide the graph into subgraphs, each having connected nodes and an (nearly) equal "potential". I've some experience with BGL, having used the "connected_components". But I cannot find an appropriate algorithm for this problem, if it is available. Actually it even could be a "network flow" algorithm dividing the total potential by Y, and starting at some point flowing the potential through the graph. But all network flow algorithms seem to be on directed graphs. This is an undirected graph. It it is not possible with a standard BGL algorithm I think we can still solve it using BGL and e.g. breadth-sort-first, but just want to verify if it is possible or maybe by an unexpected workaround. Thanks, Barend

4 5

[time series] What happened to this library?
by Christian Henning 05 Mar '09

05 Mar '09

Hi there, as far as I can tell this lib has been approved but it doesn't show up in boost. Why is it not in there? Thanks, Christian

11 21

Design conventions; passing functors
by Joachim Faulhaber 04 Mar '09

04 Mar '09

Hi, I am pondering about functor passing. Functors occur in my library (ITL) e.g. for the aggregation of associated values on insertion in interval_maps (aggregation on overlap): template<class Domain, class Codomain, ...> class interval_map{ ... //(1) My current implementation is this: // Combinator is the aggregating functor template, // instantiated at compiletime template<template<class>class Combinator> interval_map& add(const value_type& value_pair) { /*Combinator template passed or instantiated somewhere*/ } ... } //I like this definition, because it's abstract: // The functor has to be a matching template e.g. inplace_max interval_map<int,int> m; m.add<inplace_max>(some); //(1) template<class Domain, class Codomain, ...> class interval_map{ //(2) The more traditional definition template<class Combinator> interval_map& add(const value_type& value_pair) { /*Combinator type passed or called somewhere*/ } ... m.add<inplace_max<int> >(some); //(2) I prefer (1) but both definitions (1) and (2) are purely static denotations. To have adaptable functors or functors that can have states, like in ... m.add(some, max_under(42)); ... I am afraid I have to say sayonara to definition (1) and use this instead: template<class Domain, class Codomain, ...> class interval_map{ //(3) Adaptable functor template<template<class>class Combinator> interval_map& add(const value_type& value_pair, const Combinator<Codomain>& combine) { /*combine functor passed or called somewhere*/ } Now, there seems to be a convention from the STL that functors shall be passed BY VALUE. template<template<class>class Combinator> interval_map& add(const value_type& value_pair, Combinator<Codomain> combine); This is stated in [Sutter & Alexandrecu 2005, C++ Coding Standards] item 89: "Function objects are modeled on function pointers. Like function pointers, the convention is to pass them by value. All of the standard algorithms pass objects by value, and your algorithms should too." I do not really understand this convention and feel some resistance to follow it. In addition the call by value implementation can (and will) lead to heavy inefficiency by unaware usage of fat functors. So I browsed through some boost libraries and found that functors are passed by reference there (e.g. accumulators, fusion). Final question: What is the boost standard on passing functors, that I can adapt to? Cheers Joachim

6 20

Re: [boost] [optional_io] InputStreamable refinement
by Andrew Troschinetz 04 Mar '09

04 Mar '09

Just heard back from Robert, I figure it's ok to forward this information: On Feb 26, 2009, at 10:00 AM, Robert Ramey wrote: > The serialization library does no depend up optional or it's > implementation. If you > change the implemenation of optional, just make the changes > are consistent with the requirements of the serialization library. > > The fact that the serialization of optional is implemented and tested > as part of the serialization library is an anomoly. In fact, this > code and test should be moved into the optional library. I checked the optional test in the serializable library and it doesn't seem to even include optional_io.hpp. And given Robert's comments, it seems like it would be ok to make changes to optional_io.hpp. With respect to the change I suggested for operator>>() (I think in my last post I typoed and wrote operator<<(), I always get those silly things backwards!): In the case where we fail to extract optional<T>::value_type, I'm not sure what would be the best thing to do with respect to the position of the get pointer or other state bits. I had suggested this: if (in.fail () && !in.eof ()) { in.clear (); in.get (); } The intent of calling get() there is to enable this use case: stringstream sin ("one 2 three 4 five 6"); optional<int> i; while (sin >> i) { if (i) cout << "found int: " << i << endl; } // which finds 2, 4, and 6 But why move the get pointer up by one? Why one? Does this make sense? I can't provide a reasoning as to why it does, if it does. So another possibility is this: if (in.fail () && !in.eof ()) { in.clear (); in.setstate (std::ios::eofbit); } This has the added benefit of of making the following possible w/o any code change to lexical_cast: // doesn't throw, returns 0 lexical_cast<optional<unsigned> > ("-1").get_value_or (0); And if it's well documented that extracting an uninitialized optional<T> sets the eofbit on the istream, then a prudent user could (if they really wanted to) reformulate the first use case as: stringstream sin ("one 2 three 4 five 6"); optional<int> i; while (sin >> i) { if (i) cout << "found int: " << i << endl; else { sin.clear (); sin.get (); } } This leaves the why of moving the get pointer up to the user, where I think it really belongs. Because I can image some use cases where you'd want to do something other than just call get(). For example, maybe you'd want to call getline() and ignore an entire line before trying to extract another optional<T>. Or maybe you'd want to read until you found some delimiter before trying again. -- Andrew Troschinetz Applied Research Laboratories

4 9

Re: [boost] An extension to boost::variant
by Catalytic 04 Mar '09

04 Mar '09

Chris Hamilton-3 wrote: > > While boost::variant is very capable at what it does, there is one thing > it doesn't do .. > > ..My question is this: why can't boost::variant be clever about reference > data types.. > > The reason I want this, is to have a nice String variant, that > encapsulates the various forms a string can take in a current project: > std::strings, char*'s, and std::string* and > boost::shared_ptr<std::string>. I want functions to be able to handle > all of these types transparently by using variants as the argument > types. Allowing "const std::string&" as a variant type allows this to > be done while not requiring a wasteful string copy. > .. > (I have a small custom variant class implementing this, and it appears > to work well. It's not as 'full fledged' as the boost::variant class, > but the approach I've taken could surely be grafted on to boost::variant.) > > An example will be better than a lengthy explanation, please have a look at the test-cases in the boost distribution: libs/variant/test/: specially variant_reference_test.cpp IMHO, it will answer all your queries. -Cat -- View this message in context: http://www.nabble.com/An-extension-to-boost%3A%3Avariant-tp21881442p2189668… Sent from the Boost - Dev mailing list archive at Nabble.com.

5 13

[convert] Default Syntax Idea
by Stewart, Robert 04 Mar '09

04 Mar '09

I was thinking a bit about syntax for the default value for the notional boost::convert() and kin. How about the following: int const i(3); string const s("something"); int const j(convert<int>(s) | 5); convert<DestType,SourceType>(SourceType) can return a type which throws on failure in operator DestType(), but has an operator |(SourceType) which returns a second type constructed with the SourceType value. The second type provides its own operator |(SourceType) which returns that value in its operator DestType() on failure. Returning a default value in lieu of an exception is a special case; it ought not be treated like formatting. Thus, while Boost.Parameter might be appropriate to package the extra information desired for formatting, I don't like the idea of writing "default_ = 5" in the call, and I don't think ", 5" in the argument list is as clear as it could be. The syntax above is obvious and concise while being distinct from whatever may be done for formatting. _____ Rob Stewart robert.stewart(a)sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

9 32

boost::bind, problem with result type deduction and calling conventions
by Ingo.Loehken＠boc-eu.com 03 Mar '09

03 Mar '09

hi, anybody able to explain, why the code for the result type, related to special calling conventions defines an void return type ? template< class R, class T > struct add_cref< R (T::*) (), 1 > { typedef void type; }; so that code like class A { public: int __stdcall x() { return 0; } void const y() {} explicit A() { typedef boost::function<int()> fun_t; fun_t const f(boost::bind(&A::x,this)); } }; ends up with an warning at bind 1>G:\boost\boost_1_37_0\boost/bind.hpp(1643) : warning C4180: qualifier applied to function type has no meaning; ignored 1> G:\boost\boost_1_37_0\boost/bind.hpp(1682) : see reference to class template instantiation 'boost::_bi::add_cref<Pm,I>' being compiled 1> with 1> [ 1> Pm=int (__stdcall Ado::A::* )(void), 1> I=1 1> ] 1> G:\dev\workspace\files\ado\ado_bind.hxx(36) : see reference to class template instantiation 'boost::_bi::dm_result<Pm,A1>' being compiled 1> with 1> [ 1> Pm=int (__stdcall Ado::A::* )(void), 1> A1=Ado::A * 1> ] because the proposed specialization is not choosen by the compiler. Adding an __stdcall to the function signature type in add_cref fixes that problem, but still i do no understand, why the defintion is not like template< class M, class T > struct add_cref< M (__stdcall T::*) (), 1 > { typedef M const& type; }; and of course that fix is only applicable for __stdcall, where specialzations for other calling conventions can easily be generated, like for mem_fn_cc in respect to requested support for calling conventions. Thanks for your help, ILo. compiler : msvc 8.0 library : boost 1.38

2 1

[Review] Reminder: Boost.RangeEx review is going on
by Thorsten Ottosen 02 Mar '09

02 Mar '09

Dear Developers and Users, The review of Neil Groves' RangeEx library lasts until March 3, 2009. Please find the time to do a review if you are interested in this library. The discussion so far may be found here: http://archives.free.net.ph/message/20090220.122836.73bdbd04.en.html Below you will find a description of the library and information on how to write a review. best regards Thorsten, review manager What is it? +++++++++++ The library provide two very useful extensions to the range library 1. Range-based algorithms. E.g. boost::sort( rng ); which is a convenient wrapper of instead of std::sort( boost::begin(rng), boost::end(rng) ); But the new interface also allows for more expressive code because (on the fly) composition of algorithms suddenly is possible. 2. Range adaptors. E.g. std::vector<int> vec = ...; boost::copy( vec | boost::adaptors::reversed, std::ostream_iterator<int>( std::cout ) ); where the expression "vec | boost::adaptors::reversed" wraps the iterators of the range on the left in reverse iterators. The library provides a wide range (no pun intended) of Range adaptors, and they are a powerful way to create ranges on the fly and pass them to algorithms. Getting the library +++++++++++++++++++ The library may be downloaded from http://www.cs.aau.dk/~nesotto/boost/range_ex.zip or from the Boost vault under "Algorithms". The docs may be browsed online here http://www.cs.aau.dk/~nesotto/boost/libs/range/ Please note that the documentation is integrated with the current Range ilbrary. Therefore the relevant sections for the review is http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/adaptors.html and http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/algorithms.html The code may be browsed here: http://www.cs.aau.dk/~nesotto/boost/boost/range/ Notice the library is header only (exception: the adaptor tokenized() depends on Boost.Regex). Writing a review ++++++++++++++++ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. Here are some questions you might want to answer in your review: - 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? - 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 finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Special considerations ++++++++++++++++++++++ Various RangeEx like libraries have been implemented in the past. You might want to compare with those libraries when you form your oppinion: 1. John Torjo's range lib http://rangelib.synesis.com.au/libs/boost-rangelib-20040913.zip http://torjo.com/rangelib/index.html 2. Adobe's ASL libraries include range-based algorithms: http://stlab.adobe.com/group__algorithm.html I'm looking forward to your review. best regards Thorsten, Review Manager

4 5

N2346 - Defaulted and Deleted Functions emulation
by vicente.botet 02 Mar '09

02 Mar '09

Hi, is there an interest in a N2346 - Defaulted and Deleted Functions emulation http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm The idea been to use some macros that will use the =default, =delete if the compiler provides it and replace this macros by whatever has the same semantics. Alexandrescu introduced already two macros NON_ALIAS and NON_HEAP_ALLOCATED when talking about strict locks. Attached a draft for the default and deleted functions. Only one remark the macors must be used on the public part and without trailing ';', e.g. class X { BOOST_NEW_DELETE(X) Any coments are welcome, Vicente

3 6

[geometry] gtl review pre-announcement
by Tom Brinkman 02 Mar '09

02 Mar '09

I'm doing a session at boostcon about GIL and making a bunch of examples, including some about GTL. You can include those as part of your unit test cases if you like. //Tom

3 2

RPC library in the sandbox
by Jon Shuler 02 Mar '09

02 Mar '09

Does any know if the author(s) of this library are still around and plan to make any more updates to it? Jon

2 1

[thread] static thread_specific_ptr?
by k-oli＠gmx.de 01 Mar '09

01 Mar '09

Hello, can I create an static thread specific pointer for class which will initalized by different threads? struct X { static thread_specific_ptr< U > tss_ptr_; }; in some threads: X::tss_ptr_.reset( new U); And for each thread X::tss_ptr_ will point to a different object in the freestore? Oliver

6 8

rule cpp-pch unknown in module Jamfile</D:/boost/trunk/libs/math/build>?
by Peter Dimov 01 Mar '09

01 Mar '09

I'm trying and failing to run the smart_ptr tests because of: D:\boost\trunk\libs\smart_ptr\test>bjam ..\..\..\libs\math\build\Jamfile.v2:8: in modules.load rule cpp-pch unknown in module Jamfile</D:/boost/trunk/libs/math/build>. D:/boost/trunk/tools/build/v2/build\project.jam:313: in load-jamfile D:/boost/trunk/tools/build/v2/build\project.jam:62: in project.load D:/boost/trunk/tools/build/v2/build\project.jam:742: in project.use D:/boost/trunk/tools/build/v2/build\project.jam:89: in load-used-projects D:/boost/trunk/tools/build/v2/build\project.jam:73: in load D:/boost/trunk/tools/build/v2/build\project.jam:115: in load-parent D:/boost/trunk/tools/build/v2/build\project.jam:448: in initialize D:/boost/trunk/tools/build/v2/build\project.jam:303: in load-jamfile D:/boost/trunk/tools/build/v2/build\project.jam:62: in load D:/boost/trunk/tools/build/v2/build\project.jam:168: in project.find D:/boost/trunk/tools/build/v2\build-system.jam:535: in load D:\boost\trunk\tools\build\v2/kernel\modules.jam:283: in import D:\boost\trunk\tools\build\v2/kernel/bootstrap.jam:138: in boost-build D:\boost\trunk\boost-build.jam:17: in module scope -- Peter Dimov http://www.pdplayer.com

4 7

[graph] kolmogorov_max_flow color map, gray state
by Sebastian Nowozin 01 Mar '09

01 Mar '09

Hello everybody, I use the boost graph library to find the linear min-cut of a directed graph with exactly one source and one sink node (s-t min-cut). For this, I setup a linear max-flow problem and solve it using kolmogorov_max_flow. The color_map property is supposed to be usable to recover the edge cut set from the max-flow solution, see the description on http://www.boost.org/doc/libs/1_38_0/libs/graph/doc/kolmogorov_max_flow.html However, as long as there are no vertices colored "gray" I can simply tell which side of the cut a node belongs to by doing something like: std::vector<default_color_type> color(num_vertices(g_ab)); double flow = kolmogorov_max_flow(g_ab, alpha_vertex, beta_vertex, color_map(&color[0])); bool is_left = (color[node_desc] == tc_color_traits::white()); bool is_right = (color[node_desc] == tc_color_traits::black()); And this works just fine. For some problems I am solving there are gray nodes, and I do not know how to determine their position relative to the edge cut set. Is there a code example available in the boost repository or has anyone had this problem? It seems surprising to me that obtaining the edge cut set of a linear min-cut problem seems to be non-trivial using the boost graph library. I must be doing something wrong. Thanks, Sebastian

2 4

Bug in intrusive_ptr,scoped_ptr,scoped_array
by Hansi 28 Feb '09

28 Feb '09

Hello, at least with VS2005 there is a bug in the three smart pointers... If you want to check if the pointer is empty (with unspecified bool) then you get also with NULL a true back. For this the following fix should work: #if defined( _MANAGED ) static void unspecified_bool( this_type*** ) { } typedef void (*unspecified_bool_type)( this_type*** ); operator unspecified_bool_type() const // never throws { return px == 0? 0: unspecified_bool; } #else .... #endif Best regards Hansjörg

2 2

[move] Library uploaded to sandbox
by Ion Gaztañaga 28 Feb '09

28 Feb '09

Hi to all, I've uploaded a new version of the move emulation library to sandbox. I've put it temporarily in "move_semantics" folder to avoid overwriting current move code. I've put some quickbook documentation whose introduction is based in the article "A Brief Introduction to Rvalue References" by Hinnant, Stroustrup, Kozicki. http://svn.boost.org/svn/boost/sandbox/libs/move_semantics/index.html The library needs specially modified Interprocess containers (and Intrusive because of dependences), which I've also uploaded to sandbox. The examples show how movable only values can be inserted into containers. For those that don't like svn sandbox (I'm one of them) I've also put the code and the documentation here: http://www.drivehq.com/web/igaztanaga/move_semantics.zip And online documentation also here: http://www.drivehq.com/web/igaztanaga/libs/move_semantics/ The documentation is not in english, it's in my own english dialect so be careful when reading ;-) Patches and corrections welcome. I've documented some functions to create a little boostbook reference. I've invested some precious time in the library and testing different approaches to see if it plays well with containers but I would like to hear some comments on whether the direction is acceptable and if I should spend more time on it. If someone else with more time wants to continue the library, please do it! ;-) I've personally added to the library all that I've seen useful for move-aware containers, so it might lack some features (move aware algorithms, for example). Anyway, my opinion is that we need some move library, better now than later even if it's too basic, so that we can unify all redundant move emulation that we already have in boost libraries. I hope this is a step in the right direction. Best, Ion

11 41

[threadpool] new version - with rescheduling of current task
by k-oli＠gmx.de 28 Feb '09

28 Feb '09

Hi, I've uploaded a new version of boost.threadpool. It contains a free function this_task_reschedule_until() which lets the current task reschedule until a condition (passed to the fucntion) becomes true. This allows to synchronize with other async events without blocking the worker-thread (thx to Vicente). I've also added two function in order to wait for multiple tasks (it uses Anthonies future lib wait_for_any()/wait_for_all() ). Oliver

2 8

[python] Making a Python tuple from a Fusion sequence
by Bruno Lalande 27 Feb '09

27 Feb '09

Hello, I have written a little function that converts any Boost.Fusion sequence into a Python tuple (boost::python::tuple). If a sub-sequence is nested in the sequence, the result will also be a nested tuple (for instance, boost::make_tuple(0, std::make_pair(1, 2), 3) will give (0, (1, 2), 3) in Python). The source code is attached to this mail. The principle is that any sequence previously adapted to Boost.Fusion will become a tuple in Python. So, by including the right boost/fusion/adapted/xxx header, one can convert a pair, a tuple, a boost::array, and obviously any of the sequences provided by Boost.Fusion. For example: #include <boost/python.hpp> #include <boost/fusion/adapted/std_pair.hpp> #include <boost/fusion/adapted/boost_tuple.hpp> #include <boost/fusion/container/generation/make_vector.hpp> #include "make_tuple_from_fusion_sequence.hpp" using namespace boost::python; tuple from_sequence() { return make_tuple_from_fusion( boost::fusion::make_vector( 1, std::make_pair("first", "second"), 2, boost::make_tuple('a', 'b', 'c'), 3 ) ); } BOOST_PYTHON_MODULE(mymodule) { def("from_sequence", &from_sequence); } In Python we get: >>> import mymodule >>> mymodule.from_sequence() (1, ('first', 'second'), 2, ('a', 'b', 'c'), 3) Is there any interest in adding this function into Boost.Python? If yes, I can write the doc and tests, clean the source and maybe improve the implementation (for example, I feel that I could avoid the use of m_iteration with a better use of Boost.Fusion...). Regards Bruno

5 9

another approach to memory management that solves the referential cycles problem
by Achilleas Margaritis 27 Feb '09

27 Feb '09

Dear boost members, I have placed in the boost Vault, under the section "memory", the file 'mm.zip' which contains: 1) a file "readme.txt" with a little documentation. 2) a file 'main.cpp' which contains a reference implementation and test. This (I wouldn't not call it new, but certainly interesting) approach to memory management solves the problem of cycles and it can also provide a sort of garbage collection, without the issues of other approaches (explained in the readme). Suggestions, comments, ideas, etc are welcomed.

3 10

Re: [boost] [geometry] area, length, centroid, behaviour
by Mika Heiskanen 27 Feb '09

27 Feb '09

I wrote: > However, I'd hate to have to produce a certain winding rule for the > exterior and the holes in order to use the same data for more > complicated GIS calculations such as logical operations and buffering. > IMHO it should be just as easy as choosing to use the even-odd filling > rule instead of the winding rule. To which Barend Gehrels replied: > It cannot be called from the algorithms themselves: to > verify the winding rule the area has to be calculated beforehand. This > will drastically decrease performance. Certainly area calculation is significantly faster than logical operations and buffering. > The solution might be a traits class telling the winding rule the > polygon type has. Agreed. [Sorry about the unorthodox quoting, I rebuilt the reply by googling] --> Mika Heiskanen

1 0

Interest check: factory patterns
by Tor Brede Vekterli 27 Feb '09

27 Feb '09

Hi all I've been working on a "Modern C++ Design"-inspired factory/abstract factory pattern implementation for a while now, and was wondering if there was any interest in having it as a Boost library at some point? If my understanding of the existing Boost.Functional/Factory is correct, then this should not really clash with its area of operation. Factory features - Configurable identifier, mapping, error policy types - Function storage type can be overridden by the user on a per-factory basis Abstract factory features: - Auto-generation of class hierarchies (a-la Loki)--allows passing as individual factory fields - Passing of construction-arguments to the concrete type "creators" (operator new by default, but extensible) - Prototypes - Easy (re-)binding of constructor arguments - Boost.Functions if none of the above are appropriate or flexible enough - Mixing and matching creators for concrete factories. i.e., allows to use a prototype for one concrete type, Boost.Function for another, operator new for the third and so on - Easily specify if the created object should be returned as a raw pointer or a smart pointer (any type with a nested element_type is automatically recognized) - Almost everything is policy-specifyable Somewhat contrived example: typedef abstract_factory< // Want object created with no args, returned as raw pointer abstract_foo* // Want object created with std::string const ref, float by value args; returned as auto_ptr , std::auto_ptr<abstract_bar>(const std::string&, float) > abstract_factory_t; concrete_factory< // Concrete factory for abstract_factory_t abstract_factory_t // Concrete creator for abstract_foo; prototype , prototype<> // Concrete creator for abstract_bar; operator new creator (default when it's a regular type) , bar_impl > cf; // Set prototype for abstract_foo (takes ownership of raw pointers) cf.prototype<abstract_foo>(new fancy_foo_impl); const abstract_factory_t& af = cf; // By default invoke clone() on the stored prototype abstract_foo* foobj = af.create<abstract_foo>(); // Forward args to creator, in this case operator new --> constructor of bar_impl std::auto_ptr<abstract_bar> barobj = af.create<abstract_bar>("hello boost", 1234.5f); Preliminary documentation and download link can be found here: http://arcticinteractive.com/static/boost/libs/factory/doc/html/index.html I've yet to request any vault/sandbox access, because I first would really like to get some input on what people who are far more knowledgeable and experienced in C++ and software design than myself think of it :). Critique, comments, suggestions etc. are very welcome on all aspects of the library (code, design, documentation,...) Regards, Tor Brede Vekterli

1 0

Sandbox structure in subversion (was Re: [move] Library uploaded to sandbox)
by Daniel James 27 Feb '09

27 Feb '09

2009/2/17 Ion Gaztañaga <igaztanaga(a)gmail.com>: > > http://svn.boost.org/svn/boost/sandbox/libs/move_semantics/index.html [snip] > > For those that don't like svn sandbox (I'm one of them) I've also put the > code and the documentation here: Most people nowadays are putting their libraries into subdirectories of sandbox, instead of mixing it up with the stuff that's already there. It's much easier to check out and browse online. For example, there's chrono at: https://svn.boost.org/svn/boost/sandbox/chrono https://svn.boost.org/trac/boost/browser/sandbox/chrono It is messy having this in the middle of the old sandbox layout. We could separate out the two although doing this without disrupting development would be tricky. Maybe we could create a new space in subversion and let people migrate to it if they wish. We could use a more traditional subversion layout, perhaps something like: /svn/boost/projects/chrono/trunk /svn/boost/projects/chrono/branches /svn/boost/projects/move_semantics/trunk /svn/boost/projects/move_semantics/branches Daniel

6 10

[iostreams] detecting io errors
by Johan Grafstrom 27 Feb '09

27 Feb '09

Hello, I use boost:iostreams for reading and writing a binary data format. There is currently no use of filters, but the reason for using boost was to try using compression by adding a filter. I have run into some problems/questions regarding the boost:iostreams::stream class though, and was hoping that someone here might give me a hint. The files I save is project files, and the users use a versioning system to lock the files while editing. Occasionally they forget to lock and would get an error when trying to save, since the files in write protected unless locked. My first (and worst) problem was that i did not get any error at all when the write failed, I found out that this was my own fault since I used: bio::stream<bio::file_sink> outs(tstFileName, std::ios_base::out); // ... write etc... if (outs.is_open()) // error ... instead of if (outs->is_open()) // ^^ '->', not '.' must be used here // error ... but it seem like an easy pitfall for newbies like me. A different method name or at least a warning in the documentation maybe? The second problem is that I cannot find any way to get information on the nature of the write error. E g is it an access permission problem or a hardware error? The third problem is that seem to be no way to detect an error when closing the file. I have attached a short c-file to illustrate what I would want to know. I pause and remove the USB-stick with the open file before closing. c-runtime streams will give me error on close, but I cant get the same information out of boost::iostreams. Any help, directions or opinions would be appreciated. Best regards, Johan Grafström /* -*- mode: C++; coding: utf-8-dos; -*- */ /* ========================================================================== * boost_test2.cpp * * Problems: * * * Boost only reports false for outs->is_open() after error but gives no * details (write failure, invalid handle, access violation) * * * An error on file close cannot be detected * * * The worst problem was my own: * using outs.is_open() (always returns true) * instead of outs->is_open() returns false after error * * ========================================================================== */ #include <stdio.h> #include <conio.h> #include <boost/iostreams/device/file.hpp> #include <boost/iostreams/stream.hpp> void boostWriteTestFile(); void streamsWriteTestFile(); void userInteract(); namespace bio = boost::iostreams; char tstFileName[] = "write_test.txt"; int main(int argc, char *argv[]) { // DebugBreak(); if (argc == 2 && strcmp(argv[1],"streams") == 0) { printf("Write using c-runtime stream i/o\n"); streamsWriteTestFile(); } else { printf("Write using boost:iostreams\n"); boostWriteTestFile(); } return 0; } void boostWriteTestFile() { char streamText[] = "Written by boost iostreams api\n"; int msgSize = strlen(streamText); // write using boost bio::stream<bio::file_sink> outs(tstFileName, std::ios_base::out | std::ios_base::binary); int bytesWritten = outs->write(streamText, msgSize); if (bytesWritten != msgSize) printf("Error boost writing\n"); if (!outs->is_open()) printf("Error boost file closed\n"); userInteract(); // Problem: how to get error status from outs.close() ?? // returns void // in boost/iostreams/device/file.hpp:175 // template<typename Ch> // void basic_file<Ch>::close() { pimpl_->file_.close(); } // returns void thus ignoring the return value from // basic_filebuf.close() in c++ runtime <fstream> outs.close(); } void streamsWriteTestFile() { char streamText[] = "Written by c-runtume streams api\n"; int msgSize = strlen(streamText); // write using c-runtime streams FILE *fh = fopen(tstFileName, "w"); if (fh == NULL) { perror("on fopen()"); return; } size_t countWritten = fwrite( streamText, // const void *buffer, 1, // size_t size, msgSize, // size_t count, fh // FILE *stream ); if (countWritten != msgSize) { perror("On fwrite()"); return; } userInteract(); int status = fclose(fh); if (status == 0) { // ok } else { // status == EOF perror("on fclose()"); return; } } void userInteract() { printf("Please remove the file %s, in some apropriate manner e g \n" "remove the floppy or usb-drive, delete with Unlocker or equivalent.\n" "Then press any key to continue.\n", tstFileName); _getch(); }

1 0

[c++0x][trunk testing] regression tests broken
by David Deakins 27 Feb '09

27 Feb '09

Looking at the output from our regression test system, it appears that the recent cpp0x changes have broken regression testing on the trunk. From a cursory review, it looks like some of the .cpp test files now mentioned in libs/config/test/all/Jamfile.v2 did not get merged over from branches/cpp0x. I noticed that the 'no_char16_t_pass.cpp' and 'no_char16_t_fail.cpp' files are missing, along with the char32 tests, the decltype tests, the extern template tests, the long long tests, and possibly more. Beman, do you have time to take a look at this and see which additional files need to be merged over? If not, I could probably take a look but not until tomorrow. And if this has already been noticed and mentioned, my apologies for the redundant post. Thanks, -Dave Deakins

1 0

Formal Review: Boost.RangeEx
by Thorsten Ottosen 26 Feb '09

26 Feb '09

Dear Developers and Users, It's my pleasure to announce that the review of Neil Groves' RangeEx library starts today and lasts until March 3, 2009. What is it? +++++++++++ The library provide two very useful extensions to the range library 1. Range-based algorithms. E.g. boost::sort( rng ); which is a convenient wrapper of instead of std::sort( boost::begin(rng), boost::end(rng) ); But the new interface also allows for more expressive code because (on the fly) composition of algorithms suddenly is possible. 2. Range adaptors. E.g. std::vector<int> vec = ...; boost::copy( vec | boost::adaptors::reversed, std::ostream_iterator<int>( std::cout ) ); where the expression "vec | boost::adaptors::reversed" wraps the iterators of the range on the left in reverse iterators. The library provides a wide range (no pun intended) of Range adaptors, and they are a powerful way to create ranges on the fly and pass them to algorithms. Getting the library +++++++++++++++++++ The library may be downloaded from http://www.cs.aau.dk/~nesotto/boost/range_ex.zip or from the Boost vault under "Algorithms". The docs may be browsed online here http://www.cs.aau.dk/~nesotto/boost/libs/range/ Please note that the documentation is integrated with the current Range ilbrary. Therefore the relevant sections for the review is http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/adaptors.html and http://www.cs.aau.dk/~nesotto/boost/libs/range/doc/algorithms.html The code may be browsed here: http://www.cs.aau.dk/~nesotto/boost/boost/range/ Notice the library is header only (exception: the adaptor tokenized() depends on Boost.Regex). Writing a review ++++++++++++++++ If you feel this is an interesting library, then please submit your review to the developer list (preferably), or to the review manager. Here are some questions you might want to answer in your review: - 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? - 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 finally, every review should answer this question: - Do you think the library should be accepted as a Boost library? Be sure to say this explicitly so that your other comments don't obscure your overall opinion. Special considerations ++++++++++++++++++++++ Various RangeEx like libraries have been implemented in the past. You might want to compare with those libraries when you form your oppinion: 1. John Torjo's range lib http://rangelib.synesis.com.au/libs/boost-rangelib-20040913.zip http://torjo.com/rangelib/index.html 2. Adobe's ASL libraries include range-based algorithms: http://stlab.adobe.com/group__algorithm.html I'm looking forward to your review. best regards Thorsten, Review Manager

6 12

Crash in boost::gregorian::from_simple_string in BOOST 1.36
by ak1mbox-boost＠yahoo.ca 26 Feb '09

26 Feb '09

Hello, I am using date_time library from Boost 1.36. When running this code: #include <boost/date_time/gregorian/gregorian.hpp> void RunDates() { boost::gregorian::date today(boost::gregorian::day_clock::local_day()); std::string todayString=boost::gregorian::to_simple_string(today); boost::gregorian::date todayFromString(boost::gregorian::from_simple_string(todayString)); } I get a reproducible crash when calling from_simple_string command on the last line of the function. Here is the backtrace: #0 0x961c9a12 in __gnu_debug::_Safe_iterator_base::_M_attach () #1 0x00003029 in __gnu_debug::_Safe_iterator_base::_Safe_iterator_base (this=0xbffff3ac, __seq=0x100698, __constant=false) at debug/ safe_base.h:89 #2 0x00006796 in __gnu_debug ::_Safe_iterator<std::_Rb_tree_iterator<std::pair<std::string const, unsigned short> >, __gnu_debug_def::map<std::string, unsigned short, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned short> > > >::_Safe_iterator (this=0xbffff3ac, __i=@0xbffff35c, __seq=0x100680) at debug/safe_iterator.h:110 #3 0x000068a2 in __gnu_debug_def::map<std::string, unsigned short, std::less<std::string>, std::allocator<std::pair<std::string const, unsigned short> > >::find (this=0x100680, __x=@0xbffff4a4) at debug/ map.h:220 #4 0x00006f11 in boost::date_time::month_str_to_ushort<boost::gregorian::greg_month> (s=@0xbffff4a4) at date_parsing.hpp:68 #5 0x000071cb in boost::date_time::parse_date<boost::gregorian::date> (s=@0xbffff51c, order_spec=0) at date_parsing.hpp:142 #6 0x00007445 in boost::gregorian::from_simple_string (s=@0xbffff51c) at parsers.hpp:35 #7 0x00001f85 in RunDates () at /dates.cpp:18 #8 0x00001e18 in main (argc=1, argv=0xbffff568) at /main.cpp:8 The code was compiled on OSX, gcc version 4.0.1 (Apple Inc. build 5490) with Debug flags, I am linking against dynamic data_time library. Is this a known issue in 1.36 that was fixed in 1.38? going through the list of fixes did not uncover it. The same example compiled with release flags works without problems. I am not certain if this means that I am missing some defines or that release compile misses errors that debug catches. Any help with this is really appreciated! Thank you, Alex

1 0

Question about Spirit architecture
by Bernhard Merkle 26 Feb '09

26 Feb '09

Hi boost developers, The architecture for spirit is documented under http://www.boost.org/doc/libs/1_38_0/libs/spirit/classic/doc/organization.h… my question: should all modules of Core (scanner, primitives, composite, non_terminal) also be independent of each other ? so should they be independent subsystems or are they allowed to have dependencies (within the Core layer) ? thanks for your help kind regards, Bernhard.

3 5

[lambda] warning supression
by Steven Watanabe 26 Feb '09

26 Feb '09

AMDG The attached patch allows Lambda's tests to compile with warnings=all warnings-as-errors=on with gcc-4.3.0 msvc8.0express and msvc-9.0express. Ok to commit? In Christ, Steven Watanabe

3 2

[tuple] gcc warnings
by Steven Watanabe 26 Feb '09

26 Feb '09

AMDG I've tested the fix for #2388 and it looks ok. Okay to commit? In Christ, Steven Watanabe

3 2

best way to remove duplicates from forwardIterator [startIter, endIter]
by Sandeep Gupta 26 Feb '09

26 Feb '09

Hi, Given a collection in terms of [startIter, endIter] how can obtain [uniqBeginIter, uniqEndIter] that represents unique elements of the original container. I can always explicitly instantiate a set S of [startIter, endIter] and use [S.begin(), S.end()]. Is it possible to express this in terms of algorithms. Please note that I won't be able to use std::sort as startIter does not conform to RandomAccessIterator. Its a forward iterator. Thanks Sandeep

3 3

Re: [boost] [convert] Default Syntax Idea
by Vladimir.Batov＠wrsa.com.au 26 Feb '09

26 Feb '09

> From: "Stewart, Robert" <Robert.Stewart(a)sig.com> > I was thinking a bit about syntax for the default value for the > notional boost::convert() and kin. How about the following: > > int const i(3); > string const s("something"); > int const j(convert<int>(s) | 5); Yes, this idea is similar to int j = convert<int>(s).or_default(5); but does not introduce new vocabulary (my main hesitation). With the suggested op|, as I am reading it, it makes perfect reading just like I'd read English. And that is usually my criterion for an interface. So, I am voting 'yes'... in principle. See further below. > convert<DestType,SourceType>(SourceType) can return a type which > throws on failure in operator DestType(), but has an operator > |(SourceType) which returns a second type constructed with the > SourceType value. The second type provides its own operator > |(SourceType) which returns that value in its operator DestType() on failure. When the user does not want comprehensive result, it works. The problem as I see it is when the user wants the comprehensive report -- we return two different types, convert1<string, int> j1 = convert<string, int>(s); convert2<string, int> j2 = convert<string, int>(s) | 5; Sometimes I feel we need that as I might like to explicitly check if the call failed without relying on the default convert1<string, int> j1 = convert<string, int>(s) & boost::nothrow; convert2<string, int> j2 = convert<string, int>(s) | 5; if (j1 == 0 && !j1.good()) j1 = 0 but conversion failed if (j2 == 5 && !j1.good()) j2 = 5 but conversion failed Unless we convert both convert1 and convert2 to convert<string, int>::result as convert<string, int>::result j1 = convert<string, int>(s) & boost::nothrow; convert<string, int>::result j2 = convert<string, int>(s) | 5; if (j1 == 0 && !j1.good()) j1 = 0 but conversion failed if (j2 == 5 && !j1.good()) j2 = 5 but conversion failed Or we might simplify that as convert::result<int> j1 = convert::to<int>(s) & boost::nothrow; convert::result<int> j2 = convert::to<int>(s) | 5; if (j1 == 0 && !j1.good()) j1 = 0 but conversion failed if (j2 == 5 && !j1.good()) j2 = 5 but conversion failed The reason I am sticking 'to' in again is that I need the 'convert' as a namespace... or rather as a namespace-like structure: struct convert : mimic_namespace /*I have such a class*/ { template<class TypeOut> struct result { TypeOut value_; bool good_; }; struct internal_with_default { ... }; struct internal_with_no_default { ... }; template<class TypeOut, class TypeIn> internal_with_default<TypeOut, TypeIn> to(TypeIn const&); }; With namespace-like convert structure people will not be able to shortcut 'convert'. I.e. they'll always have to say convert::to which is darn close to convert_to with the advantage of having a dedicated namespace-like place instead of messing inside the boost namespace. Now it seems like I am back where I started. :-) > Returning a default value in lieu of an exception is a special case; > it ought not be treated like formatting. I have an impression that throwing/not-throwing and providing/not-providing the default have to be configured independently. Like I *might* need to throw even if I provide the default: direction dir = convert<string, direction>(str, direction::up) & boost::dothrow; Above I provide the default because I have to (direction does not have the def. ctor). However, I still *might* like to throw on failure. > Thus, while Boost. > Parameter might be appropriate to package the extra information > desired for formatting, I don't like the idea of writing "default_ = > 5" in the call, and I don't think ", 5" in the argument list is as > clear as it could be. I tend to agree with you on both. > The syntax above is obvious and concise while > being distinct from whatever may be done for formatting. You meant to say "laconic", right? Oh, just kidding. Thanks for pointing it out BTW. BTW, what do you think of convert<string, int>(s) & boost::dothrow; instead of convert<string, int>(s) >> boost::throw_t(); People seem to get put off by op>>. Best, V.

7 11

[optional_io] InputStreamable refinement
by Andrew Troschinetz 25 Feb '09

25 Feb '09

This is a spin off from the thread "[lexical_cast] A suggestion" While trying to get lexical_cast and optional to play nice I've run up against some problems with the InputStreamable solution for optional types in optional_io.hpp. The crux of the problem is that I think any given optional type should behave as much like the type it wraps as possible. For example I think this: stringstream sin ("1.2.3.4.5"); optional<double> token; while (sin >> token) cout << token << endl; Should have the same output as this: stringstream sin ("1.2.3.4.5"); double token; while (sin >> token) cout << token << endl; And that this shouldn't fail: stringstream sin ("test"); optional<string> token; sin >> token; // token shouldn't be empty The current InputStreamable solution for optional does not pass these tests. But that's not all, I also believe that there is room for even more improvement here! Since it's semantically valid to have an un- initialized optional type, I think failure to extract something off a stream should return an empty optional type _without_ setting the failbit on the stream. Here's a usage example that demonstrates what I mean by that: // output is "1 nan nan nan nan 5.5 nan nan nan nan nan nan nan -3.2 nan " istringstream sin (" 1 this 5.5 is a test -3.2 a"); optional<double> token; const double nan = numeric_limits<double>::quiet_NaN (); while (sin >> token) cout << token.get_value_or (nan) << " "; // output is "1 " istringstream sin (" 1 this 5.5 is a test -3.2 a"); double token; while (sin >> token) cout << token << " "; I did submit a ticket with the final comment proposing code that is (maybe?) a solution to this refinement. ( https://svn.boost.org/trac/boost/ticket/2659 ) Please pardon any guffaws I made in replies to that ticket, I'm still learning about the nuts and bolts of streams and boost as I go. However there is still one problem, and this brings us back to lexical_cast. Consider this example: int an_invalid_uint = -1; unsigned i = lexical_cast<optional<unsigned> > (an_invalid_uint).get_value_or (0); I believe we should expect this to store 0 in i, but instead it will throw a bad_lexical_cast exception even with my proposed revision to optional_io.hpp. A possible solution is a specialization for optional<Target> somewhere in lexical_cast.hpp that would replace code that looks something like this (pseudocode): do lexical_cast if failed to cast: throw exception With something like this: do lexical_cast if failed to cast: return optional<Target>() So is there any interest in this sort of refinement of optional's InputStreamable implementation or lexical_cast? -- Andrew Troschinetz Applied Research Laboratories

2 2

Extending asio (SCTP support)
by Hal Finkel 25 Feb '09

25 Feb '09

Hello, I've started implementing SCTP support in asio. I would like some feedback on what methodology is preferred. Although I had originally wanted to provide SCTP support as a pure add-on to the current framework, unfortunately, I don't think that can be done. For example, SCTP supports multi-homed endpoints, and the standard API provides a function sctp_bindx which can add and remove endpoint addresses from an active association (connection). While I can provide a subclass of socket_acceptor_service with this extended interface, there is no way of changing the wrapper (detail::reactive_socket_service) used to implement socket_acceptor_service's service_impl_type, and since socket_, protocol_, etc. are private members of detail::reactive_socket_service, I think that there is no way a subclass of socket_acceptor_service can access the underlying socket object. This seems to leave two options: 1. Patch the missing functionality into the existing classes. What worries me is that this approach does not seem to "scale" well with respect to the addition of new protocols. (what happens if someone needs TIPC support, for example). 2. Provide some kind of protocol-specific extension mechanism (templated base classes for example) for detail::reactive_socket_service and other such classes so that it is possible to provide protocol-specific extensions to the base asio interface. Does anyone have a preference on how I proceed? (or is there an option I've missed?) And if some extension mechanism is desired, is there a preference on the technique used for its implementation? Thank you in advance, Hal Finkel P.S. For anyone looking for a quick introduction to SCTP and its associated socket API, I've found HP's SCTP Programmer's Guide (http://docs.hp.com/en/5992-4578/index.html) to be pretty good.

2 2

[geometry] gtl review pre-announcement
by Simonson, Lucanus J 25 Feb '09

25 Feb '09

Fellow geometry authors and interested reviewers, My abstract for gtl has recently been accepted to boostcon. I was unable to put together a geometry panel discussion, however. I am also working on completing documentation for the library by April. I would like the gtl library to be under review during boostcon because I may get the opportunity to meet and talk to some of the reviewers in person. To that end I'd like to ask for volunteers to be review manager and reviewers of the library now so that it isn't a surprise and things can proceed smoothly when the documentation is ready in a few weeks. I especially want other geometry authors to be aware of my plans and schedule. I have the utmost respect for the authors of the other two serious geometry proposals. It is my hope that we can work together during the review process and after to improve and converge our libraries toward the ideal boost::geometry library that all of us can feel proud of. Eventually it is my hope that algorithms in boost::geometry come for a variety of sources selected based upon quality such that there is no single owner of the library, but rather a community. I look forward to your reviews. Thanks, Luke

1 0

Re: [boost] Boost.Convert+Boost.Parameter
by Vladimir.Batov＠wrsa.com.au 25 Feb '09

25 Feb '09

> The keywords are decoupled. > ... > Did you read through the Boost.Parameter tutorial? OK, I admit before I only glanced over the docs a couple of times. I thought I got the idea. Obviously not. :-( Now I printed it out and set down reading. Now I see the registration is all by itself and not coupled with anything. That's good. So, convert() can take those parameters in. Given we do not know how many parameters there might be I'd suggest we set those parameters with operator(). Like convert<string, int>(str)(default_ = -1)(throw_ = false)(some_other_parameter_ = ...) Given, convert() does not know and does not understand "some_other_parameter_" somebody else will need to do something with it. Who would that be and what would it do? I presume we could come up with a Boost.Parameter-based manipulator analog... or... no, I admit I am out of ideas. How can all that work? Thanks, Vladimir.

6 7

[utility] value_initialized fix causes Intel-linux 9.0 compile error
by Niels Dekker - mail address until 2010-10-10 24 Feb '09

24 Feb '09

My fix of the "const incorrectness" of boost::value_initialized (changeset [51355]), committed to the trunk last Friday, has passed the value_init_test tests successfully on most compilers, including intel-linux 10.0 and 10.1: www.boost.org/development/tests/trunk/developer/utility_.html Unfortunately it has a compile time regression failure on intel-linux 9.0, when trying to compare a value_initialized<NonPOD*> and a NonPOD*: error: more than one operator "==" matches these operands: built-in operator "pointer == pointer" built-in operator "pointer == pointer" operand types are: boost::value_initialized<NonPOD *> == NonPOD *const www.boost.org/development/tests/trunk/output/Sandia-intel-9-0-boost-bin-v2-… I don't have access to an Intel compiler, but it looks like the compile error is specific to pointers, as it doesn't seem to occur when comparing value_initialized<T> and T for other types T (int, double, POD, NonPOD). Is this a known compiler bug of the Intel 9.0? Apparently it's fixed by Intel 10.0. The fix of changeset [51355] replaced the existing conversion operator by a pair of them, overloaded for const and non-const. See also https://svn.boost.org/trac/boost/ticket/2548 Would it be okay to just mark the regression failure as "expected", and leave the implementation of boost::value_initialized as it is, including the const-fix? Otherwise, do you have any suggestion for a workaround? Note that the compile error is specific to the implicit use of the conversion operator. value_initialized also provides "get" functions and data() member functions to retrieve its value, which should still work fine on Intel 9.0. Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 0

DynObj - Library for C++ runtime plugin objects
by Arne Steinarson 24 Feb '09

24 Feb '09

I'm the developer of DynObj - a C++ library for cross platform plugin objects/components. In short, the approach of the library is to exploit the underlying compiler representation of virtual function tables. Since the VTable of any type occupies a unique place in memory, the VPTR forms a valid runtime type ID. With the help of this type ID, DynObj (in a host application) can then access type information emitted by the plugin compiler. In effect, we get a cross compiler variant of dynamic_cast<>: * U* do_cast<U*>( T *pt )* This cast operation then takes the role of *QueryInterface(...)* in COM or xpCOM. The difference is that we're not forced into using a specific base class for plugin capable types. We also get a meaningful type system shared across host/plugin, not just isolated interfaces. To go about all of this, the library relies on quite a bit of template code, effectively tracking down object and interface offsets inside classes, and then exporting them in a well defined, binary safe structure. However, to simplify this (there is a bit of 'boiler plate code' needed for each plugin type), DynObj uses a preprocessor that generates most of this, based on a few preprocessing tags embedded in C++ comments. So it is not a 100% compile-time library. Also when using plugins, a fair bit of template code is used, for instantiating objects, smart pointers, executing functions on foreign interfaces and so on. Using plugin objects becomes almost transparent in many cases. More information is available here: http://dynobj.sourceforge.net Now, I wonder if there is any interest from Boost in this type of library. At this time, I'm not eager to do a complete rewrite, since it fills our needs pretty much as it is. If there is some interest, and the basic approach and design is found useful to Boost, I'd be willing to take this some steps further, time permitting. Also, general feedback and experience with the library is appreciated. Best Regards Arne Steinarson, Z-Soft

1 0

[documentation] help - SFINAE confuses doxygen
by Simonson, Lucanus J 24 Feb '09

24 Feb '09

I have noticed after attempting to document my overloaded template functions in doxygen that is simply doesn't work. Doxygen appears to consider all SFINAE overloads of a templated function as a single function, but doxygen's treatment of them is quite erratic. It seems to generally have a bunch of assumptions built into its internal logic about what can't happen in C++ code that aren't valid in my case. Does anyone have any suggestions for how to deal with these issues? I notice that doxygen is used with BoostBook, and I know this must have come up in other libraries. How is it solved? Thanks, Luke

8 14

Re: [boost] Boost.Convert+Boost.Parameter
by Vladimir.Batov＠wrsa.com.au 24 Feb '09

24 Feb '09

Trying to use Boost.Parameter as Daniel showed. Wow, that's truly hairy stuff. Obviously I get it wrong somewhere as matching Parameters constructor cannot be found. I am trying to call int ii = convert_to<int>("1", boost::convert_parameters::default_ = -1); when I have declarations below as (I think) Daniel indicated. namespace convert_parameters { BOOST_PARAMETER_NAME((from_, tag) from_) BOOST_PARAMETER_NAME((default_, tag) default_) } template<class TypeOut, class ArgumentPack> TypeOut test(ArgumentPack const& args) { return TypeOut(); } template< class TypeOut, class TypeIn, class A0> convert<TypeIn, TypeOut> convert_to(TypeIn const& value_in, A0 const& a0) { typedef parameter::parameters<parameter::required<convert_parameters::tag::from_> > Parameters; return test<TypeOut>(Parameters(value_in, a0)); } Any help? Please? Thanks, Vladimir.

3 2

[Phoenix2] nothing is not an actor
by Francois Barel 24 Feb '09

24 Feb '09

Hi, In core/nothing.hpp, "nothing" is defined as: null_actor const nothing = null_actor(); which doesn't make it an actor, rather an "actor base". Shouldn't it rather be defined as something like: actor<null_actor> const nothing = null_actor(); Thanks, François

3 2

Re: [boost] wiki.boost.org Ancient
by David Abrahams 24 Feb '09

24 Feb '09

on Mon Feb 23 2009, DongInn Kim <dikim-AT-osl.iu.edu> wrote: > Hi David, > > Can you setup the DNS of wiki.boost.org to just point to 129.79.245.252 without > aliasing for svn.boost.org? > This cause me difficult to setup its vhost properly. > > For example, > > [root@wowbagger wiki.boost.org]# host wiki.boost.org > wiki.boost.org is an alias for svn.boost.org. > svn.boost.org has address 129.79.245.252 > [root@wowbagger wiki.boost.org]# host beta.boost.org > beta.boost.org has address 129.79.245.252 > [root@wowbagger wiki.boost.org]# I could, but --- and I'm no www expert --- I think there ought to be a redirect so that there's a canonical web address for the wiki. Otherwise you get search engines spidering it twice, etc, no? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 2

Re: [boost] Formal Review Request: Boost.Convert
by Vladimir.Batov＠wrsa.com.au 23 Feb '09

23 Feb '09

Stewart, Robert wrote... > I assume that's a reference to me. My suggestion of "conversion" was as a namespace name. > Were you referring to my suggestion of using "converter" for the function object and "convert" > for the function template that would deduce template parameters? Yes, I was referring to that latter suggestion of yours: >> namespace boost >> { >> ...class convert; > s/convert/converter/ ... > template <class TypeOut, class TypeIn> > TypeOut const > convert(TypeIn _input, TypeOut const & _default) > { > return converter<TypeIn,TypeOut>(_input, _default); > } I've essentially implemented function wrappers as you suggested. Only I called them convert_to() and convert_from() that I am hoping many people will be happy with (remembering string_to/from et al) as the names could not be any clearer: int i = convert_to<int>(str); int i = convert_from(str, -1); int i = convert_from<string, double>(str, -1); That allowed me to keep the function object as "convert" and, say, apply it to algorithms as std::transform( strings.begin(), strings.end(), std::back_inserter(integers), convert<string, int>(string(), -1) >> std::hex); which is kinda nice as well. Do you agree? Thanks, Vladimir.

1 0

Re: [boost] Formal Review Request: Boost.Convert
by Vladimir.Batov＠wrsa.com.au 23 Feb '09

23 Feb '09

I've implemented the functionality as I described (convert as a class) and uploaded it as v0.21. I feel it is a considerable step forward in many respects as now it is more of a conversion 'framework' as users can create their specific specializations of boost::convert for their specific needs (as I did with lexical_cast). At the same time it feels reconciliatory as fighting over names could be put to rest (I hope) as we or the users might write simple and generic wrappers to boost::convert. In particular, I added boost::convert_to and boost::convert_from. It's just a suggestion. We might decide to keep them or remove or rename them. I am not fussy about it. So, the deployment loos as follows: // Explicitly specified 'from' and 'to' types. My personal preference int i = boost::convert<string, int>(str, -1); string s = boost::convert<int, string>(-1, "conversion failed"); // Deduced 'from' type. int i = boost::convert_to<int>(str); string s = boost::convert_to<string>(-1); // Both types are deduced. int i = boost::convert_from(str, -1); string s = boost::convert_from(-1, "conversion failed"); Robert suggested renaming 'convert' to 'conversion' but I am not warming up to that (yet, you might have noticed I am slow) as I essentially see 'convert' as a functor, i.e. encapsulating as an action, i.e. a verb is more appropriate. For that reason the code itself looks readable (to me) as "boost::convert<int, string>" reads as 'convert int to string". Thanks, Vladimir.

2 1

[proto] lazy functions in custom domains
by Dean Michael Berris 23 Feb '09

23 Feb '09

Hi Guys, I've recently tried to play around with Boost.Proto and I think I've run into a wall. I was trying to figure this (relatively simple) case out for a while already but it I'm at my wits end not seeing why the implementation doesn't work. I'm pasting the contents of the file (unmodified) which I've tried to follow from the Getting Started document. I was trying to get the custom domain approach working, but I never seem to get the lazy function to be called. The expected result from the code below would be to have multiple lines of output that says "Getting the friends of user # ;)" but I don't see those. There are no compilation errors, and I don't see anything obviously wrong from the implementation and how I understand Lazy functions. I'm just not sure about how lazy functions though can be made part of a domain though -- didn't find anything in the Getting Started guide about it. Help would be very much appreciated (BTW I'm using Proto that's in Boost 1.38.0, building with GCC 4.0 in Mac OSX 10.5.6): ---->8-- #include <iostream> #include <boost/proto/proto.hpp> #include <vector> namespace mpl = boost::mpl; namespace fusion = boost::fusion; namespace proto = boost::proto; using proto::_; using std::vector; using std::cout; using std::endl; struct user_tag; template <class Tag> struct placeholder {}; struct friendster_action_context : proto::callable_context<friendster_action_context const> { uint32_t user_id; friendster_action_context(uint32_t id) : user_id(id) {} friendster_action_context(friendster_action_context const & other) : user_id(other.user_id) {} friendster_action_context & operator= (friendster_action_context other) { other.swap(*this); return *this; } void swap(friendster_action_context & other) { std::swap(user_id, other.user_id); } typedef uint32_t result_type; result_type operator() (proto::tag::terminal, placeholder<user_tag>) const { return this->user_id; } }; template <class Expr> struct friendster_action; struct friendster_action_domain : proto::domain<proto::pod_generator<friendster_action> > {}; template <class Expr> struct friendster_action { BOOST_PROTO_EXTENDS(Expr, friendster_action<Expr>, friendster_action_domain); typedef void result_type; result_type operator()(uint32_t id) const { friendster_action_context ctx; ctx.user_id = id; return proto::eval(*this, ctx); } }; friendster_action<proto::terminal<placeholder<user_tag> >::type> const user = {{}}; struct friend_fun { typedef vector<uint32_t> result_type; template <class T> result_type operator() (T id) const { cout << "Getting the friends of user " << id << " ;)" << std::endl; return result_type(); }; }; template <class Arg> typename proto::result_of::make_expr< proto::tag::function, friend_fun, typename proto::result_of::as_child<Arg const>::type >::type friends(Arg const & arg) { return proto::make_expr<proto::tag::function>( friend_fun(), proto::as_child(arg) ); } #include <algorithm> using namespace std; int main(int argc, char * argv[]) { uint32_t users[] = { 1, 2, 3, 4 }; uint32_t * begin = users; uint32_t * end = users + 4; cout << "Here they are: " << endl; for_each(begin, end, friends(user)); string input; cin >> input; return 0; } ---->8-- -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

2 2

[gil][ublas] Point2DConcept and ublas vector concept
by Christoph Heindl 23 Feb '09

23 Feb '09

Hi, I'd like to use my boost::ublas::bounded_vector types interchangeable with boost::gil::point2 which from my point of view makes totally sense: A convex hull algorithm for 2D would only need to be implemented once (for world coordinates and pixel coordinates) for example. This, however, seems impossible right now because of the differences in their concepts. Is it possible to somehow make a bridge between them (without copying structures)? Any plans to unify those concepts and reuse ublas types? Best regards, Christoph

1 0

Trac tickets: fixed in trunk vs. fixed in release
by Steve M. Robbins 22 Feb '09

22 Feb '09

Hi, For each bug, there are really two levels of "fixed": roughly speaking, the developer considers the issue fixed when it is committed to trunk, while the user considers the issue fixed when it is commited to the release branch. At present, the trac ticket is closed at the first gate. Unfortunately, sometimes the second gate gets forgotten. Could another state be added to the ticket lifecycle to track when it gets merged to release? My aim is to be able to identified "fixed" tickets that are not actually released and, hopefully, to decrease them in number. Maybe there are other ways to achieve this? Regards, -Steve

5 10

[Iterator] Two sets of docs?
by John Maddock 22 Feb '09

22 Feb '09

The iterator library seems to have two sets of docs: one in quickbook format and one in restructured text. Which is the correct up-to-date version, and can we get rid of the other to avoid confusion? Thanks, John.

2 2

[test] [gcc-4.3.2] check_is_close and check_is_small issues
by Dean Michael Berris 22 Feb '09

22 Feb '09

Hi Guys, I have recently upgraded to Boost 1.38 from Boost 1.35 and suddenly I get the following warnings from GCC 4.3.2: ../boost_1_38_0/boost/test/floating_point_comparison.hpp:224: error: 'boost::test_tools::<unnamed>::check_is_close' defined but not used ../boost_1_38_0/boost/test/floating_point_comparison.hpp:246: error: 'boost::test_tools::<unnamed>::check_is_small' defined but not used I have warnings treated as errors in my build and I haven't encountered this issue before. Can this be considered a regression and if yes what can I do to work around it? -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

4 6

[range-ex] generators
by Neal Becker 22 Feb '09

22 Feb '09

I have a question of generate. I believe one usually wants generators to have state. Yet, generator is passed by value. This is awkward, the workaround is to manually specify generate<ForwardRange, Generator&>( rng, gen ); Since Generator is the 2nd template parameter we must specify ForwardRange, which might be complicated. I wonder if we should have: template<class ForwardRange, class Generator> ForwardRange& generate( ForwardRange& rng, Generator & gen );

3 3

[c++0x] OK to merge cpp0x branch config changes to trunk?
by Beman Dawes 22 Feb '09

22 Feb '09

See http://svn.boost.org/svn/boost/branches/cpp0x This branch adds the following config macros: BOOST_NO_CHAR16_T BOOST_NO_CHAR32_T BOOST_NO_CONSTEXPR BOOST_NO_DECLTYPE BOOST_NO_DEFAULTED_FUNCTIONS BOOST_NO_DELETED_FUNCTIONS BOOST_NO_EXPLICIT_CONVERSION_OPERATORS BOOST_NO_EXTERN_TEMPLATE BOOST_NO_RAW_LITERALS BOOST_NO_RVALUE_REFERENCES BOOST_NO_SCOPED_ENUMS BOOST_NO_STATIC_ASSERT BOOST_NO_UNICODE_LITERALS BOOST_NO_VARIADIC_TEMPLATES The particular names were discussed in several threads nearly a year ago. The set of C++0x features detected only covers those available in at least one shipping compiler. Although I've tested locally, I'd appreciate it if someone familiar with Boost.Config could take a look at the branch before the config directories get merged into trunk. --Beman

3 3

[filesystem] security questions
by Sergei Politov 21 Feb '09

21 Feb '09

Hi, In *nix systems it is recommended practice to operate with file descriptors rather than file names. The sample commands sequence is: 1) open file 2) check file status (check symlink for instance) 3) process write operation Unfortunately I cannot find a way to do the same using boost::filesystem API. Is it planned to support such style? Best Regads, Sergei

5 5

[threadpool] new v18
by k-oli＠gmx.de 21 Feb '09

21 Feb '09

Hello, I've uploaded a new version to boost-vault. The new library contains the future library from Anthony Williams (because it seams we don't get boost.future in the next time). regards, Oliver

1 0

Formal Review Request: Boost.String.Convert
by Vladimir.Batov＠wrsa.com.au 21 Feb '09

21 Feb '09

Well, the fishing trip did not work out. :-\ Therefore, I would like to request a formal review for the Boost.String.Convert functionality. I've uploaded the file called boost-string-convert.zip to the Vault (http://www.boostpro.com/vault/index.php) It has the conversion-related header, the test/usage executable and the documentation (MS Word, HTML). Compiled on Linux and Visual Studio 2008. At the bottom is the "motivation" introductory section from the docs. There is very little of actually code, so you might just read it rather that suffering through my document mumble. Currently-known issues. 1) The attention was given to the behavior (to provide simple/advanced conversion-failure check, throw/no-throw behavior, locale, formatting) and not to the efficiency. I am sure people will come up with ways to run this damn thing much faster. I am very much looking forward to your contributions as I do not really feel I am any good at it. 2) I've implemented the recently suggested boost::stirng::convert() interface but that might need some additional work to handle corner cases correctly. I promise to look into it in due course. I would like to thank everyone participated in the lexica_cast and boost::string::convert-related discussions and expressing their views and opinions and coming up with suggestions. All of them were heard, considered and much and truly appreciated. I apologize if in the end it does not look out as you might like to see it. I swear, your contributions were not in vain. Thanks, Vladimir. Motivation I had a need for a convenient and uniform facility to convert values to and from a literal textual form. Such a need is common when converting between internal (to a program) data types and their external representations. Typical applications would be reading of configuration files, packing and unpacking internal data to and from, say, XML, etc. The boost::lexical_cast looked very promising and was the preferred solution compared to others (such as C functions, std::stringstream, etc., see the lexical_cast documentation for more discussion about alternatives). Unfortunately, I needed functionality beyond what lexical_cast was providing (configurable throw/no-throw behavior, formatting support, locale support, etc.). After discussions on the Boost developers list and with the lexical_cast author (Kevlin Henney) and the maintainer (Alexander Nasonov) it was collectively decided that the required functionality extensions were not compatible with the idea of what lexical_cast embodied and a more dedicated family of conversion functions with richer interfaces was needed. That decision resulted in the development of the following header-only string-conversion library described in this document: boost::string::convert() The interface is explicit about its purpose ? string-related -- string-to-type and type-to-string -- conversions. It builds on the lexical_cast past experience, offers the already familiar conversion functionality and more: · throw and no-throw conversion-failure handling behavior; · support for the default value to be returned when conversion fails; · formatting support based on the standard (or user-defined) manipulators (like std::hex, std::scientific, etc.); · locale support; · support for various (boost::range-compliant) char and wchar_t-based containers (std::string, std::wstring, char const*, wchar_t const*, char array[], std::vector<char>, etc.); · no DefaultConstructibility requirement for the Target type; · room to grow.

12 73

GMANE gateway to the Boost Users mailing list seems dead
by Vladimir Batov 21 Feb '09

21 Feb '09

... as its overall traffic

2 1

Re: [boost] Formal Review Request: Boost.Convert
by Andrzej Krzemienski 21 Feb '09

21 Feb '09

Hi, I would like to propose removing the default value for the second argument of convert. I believe it may be insecure. Let me explain it by exemple. What did I mean when I wrote the following code: string str = readInput(); int men = convert_to<string, int>(str); 1. I meant: "if conversion is impossible, return 0", because I read the documentation thoroughly. 2. I am a novice and didn't really think about the situation where someone types a non-int string. In case of the first option it is all fine, but if the latter is the case, it may have been better to throw an exception to the user. I would propose, rather than having a default "fallback" value to provide two overloads for convert: one with two parameters where you can provide the fallback value, and the other, one-parameter, that would indicate that you want to throw an exception on failure. Yo do not loose much of your original interface, because you can write more explicitly: int men = convert_to<string, int>(str, 0); I find it better because: 1. It forces the writer to type more clearly his intentions. (Or explicitly confirm that he is aware that the string may not be convertible to int.) 2. Releaves you from providing the throw_t argument altogether. This in turn removes the possibility of writing: convert<string, int>(str, -1) >> throw_t(); // What does -1 mean here? Regards, &rzej

2 2

[utility] A fix for the const issue of value_initialized
by Niels Dekker - mail address until 2010-10-10 20 Feb '09

20 Feb '09

The boost::value_initialized<T> utility has a major issue regarding const-correctness: It has a const-qualified conversion operator, returning a non-const reference to the T object it owns. I have already created a ticket, <https://svn.boost.org/trac/boost/ticket/2548>, and mailed Fernando Cacciola (the author of value_initialized) on this issue. He agrees that it should be fixed, and he allows me to do so. The patch I've attached to the ticked replaces the current conversion operator by two of them, overloaded for const and non-const access: operator T const &() const { return this->data(); } operator T&() { return this->data(); } The patch also fixes value_initialized::data() in a similar way. Please let me know if you have any problem with the patch. Otherwise I'd like to apply it to the trunk by the end of the week: https://svn.boost.org/trac/boost/attachment/ticket/2548/value_initialized_c… Note that the issue has been discussed here already five years ago: http://lists.boost.org/Archives/boost/2004/01/59987.php At that time, some non-conforming compilers couldn't deal with conversion operators overloaded for const and non-const access. But now I've tested the value_initialized patch on a few compilers (MSVC 2003, MSVC 2008, CodeGear), and they all succeeded. After the commit, I'll keep a close look at the regression page, of course. Kind regards, Niels -- Niels Dekker http://www.xs4all.nl/~nd/dekkerware Scientific programmer at LKEB, Leiden University Medical Center

1 1

[ignore this] Hello?
by Andrey Semashev 20 Feb '09

20 Feb '09

test

1 0

[any] Multimethod for boost::any and modified boost::any to fit multi method
by nowake＠fiercewinds.net 20 Feb '09

20 Feb '09

Hi All. I create multi method for boost::any using Modern C++ Design's multi method technique. It can dispatch method dynamically like this: _________________________________________________________________________ struct T1 { string operator()(int value) const { return string("T1(int)"); }; string operator()(double value) const { return string("T1(double)"); }; string operator()(A value) const { return string("T1(A)"); }; }; // "entry" to Multi method bool t10(Multimethod::entry<any, any, T1, int>()); bool t11(Multimethod::entry<any, any, T1, double>()); bool t12(Multimethod::entry<any, any, T1, A>()); struct T2 { string operator()(int value) const { return string("T2(int)"); }; }; // "entry" to Multi method bool t20(Multimethod::entry<any, any, T2, int>()); BOOST_AUTO_TEST_CASE(test04) { any m((T1())); any a(0); BOOST_CHECK_EQUAL( any_cast<string>(Multimethod::apply<any>(m, a)), "T1(int)"); a = 0.0; BOOST_CHECK_EQUAL( any_cast<string>(Multimethod::apply<any>(m, a)), "T1(double)"); a = A(); BOOST_CHECK_EQUAL( any_cast<string>(Multimethod::apply<any>(m, a)), "T1(A)"); m = T2(); a = 0; BOOST_CHECK_EQUAL( any_cast<string>(Multimethod::apply<any>(m, a)), "T2(int)"); }; __________________________________________________________________________ If you are interested in this multi method, please see #2749 for detail. https://svn.boost.org/trac/boost/ticket/2749 Thanks, Nowake

4 10

[asio] two-lock queue deadlocks?
by Dean Michael Berris 20 Feb '09

20 Feb '09

Hi Guys, I've run into an issue with defining BOOST_ASIO_ENABLE_TWO_LOCK_QUEUE when using Boost.Asio in Boost 1.38.0. I'm currently implementing an asynchronous HTTP client and when I wanted to try the experimental feature and on a single-core machine apparently I run into a deadlock when the asynchronous handler is itself posting to the same io_service queue that hosted it. Is this a known issue with BOOST_ASIO_ENABLE_TWO_LOCK_QUEUE, or is this a usage issue? -- Dean Michael Berris | Software Engineer, Friendster, Inc. blog.cplusplus-soup.com | twitter.com/mikhailberis | linkedin.com/in/mikhailberis | profiles.friendster.com/mikhailberis | deanberris.com

1 0

[asio] Received 3 times RST, ACK before the boost TCP returns connection failure
by allen han 20 Feb '09

20 Feb '09

Hi: Pretty new to use the boost library for networking and experienced a problem to use the TCP socket on client side. 1. using the call below to connect server: mSocket.async_connect(endpoint,boost::bind(&handleConnect, this, boost::asio::placeholders::error, ++aEndPointIterator)); 2. found connection is failed, then close the socket void handleConnect(const boost::system::error_code &aErr, boost::asio::ip::tcp::resolver::iterator aEndPointIter) { if (!aErr) { ... } else if (aEndPointIter != boost::asio::ip::tcp::resolver::iterator()) { doClose(); ... } else { ... doClose(); } } 3. From Ethereal, found that SYN, RST/ACK have been sent 3 times before the connection is closed, Client sent Server SYN, Server sent Clinet RST, ACK Client sent Server SYN, Server sent Clinet RST, ACK Client sent Server SYN, Server sent Clinet RST, ACK Question: Any flag to inform the boost TCP stack to return error if it receives the first RST,ACK?

2 1

[1.38] PDF docs release candidate available
by John Maddock 19 Feb '09

19 Feb '09

The release candidate for the PDF build of the 1.38 docs is now available from http://boost.cowic.de/rc/pdf/, unless anyone spots any last minute issues, I'll put these on sourceforge at the weekend. Enjoy, John.

3 6

[date_time] How to build the docs?
by John Maddock 19 Feb '09

19 Feb '09

Am I correct in thinking that the date_time docs need some manual intervention to build correctly? Any instructions? Thanks, John.

1 0

[fusion] C++0x support?
by Ein Held 19 Feb '09

19 Feb '09

Hello is there any chance for c++0x support (rvalue forwarding for the containers' constructors and operator=s' in particular) for fusion in 1.39? Thank you

1 0