April 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

[#pragma once]
by Sid Sacek 18 Nov '12

18 Nov '12

I've worked with the MSVC, Sun and GCC compilers. Each one of them supports #pragma once. Is there any reason to wrap this pragma within #ifdefs? Are there any compilers out there today that don't support this #pragma? #if defined( _MSC_VER ) && ( _MSC_VER >= 1020 ) # pragma once #endif Could we change this coding pattern so that it no longer looks like MSVC is being selfish? -Sid Sacek

17 20

[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

[C++0x] Emulation of scoped enums
by Beman Dawes 16 Feb '11

16 Feb '11

The improved type safety of the C++0x scoped enum feature is attractive, so I'd like to start using it as it becomes available in compilers. See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a description. Note that the committee changed the name from strongly typed enums to scoped enums. See the attached for a boost/detail header that provides macro wrappers that use scoped enums if available, otherwise fall back on C++03 namespaces and unscoped enums. It lets a library write: BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END ... BOOST_SCOPED_ENUM(algae) sample( algae::red ); void func(BOOST_SCOPED_ENUM(algae)); and then a user can write: sample = algae::green; func( algae::cyan ); Comments or suggestions appreciated, --Beman // scoped_enum_emulation.hpp ---------------------------------------------------------// // Copyright Beman Dawes, 2009 // Distributed under the Boost Software License, Version 1.0. // See http://www.boost.org/LICENSE_1_0.txt // Generates C++0x scoped enums if the feature is present, otherwise emulates C++0x // scoped enums with C++03 namespaces and enums. The Boost.Config BOOST_NO_SCOPED_ENUMS // macro is used to detect feature support. // // Caution: only the syntax is emulated; the semantics are not emulated and // the syntax emulation doesn't include being able to specify the underlying type. // // See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2347.pdf for a // description of the feature. Note that the committee changed the name from // strongly typed enums to scoped enums. // // Sample usage: // // BOOST_SCOPED_ENUM_START(algae) { green, red, cyan }; BOOST_SCOPED_ENUM_END // ... // BOOST_SCOPED_ENUM(algae) sample( algae::red ); // void foo( BOOST_SCOPED_ENUM(algae) color ); // ... // sample = algae::green; // foo( algae::cyan ); #ifndef BOOST_SCOPED_ENUM_EMULATION_HPP #define BOOST_SCOPED_ENUM_EMULATION_HPP #include <boost/config.hpp> #ifndef BOOST_NO_SCOPED_ENUMS # define BOOST_SCOPED_ENUM_START(name) enum class name # define BOOST_SCOPED_ENUM_END # define BOOST_SCOPED_ENUM(name) name #else # define BOOST_SCOPED_ENUM_START(name) namespace name { enum enum_t # define BOOST_SCOPED_ENUM_END } # define BOOST_SCOPED_ENUM(name) name::enum_t #endif #endif // BOOST_SCOPED_ENUM_EMULATION_HPP

14 27

[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

[utility] auto_buffer v2
by Thorsten Ottosen 07 Oct '09

07 Oct '09

Dear All, Hereby an updated class. Thanks to all who contributed with comments to the first try. I have made the following changes: 1. push_back() overloads are now growing 2. added swap() (boy, was this nasty to implement). I assume the allocator can be wapped without throwing. How do other people copy with this problem? 3. added copy-constructor + copy-assignment 4. made the min capacity equal to N, the number of elements in the stack buffer 5. the size of the internal buffer is now controlled via two policies: template< unsigned N > struct store_n_objects; template< unsigned N > struct store_n_bytes; the default is store_n_objects<256>. The reason is that we don't want the capacity to change just because we compile on a different platform. 6. added comparison operators Comments most welcome! best regards -Thorsten

4 7

[Endian] Version 0.10 available - Binary I/O added
by Beman Dawes 16 Sep '09

16 Sep '09

Version 0.10 of the Endian Integers library is available. Docs: http://mysite.verizon.net/beman/endian-0.10/libs/integer/doc/endian.html Zip: http://mysite.verizon.net/beman/endian-0.10.zip Sandbox: http://svn.boost.org/svn/boost/sandbox/endian This version adds binary I/O for both endian integers (<boost/integer/endian_binary_stream.hpp>) and C++ built-in types + std::string (<boost/integer/endian_binary_stream.hpp>). Support for C++0x features has also been added, ensuring that an Endian integer on C++0x is a POD. Comments appreciated! My Endian TODO list is pretty well cleared, so there are comments to the contrary, the library will be submitted for formal review in a few days. --Beman

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

[mpl]iter_fold_if Forward Backward rationale?
by Larry Evans 10 Jun '09

10 Jun '09

Why is there both a ForwardOp and BackwardOp template argument to iter_fold_if? https://svn.boost.org/trac/boost/browser/trunk/boost/mpl/iter_fold_if.hpp#L… I would have thought that only 1 was needed. Since iter_fold_if is not documented here: http://www.boost.org/doc/libs/1_38_0/libs/mpl/doc/refmanual/refmanual_toc.h… I assume it's not meant to be used by the user, but is only an implementation detail; however, it, or a variation, might be useful to implement the and_seq mentioned here: http://article.gmane.org/gmane.comp.lib.boost.devel/186204 As shown in that post, the template, while_if_then was used, and it does not require anything like both a ForwardOp and BackwardOp, it just requires the If and Then unary metafunctions. One problem I encountered with while_if_then was moving to the end of the sequence, at which time the Then metafunction couldn't be called; hence, I had to make it lazy to avoid dereferencing the end iterator. Is that somehow related to the need for BackwardOp in iter_fold_if. IOW, because iter_fold_if might reach the end iterator, it has to backup? I'm really asking because in the variadic template version of mpl, I wondering if iter_fold_if could be replaced with something like while_if_then (which may be renamed fold_if to be more consistent with other names with similar function). Any insight about the rationale for the iter_fold_if would probably save me considerable time in deciding whether it can be replaced with the proposed fold_if. -regards, Larry

3 28

Boost.Process article: Tutorial and request for comments
by Boris Schaeling 01 Jun '09

01 Jun '09

I've written an article about Boost.Process: http://www.highscore.de/cpp/process/ I've also fixed a few bugs in Boost.Process (which is now 0.31): http://www.highscore.de/boost/process.zip And the latest source code can also be found in the sandbox: https://svn.boost.org/svn/boost/sandbox/process/ For developers not familar with Boost.Process the article is a tutorial to get more easily started. For developers familiar with Boost.Process it is a request for comments. I've been looking at the big picture finally trying to find out where and how Boost.Process should be changed and in which direction it should move to become a complete library one day. As not everyone will read the entire article here are my thoughts: 1) Boost.Process is based on a few concepts like 'process' and 'context'. While those make sense there are other concepts where I wonder if they should be dropped: * 'executable' is the executable name which in practice must be a std::string. I think the original idea was to support numerous string types. This leads to the question how to support different Unicode encodings which I think is still unanswered in the Boost community. Other libraries, eg. Boost.Interprocess, simply stick to one string type (typically std::string). * 'handle' is the underlying native file handle of a stream (file descriptor on POSIX systems, handle on Windows). The concept is based on a class in the detail namespace of Boost.Process. There is just one class and it's not meant to be used by users of the library either. Thus I'm not sure what's the benefit of having an explicit 'handle' concept at all. 2) Environment variables must be sorted on Windows but not on POSIX systems. On Windows the type environment could be a typedef for std::map and on POSIX systems for std::unordered_map. Currently it's always a typedef for std::map. Is that ok? Should it be changed? Should a macro be provided in case developers want to use different typedefs? 3) Currently Boost.Process is really only useful for creating child processes. It's not possible for example to detect and iterate over other processes on a system. I guess Boost.Process should be enhanced here. Then one day the well-known utility 'ps' on POSIX systems could be implemented in Boost C++. Any comments? 4) When a process is created the standard streams (stdin, stdout and stderr) are closed by default. Is this a good choice? If it isn't what should happen otherwise? Inherting standard streams (which is the default behavior with fork on POSIX systems)? 5) Boost.Process requires to specify an absolute path to an executable which should be started. There is a helper function which returns the absolute path for an executable name (it uses the environment variable PATH). The question is if this should be done automatically if no absolute path is given? 6) When a stream of a child process is captured Boost.Process automatically creates a pipe. As pipes don't support asynchronous operations on Windows a named pipe is required (called FIFO on POSIX systems). Currently a macro must be defined to make Boost.Process use a named pipe on Windows. It might make more sense to enable developers to choose either a pipe or a FIFO explicitly - not only on Windows but on all platforms. Any comments? 7) It's possible to capture and access streams of a child process. Those streams are derived from std::istream and std::ostream and thus only support blocking I/O operations. Currently the underlying handle has to be fetched to initialize a generic I/O object from Boost.Asio to use asynchronous I/O operations. How should the library be changed to make it easier to use asynchronous I/O? 8) There is a method wait() which makes it possible to wait for another process to exit. Currently wait() is provided by the class child though. Shouldn't it really be defined by the class process (so you can wait not only for child processes to exit)? 9) As wait() blocks an asynchronous alternative should be provided. 10) The Windows-specific classes all start with win32_ (eg. win32_child). Wouldn't it make more sense to use windows_ instead (like windows_child) or a windows namespace? First other libraries use windows_ (see Boost.Interprocess). Second there should be no reason why a class like win32_child can't be used on a 64-bit Windows. Boris

4 10

[1.39.0] Ready for beta?
by Beman Dawes 29 May '09

29 May '09

I've gotten badly sidetracked by non-Boost work, but would like to get the 1.39.0 beta out tomorrow if at all possible. Are there any known showstoppers? If anyone has a few spare minutes, it would help if they could download one of the current release snapshots from http://boost.cowic.de/rc/, browse around and report any problems spotted. Library authors who use Boostbook/Quickbook, but don't have time to look at the full snapshot, might want to check http://boost.cowic.de/rc/boost-docs.7z Known problems/questions: * index.html ??? needs to be replaced by new library count. * pdf docs: Do we want to do anything more for this release? Thanks, --Beman

13 29

request for interest in a garbage collection library
by Achilleas Margaritis 29 May '09

29 May '09

Hi, I have placed in boost vault a garbage collection library: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=gc.zip… The major features of this library are: 1) it supports threads; a thread can allocate gc objects and send them to other threads. 2) it is 100% portable c++; only boost and stl are used. 3) gc pointers can point to middle of objects and arrays. 4) block allocation and finalization are customizable. The collector does not do any allocation actually, it only manages blocks. 5) the collector uses the classic mark & sweep algorithm. 6) it has good (or not that bad :-)) performance. On my test machine (a dual core Pentium at 2.5 GHz with 2 GB ram), 50000 objects out of 100000 are swept in 63 milliseconds. Of course, this is due to boost::pool :-). 7) it works with STL containers (the 'how' is described in the readme). The zip file contains a set of unit tests, the API documentation and a readme file which explains the inner workings and the design of the collector. I would appreciate it if people could take a look and share their opinions on it. Best regards Achilleas Margaritis

22 64

[gsoc] Official list released
by troy d. straszheim 29 May '09

29 May '09

On behalf of the panel of mentors, congratulations to the students listed here: http://socghop.appspot.com/org/home/google/gsoc2009/boost And a sincere thank you to all those who applied. There are a large number of entirely worthy proposals that we received that are not on that list. We had about 75 proposals, 11 willing mentors, and as you can see, Google gave us seven slots. It was very difficult to narrow down the list to these seven, and if we'd been given more slots, of course more of you would be on that list. Unfortunately, due to the sheer number of submissions and various, ahem, technical problems, it would not have been (and will not now be) possible to offer specific feedback on submissions that didn't make the cut. For this we apologize. Accepted students should eventually receive email from Google with further instructions. Per the schedule, the "community bonding" period now begins, time to get your dev. environment set up, get to know the toolchain, write some 'hello world' quickbook docs, etc. Ask for help if you need it. You can also visit some of your fellow summer coders on #boost-soc on freenode. -t

5 4

[fusion] adding infinite sequences to fusion
by Stjepan Rajko 29 May '09

29 May '09

Hi all, There's been some off-list discussion between Dan Marsden, Joel de Guzman and myself on how to address infinite sequences in fusion. Joel suggested to bring the discussion back to the list for more feedback: On Wed, Apr 15, 2009 at 6:21 PM, Joel de Guzman <djowel(a)gmail.com> wrote: > Stjepan Rajko wrote: >> >> Here is a list and description of all of the concepts that might be >> relevant: >> >> >> Forward Sequence >> begin(s) - returns a Forward Iterator >> empty(s) - returns a bool >> front(s) - any type >> >> Finite Forward Sequence >> refines Forward Sequence >> end(s) - returns a Forward Iterator >> size(s) - MPL integral constant >> >> Infinite Forward Sequence >> refines Forward Sequence >> empty(s) - returns false >> size(s) - infinity >> >> Bidirectional Sequence >> refines Forward Sequence >> begin(s) - returns a Bidirectional Iterator >> >> Finite Bidirectional Sequence >> refines Bidirectional Sequence, Finite Forward Sequence >> end(s) - returns a Bidirectional Iterator >> back(s) - any type >> >> Infinite Bidirectional Sequence >> refines Bidirectional Sequence, Infinite Forward Sequence >> >> Random Access Sequence >> refines Bidirectional Sequence >> begin(s) - returns a Random Access Iterator >> >> Finite Random Access Sequence >> refines Random Access Sequence, Finite Bidirectional Sequence >> end(s) - returns a Random Access Iterator >> >> Infinite Random Access Sequence >> refines Random Access Sequence, Infinite Bidirectional Sequence >> >> >> How does that look? > > I'd suggest posting that to the Boost list to get more feedback. > I have a feeling that infinity is a separate concept orthogonal > to traversal. But I'm not sure. > The above layout is almost orthogonal, with Infinite Forward Sequence and Finite Forward Sequence serving as "base" concepts related to Finite / Infinite. I suppose you could have less refined Infinite Sequence and Finite Sequence concepts, but I'm not sure how useful they would be (AFAICT, they could only describe `size` and `empty`). Things aren't perfectly orthogonal because Finite + Bidirectional require `back`, but Finite + Forward do not, and neither do Infinite + Bidirectional. Best, Stjepan > Regards, > -- > Joel de Guzman > http://www.boostpro.com > http://spirit.sf.net >

2 2

G++ hack/challenge?
by David Abrahams 27 May '09

27 May '09

Hi all, In preparation for BoostCon, I'm looking for a workaround for the problems described in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2855.html. In particular I need a way to detect whether a type "has a move constructor" (without causing a compiler error, of course) in GCC 4.4. Ideally, "has a move constructor" would mean - when constructed from an rvalue of the same type, a copy constructor with signature T(T const&) is not used. though I would settle for - has a constructor with the signature T(T&&) I'm willing to use G++-specific hackery if necessary. I strongly suspect it's impossible, but if you can think of any way to do it, I'd really appreciate knowing about it. You'll be my hero forever ;-) TIA, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

3 3

git clone up
by troy d. straszheim 18 May '09

18 May '09

In case this reaches any other git enthusiasts, I've rigged up a git clone that is automatically tracking boost svn, here: http://sodium.resophonic.com/git/boost/ Click around on it... it's smoking fast, despite the fact that it is running on hardware I found in the trash on the end of a mediocre uplink. There is a little howto here: http://sodium.resophonic.com/git/boost/about/ The repository (minus checkout) is about 150M, it contains branches and tags going all the way back. It will take a while to do the initial clone but fetches after that are very fast. -t

4 8

[test] Using the Boost Unit Test Framework with shared libs
by Peter 17 May '09

17 May '09

Hi I am using Boost.Test from the current boost 1.38 , on cygwin ( gcc ) and I want to use it with multiple test files and with shared libs ( in order to speed up the compilation time which is too long for me when using the header include variant ). What is the recommended way ? ( I read the doc, several times and I read the _long_ threads on the mailing list concerning the static/shared library issue, but I am not sure that I understood all the details). I did the following: *in mainTest.cpp:* #define BOOST_TEST_DYN_LINK #define BOOST_TEST_MAIN #include "../inc/globalFixture.hpp" #include "../inc/testfile1.hpp" #include "../inc/testfile2.hpp" *testfile1.hpp:* #include "globalFixture.hpp" BOOST_FIXTURE_TEST_SUITE(ATlib1, Fixture) BOOST_AUTO_TEST_CASE(Resource_Manager) { ... ....BOOST_CHECK .... } BOOST_AUTO_TEST_SUITE_END() *testfile2.hpp:* #include "globalFixture.hpp" BOOST_FIXTURE_TEST_SUITE(ATlib2, Fixture) BOOST_AUTO_TEST_CASE(FileManager { ... BOOST_CHECK .... } BOOST_AUTO_TEST_SUITE_END() *globalfixture.hpp: *#ifndef _GLOBALFIXTURE_HPP #define _GLOBALFIXTURE_HPP #define BOOST_TEST_MODULE ATlib #include <iostream> #include <boost/test/unit_test.hpp> #include <boost/test/detail/unit_test_parameters.hpp> #include <boost/bind.hpp> #include <boost/test/output_test_stream.hpp> using namespace boost::unit_test; struct GlobalConfig { GlobalConfig() { std::cout << "GlobalConfig setup\n"; using namespace boost::unit_test; if (runtime_config::log_level() < log_warnings) unit_test_log.set_threshold_level(log_successful_tests); }; ~GlobalConfig() { std::cout << "GlobalConfig teardown\n"; } }; BOOST_GLOBAL_FIXTURE(GlobalConfig); struct Fixture { Fixture() { BOOST_TEST_MESSAGE("setup Fixture"); using namespace boost::unit_test; unit_test_log.set_threshold_level(log_successful_tests); } ~Fixture() { BOOST_TEST_MESSAGE("teardown Fixture"); } }; #endif /* _GLOBALFIXTURE_HPP */* *I then link to boost_unit_test_framework-gcc34-mt-1_38.so The link passes , but I get a warning from gcc++ 3.4.4 that auto-linking has been enabled ( I will provide the exact details if useful ). I can execute the resulting mainTest.exe without problems, but the compiler warnings tells that something is not quite right. Is the above example the right way to use multiple test files ? Are the flags for shared libs correctly set ? Thanks for your help. PS: I think that Boost.Test is not easy to grasp ( at least for me ). I think this is partially due to a lack of complete examples ( involving for examples a test suite with more than one test file ). Also the static/shared library topic and the related macros ( BOOST_TEST_DYN_LINK etc ) could do with a concrete example. Maybe the mentioned case above could serve as an example after clarification. Peter

3 3

[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

[test]
by Jochen Heckl 17 May '09

17 May '09

Hi, I think I stumbled over a problem in the boost unit test library. I'm running MSVC 2008 SP1. Maybe also worth mentioning is, that I use _HAS_TR1=0 with any msvc build. Also I compile boost using bjam define=_HAS_TR1=0 ... Well straight to the problem: this code (boost\test\utils\basic_cstring\basic_cstring.hpp, around line 170) template<typename CharT> inline basic_cstring<CharT>::basic_cstring( std_string const& s ) : m_begin( s.c_str() ) , m_end( m_begin + s.size() ) { } will result in a corrupted basic_cstring, if the source string s goes out of scope, which is the case here ( \boost\test\impl\unit_test_main.ipp, around line 179 ) ... int BOOST_TEST_DECL unit_test_main( init_unit_test_func init_func, int argc, char* argv[] ) { try { framework::init( init_func, argc, argv ); if( !runtime_config::test_to_run().is_empty() ) { test_case_filter filter( runtime_config::test_to_run() ); // <--- parameter will become corrupted traverse_test_tree( framework::master_test_suite().p_id, filter ); } ... because of the temporal std::string return from retrieve_parameter (boost\test\impl\unit_test_parameters.ipp, around line 353 ) const_string test_to_run() { return retrieve_parameter( TESTS_TO_RUN, s_cla_parser, s_empty ); } as quick and very very dirty fix I currently use: test_to_run() { static std::string TTR = retrieve_parameter( TESTS_TO_RUN, s_cla_parser, s_empty ); return TTR; } However, I would welcome, if somebody could supply a more suitable solutions. Best Jochen

2 1

[gsoc] Proposal for Generic Trie, Radix Tree, and Suffix Array Data Structures
by Chris Wagner 17 May '09

17 May '09

Hello, I am interested in writing a library consisting of generic implementations of several common data structures and algorithms primarily useful in text-processing. I believe these would be useful additions to Boost and would like to work on them for GSoC. Before I submit my proposal, I would like to hear whether or not the community agrees that this is a good idea, and I would appreciate any suggestions or comments offered. My plan is to implement a trie / prefix tree data structure, STL set/map-like classes implemented over the trie, a radix tree, a suffix tree implemented over the radix tree, and a suffix array. These would be instantiable over arbitrary sequence types, and use iterator traits to determine the contained type. I am a student at Kent State University, working on an M.S. in Computer Science in a combined undergraduate/graduate program. I have a particular interest in computational linguistics, and I will admit that am especially interested in this project because of how it could be applied to my own field, but I believe that these types would be of general utility to the programming community as a whole. Thank you for your time, Chris Wagner

5 5

[1.39.0] Beta candidate
by Beman Dawes 15 May '09

15 May '09

The beta candidate files are up at http://boost.cowic.de/rc/ Before pushing these out to SourceForge, it would be great if a few Boosters could download and try them out as a final QA check. Post your experiences here. Thanks, --Beman

9 24

Review Request: Algorithm.Sorting
by Steven Ross 15 May '09

15 May '09

I have uploaded algorithm_sorting.zip for a formal review to become Boost.Algorithm.Sorting, if people feel that is appropriate. It is 3 templated hybrid radix-based/comparison-based algorithms, specialized to sort certain types of data more efficiently. All 3 have superior worst-case and average-case performance to std::sort, based upon my testing. None of these algorithms use much additional memory. All of them can sort key + data, and as they do fewer swaps, tend to do so much faster than std::sort. As a general rule, the speedup of these algorithms relative to std::sort increases as data set size increases. These algorithms tend to be faster relative to std::sort when comparisons are slow, as they do less (or no) comparisons. string_sort, which sorts strings in O(n*length) time, as compared to O(n*length*log(n)) for pure comparison-based algorithms. It is consistently faster than std::sort in string sorting, by a little more than a factor of 2 based upon my testing. float_sort, which sorts IEEE floating-point numbers as integers, but attaining the same ordering as std::sort, with the exception of -0.0 and NaNs, both of which cannot be ordered based upon their comparison function. float_sort is roughly twice as fast as std::sort on UNIX-type OSes I've tested on, and roughly 7X as fast on Windows. I believe this speedup to be because floating-point comparisons are slow on Windows. integer_sort, which sorts integers around 60% faster than std::sort on UNIX-type OSes, and 25% faster on Windows. On Windows with MSVC, std::sort sorts already-sorted and small range data extremely quickly, and integer_sort processes already-sorted data slower than it by as much as a factor of 3X. I believe this to be due to some optimization for already-sorted data, as integer_sort takes substantially less absolute time on already-sorted data than unsorted data. So integer_sort on Windows has a tradeoff: better worst-case and average-case performance, but worse best-case performance. integer_sort and float_sort share some tuning parameters. I have set values that seem to work well on both UNIX-type and Windows OSes, but people are welcome to try to see what values are best for their system and problem type. The ideal values for integers and floats may be different on some systems (such as Windows), but for simplicity they are kept the same. A tuning/testing script named tune.pl is included, for those who wish to see how fast these algorithms are on their system (and verify correctness). I don't recommend using it for tuning without the -large option, and that takes days. If you do use it for tuning, I also recommend the -verbose option, to see what it's doing.

6 19

[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

[iostreams] regression - Missing include guard in boost/iostreams/device/mapped_file.hpp
by Bjørn Roald 10 May '09

10 May '09

Hi, Seems like the trunk@46692 commit, 25 june 2008, removed the include guard in boost/iostreams/device/mapped_file.hpp This breaks gcc43 compilation of sources directly including this header. Eg. http://www.mapnik.org/ trunk code. -- Bjørn

2 4

[thread] on_tls_prepare in win32\tss_pe.cpp incompatible with static linkage to a /clr object
by Matthew Chambers 06 May '09

06 May '09

I'm very interested in being able to have a native C++ executable which makes use of boost's TSS and also be able to wrap .NET modules with C++/CLI (i.e. /clr). And I much prefer it to be statically linked. The C++/CLI wrappers work fine when they are dynamically linked, but they cause a runtime initialization error (0xc000007b) whenever they are connected in only static links. It doesn't matter whether the host executable is compiled with /clr or not - somehow the MSVC linker knows to add some CLR initialization voodoo to the PE header whenever a static link to a /clr-enabled object is made. And that PE header voodoo seems to be incompatible with some of boost::thread's own brand of PE header voodoo which appears to be intended to provide TLS support for Windows. But as far as I can tell, I was able to get TLS working with MSVC9 even after commenting out the on_tls_prepare lines in tss_pe.cpp - commenting out the other lines wasn't necessary: > #if (_MSC_VER >= 1400) > //#pragma section(".CRT$XIU",long,read) > #pragma section(".CRT$XCU",long,read) > #pragma section(".CRT$XTU",long,read) > #pragma section(".CRT$XLC",long,read) > static __declspec(allocate(".CRT$XLC")) _TLSCB > __xl_ca=on_tls_callback; > // static __declspec(allocate(".CRT$XIU"))_PVFV p_tls_prepare = > on_tls_prepare; > static __declspec(allocate(".CRT$XCU"))_PVFV p_process_init = > on_process_init; > static __declspec(allocate(".CRT$XTU"))_PVFV p_process_term = > on_process_term; > #else I put together a test case that I'm pretty sure shows that TLS still works without that function. At the very least, can there be some preprocessor define to manually disable it for CLR compatibility? Or perhaps there is a way to adjust this voodoo to be compatible with the CLR initialization? I'm hosting the test case at: http://fenchurch.mc.vanderbilt.edu/files/TLS_CLR_Test.7z It includes a main function which runs a test of the TSS semantics, and a CLR class which tests console output via C++/CLI. I included binaries and the boost_thread.lib files for both the broken and "fixed" versions of tss_pe.cpp. Thanks, Matt Chambers

2 2

[aligned storage] support for empty storage
by Thorsten Ottosen 06 May '09

06 May '09

Hi all, Currently the following fails: typedef boost::aligned_storage< 0, 4u > storage; storage s; because this will try to create an empty array. Does anybody have anything against adding the following specialization: template< std::size_t alignment_ > struct aligned_storage_imp<0u,alignment_> { /* intentionally empty */ }; Also, I would like to derive from aligned_storage_imp to get the EBO: template < std::size_t size_ , std::size_t alignment_ = std::size_t(-1) > class aligned_storage : private detail::aligned_storage::aligned_storage_imp<size_, alignment_> { ... } The above changes enable the following program typedef boost::aligned_storage< 0, 4u > storage; struct simple : storage { int i; }; #include <iostream> int main() { std::cout << sizeof(storage) << " " << sizeof(simple); } to output "1 4" instead of "1 8" on gcc. In case your are wondering, then I need this functionality in boost::auto_buffer to get rid of the extra word when the stack-buffer is empty (thus making auto_buffer as small as vector). Comments? -Thorsten

2 4

[Review Results] Range.Ex library accepted into boost
by Thorsten Ottosen 04 May '09

04 May '09

Dear all, It is my pleasure that Neil Groves' RangeEx library has been accepted into boost. Congratulations Neil! There are quite a number of minor issues that need to be resolved before the library is release ready, see below for a summary. Review statistics ----------------- Full Reviews: 8. Discussion: extensive. I had the clear impression that everybody that participated in the discussion were in favor of this library, albeit they did not have time to submit a full review. I did not hear a single statement saying that this library should be rejected. Thanks to everybody that participated in the review and its discussions. Issue Summary ------------- Below is given a list of topics that must be adressed before the library can be included into boost. In general, we should try to discuss them one at a time in seperate threads. Many people suggested various extensions, new algorithms (e.g. from adope), etc. **In general we should not require Neil to add all these if he does not have the time currently: the basic infrastructure, the concepts, the naming and organization of the library is much more important. Then we can add all these things later.** 1: documentaion =============== The documentation should clearly reflect if an algorithm delegates to a standard algorithm. If the algorithm is new, then it should state complety and exception-safety. More examples would be welcome. Sometimes the rationale and explanations could be improved, e.g for operator|(). 2: return type specification for find() etc =========================================== There where no major objection to the mechanism, but some found the syntax ugly. I believe the suggested syntax (e.g.) boost::find[_f,_e]( range, x ) boost::find[_f+1,_e]( range, x ) was considered good by most. 3: namespace organization ========================= Currently the library uses the namspaces boost boost::adaptors Some raised concern about putting the algorithms straight in the boost namespace before we have a general agreement on where to put algorithms (e.g. in boost::algorithm or boost::ranges or whatever). I think it will make sense to put each algorithm in its own header, since we might have to include additional standard library headers for calling algorithms that are implemented as member functions (but see 7 below). Feedback is most welcome. 4: naming convention for adaptors ================================= The following have been proposed throughout the review (here examplified with "transform"): | transformed( fun ) | transform( fun ) | transform_view( fun ) | view::transform( fun ) There where no consensus during the review. Other libraries seem to use the _view suffix, which is a strong argument for that candidate (in that case, I suggest to drop the adaptors namespace). 5: naming convention for the adaptor generators =============================================== Many people like to be able to say make_transform_range(r,fun) instead of r | transformed( fun ). There was no concensus on how to name these functions. Here are some candidates: make_transform_range( r, fun ) transformed( r, fun ) transform( r, fun ) (*) transform_view( r, fun ) (*) was dislike by some because it has exactly the same spelling as the algorithm transform. Many felt that the confusion is too big if view generators are not named different from the actual algorithms. 6: reintroducing _if variants of algorithms =========================================== An important problem with the suggested approach was the the iterator returned by an algorithm after applying | filtered( pref ) are now filtered iterators and so one needs to manually unwrap the return iterator. This provided enough justification for reintroducing these algorithms. (One could imagine that this unwrapping was done automatically by a conversion operator such that iterator i = boost::find( r | boost::filtered( pred ), x ); "just worked". However, the syntax is still slightly worse than just using the original algorithm). Generic programming is concerned with the use of orthogonal concepts which put together yields all possible combinations of algorithms. If we reintroduce all _if algorithms, we have to aks ourselves "when does it end?". Should all new algorithms then simply add _if variants? This seems very much against the spirit of generic programming. The problem with the iterators being changed (as in the find example) seems to suggest the following guideline: "If the algorithm returns an iterator, it makes sense to provide an _if overload. Otherwise it does not." Under this guideline, find_if() should be there, but count_if() should not be provided. 7: should algorithms call member function when possible? ======================================================== I heard one strong voice against this. The reason was that the algorithm implemented as member function often has quite different guarantees w.r.t. complexity, reference and iterator stabililty. I think this is a very strong argument. Also, we can add this later if good arguments appear, but it is much harder to take away. We also have to remember Scott Meyers item "Beware of container independent code" which also suggest that this is a bad idea. At the very menimum, the original algorithm and the member function should have similar semantics. This seems to suggest that we can call set::lower_bound() from boost::lower_bound(). In that case, the best way would probably be to add these as overloads in the boost namespace: template< class T, class A > typename std::set<T,A>::iterator lower_bound( std::set<T,A>& s ); template< class T, class A > typename std::set<T,A>::const_iterator lower_bound( const std::set<T,A>& s ); 8: making return values of algorithms consistent/intuitive ========================================================== For example, sort(r) returns the sorted range, but sort_heap(r) does not. Similar issues for partial_sort(). Please go through all algorithms to see if this done correctly. 9: output range concept? ========================= It appears that the only use for an output iterator in the library was for boost::copy(rng,iter), and the only use for that function was for "sinks" like std::ostream_iterator<T>(...). This seems to be the only safety hole left in the library. Here's an idea to how we might remove that: create a new "copy sink" concept: struct array_copy_sink { ... template< class Iterator > copy( Iterator begin, Iterator end ) { ... } }; Then we might imagine boost::copy( rng, boost::ostream_sink(std::cout) ); boost::copy( rng, boost::array_sink(an_array) ); boost::copy( rng, boost::ptr_sink(begin,end) ); boost::copy( rng, boost::front_insert_sink(a_deque) ); ... For optimal performance, we also need a "nonoverlapping copy sink" concept, and an algorithm that expects that sink (or that boost::copy() determines the type of the sink automatically). 10: automatic projection ======================= Adope has algorithms overloaded such that projection is very easy: struct my_type { int member; double another_member; }; //... my_type a[] = { { 1, 2.5 }, ... }; // sort the array by the first member: sort(a, less(), &my_type::member); my_type* i = lower_bound(a, 5, less(), &my_type::member); We should be able to express this well, albeit not as concise, with my_type* i = boost::lower_bound( a | project( &my_type::member ), 5, less() ); where project( ... ) could simply return a transform iterator constructed with boost::bind(). There is another problem, however, because now the return value is a tranform_iterator of some form. Appending .base() would solve it, albeit it is somewhat ugly. Again this might raise the question of an implicit conversion. I just want to say this is not a critical issue as we can always add these overloads. --- End of Issues ---- Again, I would like to thank everybody that participated in the review. best regards Thorsten, review manager

2 1

[move] New version with move-aware containers library
by Ion Gaztañaga 03 May '09

03 May '09

Hi to all, Sorry for the delay, but finally I've found some time to uploaded a new version of Boost.Move: Sandbox: https://svn.boost.org/trac/boost/browser/sandbox/move ZIP file with docs: http://www.drivehq.com/web/igaztanaga/move.zip Online docs: http://www.drivehq.com/web/igaztanaga/libs/move/ Changes: -> Changed folder from boost/move_semantics to boost/move. -> I've extracted all the containers from Boost.Interprocess, put them in boost/container and they only depend on official Boost SVN code (I haven't tested it, but it should be also nice with Boost 1.38). There is no documentation for these containers. -> Fixed a bug with EDG-based compilers. -> Note: I haven't applied yet the patch for non-sfinae compilers. With this changes, I think move emulation is quite portable (at least MSVC, EDG and GCC). Now that containers are independent from Boost.Interprocess, I would like to ask about the next step. If the move library is added, where should we put those containers? I would like to just drop common (vector, list, ...) Boost.Interprocess containers and just maintain these move-aware ones. If move emulation is considered mature enough, we should also plan when could we port all custom move-emulations present in several boost libraries to the "official" move library. Best, Ion

8 20

[gil] Google analytics script tags
by Daniel James 02 May '09

02 May '09

Hi, If you've missed it, there was a recent thread about using google analytics in offline copies of boost and the consensus was firmly against them. The gil documentation includes the google analytics javascript but doesn't seem to use it. So I assumed that their inclusion was a mistake and went ahead and removed them on trunk. I hope that wasn't presumptuous. But I did this on the generated documentation as I couldn't work out how it is generated. It'd useful to have some brief instructions and any necessary files. Ideally we should be able to generate them with boost build but a manual doxygen call is fine. thanks, Daniel

3 4

Intentions of Boost.TR1
by David Abrahams 02 May '09

02 May '09

I just saw this post on comp.lang.c++.moderated. I wonder if the Boost.TR1 documentation shouldn't clarify its intended use or degree of conformity. I don't think TR1 conformity is something we have been paying much attention to, is it? -- Dave Abrahams BoostPro Computing http://www.boostpro.com

5 4

German Boost book updated
by Boris Schaeling 02 May '09

02 May '09

For those who know German: I've added five more chapters to my Boost book at http://www.highscore.de/cpp/boost/. There are now altogether 16 chapters covering 29 Boost libraries. The book does not try to replace the documentation but is written in a tutorial style to give developers a kick start. It explains what the numerous libraries are good for and how they are used without going too much into detail. Any feedback is, as always, appreciated! Boris

2 2

Boostcon Boost++0x Session
by Michael Caisse 02 May '09

02 May '09

Dave - I am sorting out which sessions to attend and wish there was more of me. For the Boost++0x sessions reading a tutorial is a prerequisite. Is the tutorial on the boostcon site and I just failed to find it? Thank you- michael -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com

2 3

how to build boost version 1_34_1 with gcc in non-standard location?
by Oliver Kullmann 01 May '09

01 May '09

Hello, I'm wrestling here for a long time with the following problem, and I would be very glad if somebody could help me here (seems to be straight-forward, but I can't find anything anywhere on the subject): I have to build some C++ code which doesn't compile with the system gcc version 4.3.1. So I have installed gcc version 4.1.2 locally. Now that C++ code uses Boost version 1_34_1, and doesn't compile with higher versions. Alright, so I install 1_34_1; very unfortunately, linking is necessary, and here is the problem: Obviously I have to build Boost 1_34_1 with the locally build gcc 4.1.2, and now how can I tell the Boost-build where to find gcc??? What I found is to use PACKAGEPATH/bjam/bjam --toolset=gcc-4.1.2 --toolset-root=PATH_TO_GCC_DIR --prefix=INSTALLATION_DIR --build-dir=BUILD_DIR "-sGCC_ROOT_DIRECTORY=PATH_TO_GCC_DIR" install --without-python However, as I had to found out after some time, this doesn't have any effect --- Boost just builds with the system compiler, and ignores all these specifications of PATH_TO_GCC_DIR. Now what is the right way to do it?? I would be really glad for help. Oliver

2 2

[Graph] transitive reduction
by boese-wolf＠math.uni-frankfurt.de 30 Apr '09

30 Apr '09

Hi! May I propose the following implementation for a transitive reduction to be added to the boost graph library? I'm a novice and the quality of the code I produced surely does not meet boosts standards, but maybe with some help, I'm able to improve it. So, please don't shoot me. #ifndef MY_OWN_TRANSITIVE_REDUCTION_HPP_INCLUDED #define MY_OWN_TRANSITIVE_REDUCTION_HPP_INCLUDED #include <vector> #include <algorithm> //std::find #include <boost/concept/requires.hpp> #include <boost/concept_check.hpp> #include <boost/graph/topological_sort.hpp> #include <boost/graph/graph_traits.hpp> #include <boost/property_map.hpp> //I actually didn't care which of those heades include some of the //others and whicht could be left out, for this reason, I simply added a //header when I used a function, described to be in this header by the //boost graph documentation //also I didn't got all of the concepts thin. Am I suppose to check //for all concepts, which are needed for functions I call? (As if I //wouldn't do that, the users would see the functions called by //complaining about missings concepts, which would be clearly an error //message revealing internal implementation and should therefore be avoided?) //the pseudocode which I followed implementing this algorithmn was taken //from the german book Algorithmische Graphentheorie by Volker Turau //it is proposed to be of O(n + nm_red ) where n is the number //of vertices and m_red is the number of edges in the transitive //reduction, but I think my implementation spoiled this up at some point //indicated below using namespace boost; template <typename Graph, typename GraphTR, typename G_to_TR_VertexMap, typename VertexIndexMap> BOOST_CONCEPT_REQUIRES( ((VertexListGraphConcept< Graph >)) ((IncidenceGraphConcept< Graph >)) ((MutableGraphConcept< GraphTR >)) ((ReadablePropertyMapConcept< VertexIndexMap, typename graph_traits<Graph>::vertex_descriptor >)) ((Integer< typename property_traits< VertexIndexMap >::value_type >)) ((LvaluePropertyMapConcept< G_to_TR_VertexMap, typename graph_traits<Graph>::vertex_descriptor >)), (void)) transitive_reduction( const Graph& g, GraphTR& tr, G_to_TR_VertexMap g_to_tr_map, const VertexIndexMap & g_index_map ) { typedef typename graph_traits<Graph>::vertex_descriptor Vertex; typedef typename graph_traits<Graph>::vertex_iterator VertexIterator; typedef typename std::vector<Vertex>::size_type size_type; std::vector<Vertex> topo_order; topological_sort( g, std::back_inserter( topo_order ) ); std::vector<size_type> topo_number_storage( num_vertices(g) ); iterator_property_map<size_type*, VertexIndexMap, size_type, size_type&> topo_number( &topo_number_storage[0], g_index_map ); { typename std::vector<Vertex>::reverse_iterator it = topo_order.rbegin(); size_type n = 0; for(; it != topo_order.rend(); ++it,++n ) { topo_number[ *it ] = n; } } std::vector< std::vector< bool > > edge_in_closure(num_vertices(g), std::vector<bool>( num_vertices(g), false)); { typename std::vector<Vertex>::reverse_iterator it = topo_order.rbegin(); for( ; it != topo_order.rend(); ++it ) { g_to_tr_map[*it] = add_vertex(tr); } } for( typename std::vector<Vertex>::iterator it = topo_order.begin(); it != topo_order.end(); ++it ) { size_type i = topo_number[ *it ]; edge_in_closure[i][i] = true; std::vector<Vertex> neighbors; //I have to collect the successors of *it and traverse them in //ascending topological order. I didn't know a better way, how to //do that. So what I'm doint is, collection the successors of *it here { typename Graph::out_edge_iterator oi,oi_end; for( tie(oi, oi_end) = out_edges( *it, g ); oi != oi_end; ++oi ) { neighbors.push_back( target( *oi, g ) ); } } { //and run through all vertices in topological order for( typename std::vector<Vertex>::reverse_iterator rit = topo_order.rbegin(); rit != topo_order.rend(); ++rit ) { //looking if they are successors of *it if( std::find( neighbors.begin(), neighbors.end(), *rit) != neighbors.end() ) { size_type j = topo_number[ *rit ]; if( not edge_in_closure[i][j] ) { for(size_type k = j; k < num_vertices(g); ++k) if( not edge_in_closure[i][k] ) //here we need edge_in_closure to be in topological order, edge_in_closure[i][k] = edge_in_closure[j][k]; //therefore we only access edge_in_closure only through //topo_number property_map add_edge(g_to_tr_map[*it], g_to_tr_map[*rit], tr); } //if ( not edge_in_ } //if (find ( } //for( typename vector<Vertex>::reverse_iterator } // { } //for( typename vector<Vertex>::iterator } //void transitive_reduction #endif //#ifndef MY_OWN_TRANSITIVE_REDUCTION_HPP_INCLUDED Best regards, Eric

2 3

[ANN] GCC 4.4.0 Released
by Eric Niebler 29 Apr '09

29 Apr '09

This might interest some here: http://gcc.gnu.org/ml/gcc/2009-04/msg00590.html It'd be nice to get some test coverage. Any takers? -- Eric Niebler BoostPro Computing http://www.boostpro.com

5 6

[multi-index] Changing hash_index_node.hpp to double linked list
by brad higgins 29 Apr '09

29 Apr '09

I am using boost multi-index, with a hashed-non-unique lookup. In my data, I am expecting many hash collisions. When I erase the multi- index, I find very poor performance. On investigation, I found that the hash collision data structure is a single linked list, and that removing an element involves traversing the entire list. Removing all of the elements involves traversing the list many times. Since my data has many collisions, I am traversing a very long list very many times. I know that the hash table is not designed for use with many collisions, but it is still faster in my testing on insert and serialization than the ordered_non_unique index specifier. I may end up using ordered_non_unique to avoid the worst-case erase() performance, and it may be good enough for the insert() performance. However, I would like to investigate making the hash collisions double- linked. I tried editing boost/multi_index/detail/hash_index_node.hpp, to make it a double-linked list, but I am seeing one of the included tests fail (test_safe_mode). I can't spot any bugs in my hash_index_node.hpp changes. What, apart from hash_index_node.hpp, needs to be updated, to support a double- linked list? boost/multi_index/detail/bucket_array.hpp? Others? Thanks, Brad

3 3

[encrypted strings]
by Sid Sacek 29 Apr '09

29 Apr '09

Does boost have any compile-time classes for string encryption? Is it even possible? When a hacker dumps an executable, they can see all of the strings the program might use, and some of those strings may contain sensitive information. Does boost have any classes that can encode the strings at compile-time? Ideally, the third string in the code below would never compile the "secret" string into the final binary. Regards, -Sid void foo( void ) { char const * s1 = "abc"; string s2 = "xyz"; encrypted_string s3( "secret" ); }

11 28

Re: [boost] [multi-index] Changing hash_index_node.hpp to double linked list
by JOAQUIN M. LOPEZ MUÑOZ 28 Apr '09

28 Apr '09

________________________________________ De: boost-bounces(a)lists.boost.org [boost-bounces(a)lists.boost.org] En nombre de brad higgins [bhiggins(a)arbor.net] Enviado el: martes, 28 de abril de 2009 21:56 Para: boost(a)lists.boost.org Asunto: Re: [boost] [multi-index] Changing hash_index_node.hpp to double linked list > Hi Joaquín, > Thanks for the quick response. I have attached the files I edited. > > Thank you very much for the help, Please allow a day or two till I find time to delve into this. I'll get back to you. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[interprocess] patch for AIX
by Etienne PIERRE 28 Apr '09

28 Apr '09

Hello, Currently interprocess doesn't work on AIX for two reasons : - detail/os_thread_functions.hpp uses ::pthread_equal but this fails because pthread_equal is a macro under AIX and it fails because of the :: prefix - in detail/atomic.hpp there is no implementation of PowerPC under AIX so I added one that uses the combination of lwarx and stwcx for each function to implement. I saw that under AIX, the detail/atomic_count.hpp and detail/sp_counted_base.hpp falls back to a pthread implementation, I could submit a patch for a real atomic implementation under AIX but I wonder if there are other places in boost where this should be done ? Thanks, Etienne PIERRE

2 2

[Boost.any] Nightly trunk testing failures
by K. Noel Belcourt 28 Apr '09

28 Apr '09

Hi, Most nightly trunk testing results are failing with this error message. Have their been recent changes to Boost.any that could have caused this? # Making "/var/scratch/boost/results" directory... # Starting tests ("/var/scratch/boost/tools_bjam/bin.linuxx86/bjam" "- sBOOST_BUILD_PATH=/var/scratch/boost:/var/scratch/boost/tools_bb" "- sBOOST_ROOT=/var/scratch/boost/boost" "--boost=/var/scratch/boost/ boost" "--boost-build=/var/scratch/boost/tools_bb" "--debug- configuration" -l300 intel-10.0 -d2 preserve-test-targets=off --dump- tests -j8 link=static "--build-dir=/var/scratch/boost/results" >>"/ var/scratch/boost/results/bjam.log" 2>&1)... # Running Boost.Build tests Traceback (most recent call last): File "run.py", line 60, in <module> runner(root) File "/var/scratch/boost/tools_regression_src/regression.py", line 193, in __init__ self.main() File "/var/scratch/boost/tools_regression_src/regression.py", line 551, in main getattr(self,action_m)() File "/var/scratch/boost/tools_regression_src/regression.py", line 516, in command_regression self.command_test() File "/var/scratch/boost/tools_regression_src/regression.py", line 317, in command_test self.command_test_boost_build() File "/var/scratch/boost/tools_regression_src/regression.py", line 354, in command_test_boost_build "boost/bin.v2/libs/any/test/any_test.test")); OSError: [Errno 2] No such file or directory: '/var/scratch/boost/ results/boost/bin.v2/libs/any/test/any_test.test' We get the exact same error message on all Sandia testers, and from the looks of it, most other testers are having the same problem. Any help in getting testing going again would be appreciated. Thanks. -- Noel

3 4

mpl::print and the sun compiler
by Dmitry Goncharov 28 Apr '09

28 Apr '09

The sun c++ compiler doesn't issue a warning about comparison between signed and unsigned integer expressions. The attached patch makes mpl::print produce "implicit int is not supported" warning. With the patch applied the compiler output looks like this: $ CC +w -c print.cpp "/home/dgoncharov/boost/trunk/boost/mpl/print.hpp", line 55: Warning: Implicit int is not supported in C++. "print.cpp", line 3: Where: While specializing "boost::mpl::print<int>". "print.cpp", line 3: Where: Specialized in non-template code. 1 Warning(s) detected. Br, Dmitry

1 0

Re: [boost] [encrypted strings]
by Kasra 28 Apr '09

28 Apr '09

Sid Sacek Wrote: >This sounds very cool. Let me know when you're done. I would definitely >use it. For your needs the library is fully implemented, you don't need to look into RC4 implementation since the library already has many algorithms. On your encrypted string problem, it is best to user during installation techniques. Create an encrypted archive where the user has to provide a product key for the installation to commence. Read decrypted contents from the archive, encrypt it using any encryption algorithm you like however, use a PRNG to generate the key. Seed the PRNG from the available hardware and host OS and etc. Then each time you want the plaintext you regenerate your PRNG then decrypt your ciphertext. -- Kasra

2 1

Re: [boost] [asio] send blocks with MSG_DONTWAIT (linux)
by Stefan Pledl 28 Apr '09

28 Apr '09

> You can switch your socket in the non-blocking mode with > basic_stream_socket::non_blocking_io(). > Though asio should handle MSG_DONTWAIT as well. > > BR, Dmitry Hi Dimitry, that's right, but i need a blocking read and a non-blocking wirte. With basic_stream_socket::non_blocking_io() both, read and write are non-blocking. When i use C-functions read is blocking and write is non-blocking (when passing MSG_DONTWAIT). Best regards Stefan

1 0

Help with VMS port of CMake
by Bill Hoffman 27 Apr '09

27 Apr '09

Hi, I am trying to port CMake to VMS. For the first pass I am going to use the GNV tools and gmake. I am very close, but I am having trouble with files that have more than one "." in the name. CMake uses files like that in several places, as do many CMake based projects. Assuming I use POSIX paths on VMS, does anyone on this list know what magic the GNV cat program uses to handle the following: This works: cat /idisk1/devel/Windows-cl.cmake.in I wrote a simple C++ program that uses fstream to open argv[1], and get the following results: These work: ./test. Windows-cl.cmake.in ./test. Windows-cl^.cmake.in ./test. idisk1:[devel]Windows-cl^.cmake.in This does not: ./test. /idisk1/devel/Windows-cl.cmake.in Any help would be appreciated. Sorry if this is not very boost related, but in previous CMake discussions on the list the topic of VMS came up, so I thought there might be someone that could help me out. Thanks. -Bill

1 0

[reference_wrapper] feature request
by Thorsten Ottosen 27 Apr '09

27 Apr '09

Hi, It came up again in the RangeEx review that we really need reference_wrapper<T> to implement a forwarding operator(). Personally I don't care much for more than one or two arguments, but I guess others will. Thanks -Thorsten

2 1

Re: [boost] [encrypted strings]
by Kasra 27 Apr '09

27 Apr '09

Hi, I am working on a Crypto library for that could do compile time encryption/decryption, however, requires 'constexpr' support from the compiler: template<class T> constexpr void encrypt(T& cipher_text, const T& plain_text) const throw(bad_state); template<class T> constexpr void decrypt(T& cipher_text, const T& plain_text) const throw(bad_state); -- Kasra

2 1

Re: [boost] [encrypted strings]
by raindog＠macrohmasheen.com 27 Apr '09

27 Apr '09

Boost does not have one. If I were you however I would look into a commercial protector such as themida (www.oreans.com) or armadillo or asprotect. ------Original Message------ From: Sid Sacek Sender: boost-bounces(a)lists.boost.org To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Sent: Apr 27, 2009 8:21 AM Subject: [boost] [encrypted strings] Does boost have any compile-time classes for string encryption? Is it even possible? When a hacker dumps an executable, they can see all of the strings the program might use, and some of those strings may contain sensitive information. Does boost have any classes that can encode the strings at compile-time? Ideally, the third string in the code below would never compile the "secret" string into the final binary. Regards, -Sid void foo( void ) { char const * s1 = "abc"; string s2 = "xyz"; encrypted_string s3( "secret" ); } _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

2 1

[tokenizer] Deprecated class used by default
by Boris Schaeling 27 Apr '09

27 Apr '09

I just noticed that although the class char_delimiters_separator is deprecated it is used by default by Boost.Tokenizer. I don't know when char_delimiters_separator was deprecated in favor of char_separator but it goes back to 1.33.1 (see http://www.boost.org/doc/libs/1_33_1/libs/tokenizer/index.html) Any plan to change the default class soon (doesn't need to be in 1.39.0 of course as it's pretty late for such a change)? Boris

1 0

beta docs on the website
by Michael Marcin 27 Apr '09

27 Apr '09

Shouldn't http://beta.boost.org/doc/ have 1.39 docs at this point? -- Michael Marcin

2 1

[asio] send blocks with MSG_DONTWAIT (linux)
by Stefan Pledl 27 Apr '09

27 Apr '09

If i pass the flag MSG_DONTWAIT to basic_stream_socket::send(buffers, flags) the call blocks in the following situation. -> Connection is established (boost::asio::socket_base::send_buffer_size option(2048) is set) -> sending data form local endpoint to remote endpoint -> remote endpoint does not read the data due to software bug/crash etc. -> sendqueue (see netstat) on local endpoint runs full -> send on local endpoint blocks at this point I think the flag MSG_DONTWAIT should avoid this blocking call. If i do the same using C-function send(fd, buf*, len, flag) the call does not block. I have analyzed the code and i think the problem is in send function in asio/detail/reactive_socket_service.hpp socket_ops::send returns but socket_ops::poll_write blocks. I have added the following changes (see comments __SP__) and all works ok for me. Is the blocking desired or where is my mistake? modified code form asio/detail/reactive_socket_service.hpp ---------------------------------------------------------- // Send the given data to the peer. template <typename ConstBufferSequence> size_t send(implementation_type& impl, const ConstBufferSequence& buffers, socket_base::message_flags flags, boost::system::error_code& ec) { if (!is_open(impl)) { ec = boost::asio::error::bad_descriptor; return 0; } // Copy buffers into array. socket_ops::buf bufs[max_buffers]; typename ConstBufferSequence::const_iterator iter = buffers.begin(); typename ConstBufferSequence::const_iterator end = buffers.end(); size_t i = 0; size_t total_buffer_size = 0; for (; iter != end && i < max_buffers; ++iter, ++i) { boost::asio::const_buffer buffer(*iter); socket_ops::init_buf(bufs[i], boost::asio::buffer_cast<const void*>(buffer), boost::asio::buffer_size(buffer)); total_buffer_size += boost::asio::buffer_size(buffer); } // A request to receive 0 bytes on a stream socket is a no-op. if (impl.protocol_.type() == SOCK_STREAM && total_buffer_size == 0) { ec = boost::system::error_code(); return 0; } // Send the data. for (;;) { // Try to complete the operation without blocking. int bytes_sent = socket_ops::send(impl.socket_, bufs, i, flags, ec); // Check if operation succeeded. if (bytes_sent >= 0) return bytes_sent; // Operation failed. if ((impl.flags_ & implementation_type::user_set_non_blocking) || (ec != boost::asio::error::would_block && ec != boost::asio::error::try_again)) return 0; // __SP__ // do not poll if flag MSG_DONTWAIT is set if (flags & MSG_DONTWAIT) return 0; // __SP__ // Wait for socket to become ready. if (socket_ops::poll_write(impl.socket_, ec) < 0) return 0; } }

2 1

Re: [boost] discussion of garbage collection in C++
by Kasra 27 Apr '09

27 Apr '09

Edward Diener wrote: >Also, for people looking for a runtime envrironment for C++, they can look >at Ch. Or CERN.ROOT.CINT project. Either way we are looking at GC in C++ from the wrong direction. I like to know and be able to determine where the memory allocation deallocation occurs. When the constructor and destructor is called using RAII, however, this doesn't mean I shouldn't use GC. GC is supposed to release unused memory, not to call the destructors of objects; although it does on most implementations. [example bool g(int); for(int i=0; i<10000; i++) { // allocate a memory of size = sizeof(Foo) // then construct an instance of Foo on that memory gc_ptr<Foo> f(new (gc) Foo()); // if g(i) == true, delete the memory if( g(i) ) operator delete(f, gc); } // delete all of the objects. GC::collect(); example] The distinction is between construction/destruction of objects and allocation/deallocation of memory. We let GC to perform allocation/deallocation of memory, while we allow ourselves optionaly to take control of construction/destruction of the objects allocated on that memory. This distinction is so important while everyone ignores :D -- Kasra

3 2

[ASIO] Host not found (authoritative)
by Alexander Dong Back Kim 27 Apr '09

27 Apr '09

Dear members, This is a very beginner's question on ASIO. I followed the tutorial example "daytime" in the ASIO document. Server one seems running well because nestat shows the port has been opened and listening. However, when I run the client one, the application prints out "Host not found (authoritative)" message only. I'm using port 21165. $ ./client localhost:21165 Is my command wrong? cheers, Alex Kim

1 0

[1.39] Merge to release
by Daniel James 27 Apr '09

27 Apr '09

Is it okay to merge this? https://svn.boost.org/trac/boost/changeset/52598 It's just a trivial CSS bug fix. thanks, Daniel

4 3

[gc] new implementation in boost vault that solves the issue of finalization order
by Achilleas Margaritis 26 Apr '09

26 Apr '09

Hi. I have posted a new gc implementation in the boost vault here: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=gc1.zi… The code included in the file is a garbage collector with the following differences from the previous one: 1) finalization order that respects destructor semantics, except when there are cycles. In the previous collector, the order of finalization was random. In the new collector, an unreachable object A that is pointed to by another unreachable object B will be finalized after B is finalized. This allows the use of gc ptrs within destructors. 2) O(1) detection of member ptrs: pointers registers themselves to the appropriate ptr list as they are created. In the previous collector, pointers where discovered in the collection phase by look-up on the sorted blocks. The code is not completed or polished, but it is published for discussing possible implementation ideas. The main bottleneck right now is how to locate blocks from pointers. The current solution is to sort the blocks by address at collection time, then use std::upper_bound to locate the blocks. This has O(log2(N)) complexity, where N is the number of blocks.

1 0

[ANN] Spirit V2.1 (beta) committed to the Boost SVN
by Hartmut Kaiser 26 Apr '09

26 Apr '09

Hi all, The Spirit team proudly announces that we committed Spirit V2.1 (beta) to the Boost SVN (trunk). We will continue the development there, so please don't use the Spirit SVN anymore as it will quickly go out of sync. Spirit V2.1 is a complete rewrite of V2.0, while maintaining most of the V2 interface. We will add a comprehensive document explaining what's changed soon. Here are some of the highlights: - More homogeneous interface (multi-attribute API similar to printf/scanf, but using Qi/Karma format descriptions) - More balanced set of primitives and directives (Qi and Karma now better complement each other) - Reduced compile times! Compilation is up to 50% faster if compared to equivalent code from V2. - Optimized execution times. Spirit is now faster than ever before. - Simplified usage of grammars and token definitions - Fixed a whole bunch of bugs and inconsistencies - etc. Please report any experience you might gain (good and bad)! As a side note: Joel and I will give a talk about Spirit V2.1 at BoostCon in Aspen slightly more than a week from now. You still can register (www.boostcon.com) if you haven't done yet. On behalf of the Spirit team Regards Hartmut PS: We would like to thank all who participated and contributed to this. It really was a major team work!

1 0

Boost 1.39.0 beta 1 is available for download
by Beman Dawes 26 Apr '09

26 Apr '09

Boost 1.39.0 beta 1 is available for download from SourceForge. See http://sourceforge.net/project/showfiles.php?group_id=7586&package_id=8041&… New Libraries: Signals2. Updated Libraries: Asio, Flyweight, Foreach, Hash, Interprocess, Intrusive, Program.Options, Proto, PtrContainer, Range, Unordered, Xpressive. Updated Tools: Boostbook, Quickbook. Plus the usual bug fixes to numerous libraries. Please report any problems to the Boost users or developers mailing list. Thanks, --Beman Dawes, Daniel James, and all the other Boosters who help get releases out

1 0

[quick-book] suggestion about library compatibility
by Thorsten Ottosen 26 Apr '09

26 Apr '09

Hi, quickbook already has Admonitions like [note a note] which generates a nice box with an icon. I think it would be useful to have addition admonitions to indicate the following - the library can be serialized with Boost.Serialization - the library can be compiled without exceptions (BOOST_NO_EXCEPTION) - the library can be used with Boost.Interprocess so these can be stated in a consistent manner up front in the documentation. Perhaps it is better that these are written up front like [library Boost.AutoBuffer [quickbook 1.4] [copyright 2009 Thorsten Ottosen] [compatibility noexceptions serialization interprocess] ] ? Any comments? -Thorsten

2 1

[mpl] mpl::string, help needed (vacpp, sun, borland)
by Eric Niebler 25 Apr '09

25 Apr '09

A few days ago, I added mpl::string (a compile-time string class template) to trunk. I expected horrific portability problems with my use of multi-character literals, but it's not as bad as all that judging from the test results. There are only a few failures on compilers I don't have access to: vacpp, sun and borland. I invite anybody with access to these compilers to "bjam string" in the libs/mpl/test directory, try their hand at fixing the problems and submitting a patch. Thanks! -- Eric Niebler BoostPro Computing http://www.boostpro.com

3 10

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

BoostCon 2009 Registrar's Report
by Kim Scheibel 24 Apr '09

24 Apr '09

I'm very happy to report that, despite the current economic climate, we currently have a very solid number of confirmed registrations for BoostCon 2009. 84 registrations to be precise, of which 6 were registered in the last two days alone. You still have time to register at the discounted price of USD599 at http://www.boostcon.com/registration, on or before Apr. 26th. After that, the fee is USD699. Best regards, Kim Scheibel BoostCon 2009 Registrar

1 0

Re: [boost] request for interest in a garbage collection library
by Kasra 24 Apr '09

24 Apr '09

>One of the advertised advantages was that is was written purely in >standard C++, which isn't the case of Boehm which isn't portable. I am sure Boehm supports so many platforms and many compilers. Even so, an interpretation from C to ISO C++ is enough for that problem. >> auto_ptr<char*> traced_buffer(new (gc_traced) char[1024]); > This raises undefined behaviour, I believe. gc allocated memory slab is always zero, so there would be no live pointers on the traced_buffer memory slab. I think we the concept of the GC should encapsulate two things separately. memory allocation/deallocation object construction/destruction [example class foo; { auto_ptr< foo > foo_bar(new (gc) foo()); } // call foo_bar->~foo(); example] the RAII call the destructor but the memory that was occupied is not necessarily free. the gc::collect(), collects the memory as well as calling the destructor for non-destructed objects. -- Kasra

7 11

Re: [boost] [soc2009] Proposal for serialization library
by uwe.arzt 24 Apr '09

24 Apr '09

Hartmut Kaiser wrote: > > >> implementation has not responded to my email. You can check out the >> code >> here: >> http://code.google.com/p/google-summer-of-code-2008- >> boost/downloads/list > > In this case you might want to contact the mentor of last year's YAML > project: Joel de Guzman (joel at boostpro dot com). > > Do you know if the merge to boost is planned in the (near) future? Who should be contacted about that? Is help needed? Thanks :q! Uwe -- View this message in context: http://www.nabble.com/-soc2009--Proposal-for-serialization-library-tp226009… Sent from the Boost - Dev mailing list archive at Nabble.com.

1 0

Re: [boost] Boost.Process article: Tutorial and request for comments
by Boris Schaeling 24 Apr '09

24 Apr '09

On Tue, 21 Apr 2009 16:05:04 +0200, Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> wrote: > [...]I assume the name of the executable should be in the locale > character set. > So std::string, or even const char*, appear suitable. > > Now, if you want to perform automatic translation from unicode to locale > character set, why not, but that's another layer on top of that. An > unicode string type should be convertible to the locale character set > easily enough so that you don't need to that in your library, however. > > You could eventually add support for wide characters, though. While wide > characters are Unicode on Windows, they are as far as C++ is concerned > just another locale character set, and I think considering them as > nothing more than that is best. > > As far as I know, POSIX systems simply don't have APIs for wide > characters, however. Another problem on Windows might be that new projects in VC++ 2008 automatically assume Unicode is used. Thus all Windows API functions expect wide character strings which again means for executable names std::wstring would need to be used. And I don't know if developers really think about it and not simply assume that they can use std::string in all cases. I think Ion faced a similar problem when he developed Boost.Interprocess which only accepts const char* strings (and according to http://www.boost.org/doc/libs/1_38_0/doc/html/interprocess/acknowledgements… waits for string conversion utilities which would be the additional layer you mentioned). >> * 'handle' is the underlying native file handle of a stream (file >> descriptor on POSIX systems, handle on Windows). The concept is based >> on a >> class in the detail namespace of Boost.Process. There is just one class >> and it's not meant to be used by users of the library either. Thus I'm >> not >> sure what's the benefit of having an explicit 'handle' concept at all. > > Isn't it in case Boost.Process doesn't implement the features I need, so > that I may use them directly with the native functions? Before I had added a handle() function to the stream classes there was no way to access a handle. Indeed I had added handle() because I wanted to use the file descriptor/Windows HANDLE for asynchronous I/O. I think I agree with you that it should be possible to access native handles. However I'm not sure if a concept has to be defined. Maybe I understand concept wrong but if I hear concept I think about extensibility and different types. In that sense a concept for an executable name makes sense to me (if it wasn't so difficult to support it). But I'm not sure how it fits to a handle? Boris > [...]

1 0

Boost Serialization problem
by Suhail 24 Apr '09

24 Apr '09

Hallo I have currently installl the Boost boost_1.38 . Start new program in VC2003 add following lib in my project boost_serialization-vc71-mt-1_38.lib boost_serialization-vc71-mt-gd-1_38.dll example code: #include <boost/archive/text_oarchive.hpp> #include <boost/archive/text_iarchive.hpp> #include <iostream> #include <fstream> #include <stdio.h> using namespace std; void save() { std::ofstream file("archiv.txt"); boost::archive::text_oarchive oa(file); int i = 7; oa << i; } void load() { std::ifstream file("archiv.txt"); boost::archive::text_iarchive ia(file); int i = 0; ia >> i; std::cout << i << std::endl; } //========================================================== /// Main function //========================================================== void main(int argc, char* argv[]) { save(); load(); } After executing this example "archiv.txt" only stores 22 serialization::archive 5 instead of 22 serialization::archive 5 1 Could someone help me where i am making mistake??

1 0

Interest in atomic library?
by Seth LaForge 23 Apr '09

23 Apr '09

In this day and age, running our C++ programs off fossil fuels makes a dangerous contribution to global warming and requires purchase of carbon offsets for ethical programming. Thus I think it's time for a Boost atomic power library. Oops, sorrry, wrong meaning of atomic. What would people think of an atomic integer library, along the lines of Linux's asm/atomic.h? I'd propose a class atomic<T> implementing operations like atomic read (implicit conversion to T), atomic set (assignment from T), and compare-and-exchange. For integral types it would support atomic add and return result (operator+=), atomic subtract and return result (operator-=), atomic increment and return result (prefix operator++), and atomic decrement and return result (prefix operator--). For arbitrary architectures or unhandled types of T, there would be a naive implementation using a mutex. On supported architectures there would be specializations for integral T types, using assembly to implement more efficient atomic operations. This assembly could pretty much just be borrowed from the Linux asm/atomic.h headers. What do people think? I see pros: + Cross-platform efficient atomic operations for efficient threaded apps. I see cons: - Hard to predict whether your atomic ops will be efficient (no specialization for your architecture/T). - Some architectures may implement different atomic ops, making the above ops not the most efficient. I think the pros outweight the cons. I'd personally much rather use a Boost.atomic library than asm/atomic.h. Seth

6 7

Re: [boost] request for interest in a garbage collection library
by Kasra 23 Apr '09

23 Apr '09

>This library is not better than Boehm's gc (certainly slower than Boehm's), >but it is portable C++. I have looked at the library more thoroughly now. If you are interested in improving performance I have a method that could improve the performance big time. Just drop me a personal email. -- Kasra

1 0

Re: [boost] request for interest in a garbage collection library
by Kasra 23 Apr '09

23 Apr '09

I have interest in garbage collection. However, I have few questions about this library. * How is it going to be better than The Boehm GC? * Why isn't it a wrapper for Bohem? This header is what is used within our organisation for GC memory management. [C++ =============================================== C++] #ifndef __GC__ #define __GC__ #define GC_NOT_DLL #include <bohem/gc.h> #include <bohem/gc_allocator.h> #undef GC_NOT_DLL #ifdef BOOST_MSVC # pragma comment(lib, "gc.lib") #endif namespace { using gc_allocator; using gc_traceable; extern const struct gc_memory_t { } gc; extern const struct gc_traceable_t { } gc_traced; inline void* operator new(size_t size, const gc_memory_t&) throw(bad_alloc); inline void* operator new[](size_t size, const gc_memory_t&) throw(bad_alloc); inline void operator delete(void* memory, const gc_memory_t&) throw(bad_alloc); inline void operator delete[](void* memory, const gc_memory_t&) throw(bad_alloc); inline void* operator new(size_t size, const nothrow_t&, const gc_memory_t&) throw(); inline void* operator new[](size_t size, const nothrow_t&, const gc_memory_t&) throw(); inline void operator delete(void* memory, const nothrow_t&, const gc_memory_t&) throw(); inline void operator delete[](void* memory, const nothrow_t&, const gc_memory_t&) throw(); inline void* operator new(size_t size, const gc_traceable_t&) throw(bad_alloc); inline void* operator new[](size_t size, const gc_traceable_t&) throw(bad_alloc); inline void operator delete(void* memory, const gc_traceable_t&) throw(bad_alloc); inline void operator delete[](void* memory, const gc_traceable_t&) throw(bad_alloc); inline void* operator new(size_t size, const nothrow_t&, const gc_traceable_t&) throw(); inline void* operator new[](size_t size, const nothrow_t&, const gc_traceable_t&) throw(); inline void operator delete(void* memory, const nothrow_t&, const gc_traceable_t&) throw(); inline void operator delete[](void* memory, const nothrow_t&, const gc_traceable_t&) throw(); } #endif /* __GC__ */ [C++ =============================================== C++] [example auto_ptr<char*> gc_buffer(new (gc) char[1024]); auto_ptr<char*> traced_buffer(new (gc_traced) char[1024]); example] -- Kasra

3 2

[1.39.0] [Lambda] [Iterator] Warnings with gcc 4.3?
by Beman Dawes 22 Apr '09

22 Apr '09

In an email about something else, someone asked: ... we will be eager to use your upcoming version 1.39. One point we would be interested is to remove the following warnings on gcc 4.3. Would you know if those were fixed? <warning value="boost-1_38/boost/lambda/detail/lambda_functors.hpp:137: warning: type qualifiers ignored on function return type" /> <warning value="boost-1_38/boost/lambda/detail/select_functions.hpp:55: warning: type qualifiers ignored on function return type" /> <warning value="boost-1_38/boost/lambda/detail/select_functions.hpp:60: warning: type qualifiers ignored on function return type" /> <warning value="boost-1_38/boost/lambda/detail/select_functions.hpp:65: warning: type qualifiers ignored on function return type" /> <warning value="boost-1_38/boost/iterator/iterator_facade.hpp:652: warning: type qualifiers ignored on function return type" /> Does anyone know the status of these? --Beman

2 2

[Boost-announce] Review Conclusion - Futures Library
by Tom Brinkman 21 Apr '09

21 Apr '09

Review Conclusion - Futures Library Braddock Gaskill http://braddock.com/~braddock/future Anthony Williams http://www.justsoftwaresolutions.co.uk/files/n2561_future.hpp The lack of examples and documentation made them difficult to review. Nevertheless, Anthony Williams futures library did receive almost unanimous and enthusiastic support. Unfortunately, the depth of the support was very shallow. I just finished my first read of Anthony's book "C++ Concurrency in Action and acknowledge his expertise in the areas of multi threaded and parallel programming. (http://www.manning.com/williams/) Anthony is the maintainer of boost::threads. Anthony's Future library has been approved for the next major release of c++ standard. Conclusion Braddock Gaskill - Rejected Anthony Williams - Approved Anthony's Futures library is approved for inclusion into boost::threads. As he is the maintainer of that library, he should be given maximum latitude about how that is to be done. In the future, if Anthony wants to re-publish the library as a top-level boost library, then he needs to resubmit it again with samples and test cases, which are lacking. Requirements As per the usual boost library requirements, examples and test cases are needed. Anthony should also improve the documentation, which should not be a problem as he is a prolific author in the area of multi threaded programming. Review Manager Tom Brinkman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-announce

3 2

[mpi] Automatically Cascading/Nested Reduce?
by Dean Michael Berris 21 Apr '09

21 Apr '09

Hi Guys, I'm writing quite a number of parallel-distributed applications in the day job, and I'm missing a facility which allows for "automagically" nesting my reductions. The reduction strategy I'm looking for is one of a networked approach where (if you can imagine a tree): 0 |-1 | |-2 | |-3 | |-4 |-5 |-6 Nodes 2 and 3 send their data to node 1, node 5 and 6 send their data to node 4, and eventually node 1 and 4 send their (reduced) data to node 0. My idea is that it should be simple to implement this without having to go through too much trouble with communicators -- or that it could be automagically done by hiding the communicator splits in the special reduce implementation. Would something like this be best implemented within Boost.MPI? Or is there a way of implementing this by composing the functionality already available in Boost.MPI? The reason I ask is that sometimes the reduction step dominates the amount of time the application spends especially when you have quite a number of nodes (around 90ish). Being able to parallelize (or nest) the reduction would definitely help, but the cost of supporting that routine over a number of applications seems to warrant a special implementation of the Boost.MPI reduce. TIA -- 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 3

Problem with write_graphviz
by Josep TORRAS FLAQUER 21 Apr '09

21 Apr '09

Hello, I'm working with boost graph library. I'm creating a graph and i'd like to write its description into a file or to display it on the screen. The properties of Edges and Vertex are bundled, and i'm not able to write them. I have read the doc once and again and i don't get to find a solution. I have looked for examples but i haven't found anything actually useful for me. Could anyone please help me or propose a possible solution? Here is my code: #include <boost/graph/iteration_macros.hpp> #include <string> #include <boost/tuple/tuple.hpp> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/visitors.hpp> #include <boost/graph/breadth_first_search.hpp> #include <map> #include <boost/graph/adj_list_serialize.hpp> #include <boost/archive/text_iarchive.hpp> #include <boost/multi_array.hpp> #include <cassert> #include <boost/graph/graphviz.hpp> //using namespace boost; struct VertexProperties{ std::string gate_type; int gate_level; int gate_index; int num_input; float prob_err; }; struct edge_properties { std::string name; }; typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::undirectedS, VertexProperties , edge_properties> Graph; typedef boost::graph_traits<Graph>::vertex_descriptor Vertex; typedef boost::graph_traits<Graph>::edge_descriptor Edge; int main() { int i=0; //const char* name = "123"; Graph g; Vertex u1; u1=add_vertex(g); g[u1].gate_type = "Input"; g[u1].gate_level=1; g[u1].gate_index=i; g[u1].num_input=0; g[u1].prob_err=0; i++; Vertex u2; u2=add_vertex(g); g[u2].gate_type = "Input"; g[u2].gate_level=1; g[u2].gate_index=i; g[u2].num_input=0; g[u2].prob_err=0; i++; Vertex u3; u3=add_vertex(g); g[u3].gate_type = "Input"; g[u3].gate_level=1; g[u3].gate_index=i; g[u3].num_input=0; g[u3].prob_err=0; i++; Vertex u4; u4=add_vertex(g); g[u4].gate_type = "XOR"; g[u4].gate_level=2; g[u4].gate_index=i; g[u4].num_input=0; g[u4].prob_err=0.001; i++; Vertex u5; u5=add_vertex(g); g[u5].gate_type = "AND"; g[u5].gate_level=1; g[u5].gate_index=i; g[u5].num_input=0; g[u5].prob_err=0.001; i++; Vertex u6; u6=add_vertex(g); g[u6].gate_type = "XOR"; g[u6].gate_level=1; g[u6].gate_index=i; g[u6].num_input=0; g[u6].prob_err=0.001; i++; Vertex u7; u7=add_vertex(g); g[u7].gate_type = "AND"; g[u7].gate_level=1; g[u7].gate_index=i; g[u7].num_input=0; g[u7].prob_err=0.001; i++; Vertex u8; u8=add_vertex(g); g[u8].gate_type = "OR"; g[u8].gate_level=1; g[u8].gate_index=i; g[u8].num_input=0; g[u8].prob_err=0.001; i++; Edge e1; e1=(add_edge(u1,u4,g)).first; Edge e2; e2=(add_edge(u1,u5,g)).first; Edge e3; e3=(add_edge(u2,u4,g)).first; Edge e4; e4=(add_edge(u2,u5,g)).first; Edge e5; e5=(add_edge(u3,u6,g)).first; Edge e6; e6=(add_edge(u3,u7,g)).first; Edge e7; e7=(add_edge(u4,u6,g)).first; Edge e8; e8=(add_edge(u4,u7,g)).first; Edge e9; e9=(add_edge(u5,u8,g)).first; Edge e10; e10=(add_edge(u7,u8,g)).first; const char* name[] = { "Input 1", "Input 2", "Input 3","XOR","AND","XOR","AND","OR"}; int index[] = {g[u1].gate_index,g[u2].gate_index,g[u3].gate_index,g[u4].gate_index,g[u5].gate_index,g[u6].gate_index,g[u7].gate_index,g[u8].gate_index}; write_graphviz(std::cout, g, boost::make_label_writer(name)); } I am able to write a label, but i can't write all the properties, and that's what i want. Thank you. Josep

2 2

[Math] Making math compile on C99 archs with no long double
by Seth LaForge 21 Apr '09

21 Apr '09

In trying to compile Boost 1.38.0 for arm/gcc-4.1.2, which has no long double support, I ran into the following compile error: ./boost/math/special_functions/expm1.hpp: In function ‘long double boost::math::expm1(long double, const boost::math::policies::policy<boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy, boost::math::policies::default_policy>&)’: ./boost/math/special_functions/expm1.hpp:270: error: ‘::expm1l’ has not been declared The fix is simple - the expm1.hpp is trying to use a long double C99 function despite BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS being defined. The following patch (also attached in case gmail mangles it) fixes the problem: diff -r -u boost_1_38_0.orig/boost/math/special_functions/expm1.hpp boost_1_38_0/boost/math/special_functions/expm1.hpp --- boost_1_38_0.orig/boost/math/special_functions/expm1.hpp 2009-01-07 08:37:59.000000000 -0800 +++ boost_1_38_0/boost/math/special_functions/expm1.hpp 2009-04-20 18:24:33.312485307 -0700 @@ -267,10 +267,12 @@ #if defined(BOOST_HAS_EXPM1) && !(defined(__osf__) && defined(__DECCXX_VER)) # ifdef BOOST_MATH_USE_C99 inline float expm1(float x, const policies::policy<>&){ return ::expm1f(x); } +# ifndef BOOST_MATH_NO_LONG_DOUBLE_MATH_FUNCTIONS inline long double expm1(long double x, const policies::policy<>&){ return ::expm1l(x); } -#else +# endif +# else inline float expm1(float x, const policies::policy<>&){ return ::expm1(x); } -#endif +# endif inline double expm1(double x, const policies::policy<>&){ return ::expm1(x); } #endif

2 1

BoostCon lodging
by Sebastian Redl 20 Apr '09

20 Apr '09

Hi list, Two things. First, a comment at the BoostCon lodging page[1] gave me the impression that lodging for two isn't actually cheaper than for one. Is this correct? Second, is anyone interested in sharing a room at a place where this actually is cheaper? (And do you have recommendations for such a place?) I have to pay for lodging myself and would like to reduce the costs. Regards, Sebastian [1] http://www.boostcon.com/location/lodging#reservations

3 3

[smart_ptr] post 1.34 regression
by Gennadiy Rozental 20 Apr '09

20 Apr '09

Hi, Following snippet compiles fine with 1.34.1 -------------------------- #include "boost/shared_ptr.hpp" class Base { public: virtual ~Base() {} }; class Derived; boost::shared_ptr<Base> foo() { return boost::shared_ptr<Derived>(); } class Derived : public Base {}; -------------------------- It fails though with boost 1.36: a.cpp: In function `boost::shared_ptr<Base> foo()': a.cpp:13: error: conversion from `boost::shared_ptr<Derived>' to non-scalar type `boost::shared_ptr<Base>' requested Looks like it caused by additional argument in template constructor sp_enable_if_convertible. Is it intentional? Can we still support old use case? Gennadiy

2 1

[SCOPE_EXIT] compiler errors for structure members
by Sid Sacek 20 Apr '09

20 Apr '09

struct { int one; } test ; test.one = 55; BOOST_SCOPE_EXIT( ( test.one ) ) { } BOOST_SCOPE_EXIT_END The above code gives me lots of compiler errors. Is there a special syntax I have to provide to be able to use structure members? Thanks, -Sid Sacek The errors I get using MSVC 2008 are: error C2065: 'boost_se_tag_0_12' : undeclared identifier error C2144: syntax error : 'int' should be preceded by ')' error C2059: syntax error : ')' error C2065: 'boost_se_tag_0_12' : undeclared identifier error C2143: syntax error : missing ')' before 'constant' error C2039: 'type' : is not a member of '`global namespace'' error C2653: 'boost_se_wrapped_t_0_12' : is not a class or namespace name error C2143: syntax error : missing ';' before '{' error C2065: 'boost_se_param_t_0_12' : undeclared identifier error C2065: 'boost_se_tag_0_12' : undeclared identifier error C2065: 'boost_se_tag_0_12' : undeclared identifier error C2143: syntax error : missing ',' before 'constant' C2143: syntax error : missing ',' before ')' error C2653: 'boost_se_params_t_12' : is not a class or namespace name error C2143: syntax error : missing ';' before '{' error C2143: syntax error : missing ';' before '}' error C2143: syntax error : missing ';' before '}' error C2143: syntax error : missing ',' before ')'

2 6

[graph] a patch for dominator_tree.hpp
by Jongsoo Park 20 Apr '09

20 Apr '09

Hi all, Recently, I've got few mails concerning about the performance of my dominator tree implementation in the boost graph library, which can be solved by a simple modification. The attached file is my patch on that problem which is based on the most recent version in the subversion repository. Could somebody who has a permission to modify the code apply this patch? The patch has only 5 lines difference and I've double checked it works correctly. Thanks, Jongsoo

2 2

[math] merge of signbit(-NaN) fix?
by Francois Barel 20 Apr '09

20 Apr '09

Hi, Boost.Math had some changes on trunk a few months ago, on the implementation of signbit, to fix the invalid result of signbit(-NaN) (fixed by using Johan Rade's fp_traits library). Currently, in order to work with multiple Boost releases, Spirit2x uses: - a custom version of signbit when compiled against an older Boost release, - the Boost.Math implementation when compiled against Boost 1.39 or later (on the assumption that those changes will be in Boost 1.39). But looking at the schedule sent by Beman, we're nearing the 1.39 beta (some time this week), and those changes have not been merged to release branch. I was wondering, is it planned to merge them for 1.39, or will it only be done in a later release? Thanks, François

1 0

Building stage by default, pt. 2
by Vladimir Prus 19 Apr '09

19 Apr '09

Hi, previously, we discussed that building the 'stage' target by default would be a good idea -- since some users forget that and don't have an easy way to get at built libraries. See: http://thread.gmane.org/gmane.comp.lib.boost.devel/182787 I've now implemented the change, taking into account the comments in that thread. In particular: - the message now uses absolute paths - the location of headers is explicitly specified Here's an example of the message that is output if you do "./bjam" in Boost root: Building C++ Boost. After the build, the headers will be located at /home/ghost/Work/Boost/boost-svn The libraries will be located at /home/ghost/Work/Boost/boost-svn/stage/lib Use 'bjam install --prefix=<path>' if you wish to install headers and libraries to a different location and remove the source tree. I was considering outputting a 'summary' at the end of the build, as opposed at the beginning, but that would require some Boost.Jam changes and therefore cannot be accomplished at this point of release cycle. Anybody wishes to comment on the wording before this gets merged to release branch? - Volodya

3 6

Re: [boost] [boost::exception] operator >>
by Gaydov Victor 19 Apr '09

19 Apr '09

> > Emil Dotchevski <emildotchevski(a)gmail.com> wrote: >> > hello! i'm using boost::exception in one project and did small modification >> > for myself, what do you think about it ? >> > >> > i don't want to create a lot of exception classes, because my 'catches' will >> > use only a few of them anyway. but while exception is throwing, some >> > functions add different information to it (with operator <<) that is useful >> > in diagnostic messages. >> > >> > so when we decide to extract that information from exception, we need to >> > study what useful information it has. instead of using if-else it'll be nice >> > to use inheritance of _errors_ (not exceptions), for example: >> > >> > throw our_exception () << error_1 (); >> > ... >> > catch (our_exception & e) >> > { >> > re-throw e << error_2 (); >> > } >> > ... >> > catch (our_exception & e) >> > { >> > shared_ptr <base_of_error_1_and_2> ptr; >> > while (e >> ptr) >> > cout << ptr->format_error_message(); >> > } >> > > I understand what you are doing but I don't understand why. Could you > provide a non-abstract example of a use case that benefits from this > addition? No problem. We have to basic exception classes: errors associated with external files or system calls and internal interpreter errors. To work properly, program don't need a lot of information about errors, but we need this information in error messages. boost::exception gives simple way to collect error context so each function does not need to worry about errors it catches, but should just add its context. In result, content of exception depends on it path throw function and modules. A few pieces of code (i omit boring parts): struct silent : virtual exception { inline silent (guid_t e) : exception (e) {} }; struct critical : virtual exception { inline critical (guid_t e) : exception (e) {} }; template <typename level> struct system_error : public level { inline system_error (guid_t e) : exception (e), level (e) {} }; struct info { virtual void printf (boost::format &) const = 0; virtual guid_t format (void) const = 0; virtual ~info () {} }; // in RL we generate them using boost macros :) struct module_info_e : public info { guid_t format (void) const { return 101; } void printf (boost::format & dest) const { const boost::tuple < string, string > & tuple = static_cast < const boost::error_info< module_info_e, boost::tuple <string, string> > *> (this) -> value(); dest % tuple.get<0>() % tuple.get<1>() ; } }; typedef boost::error_info < module_info_e, boost::tuple < string, string > > module_info ; enum { bad_module }; ....... // in Module::arch_dependent::load throw system_error <silent> (bad_module); ..... // in Module::load catch (silent & e) { throw e << module_info (make_tuple ("1.so", "error while loading")); } ..... // in Script::run that can run command that loads module (or not, we don't know) catch (silent & e) { throw e << context_info (make_tuple (current_line)); } ..... // some function that should be stable catch (exception & e) { print_error (e); } print_error() is a point where we should discover exception content. In above example it is like this: ostringstream message; for (boost::shared_ptr <info const> base ; e >> base ; ) { boost::format format (Sys::Instance().Reader <Resources> :: get <char_t*> (base->format ( ))); // get format string for error base->printf (format); // fill format string with error info content message << format << std::endl; } If we use exception hierarchy instead of error information hierarchy we don't have such freedom like this (using virtual functions) because we can't combine error information so random. So it is main purpose -- to avoid worrying about what errors we are catching). Also IMHO it is not too beautiful because a lot of functions shouldn't know anything about error information, only about exceptions, so they should be separated. I don't insist on this, just report changes that I need for myself. I'm sorry i'm too verbose (or sorry if i'm not verbose enough :)

1 0

C++ function bind
by claud.86＠email.it 19 Apr '09

19 Apr '09

Hi to all, i use libboost recently, it is the ideal solution for my software c++. Now I'm using asio and I need to invoke a function like this: fun(time_from_string("2010-01-30 5:03:02"),bind(&timer::run,this)); The body of fun will look like this: void fun(ptime t,void h) { ... timer.async_wait(h); ... } Obviously the return of the type of bind is not void and that is why there is an error. What kind should be the h parameter? Which is the prototype of fun? Thanks for your attention Claudio -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it: http://www.email.it/f Sponsor: Tutto in tempo reale sul tuo cellulare: news, messaggistica istantanea, email e molto altro ancora con m.email.Scopri di più Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8919&d=20090417

3 2

Extracting floating point constant exponent/mantissa at compile time
by Joel Falcou 19 Apr '09

19 Apr '09

I'm seeking a way to perform compile-time "bitwise" casting of floating value aka turning a float into an uint32_t value with the same bit pattern. Eg: -3.14f becoming 0xC048F5C3 I saw a mpl::double_ in the vault but I can't make tail nor head of the trick used in the large macros.hpp file. Considering I only need the capability of storing a flaot as a bit pattern and don't need the additional arithmetic, can someone enlighten me on the process used in mpl::double ?

2 5

[ptr_container] Documentation refers to a nonexistent member function
by Michael Marcin 19 Apr '09

19 Apr '09

The docs mention a release_back method which doesn't seem to exist. http://tinyurl.com/dyaumy -- Michael Marcin

2 1

[range] Extended... maybe?
by Vladimir.Batov＠wrsa.com.au 19 Apr '09

19 Apr '09

I am trying something looking fairly reasonable: string str1 = boost::replace_all_copy(str, 'x', '0'); It obviously fails to compile with: error: no matching function for call to 'begin(const char&)' error: no matching function for call to 'end(const char&)' as replace_all_copy() wants boost::ranges for the 2nd and 3rd parameters: replace_all_copy( const SequenceT &, const Range1T &, const Range2T &); and 'x' and '0' are not boost::ranges. Would that be sensible to extend boost::range along the following lines to allow string_algo to work with individual characters? namespace boost { template<> struct range_iterator<char> { typedef char* type; }; template<> struct range_const_iterator<char> { typedef char const* type; }; namespace range_detail { template<> inline char const* boost_range_begin(char const& c) { return &c; } template<> inline char const* boost_range_end(char const& c) { return &c + 1; } } } Thanks, Vladimir. P.S. I do understand that the following works string str1 = boost::replace_all_copy(str, "x", "0");

6 8

[1.39] Release notes
by Daniel James 19 Apr '09

19 Apr '09

Hello all, If you haven't already, please can you add your release notes for 1.39. It's the same procedure as always, the notes are stored in 'boost_1_39_0.qbk' in the directory: https://svn.boost.org/svn/boost/website/public_html/beta/feed/history If you don't know quickbook please don't worry about the syntax, I'll clean up any problems and rebuild the page daily - all that matters is that your intent is clear. If for any reason you can't commit to the website then email your notes to the list and I'll add them. thanks, Daniel

1 0

[fusion] fix for Ticket #2761
by Stjepan Rajko 19 Apr '09

19 Apr '09

Hi, The attached (minimal) patch addresses ticket #2761: https://svn.boost.org/trac/boost/ticket/2761 I tested the fix on my platform (gcc 4.0.1/darwin) and it didn't break any tests. Could this be committed to trunk? (I *think* I might even be able to do the commit myself, if it is OK). Thanks, Stjepan

1 0

[smart_ptr] make_shared perfect forwarding bug
by Frank Mori Hess 18 Apr '09

18 Apr '09

Perfect forwarding doesn't seem to work quite correctly with boost::make_shared. The attached program, which tries to pass a move-only type through make_shared fails to compile with gcc in c++0x mode. To fix it, I had to change the definition of detail::forward in make_shared.hpp to use rvalue references: #if defined( BOOST_HAS_RVALUE_REFS ) template< class T > T&& forward( T &&t ) { return t; } #endif This is just based on looking at how gcc implements std::forward. Is this the right fix?

2 1

[boost::exception] operator >>
by Gaydov Victor 18 Apr '09

18 Apr '09

hello! i'm using boost::exception in one project and did small modification for myself, what do you think about it ? i don't want to create a lot of exception classes, because my 'catches' will use only a few of them anyway. but while exception is throwing, some functions add different information to it (with operator <<) that is useful in diagnostic messages. so when we decide to extract that information from exception, we need to study what useful information it has. instead of using if-else it'll be nice to use inheritance of _errors_ (not exceptions), for example: throw our_exception () << error_1 (); ... catch (our_exception & e) { re-throw e << error_2 (); } ... catch (our_exception & e) { shared_ptr <base_of_error_1_and_2> ptr; while (e >> ptr) cout << ptr->format_error_message(); } i attached 'test.cpp' and 'operator.cpp' with stupid realization and example. if somebody thinks it can be useful of cause i can rewrite it to make it more practical.

2 2