September 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

[RangeEx] Where is the current version?
by Mathias Gaunard 19 Apr '10

19 Apr '10

Where is the current version (or a fairly recent version) of RangeEx? I can't find anything on the trunk, the sandbox or the vault.

5 13

[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

Trac XMLRPC support
by Vladimir Prus 21 Mar '10

21 Mar '10

Would it be possible to have XMLRPC plugin installed in Boost Trac instance? See: http://trac-hacks.org/wiki/XmlRpcPlugin The installation appears to be fairly simple (and indeed seems to just work somewhere else). This will allow to use third-party tools to grab tickets from Boost Trac, which will hopefully lead to more issues fixed :-) - Volodya

4 5

boost::mpl::for_each and value_initialized
by Peter Foelsche 08 Feb '10

08 Feb '10

Dear All, what is the use of value_initialized in boost::mpl::for_each? It should be sufficient if the value is initialized by the constructor. value_initialized() calls memset() in before calling the constructor. This memset() is not being optimized away with gnu-c++ 4.4.1. What class does require zeroed memory to work correctly? Peter *** boost_1_40_0/boost/mpl/for_each.hpp Mon Aug 17 22:16:53 2009 --- boost_1_40_0.saved/boost/mpl/for_each.hpp Tue Sep 1 12:54:55 2009 *************** *** 71,78 **** // dwa 2002/9/10 -- make sure not to invoke undefined behavior // when we pass arg. ! value_initialized<arg> x; ! aux::unwrap(f, 0)(boost::get(x)); typedef typename mpl::next<Iterator>::type iter; for_each_impl<boost::is_same<iter,LastIterator>::value> --- 71,78 ---- // dwa 2002/9/10 -- make sure not to invoke undefined behavior // when we pass arg. ! //value_initialized<arg> x; ! aux::unwrap(f, 0)(arg()); typedef typename mpl::next<Iterator>::type iter; for_each_impl<boost::is_same<iter,LastIterator>::value>

5 10

Interest check: Boost.Mock
by Peter Bindels 26 Dec '09

26 Dec '09

Hi all, Over the past three-quarters of a year I've been working (with three friends) on a mocking framework for C++. In our vision, it would be a good complement to Boost.Test for testing classes separate from interfaces required - it would improve the ability to unit-test the classes that tie others together and that implement higher-level algorithms. It does this by creating an object that is "derived" from a given class at runtime, and replacing the functions with functions that redirect to verifying logic. The verifying logic uses basic structures to record expectations and to verify they happened. These ways of creating an object at runtime and modifying it are highly compiler dependant but remarkably portable - as it runs on at least 3 different compiler series (GCC, MSVC, EDG-based) and 5 platforms (Windows XP, Windows CE, Linux, QNX, bare platform), with few modifications. The library has been released under the name "Hippo Mocks" already. I'm interested in submitting it to Boost for three reasons. First of all, I believe that there may be obvious or very interesting optimizations or expansions I do not notice. Second, as Christian has elaborated on already, having the Boost tag on the project makes it more noticed and more used. As it has taken quite a bit of time from me already I would like people to use it. Third, Boost.Test allows testing code but does not support mocking. In the environment of unit testing, anything that is not a base library benefits from mocking by abstracting away details that are irrelevant and that will break your test unnecessarily. For Boost the main changes would be superficial in the naming and in using more default libraries instead of a new implementation. For Hippo Mocks I've decided to make no assumptions in anything over C++98 so there's a full Tuple implementation and so on. If there's an interest I'll spend the evening porting the code to qualify for the Boost coding norms and upload it to the vault (if I can - but that should be OK). I would like you to take a look at the code and tell me what you think of it. Thanks for your time. Kind regards, Peter Bindels

8 10

[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

[thread] #2742 Why the at_thread_exit cleanup function is const?
by vicente.botet 25 Nov '09

25 Nov '09

Hi, Anthony, could you verify the patch and test I have attached to the ticket works for other platforms that cygwin? Thanks, _____________________ Vicente Juan Botet Escribá

2 1

[move][container] Review Request (new versions of Boost.Move and Boost.Container in sandbox and vault)
by Ion Gaztañaga 17 Nov '09

17 Nov '09

Hi to all, I've just uploaded to boost sandbox... http://svn.boost.org/svn/boost/sandbox/move/) and Boost.Vault... http://www.boostpro.com/vault/index.php?action=downloadfile&filename=boost.… ...new versions of libraries Boost.Move and Boost.Container. Online documentation can be found here: Boost.Move http://svn.boost.org/svn/boost/sandbox/move/libs/move/doc/html/index.html Boost.Container http://svn.boost.org/svn/boost/sandbox/move/libs/container/doc/html/index.h… I would like to request a review for both libraries. Boost.Move is quite small (just one header). Boost.Container depends on Boost.Move and Boost.Intrusive so you must download also the post-1.40 version of Intrusive placed in the same package (Boost.Container uses new features from Intrusive not included in Boost 1.40). Just take fresh Boost 1.39 folder and overwrite it with package contents. ************************ What's new in Boost.Move: ************************ ->The library has been modified to support moving rvalues of copyable AND movable types, a limitation of the previous version. This changes where proposed by Klaus Triendl in this thread: http://lists.boost.org/Archives/boost/2009/06/153266.php The library has now new macros to declare copyable and movable types and movable only types. Old macros are still there for backwards compatibility (specially unordered library which was also ported to this move sandbox) but I expect to remove them if current approach is considered better. ->Updated documentation and tests. ************************ What's new in Boost.Container: ************************ -> Added tests and documentation -> Updated the library to the new Boost.Move macros * * * I've tested both libraries in Windows XP using the following compilers: Visual 7.1, Visual 8.0, Visual 9.0, Intel 10.0, Mingw-gcc 4.3 and Mingw-gcc 4.3 in C++0x mode. The library should work on any C++03 conforming compiler Best, Ion

19 95

Boost.Variant is not EqualityComparable
by brook＠biology.nmsu.edu 12 Nov '09

12 Nov '09

I just ran into the case that Boost Variant does not satisfy the EqualityComparable concept. While it provides operator==() and operator<() (and therefore is LessThanComparable), it does not provide operator!=(), which is required for the EqualityComparable concept. Is this by design or oversight? It seems reasonable to expect that a Boost Variant model this concept, but perhaps I am missing something. In case it is by oversight, the following patch seems to provide the missing operator. Cheers, Brook --- boost/variant/variant.hpp.orig 2009-05-13 21:21:59.000000000 -0600 +++ boost/variant/variant.hpp 2009-05-25 19:21:40.000000000 -0600 @@ -1681,6 +1681,8 @@ return rhs.apply_visitor(visitor); } + bool operator!=(const variant& rhs) const { return !(*this == rhs); } + bool operator<(const variant& rhs) const { //

6 7

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

Time for another bug sprint (after 1.41 ships)?
by Marshall Clow 09 Nov '09

09 Nov '09

Earlier this year, we had a "bug sprint", where many people focused on fixing bugs in Boost. We managed to get the # of open tickets down from 800 to about 720. As of today, there are 820 open tickets in Trac. Is it time to focus on swotting bugs again? 1.41 is scheduled for release on 1-November; that's six weeks from yesterday. How about a bug sprint starting on 14-November, finishing on 22- November? That's two weekends - and finishes up before the American Thanksgiving holiday. -- Marshall P.S. This doesn't mean that people have to wait until November to fix bugs ;-) ;-)

12 25

[integer] Compilation failed in Visual Studio
by Adam Badura 28 Oct '09

28 Oct '09

Following simple program: #include <boost/integer_fwd.hpp> int main() { return 0; } does not compile in Visual Studio 2008 with Boost 1.40.0. Compilation errors are following: 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(70) : error C2039: 'long_long_type' : is not a member of 'boost' 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(70) : error C2065: 'long_long_type' : undeclared identifier 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(70) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(73) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template Adam Badura

6 9

[BGL] Multithread problem inserting edges and exploring the same graph
by Cosimo Calabrese 21 Oct '09

21 Oct '09

Hi to all, I've a problem on BGL. My environment is WinXP, Visual Studio 2005, Boost 1.37. I'm trying to use BGL in the following way. I've a single graph in my application, that is an adjacency_list< vecS, vecS, ... >, and I've 2 kind of threads that work on the graph: - some "Explorer" threads, that executes a Dijkstra's algorithm repeatedly; - some "Integrator" thread, that call the add_edge() function repeatedly. The program often crashes, because it cannot dereference some graph elements, some auto_ptr... The crash isn't sistematic, so I think there's a concurrency problem. I think that the problem is in the use of the vectors in the implementation of the graph. In general, if I've an iterator 'it' that point on an vector's element A, and I insert another element B before A, then the iterator is now invalid. I suppose that it happens something of similar in the graph. If I read the out-edge list of a vertex at the same time that I add another out-edge to the same vertex, the reading may be inconsistent. So I've tried with an adjacency_list< listS, vecS, ... >, because if I add an element to a list, the previous reference are still valid, but I've experienced the same problem again. If what I've said is correct, then I think that with an adjacency_matrix I will not have problems, but I've approximately 5 millions of vertices, and the graph is sparse. I think that is a waste of memory. And what about the exploring time? Another question: if I launch *only* a set of Explorer thread, it seems that there aren't problems with EdgeList = listS and EdgeList = vecS too. Can someone confirm to me that the exploring algorithms, like Dijkstra, don't modify the graph structure? Are they read-only algorithms? Can I safely launch multiple exploration threads simultaneously? Can someone help me? Many thanks in advance, Cosimo Calabrese.

5 24

[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

[rdb] 0.0.09
by Jean-Louis Leroy 04 Oct '09

04 Oct '09

In this version : * EXISTS * consistency check in INSERT...SELECT * DISTINCT, ALL * transactions The transaction stuff is pellicular. It simply maps to vendor calls. I am hesitating a bit, either make a common interface for the most common operations (like execute) directly in each backend (aside with vendor-specifc calls) or put them in a separate wrapper or even decide that it's not in the scope. There's more redesign in the select from which I think I can get an elegant implementation of vendor-specific features (like LIMIT). The idea is to pass all the data in a fusion map, allowing vendor specific parts of the statement to slip their own data inside it. In fact this also is how DISTINCT works. I dropped the composition of lists via chained calls to operator (). It's all preprocessor-based now. The () chain system was limited by FUSION_MAX_VECTOR_SIZE anyway. I have installed MySQL on my computer. I am still accessing it via ODBC but I'll probably start the native support soon. Yesterday I tried to upload and just when I pushed the upload button the vault server crashed. I suspect that it was my upload that triggered it. J-L

6 15

[Fusion] port to c++0x
by Christopher Schmidt 04 Oct '09

04 Oct '09

I participated in Google's 'Summer of Code' for Boost this year. My project was to port Boost.Fusion to c++0x. The program is over now and I would like to give you a short report on my work and put my code up for comments. In a nutshell, there is rvalue support, native variadic templates are used if possible and the public classes and (meta-) functions are guarded by a set of static asserts that detect most invalid (template) arguments. I also added certain new functionality to provide an easier, faster and more intuitive programming interface. My implementation is pretty much backwards compatible and all test cases pass on gcc 3.4/4.4 and vc 9. Here is a short overview of the most striking changes besides the implementation of raw c++0x support. I removed the deque container and the extension-classes. The deque container is undocumented and, in my opinion, does not go well with the other container due to its intrinsic extension mechanism. There also should not be a performance gain compared to a regular fusion::joint_view in combination with two fusion::vector. The extension classes are pretty much Boost.Proto specific. At the moment they seem to be out of place, especially as they are undocumented, unmaintained and not even part of the regular file structure. I would like to see them either fully documented (with the underlying concept of segmented sequences) or in the detail namespace of Boost.Proto. I added support for associative iterators. An associative forward sequence shall provide an iterator type which implements the extension backend of the intrinsic (meta-)functions fusion::result_of::value_of_data, fusion::deref_data and fusion::result_of::key_of. This has the advantage that all view classes, even fusion::iterator_range, are able to adapt the underlying sequence's associative-ness. fusion::transform_view, as a special case, got an additional template parameter. This parameter specifies whether the view should model either the forward concept only or the associative and the forward concept. This design breaks consistency with Boost.MPL. Unfortunately these changes are crucial and I would rather risk this break with Boost.MPL than missing that important feature. Using the old implementation, there is no way to avoid explicitly converting from a view back to an associative sequence to preserve the associative-ness. This leads to a nasty runtime overhead due to evaluation of every element of the view and copy-/move-constructing it. Besides, other changes include: -If the compiler supports rvalue references, all fusion container have a template constructor (taking either const lvalue or 'templated' rvalue references). -If the compiler supports variadic templates, fusion::cons, fusion::pair and fusion::single_view have a variadic template constructor (taking either const lvalue or 'templated' rvalue references) that allows emplace construction. -The view classes adapt the full category of their underlying sequences. As mentioned above, the associative-ness is preserved, but also, if possible, the random-access or bidirectional trait. -The result_of::-metafunctions accept r- and lvalue references arguments. If an argument is not reference-qualified, it will be considered to be an lvalue reference. All existing extension implementations must be changed to adapt this new behaviour. -The algorithm functions now also take (and correctly forward) non-const reference arguments. -Fusion iterators (with reference compatible sequence types and a very same index) and views (with reference compatible sequence types) have a working operator= that correctly reassigns the underlying sequence references. -Fusion now also adapts MPL iterators. If, and only if, the <boost/fusion/adapted/mpl.hpp>-header is included, mpl sequences and iterators are recognized as fusion sequences and iterators. -There are new headers to adapt std::(tr1::)array or std::(tr1::)tuple. The overall compile-time performance of my code is satisfying. Compiling a compilation unit that includes all possible fusion headers takes on gcc 4.4 slightly more time than the official fusion implementation. If native variadic templates are present, the compilation is a lot faster (usually up to 3 to 6 times), regardless of the value of FUSION_MAX_xxx_SIZE. The compile-time performance of actual fusion code is mixed. The intrinsic container and iterator (meta-)functions compile a little bit slower compared to the official fusion implementation. This is due to explicit removal of the references on the arguments of all result_of::metafunctions and some additional abstraction layer. If the compiler support rvalue references, there has to be a rather ugly and slow type evaluation/transformation to avoid issues with rvalue references on non-array, non-class types (see /support/internal/ref.hpp and 8.5.3p5 of the current c++0x draft for more details). On the other hand, I added several optimizations (such as result preevaluation), and, if variadic templates are present, the actual instantiation of fusion containers is a lot faster. All in all, the compile-time performance is a little bit worse if c++0x features are not present. If c++0x features are present, the code should compile a little bit faster in most cases. For example, the lambda example of the Boost.Proto documentation, which internally heavily relies on Boost.Fusion, takes on my machine 2.6 seconds to compile with the 'old' fusion on gcc 4.4, 3 seconds with my port without -std=c++0x, and 2.1 seconds with c++0x features being present. The overall performance might be even better once Boost.MPL adapts native variadic templates and the compiler supports template aliases. There have been tons of other changes, mostly bugfixes, optimizations (in terms of compile time of course) and removals of redundancy. Whenever I had the choice, I tried to prefer clean, redundancy-free instead of heavily optimized code. The overall performance loss is not noticeable though, and most compile-time optimizations that go beyond the as-little-template-instantiations-as-possible paradigm are pretty much compiler dependent anyway. There is still some work to do. I did not add c++0x-specific test cases and there are several parts of the documentation which need to be updated. By the way, are there any official guidelines for documenting c++03/c++0x-specific differences? For now, I would like to hold off on implementing these changes until Boost.TypeTraits adapts c++0x. Right now I implemented missing or incorrectly behaving trait functions in the fusion::detail-namespace. I would rather like to use the official ones, at least in the documentation and in the test cases. Besides that, I think my implementation is trunk-ready. If there are no objections, I would like to finish the outstanding work as soon as possible, and then merge my code with the trunk. Of course I will provide long-term support for the project. In fact, I would love to become an official fusion maintainer. You can find the code in the boost sandbox (/sandbox/SOC/2009/fusion). If you test the code with a compiler that has decltype support, please use the HEAD of the trunk rather than the official 1.40 distribution package to compile your code. Best regards Christopher

6 17

Review Request: Boost.Itl; The Interval Template Library
by Joachim Faulhaber 03 Oct '09

03 Oct '09

Dear developers, the Interval Template Library is now in a state where I think it does conform the requirements and guidelines for boost libraries fairly well. To decide, whether it's design, implementation and overall usefulness is sufficient to be accepted in the boost libraries collection is now up to you. In the last round of refactoring I concentrated on efficiency and optimization issues. The implementation of the itl's interval containers is still based on std::set and std::map, but algorithms are now exploiting hinted insert and are manipulating intervals and values in place instead of copying in many instances. This way, it has been possible to improve performance significantly. Along the way of implementing optimizations I have documented the complexity guarantees for all important functions of the library's interface. Please note that the original ITL as presented in May 2008 has been split into 3 parts and only the *first* part is submitted for review: itl : Core library, interval containers, SUBMITTED FOR REVIEW Additional parts are: itl_xt : Extensions like histories and generalized crosstables validate: The law based test automaton (LaBatea). A validation tool using laws aka axioms. *itl* is a complete library containing all required ingredients particularly a separate test suite (NOT using LaBatea) and the quickbook documentation. The code is successfully compiled and tested with gcc-3.4.4, 4.1.0, 4.3.2 and msvc-8.0, 9.0. I have uploaded the review version as itl_3_1_0.zip to the vault in section containers. http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_3_… Another file itl_plus_3_1_0.zip contains all three parts (itl, itl_xt and validate). http://www.boostpro.com/vault/index.php?action=downloadfile&filename=itl_pl… Reviewers interested in the law based testing part may have to refer to this file to examine those tests. The law base testing examples compile and run with gcc-4.3.2, msvc-8.0 and 9.0. LaBatea does not compile with gcc-4.1.0 or older. The quickbook generated documentation is included in the zip files and is also available online at http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/index.html Sources are also available form the sandbox: https://svn.boost.org/svn/boost/sandbox/itl/ To close my request for review, let me take the opportunity to do some advertisement ;-) focusing on some of the itl's highlights. * The Itl emerged out of real world software development extracting generic functionality from numerous use cases of the date time problem domain. (http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/ex…) But the need for the same data structures occurs in other fields as well. E.g. Zachary Turner uses a compressed_bitmap similar to an itl::interval_set to manage very large file system allocation bitmaps and gives more use cases here (http://lists.boost.org/Archives/boost/2009/06/152817.php) * Aggregation on overlap not only provides a useful feature to compute aggregation results on interval_maps like statistics, it also leads to a generalized addition operation on maps that exhibits interesting semantical properties. E.g. (http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/semant…) * The itl's design is based on sets of laws (aka axioms) that are described in the documentation. (http://herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/semant…) These law sets not only are giving a formal specification of the library. Using the law based testing tool (LaBatea) (https://svn.boost.org/svn/boost/sandbox/itl/boost/validate) allows to validate the library code for every specified law. * For the itl, 18 laws have been validated on the 7 container templates with varying instantiation types for template parameters, running a total of 719 different law instances (each of them for large numbers of randomly generated test data). (https://svn.boost.org/svn/boost/sandbox/itl/libs/validate/example/) This gives everyone a method to check semantical properties of the library in a way that is more powerful than traditional unit tests. To get the 'complete picture' of the library's interface you may want to refer to the synoptic function table first (http://www.herold-faulhaber.de/boost_itl/doc/libs/itl/doc/html/boost_itl/in…) before looking at more specific topics. Hoping to have quickened your appetite to take a closer look at this library before and during the review process. best regards Joachim Faulhaber

6 28

Hello and a quick question.
by S. Brad Daughdrill 02 Oct '09

02 Oct '09

Hello to all, I first want to say hello to all the members. I recently ran across your project, and I am really interested in working with you all. My question is are there an example that use forms? The example I found all seem to be console applications and while they are helpful, I really want my students to start programming with forms (initially at least). They will be using Visual C++ 2008 Express. Thank you for everything ahead of time. Brad *----- S. Brad Daughdrill The University of Alabama B.S. Management Information Systems M.S. Operations/Project Management M.B.A. Financial Risk M.A. Economics (Candidate) 146 Lenora Drive Tuscaloosa, AL 35401 (o) 205.348.7591, Bidgood Hall - 351E (c) 251.510.3089 (e) S.Brad.Daughdrill(a)Gmail.com*

3 2

[rdb] 0.0.10 + documentation
by Jean-Louis Leroy 01 Oct '09

01 Oct '09

I have uploaded a new revision to the vault. The only /visible/ change in the API is the syntax for the insert...select statement. It was `insert_into(table)(cols)(select(...))`, it is now `insert_into(table)(cols).select(...). The syntax engine is beginning to look more and more like a compile-time finite state machine. And there is the beginning of a documentation ! you can view it here : http://www.yorel.be/boost/libs/rdb/doc/html/index.html The tutorial is 2/3 complete for this phase (i.e. sans prepared statements). The structure of the doc is strongly influenced by Fusion's - no wonder, I spent so much time in it ;-) While I like the overall structure, I wonder if the Fusion style is appropriate for a tool that is not so much into meta-programming (well at least on the outside). I documented insert_into in this fashion (see http://www.yorel.be/boost/libs/rdb/doc/html/rdb/sql_subsystem/statements/in…) for a test. If you have opinions, please voice them. J-L

2 2

Re: [boost] On the Road to Aspen (BoostCon 2010)
by pete＠pcbartlett.com 01 Oct '09

01 Oct '09

On Tue 29/09/09 12:22 , Joel de Guzman <joel(a)boost-consulting.com> wrote: > Edouard A. wrote: > > Hi Joel, > > > > You can also create a twitter account and link your Facebook page > to this > > twitter account, mirroring all your facebook status updates to > your twitter > > account. > > > > This increases visibility and give the possibility to your fans to > choose > > the medium they like to follow you. > Thanks, Edouard. Done. BoostCon Facebook Linked to > Twitter (@BoostCon) > http://www.twitter.com/BoostCon Many users of Boost are in corporate environments. Many corporate environments block access to Facebook and/or Twitter (mine blocks both) domains. It'd be great therefore if Boost didn't move too much content there if equivalent

4 4

Double free from UTF
by janm-boost-devel＠transactionware.com 01 Oct '09

01 Oct '09

Hi, I am seeing a double free when using boost-test on: - FreeBSD 7.2-STABLE, amd64 (gcc 4.2.1) with boost 1.39 - Mac OSX 10.6.1, x86_64 (XCode 3.2, gcc 4.2) with boost 1.40 I don't see the problem on Windows XP with Visual C++ 2005 Express. A simple test case is below, just run. The _malloc_options is to make the system malloc() fill memory with 0xa5 on allocation and 0x5a on deallocation. #define BOOST_TEST_MAIN #include <boost/test/included/unit_test.hpp> #include <stdlib.h> const char* _malloc_options = "J"; BOOST_AUTO_TEST_CASE(broken) { BOOST_CHECK(true); } Output: Running 1 test case... *** No errors detected zsh: bus error (core dumped) ./a.out Stack Trace: #0 0x0000000800b1bdee in free () from /lib/libc.so.7 #1 0x000000000043e51c in boost::unit_test::framework_impl::clear (this=0x55ad20) at framework.ipp:133 #2 0x000000000043e652 in ~framework_impl (this=0x55ad20) at framework.ipp:122 #3 0x00000000004110c6 in __tcf_1 () at framework.ipp:222 #4 0x0000000800b6dbb6 in __cxa_finalize () from /lib/libc.so.7 #5 0x0000000800b1f7c7 in exit () from /lib/libc.so.7 #6 0x0000000000404595 in _start () Any ideas? Thanks, Jan Mikkelsen

6 12

Interest in flat_iterator for nested containers?
by Christoph Heindl 01 Oct '09

01 Oct '09

Hi, is there any interest in an iterator that provides a flat view of nested containers? For example ---------- using namespace boost::assign; typedef std::list<int> inner_container_type; typedef std::vector<inner_container_type> outer_container_type; outer_container_type elements(6); elements[1] += 1,2,3; elements[2] += 4,5; elements[4] += 6; BOOST_CHECK(std::equal( make_flat_iterator(elements.begin(), elements.end()), make_flat_iterator(elements.end(), elements.end()), list_of(1)(2)(3)(4)(5)(6).begin()) ); ---------- If so, I'll be glad to share my code with the boost community. I attach my current state of development and a single test suite. The current state of development contains a class named flat_iterator, a make_flat_iterator function and a set of meta-functions to derive required types. flat_iterator derives from boost::iterator_adaptor. It derives an inner_iterator type from the passed iterator to be adapted (outer_iterator type). The value_type of outer_iterator is required to model STL container concept. The value_type passed to boost::iterator_adaptor is const-qualified if the reference type of the outer_iterator or inner_iterator type is const-qualified (please see question 1 below). The traversal category of flat_iterator is bidirectional if the the outer_iterator and inner_iterator type are at least bidirectional. It models forward traversal else (question 2). flat_iterators can be stacked over each other to recursively flatten a hierarchy of arbitrary levels. ---------- using namespace boost::assign; typedef std::list<int> level_0; typedef std::vector<level_0> level_1; typedef std::vector<level_1> level_2; level_2 elements(10); elements[2] += list_of(1)(2); elements[4] += list_of(3)(4); typedef flat_iterator<level_2::iterator> flat_iterator_outer; typedef flat_iterator<flat_iterator_outer> flat_iterator_inner; flat_iterator_outer outer_begin(elements.begin(), elements.end()); flat_iterator_outer outer_end(elements.end(), elements.end()); flat_iterator_inner inner_begin(outer_begin, outer_end); flat_iterator_inner inner_end(outer_end, outer_end); BOOST_CHECK(std::equal(inner_begin, inner_end, list_of(1)(2)(3)(4).begin())); ---------- Open questions: * Currently the the value_type passed to boost::iterator_adaptor is const qualified based on required reference type of the outer_iterator, which renders the code for input iterators unusable, right? What's the best way to achieve const correctness? * The traversal category of flat_iterator is supposed to be the 'greatest common divisor' of the inner and outer iterator type. Is there a meta-function in boost that provides that type? Currently bidirectional traversal is chosen if both, inner and outer iterator, are at least of bidirectional traversal. Else forward traversal is chosen (which is of course incorrect when incrementable is passed). * Stacking flat_iterators to flatten out a hierarchy of arbitrary levels is possible but currently requires a lot of typing. I think that applying some recursive meta-functions to generate a correct iterator types for such situations should be possible but is beyond my current knowledge of meta-programming. Kind regards, Christoph

2 8

boost::variant and "Current Approach: Temporary Heap Backup" vs "An Initial Solution: Double Storage"
by Peter Foelsche 01 Oct '09

01 Oct '09

1) boost::variant and "Current Approach: Temporary Heap Backup" vs "An Initial Solution: Double Storage" Please provide both solutions. A potential heap allocation may prevent certain application areas. 2) I also do not understand that exception safety requires that the variant is never empty (e.g. empty() returning always false). What is the use of calling the constructor (of which type btw?) if somebody creates an unintialized variant variable? Or: In the following piece of code is the std::string constructor being called? boost::variant<std::string, int> s; Thanks Peter

2 8

Re: [boost] On the Road to Aspen (BoostCon 2010)
by Pete Bartlett 29 Sep '09

29 Sep '09

I'm sorry somehow my message was sent before I was ready... I wrote: >Many users of Boost are in corporate environments. Many corporate environments block access to Facebook and/or >Twitter (mine blocks both) domains. >It'd be great therefore if Boost didn't move too much content there if equivalent .. functionality is available on boost.org. I understand that many will think the problems lie with unenlightened corporate policies rather than boost, but the latter has a rich and noble history of BOOST_WORKAROUNDing the mistakes of others :-). Pete

1 0

[smart_ptr] comparison of intrusive_ptr objects
by Dmitry Vinogradov 29 Sep '09

29 Sep '09

Does anybody know why intrusive_ptr has ==, != and < operators, but the rest ones are missing (i.e. >, <=, >=)? It makes hard to use intrusive_ptr in generic code.

4 3

Using some of Boost on i5/OS but still problems
by Jon Brisbin 29 Sep '09

29 Sep '09

I was able to use Boost FOREACH in my tests, now I'm trying to use Boost optionals in a C++ ILE module. The compiler is yelling at me, though: "/home/jbrisbin/include/boost/optional/optional.hpp", line 434.66: CZP0210(30) "T" is not a base class of "basic_string<char,std::char_traits<char>,std::allocator<char> >". "/home/jbrisbin/include/boost/optional/optional.hpp", line 434.10: CZP0700(0) The previous message was produced while processing "boost::optional_detail::optional_base<std::basic_string<char,std::char_ traits<char>,std::allocator<char> > >::destroy_impl(is_not_reference_tag)". "/home/jbrisbin/include/boost/optional/optional.hpp", line 408.9: CZP0700(0) The previous message was produced while processing "boost::optional_detail::optional_base<std::basic_string<char,std::char_ traits<char>,std::allocator<char> > >::destroy()". "/home/jbrisbin/include/boost/optional/optional.hpp", line 237.24: CZP0700(0) The previous message was produced while processing "boost::optional_detail::optional_base<std::basic_string<char,std::char_ traits<char>,std::allocator<char> > >::~optional_base()". "/home/jbrisbin/include/boost/optional/optional.hpp", line 145.7: CZP0700(0) The previous message was produced while processing "boost::optional_detail::optional_base<std::basic_string<char,std::char_ traits<char>,std::allocator<char> > >::__dftbdt()". "/home/jbrisbin/include/boost/optional/optional.hpp", line 522.5: CZP0700(0) The previous message was produced while processing "boost::optional<std::basic_string<char,std::char_traits<char>,std::allo cator<char> > >::~optional()". "/home/jbrisbin/include/boost/optional/optional.hpp", line 454.7: CZP0700(0) The previous message was produced while processing "boost::optional<std::basic_string<char,std::char_traits<char>,std::allo cator<char> > >::__dftdt()". "/home/jbrisbin/src/boosttest.cpp", line 6.5: CZP0700(0) The previous message was produced while processing "main(int, char **)". Any hints on what I need to hack here? This seems to be a problem with: void destroy_impl ( is_not_reference_tag ) { get_ptr_impl()->T::~T () ; m_initialized = false ; } I understand what's happening, I'm just not sure how to make the i5/OS compiler happy with this. I keep running into little quirks like this where the AS400 needs a little different treatment. IBM says Boost won't work on the AS400, which I'm finding to be inaccurate at best. It DOES work, just not everything straight out of the box. Lots of things work fine, but some need a little bit of tweaking. What else can I try to get the destructor called? Jon Brisbin Portal Webmaster NPC International, Inc.

2 2

On the Road to Aspen (BoostCon 10)
by Joel de Guzman 29 Sep '09

29 Sep '09

Hi, The road to Aspen starts now. I've been to all three BoostCon events since its inaugural conference in 2007. I can tell you, the experience is definitely amazing. I've been a Boost developer since 2001. Boost is like a virtual family to me. From 2001, I've known and collaborated with countless people, many of which I haven't actually met, until the first BoostCon in 2007. Amazing people like Hartmut Kaiser, Dan Marsden, Eric Niebler, to name a few, were just names. Before BoostCon, I often wished to get to see the faces behind the names. It was exhilarating to finally meet these folks, have a couple of beer (and Pizza!), talk about C++, library development, the wondrous mountains of Aspen, the trees, the bears and coyotes (hah!). If this looks too much like a friendly post, well, it is! I'd like to break a bit from the highly technical discussions taking place in these mailing lists and point you to a FaceBook group named, ermm, "BoostCon" :-) http://www.facebook.com/group.php?gid=125839305706 My task is to invite you guys to join in. You do not have to be a former BoostCon attendee. Everyone here is invited to join. If you want to see the "faces" behind the names, get to know more of the people behind Boost, get to know more friends that share your passion for Boost, C++, templates, etc., in a more relaxed venue, this is the place. If you have even the slightest inkling to attend a future conference, well, join in. Here we can discuss things like sharing rooms to cut cost, where to find the best food in town, car pooling etc. In preparation time prior to the conference, we can discuss matters like which kind of talks you want to see, keynote speakers you'd be interested in seeing, etc. For past BoostCon attendees, here’s a chance to meet up again. Hey, even if you are not planning to attend, I'd like to invite you anyway. Consider this group as a friendly face of Boost :-). Hopefully, the friendly atmosphere will make you attend anyway ;-) Cheers, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

3 5

Pretty type_info::name string?
by Emil Dotchevski 28 Sep '09

28 Sep '09

Do we have in Boost something that would attempt to return the pretty version (meaning, it'd fall back to returning the ugly version) of the std::type_info::name string? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

6 5

Trunk tests broken, missing file
by Belcourt, Kenneth 27 Sep '09

27 Sep '09

error: Unable to find file or target named error: 'algorithm/nview.cpp' error: referred from project at error: '../libs/fusion/test'

2 1

[fusion] inconsistency in size metafunction
by Jean-Louis Leroy 27 Sep '09

27 Sep '09

Consider : #include <boost/fusion/include/vector.hpp> #include <boost/fusion/include/push_back.hpp> #include <boost/fusion/include/size.hpp> #include <boost/mpl/assert.hpp> #include <boost/type_traits/is_same.hpp> int main() { using namespace boost; using namespace fusion; typedef vector<int, int> seq1; typedef result_of::push_back<vector<int>, int>::type seq2; BOOST_MPL_ASSERT((is_same<result_of::size<seq1>::type, result_of::size<seq2>::type>)); } One would not expect this to fail, however it does : 'boost::mpl::assertion_failed' : cannot convert parameter 1 from 'boost::mpl::failed ************boost::is_same<T,U>::* ***********' to 'boost::mpl::assert<false>::type' 1> with 1> [ 1> T=boost::mpl::int_<2>, 1> U=boost::mpl::integral_c<int,2> 1> ] J-L

2 2

Boost.Iterator filter_iterator issues
by Christoph Heindl 27 Sep '09

27 Sep '09

Hi, I think I've found an issue with boost::filter_iterator when decrementing a valid iterator without having any predicate evaluating to true on its way back. filter_iterator.hpp line# 93 states void decrement() { while(!this->m_predicate(*--(this->base_reference()))){}; } which will ?clearly? pass beyond the initial start iterator if no predicate evaluates to true. Is it a requirement for the iterator being adapted by filter_iterator to catch decrements past the containers begin range? The following test will iterate 'iter' past containers begin iterator which will trigger a debug assertion on MSVC. template<class _Iterator> void dec_iterator(_Iterator iter) { BOOST_CHECK(*iter == 2); --iter; // iterates past begin } BOOST_AUTO_TEST_CASE(test_filter_iterator) { using namespace boost::assign; typedef std::vector<int> container_type; container_type values = list_of(0)(1)(2); dec_iterator(boost::make_filter_iterator(std::bind2nd(std::greater<int>(), 1), values.begin(), values.end())); } Please help me clarifying this issue. Best regards, christoph

2 2

[fusion] useful as_variant in spirit2
by Christian Holmquist 26 Sep '09

26 Sep '09

Good day everyone, The function in boost\spirit\home\support\detail\as_variant.hpp seems to have no dep. on spirit, and it's a useful utility that would fit into fusion/support/as_variant.hpp> IIUC it's a meta function that computes a variant<T0, ..., TN> from a fusion sequence<T0, ..., TN>. I think there's no reason for a runtime counterpart, i.e. as_variant<Seq>::type is a valid expression but as_variant(Seq) and result_of::as_variant<Seq>::type is not. Thus, the function is already complete. Does it seem reasonable to you to include in fusion? The work of moving it would be to only update the docs, as spirit2 probably does excessive testing of this function anyway. I could collect the docs from other parts of fusion, and put together a separate test file if needed. All real work is already done, just presentation and formality that is lacking. Have a nice weekend, Christian

5 4

Tools for singleton or monostate or alternative
by Mateusz Loskot 25 Sep '09

25 Sep '09

Hi, I would like to kindly ask for advice in finding tools within Boost collection that could help me to solve my problem. I'm developing a library (it will be used as dynamic-linked library). I need to manage a bunch of related values (numbers) globally. All values are shared across a client process, by its all threads, so thread-safety is under consideration. Mostly, a client needs to read the values (defaults) and sometimes, very rarely, a client needs to re-set the values. I consider to implement it using singleton or monostate pattern with thread-safety (and DLL-safety in mind), so actually Tobias Schwinger's Singleton library [1] would solve this problem well. However, I would prefer something from the Boost collection - Tobias' lib hasn't been approved [2], quite pity as Boost lacks of such tool, IMHO. Also, I've considered digging out singleton stuff from the boost::pool::detail, but I'm not convinced to this idea. I haven't found anything related to monostate patter in Boost. Would anyone suggest a tool available in Boost that would be usable to wrap up some basic but robust solution for my problem? By the way, any plan for update and another round of review of Tobias' library? [1] http://torjo.com/tobias/index.html [2] http://lists.boost.org/boost-announce/2008/01/0171.php Best regards, -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org

2 2

[rdb] Uploaded 0.0.07
by Jean-Louis Leroy 25 Sep '09

25 Sep '09

This version features : * insert...set syntax (but no insert...select yet) * update [where] * delete from [where] * create and drop follow the same syntax pattern as the others * attempts to simplify the internals (in insert - select still needs a second look) * some concept checks It's *beginning* to look like something one could use in simple real apps. What's missing before it qualifies is imo `like', 'exists' and transactions. That should not take long. This version compiles with msvc9 and gcc 4.4.1. I tested on Win32 with an Access db via ODBC. The sql engine tests pass on Linux but I have not tried the ODBC test suite on Unix yet. If somebody tries it, please tell me. I have changed the naming scheme : first number is major revision ; second is the milestone (crud with direct execution ; transactions ; prepared statements ; dialects ; constraints ; dynamic sql - which btw I am now nearly sure I can fit elegantly in my framework ; views). Third number is just there for getting ++'ed. The test suite is still the doc but after the transactions I'll begin documenting. Probably with QuickBook. It's funny to see that some people are still downloading 0.04. As I write this the downlaod count bumped to 21 :-D To avoid confusion due to the change in the versioning scheme I deleted the old versions. J-L

4 10

[interprocess][multi_index] emplace() is not sufficient for maps
by Thorsten Ottosen 25 Sep '09

25 Sep '09

Hi Ion and Joaquín, This issue is related to node-based containers. I think you both have added emplace() to provide efficient in-place construction. However, I often encounter a situation where emplace() is not sufficient for me. The situation is characterized by the need to calculate the key after the mapped value (a heavy object) has been placed in the pair. To calculate the key the mapped value needs to be modified (the key is calculated as a side-effect). I therefore suggest that we add a new function: typedef ... map; map m; map::node_ptr p = m.get_node_ptr(<like emplace, but only for constructing the mapped value>); p->pair.first = modify( p->pair.second ); m.insert( boost::move(p) ); Thoughts? -Thorsten

5 21

Boost build problem
by Emil Dotchevski 25 Sep '09

25 Sep '09

I'm trying to use <link>static and <runtime-link>static with my own code, which depends on boost filesystem, and I have the problem that the linker is passed libboost_filesystem-vc80-mt-sgd-1_41.lib while the debug\link-static\runtime-link-static folder has libboost_filesystem-vc80-sgd-1_41.lib. (I've built bjam from the latest trunk sources and I'm using the latest trunk revision of boost build.) HALP! :) Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

5 7

[rdb] Uploaded 0.0.08
by Jean-Louis Leroy 24 Sep '09

24 Sep '09

Tonight: * insert...where (but doesn't check consistency between insert list and values returned form select) * like J-L

1 1

boost::variant -- this code compiles fine -- I think it should not compile
by Peter Foelsche 24 Sep '09

24 Sep '09

#include <boost/variant.hpp> struct test { }; int main(int argc, char **argv) { boost::variant<std::string, int, double> s; boost::get<test>(s); return 0; }

2 1

Matrix Library
by Cem Kalyoncu 24 Sep '09

24 Sep '09

As a part of our graphics study, we have built a 2D matrix class to implement few matrix operation. After the study we have expanded our aim for matrix operations system and started building a matrix and possibly a math library. Currently matrix library is quite near to the finish. To make it as generic as possible, we have used templates. Current state of the project can be accessed from http://sourceforge.net/projects/mathlibcpp/ (SVN: https://mathlibcpp.svn.sourceforge.net/svnroot/mathlibcpp/) A simple search revealed that there is no matrix module for boost libraries. We are willing to resolve compatibility issues and lend our support this module. However, before taking any action, I would like to ask your opinions. Thanks in advance, Cem Kalyoncu Following functions exists in the library: Set/Get/GetData/() Resize/GetSize/GetCols/GetRows isSquare/isIdentity Compare/==/!= =/Copy constructor/CopyTo [Row|Col|]Min/Max/Average/Sum/Median [Row|Col]MinIndex/MaxIndex SortRows RemoveCol/RemoveRow matrix operators (+, -, *, +=, -=, *=) scalar operator (+, -, /, *, +=, -=, *=, /=) Transpose/Determinant/Inverse/Minor/Cofactor/Adjoint Uses a managedbuffer and allows temporary matrixes which are not copied Identity/ZeroFilled/RandomFilled/RobertsCross/SobelX|Y conversion to string and output to a stream is supported

5 4

pool allocation
by Stefan Strasser 24 Sep '09

24 Sep '09

I took a closer look at Boost.Pool today to replace some default allocation of small objects. what I found there was a little disappointing, at least for my use case. the object_pool has 2 major downsides: - no dynamic block allocation - destroying one(!) object is O(N), with N being the number of unused objects in the pool so I wrote some code for my own use. I'm not suggesting this code should be added to boost, but something like it. struct A{ ... }; { pool<A,100> pool; A *a; for(int c=0;c<250;++c){ a=pool.new_(); // O(1) } pool.delete_(a); //O(1), destructs } //destruction of 249 objects, O(N) this allocates 3 memory blocks. but it also has one pointer memory overhead per object, to achieve constant time deletion. but you can use that pointer while the object is in use, which was what lead to this code: I needed to store unused boost.intrusive nodes: struct A : intrusive::[s]list_base_hook<>{ ... }; { [s]list_pool<A,[s]list_base_hook<>,100> pool; //same as above } this has no memory overhead, as the list hook can be used by the pool. here's the code: http://www.boostpro.com/vault/index.php?action=downloadfile&filename=intrus…

3 4

[asio] Mixing of sync and async calls
by Roland Schwarz 24 Sep '09

24 Sep '09

Is it legal to mix async and sync function calls? (I was not able to find the answer in the doc.) E.g. socket.async_read_some(buf); socket.write_some(otherbuf); Also when in a blocking sync call, will it be possible to "cancel" it from another thread, e.g. by posting to the io_service which will invoke a close on the socket? Thank you in advance. -- _________________________________________ _ _ | Roland Schwarz aka. speedsnail |_)(_ | sip:speedsnail@ekiga.net | \__) | mailto:roland.schwarz@chello.at ________| http://www.blackspace.at

2 2

[BGL] read_graphviz()/read_graphml() and subgraphs
by Giuseppe Di Guglielmo 24 Sep '09

24 Sep '09

Dear all, I read on the 'read_graphviz()' page in BGL library doc http://www.boost.org/doc/libs/1_40_0/libs/graph/doc/read_graphviz.html * read_graphviz treats subgraphs as syntactic sugar. It does not reflect subgraphs as actual entities in the BGL. Rather, they are used to shorten some edge definitions as well as to give a subset of all nodes or edges certain properties. For example, the DOT graphs digraph { a -> subgraph {b -> c} -> e } and digraph { a -> b -> e ; a -> c -> e ; b -> c} are equivalent. Is this actually true? Can I read sub-graph from DOT description and obtain a subgraph object? http://www.boost.org/doc/libs/1_40_0/libs/graph/doc/subgraph.html Eventually are subgraph supported by 'read_graphml()' function? http://www.boost.org/doc/libs/1_40_0/libs/graph/doc/read_graphml.html Thanks, G.

1 0

[multi_index] Missing mutex lock?
by Anatoly Pinchuk 23 Sep '09

23 Sep '09

Possible traversal and modifications of a safe container iterators list inside safe_mode::detach_equivalent_iterators function are not protected with locking like the following one in safe_iterator_base::detach function. #if defined(BOOST_HAS_THREADS) boost::detail::lightweight_mutex::scoped_lock lock(cont->mutex); #endif Unless some kind of synchronization is provided by callers of the safe_mode API, the list above can be traversed/modified and modified concurrently in BOOST_HAS_THREADS environment. It would be great if somebody can confirm or deny that there is the access synchronization problem. Regards, Anatoly

3 5

Re: [boost] scoped_ptr deleter
by Berserker 22 Sep '09

22 Sep '09

Stewart, Robert wrote: > That change creates multiple, distinct classes. > shared_ptr<T,boost::checked_deleter<T>> is not the same as shared_ptr<T,my_deleter<T>>. > By embedding the deleter in the shared_ptr with type erasure, > shared_ptr<T> is shared_ptr<T> is shared_ptr<T>, regardless of the deleter. Sure and that's the point :) As I wrote, since the "noncopyable nature" of scoped_ptr (shared_ptr is copiable by design), the creation of distinct classes isn't a problem. I think that the "real problem" here is to provide a solution that doesn't require extra memory overhead. _________________________________________________________________ Gossip, Sport, Notizie... Accendi la Messenger TV! http://www.messenger.it/messengerTV.aspx

9 24

Re: [boost] [Boost-users] Parallel BGL status in Boost
by Craig Henderson 22 Sep '09

22 Sep '09

> Nick Edmonds wrote: > >> On Sat, Sep 12, 2009 at 9:42 PM, Nick Edmonds > <ngedmond(a)cs.indiana.edu> wrote: > >> > >>> yet). There's also a very nascent project to do multi-core/highly > >>> multi-threaded BGL, starting from the BGL sources as opposed to > PBGL. > >> > >> Any pointers ? It would be nice if they look at using the map-reduce > >> library (boost candidate) > >> > > It's very early stages so no, no docs/code yet, it's basically some > new PhD students in my lab with me and another post-doc mentoring > them. I would anticipate that map-reduce is too > coarse-grained/BSP-like to capture the fine grained dependencies we > need to capture to get good performance in a memory-bandwidth bound > domain like sparse graphs, but I'll mention it and see if they want to > write a sample algorithm with it and run some numbers. We're > investigating a few different options for organizing/parallelizing the > work, including starting from scratch. > > It would be nice to see how the map-reduce library performs though. > Do you have any performance data for using it on highly multi-threaded > architectures (Sun Niagara, Cray XMT, anything with >8 cores really)? > Hi Nick, the Map/Reduce library is available in the sandbox and in the vault. The performance is as much down to the implementation of the map and reduce tasks as the framework itself. Jose has compared performance of my library with Standford University's Pheonix implementation and the performance is comparable (http://lists.boost.org/Archives/boost/2009/08/155759.php) I have tested the library on MS Windows on servers with 16-cores and performance has scaled well - if you get the input's segregated sufficiently to avoid contention. I don't yet have any benchmarks, but am looking for some suitable algorithms if you're interested in contributing. Regards -- Craig

1 0

Creating a new toolset for System i *SRVPGMs
by Jon Brisbin 22 Sep '09

22 Sep '09

We're integrating our C++ development with our RPG/400 development and since we use Boost on the PC end, we'd really like to use Boost on the AS400/System i integration stuff. I can successfully compile service programs on the 400 that use boost header-only libraries (with some minor tweaking of the Boost source...I'm finding various things that have to be changed to accommodate the 400 compiler) using the "ixlc" compiler. I think what I need to do to use Boost.Build on the 400 is to create a new toolset that is like gcc, but uses the "ixlc" and "ixlclink" commands to compile *MODULEs and *SRVPGMs. I'm just not familiar enough with Boost.Build to figure out how to do this. I'm actually a Java programmer and not even very experienced in C++, though I've been a unix geek for a long time, so I'm very familiar with the build tools. Since the library/file(member) convention of working with these files on the 400 doesn't translate directly across to files on a unix-like filesystem, I'm thinking I'll have to have directories that correspond to libraries and the source file basename that corresponds to the object name. For example, source file: cpplib/mycpptest.cpp would be compiled using "ixlc" like: ixlc -ocpplib/mycpptest -qdbgview=all -qprint (other options) cpplib/ mycpptest.cpp this would create a *MODULE object called "MYCPPTEST" in library "CPPLIB". How would I translate this to a boost build toolset that I could use by writing a Jamfile like the following...? module cpplib/mycpptest : cpplib/mycpptest.cpp ; srvpgm cpplib/mycpptest : cpplib/mycpptest cpplib/myothrmod ; at some point, I'd probably like to specify a default library, but I can probably do that by using variables in my project's root file. Can anyone help me with this, even though you may not have direct experience with the AS400 (it would be great if there were boost developers who worked on or with 400's, though! ;)? Jon Brisbin Portal Webmaster NPC International, Inc.

1 0

[serialization] serialize shared_from_this() pointer
by Zoran Cvetkov 22 Sep '09

22 Sep '09

Does someone have experience serializing a class that inherits from a shared_from_this() pointer? If I just do nothing I am getting 0 pointer during deserialization. What would be the proper syntax for serializing it, if it's needed?

1 0

review request: addition to type_traits library of is_less_comparable<T> and others
by Frédéric Bron 22 Sep '09

22 Sep '09

Hi folks, I would like to propose to your review the following addition to the type_traits library. The addition is attached to this email and also available in the sandbox at https://svn.boost.org/trac/boost/browser/sandbox/type_traits The purpose of the addition is to add type traits to detect if type T is comparable in the sens of <, <=, >, >=, == or != operators, i.e. if t1<t2 has a sens when t1 and t2 are of type T (same for <=, >, >=, ==, !=). The following traits are added: is_equal_to_comparable<T> is_greater_comparable<T> is_greater_equal_comparable<T> is_less_comparable<T> is_less_equal_comparable<T> is_not_equal_to_comparable<T> The names are based on the corresponding names of the standard template library (<functional> header, section 20.3.3 of the standard). The compilation has been tested with g++ 4.3.2 and icpc 10.0 on linux 64 bits, g++ 3.4.4 on cygwin, mingw32 3.4.4 on cygwin. I must add that I did not invent the code (I obtained some help from the boost mailing list) but I put it together in a form that should be acceptable to boost. Regards, Frédéric

8 23

Possible submission: Dynamic library policy loading library?
by Rob Meijer 22 Sep '09

22 Sep '09

In the Open Computer Forensics Architecture library ( http://sourceforge.net/projects/ocfa/ ), a simple template sub library is used for policy loading with shared libraries. This stuff is currently buried in a large library, and it would seem prety usefull to extract this sub library into an enviroment (like boost) where it can be used within a wider scope. To show apptoximately how this sub library is used, I've taken a few lines from a part of OcfaLib that uses this functionality: The below example is used to load an implementation of the abstract TreeGraphFactory class within a loadable library "libtesttreegraph.so" with a constructor function named "constructor" in it. std::string module="testtreegraph"; //Define a type for the constructor. typedef SinglePointerConstructor< TreeGraphFactory, std::map< std::string,misc::Scalar > > CTreegraphType; //Define a type for the policy loader. typedef PolicyLoader<CTreegraphType> PLTreeGraph; //Create a new policy loader object for a given module and constructor function name. PLTreeGraph *mPolicyLoader=new PolicyLoader<CTreegraphType>(module,"constructor"); //Fetch the constructor from the policy loader. CTreegraphType *constructor = mPolicyLoader->constructor(); //Construct an object using the constructor TreeGraphFactory * mActiveFileSystem =(*constructor)(attributes); For more info, the relevant headers in the ocfa source tree are: OcfaLib/inc/misc/PolicyLoader.hpp OcfaLib/inc/misc/VoidToFunction.hpp It probably needs some work on portability and needs more constuctor templates to be fully generically usable, but I feel this has the potential to be a very usefull extention to boost. Do you people feel this should be further explored and submitted as a possible extension for boost? Rob

1 0

Feed pointers to a container, however use the member of the data type which pointer refer to
by 路邓 22 Sep '09

22 Sep '09

Dear All: In the following codes, I feed the container with B*, however I user the member of B as the index. Can somebody explain to me how this work out? And It seems that if smart pointers are feeded into the container, it still works out. #include <boost/config.hpp> /* keep it first to prevent nasty warns in MSVC */ #include <boost/multi_index_container.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/member.hpp> #include <iostream> using namespace boost::multi_index; class B { public: int idx; }; typedef boost::multi_index_container< B*, indexed_by< ordered_unique< BOOST_MULTI_INDEX_MEMBER(B, int, idx) > > >Container; int main() { Container container; B* p1 = new B; B* p2 = new B; p1->idx = 2; p2->idx = 1; container.insert(p1); container.insert(p2); Container::iterator iter; for(iter=container.begin();iter!=container.end();iter++) { B* tmp = (*iter); std::cout << tmp->idx << std::endl; } return 0; } ___________________________________________________________ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/

2 1

Feed pointers to a container, however use the member of the data type which pointer refer to as an index
by 路邓 22 Sep '09

22 Sep '09

Dear All: In the following codes, I feed the container with B*, however I user the member of B as the index. Can somebody explain to me how this work out? And It seems that if smart pointers are feeded into the container, it still works out. #include <boost/config.hpp> /* keep it first to prevent nasty warns in MSVC */ #include <boost/multi_index_container.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/member.hpp> #include <iostream> using namespace boost::multi_index; class B { public: int idx; }; typedef boost::multi_index_container< B*, indexed_by< ordered_unique< BOOST_MULTI_INDEX_MEMBER(B, int, idx) > > >Container; int main() { Container container; B* p1 = new B; B* p2 = new B; p1->idx = 2; p2->idx = 1; container.insert(p1); container.insert(p2); Container::iterator iter; for(iter=container.begin();iter!=container.end();iter++) { B* tmp = (*iter); std::cout << tmp->idx << std::endl; } return 0; } 好玩贺卡等你发，邮箱贺卡全新上线！ ___________________________________________________________ 好玩贺卡等你发，邮箱贺卡全新上线！ http://card.mail.cn.yahoo.com/

1 0

[variant]anyone working on variadic template version?
by Larry Evans 22 Sep '09

22 Sep '09

Is anyone working on a variadic template version of variant, i.e. one that defined as: template<typename... T>class variant; instead of: template < typename T0 = detail::variant::void_ , typename T1 = detail::variant::void_ ... , typename T19 = detail::variant::void_ > class variant; ? I'm thinking of attempting that, but I'd hate to waste time if someone else has already done it or made some progress on it. Although BoostCon09 did have a workshop on CXX0x: http://www.boostcon.com/community/wiki/show/Start/HandsOnCXX0x/ the sandbox directory for that: https://svn.boost.org/svn/boost/sandbox/boost0x didn't appear to use the variadic template feature in variant: https://svn.boost.org/svn/boost/sandbox/boost0x/boost/variant/variant_fwd.h… TIA. -regards, Larry

3 6

[rdb] 0.04
by Jean-Louis Leroy 21 Sep '09

21 Sep '09

I have uploaded a new version of my relational database library to the vault. It implements the ideas I described in another thread. This time it even puts things in a real (odbc) database and retrieves them. I see that 12 have downloaded the previous versions. If you have time please send me feedback. Have you been able to compile it ? Has anybody tried on Unix or with other compilers ? Please note: * It's a work in progress ; for the curious only. * I develop on Windows with Visual Studio Express 2008. There is a solution file in the msvc dir. Nothing bjam works yet. * Currently the doc is the test suite Jean-Louis Leroy

3 8

[rdb] 0.05 - also a fusion problem
by Jean-Louis Leroy 21 Sep '09

21 Sep '09

This upload is mostly for fixing an embarassing bug that the test suite would have detected if I had not put a "return 0" in the middle of it. In addition I have restructured the tests into suites and cases. Jam files begin to work, at least they allow me to build with bjam from the boost tree. While I'm at it, here's the bug, in case somebody has an idea. I have to initially create my fusion::list's of expressions and tables with `push_back(list<>(), val)' instead of just `make_list(val)', otherwise I get access violations. I see in the debugger that the first element of my list is damaged during the next function call, most probably because a reference to a temporary was created along the way. Has anybody had this kind of problem ? I use boost 1.39. J-L

1 0

Problems testing compiling on AS400/i5/whatever
by Jon Brisbin 21 Sep '09

21 Sep '09

I'm using the QSH environment on AS400 and the "ixlc" compiler (basically just CRTCPPMOD), trying to compile the following test program: #include <iostream> #include <boost/foreach.hpp> int main(int argc, char** argv) { std::string hello = "Hello, world!"; BOOST_FOREACH( char ch, hello ) { std::cout << ch << std::endl; } return (EXIT_SUCCESS); } Which results in the following errors: The compilation failed. /home/jbrisbin/include/boost/type_traits/is_member_pointer.hpp Line 000054 "/home/jbrisbin/include/boost/type_traits/ is_member_pointer.hpp", line 54.63: CZP0403(30) "template <class T, class U> struct boost::is_member_pointer<U T::* const>" is alread ERROR 1 001 /home/jbrisbin/include/boost/type_traits/is_member_pointer.hpp Line 000055 "/home/jbrisbin/include/boost/type_traits/ is_member_pointer.hpp", line 55.63: CZP0403(30) "template <class T, class U> struct boost::is_member_pointer<U T::* volatile>" is alr ERROR 1 001 /home/jbrisbin/include/boost/type_traits/is_member_pointer.hpp Line 000056 "/home/jbrisbin/include/boost/type_traits/ is_member_pointer.hpp", line 56.63: CZP0403(30) "template <class T, class U> struct boost::is_member_pointer<U T::* const volatile>" ERROR 1 001 2 000051 The full text of the error complains that these are already defined. Does anyone have pointers or tricks that could point me in the right direction to compile programs that use header-only Boost libs on the AS400? Any help would be appreciated! :) Jon Brisbin Portal Webmaster NPC International, Inc.

1 0

[PBGL] and [MTGL]
by Cosimo Calabrese 21 Sep '09

21 Sep '09

Hi to all, I open this discussion as a "branch" of "[BGL] Multithread problem inserting edges and exploring the same graph". Can someone tell me if the PBGL and MTGL can help me? I report my problem below, for sake of comfort. Thanks in advance, Cosimo Calabrese. ************************************************** I've a problem on BGL. My environment is WinXP, Visual Studio 2005, Boost 1.37. I'm trying to use BGL in the following way. I've a single graph in my application, that is an adjacency_list< vecS, vecS, ... >, and I've 2 kind of threads that work on the graph: - some "Explorer" threads, that executes a Dijkstra's algorithm repeatedly; - some "Integrator" thread, that call the add_edge() function repeatedly. The program often crashes, because it cannot dereference some graph elements, some auto_ptr... The crash isn't sistematic, so I think there's a concurrency problem. [...] **************************************************

2 1

Python 3 support has landed on boost trunk
by Stefan Seefeld 21 Sep '09

21 Sep '09

Hi there, as some of you may know, Haoyu Bai has worked over the summer on Python 3 support for Boost.Python. This work happened on a branch, which I merged back into trunk last night. Now we need to set up testers to run the testsuite with some Python 3 variant, as that is a new platform to track. I will see whether I can set one up on one of my machines. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...

3 4

[filesystem] Compatibility with STLPort
by Andrey Semashev 21 Sep '09

21 Sep '09

Hi, I've created ticket #3241 some time ago, with a patch attached. It's about Boost.Filesystem compatibility with STLPort expression templates feature. So far no activity has appeared on it, although the fix is trivial. Is it OK if I go ahead and commit the patch? PS: Ticket URL is https://svn.boost.org/trac/boost/ticket/3241

3 6

unsigned long vs unsigned int vs std::size_t (32b platform)
by Christoph Mathys 21 Sep '09

21 Sep '09

Hello! First: I'm working on 32b Linux (gcc 4.2.4) and 32b XP (Visual Studio 9 SP1). I tried to switch from stdint.h to boost/cstdint.hpp, but had to find out that this is not as straight forward as I thought. The compilers handle 'unsigned int' and 'unsigned long' as different types, even though on 32b it is AFAIK the same type. This by itself is OK, but gcc and VS9 seem to disagree in where it comes to defining std::size_t. The result is that the code at the end compiles on visual studio, but not on gcc: asdf.cpp: In function ‘void someFunc(size_t)’: asdf.cpp:6: error: redefinition of ‘void someFunc(size_t)’ asdf.cpp:5: error: ‘void someFunc(uint32_t)’ previously defined here asdf.cpp: In function ‘int main(int, char**)’: asdf.cpp:16: error: call of overloaded ‘someFunc(long unsigned int&)’ is ambiguous asdf.cpp:4: note: candidates are: void someFunc(uint16_t) asdf.cpp:5: note: void someFunc(uint32_t) In the stdint.h we used for visual studio previously, this error did not occur because uint32_t was typedefd to 'unsigned __int32'. Now, the questions are: - should boost::uint32_t be typedefed to the same thing that std::size_t is on 32b platforms? - Is the size of std::size_t fixed or dependant on the platform it is used on? - Did I do something wrong and there is a much better way of doing it avoiding those problems in the first place? #include <boost/static_assert.hpp> #include <boost/cstdint.hpp> void someFunc(boost::uint16_t) { } void someFunc(boost::uint32_t) { } void someFunc(std::size_t) { } int main(int, char**) { BOOST_STATIC_ASSERT(sizeof (unsigned long) == sizeof (unsigned int)); BOOST_STATIC_ASSERT(sizeof (unsigned long) == sizeof (std::size_t)); unsigned long ul = 42; unsigned int ui = 1337; std::size_t st = 2; someFunc(ul); someFunc(ui); someFunc(st); return 0; }

5 7

[repost][multi_index][serialization][Huang-Vista-x86_32_intel] Help with weird test failure
by joaquin＠tid.es 21 Sep '09

21 Sep '09

Hi, my first attempt went unanswered, reposting in the hope it'll bring more attention this time around: Huang-Vista-x86_32_intel toolset, which runs Intel 11.1 for Window, has this weird error on the serialization test for Boost.MultiIndex: Running 1 test case... ../libs/multi_index/test/test_serialization_template.hpp(82): error in "test_main_caller( argc, argv )": check all_indices_equal(m,m2) failed unknown location(0): fatal error in "test_main_caller( argc, argv )": std::exception: invalid signature (http://tinyurl.com/nd89x2 ) What I find weird is the throwing of invalid_signature, a Boost.Serialization exception that, according to docs, indicates that the beginning of a serialization file is not correct. I can't see how a problem with serializing multi_index_containers can lead to a file signature error. Any clue? Maybe the toolset maintainer can run this manually and provide more info? Thank you in advance, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

1 0

[Foreach] Proposal to simplify using Boost.Foreach with maps
by Chris Purcell 20 Sep '09

20 Sep '09

As documented in the manual ("Pitfalls"), BOOST_FOREACH is a little awkward to use with associative containers. I've used the following in the past to simplify my own code, and wondered if it was suitable to add to the Boost Foreach library proper. std::map<int, int> my_map; BOOST_FOREACH_PAIR(int key, int value, my_map) std::cout << key << " : " << value << "\n"; The BOOST_FOREACH_PAIR macro is a clone of the BOOST_FOREACH macro with an extra for loop in it to assign both first and second from each pair in the map. If either is not wanted, ignore from Boost.Tuples can be used: std::vector<int> values; BOOST_FOREACH(boost::tuples::ignore, int value, my_map) values.push_back(value); References can be used just as with BOOST_FOREACH, to create a modifying loop: BOOST_FOREACH_PAIR(int key, int& value, my_map) value += key; There are a few alternatives to my solution that I have seen: (1) Predeclare a pair and use it each time around the loop: std::pair<int, int> kv; BOOST_FOREACH(kv, my_map) std::cout << kv.first << " : " << kv.second << "\n"; This adds overhead from copying pairs, and does not give meaningful names to the two halves of the pair. It also has no simple extension to a mutating loop that I am aware of. (2) Typedef the value type of the map before the loop, and use .first and .second: typedef std::pair<const int, int> KeyValue; BOOST_FOREACH(KeyValue const& kv, my_map) std::cout << kv.first << " : " << kv.second << "\n"; This removes the copying overhead, and is easy to change to a mutating loop, but still does not meaningfully name the key and value (3) Use Boost.Tuple's tie to turn the single assignment of BOOST_FOREACH into a double assignment: int key, value; BOOST_FOREACH(boost::tie(key, value), my_map) std::cout << key << " : " << value << "\n" This gives meaningful names, but has copying overhead (albeit not in this simple example). It also has no simple extension to a mutating loop that I am aware of. The key objection to all of these alternatives, from my point of view, is simply that they are unnecessarily complicated. The new macro is much cleaner. Implementation of BOOST_FOREACH_PAIR is simple: turn the innermost assignment loop of BOOST_FOREACH into a pair of loops, one assigning key, one value. Cheers, Chris Purcell

6 11

[polygon] late review
by Gordon Woodhull 20 Sep '09

20 Sep '09

Hi all, Sorry this is late - I intended to participate in the discussion, but the review schedule happened to intersect with an offline vacation. (Plus day job, school starting, etc.) Thank you, Luke, for submitting what I think is a very good start toward a Boost geometry library. I do not think the library is ready for inclusion in Boost at this time, but I believe it will be with further improvements. I would almost vote for acceptance with conditions, but the list is long and I think the concepts merit more discussion. Unfortunately I have not had time to take an in-depth look at the library; I have read some of the documentation and examples and it looks useable. So this is mostly a non-technical review of the issues raised by others. Also I offer a bit of "meta-review" of the review process for libraries that will continue to evolve and merge with other libraries. My application domain is mainly graph drawing (network visualization) but I might also use this in 2D screen graphics and games. For these purposes, the restriction to two dimensions is acceptable, and even the restriction to integer coordinates is mostly acceptable. However, I think the library name should reflect these restrictions. It will be some time (if ever) before a library can claim to be The geometry or polygon library. Boost has no merge process (if that's even possible), and neither Polygon nor GGL subsumes the other, so I think they should eventually be accepted in parallel, and merge concepts and algorithms over time. As I see it, this library provides two major contributions: 1. A set of concepts for VLSI and other 45/90 degree applications which can in the future be extended or bridged to other geometric problem domains, e.g. GIS, 3D, n-dimensional. 2. An extremely robust and (I believe) efficient polygon intersection algorithm. The interface still needs some work, but the concepts are a valuable first pass at defining this domain. I want to see some system of libraries that supports rectangles through arcs all the way up to splinegons. This isn't that, but I am patient. I will be interested to compare the advantages of concepts for polygons with holes versus the runtime version in GGL. I don't agree that accepting a library where the concepts/interface are incomplete or even wrong will pollute a future generalized geometry library. This library will just have to improved over time, and influenced by libraries from other domains. To mention just one specific interface problem: I don't like rect - int meaning shrink the rectangle. I think that everyone is going to have strong opinions about what operators they like and dislike and I hope that some future geometry library will allow choosing different sets for different domains. The intersection algorithm is very, very cool and I hope the ideas can be extended someday by someone to provide robust intersection of arcs and splines. I don't yet understand whether this is possible. I agree with those who would like to see lazier evaluation to run the intersection algorithm on as much as possible. Luke and Barend, I'm sorry but I don't believe either of your benchmarks. I think you are choosing problems that suit each of your libraries. This is understandable, but we will need to build a comprehensive suite of examples from many different domains to learn which algorithms are actually faster in which situations. Meta-review I admire the Boost process for protecting authorial control over libraries. However, one consequence is that two very important requirements, maintenance and cooperation, are only ensured indirectly by vigorous debate. 1. Maintenance. This is not really addressed by the Boost rules or review process, except to remind authors that they will be responsible for maintenance or for finding a new maintainer. There is no way to compel authors to respond to their users except for the threat of library removal which IIUC has almost never happened. So one of my essential criteria in reviewing a library - I've only reviewed one other library but followed many other reviews closely - is the attitude of the author toward changes requested. Users are inevitably going to have new requirements. Luke definitely seems willing to make the changes that are needed to get this into Boost, and I trust that he'll continue to help it adapt. I am slightly concerned that Intel will not allow the library to depend on Boost because I think that will slow down improvement. In particular I think operator customization and lazy evaluation would be helped by using Proto. I hope Intel will allow this. Or maybe that's the scope of a different library. 2. Cooperation. Boost has no rules or process for making libraries work together, never mind merging them. Maybe there is some work to be done here. But people will naturally want to make their libraries compatible if they're under the same umbrella. Competition is also a healthy human drive, but it's especially productive when there is some basis of cooperation, as I think there is between Luke and Barend, despite how nerves may have frayed during this review. I hope that both libraries are accepted, when ready, and that the authors and others interested in a "universal" Boost geometry library work to find the commonalities and connections. Fervently waiting, Gordon

2 2

Formal Review: Boost.Polygon starts today August 24, 2009
by Fernando Cacciola 20 Sep '09

20 Sep '09

Dear Developers, The formal review of the Boost.Polygon library by Lucanus Simonson starts today, August 24, 2009 and will finish September 2, 2009. I really hope to see your vote and your participation in the discussions on the Boost mailing lists! --------------------------------------------------- About the library: The boost polygon library provides algorithms focused on manipulating planar polygon geometry data. Specific algorithms provided are the polygon set operations (intersection, union, difference, disjoint-union) and related algorithms such as polygon connectivity graph extraction, offsetting and map-overlay. These so-called Boolean algorithms are of significant interest in GIS (Geospatial Information Systems), VLSI CAD as well al other fields of CAD, and many more application areas, and providing them is the primary focus of this library. The polygon library is not intended to cover all of computational geometry in its scope, and provides a set of capabilities for working with coordinates, points, intervals and rectangles that are needed to support implementing and interacting with polygon data structures and algorithms. Specifically, 3d and non-Cartesian/non-planar geometry is outside of the scope of the polygon library The design philosophy behind the polygon library was to create an API for invoking the library algorithms it provides on user geometry data types that is maximally intuitive, minimally error-prone and easy to integrate into pre-existing applications. C++-concepts based template meta-programming combined with generic operator overloading meets these design goals without sacrificing the runtime or memory efficiency of the underlying algorithms. This API makes the following code snippet that operates on non-library geometry types possible: void foo(list<CPolygon>& result, const list<CPolygon>& a, const list<CPolygon>& b, int deflateValue) { CBoundingBox domainExtent; using namespace boost::polygon::operators; boost::polygon::extents(domainExtent, a); result += (b & domainExtent) ^ (a - deflateValue); } The source is available at http://svn.boost.org/svn/boost/sandbox/gtl/boost/polygon/ And the documentation is at http://svn.boost.org/svn/boost/sandbox/gtl/doc/index.htm --------------------------------------------------- Please always state in your review, whether you think the library should be accepted as a Boost library! Additionally please consider giving feedback on the following general topics: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? Best Regards Fernando Cacciola Review Manager

30 142

SQL client library ?
by Jean-Louis Leroy 19 Sep '09

19 Sep '09

What's the situation with SQL client libraries (similar to Rogue Wave's DBTools.h++) ? I know that there's a boost_sql_cli in the Vault, but it doesn't seem to make much progress. I have also heard about plans to bring Soci into Boost. Thanks, Jean-Louis

19 42

Error building Boost.MPI on WinXP with MPICH2
by Craig Henderson 19 Sep '09

19 Sep '09

I am trying to build Boost.MPI for the first time. I've downloaded and installed MPICH2 on my Windows XP machine, and added "using mpi ;" to tools/build/v2/user-config.jam file, and the mpich2/bin to the path. When I run bjam, I get the following output. ------------------------------------------------------ C:\root\Development\Library\Boost\boost_1_39_0>..\bjam --with-mpi The system cannot find the path specified. The system cannot find the path specified. The system cannot find the path specified. MPI auto-detection failed: unknown wrapper compiler mpic++ Please report this error to the Boost mailing list: http://www.boost.org You will need to manually configure MPI support. WARNING: No python installation configured and autoconfiguration failed. See http://www.boost.org/libs/python/doc/building.html for configuration instructions or pass --without-python to suppress this message and silently skip all Boost.Python targets Building C++ Boost. ------------------------------------------------------ The environment runs for building all other Boost libraries. Any ideas what's wrong or how to diagnose the problem? Thanks -- Craig Craig Henderson http://www.craighenderson.co.uk http://www.siteupdatenotification.com

1 0

cannot pass objects of non-POD type ‘class boost::detail::shared_count’ through ‘...’; call will abort at runtime
by Dave Steffen 19 Sep '09

19 Sep '09

Hi Folks [ Sorry if this gets posted twice; my company email server changed my email address, and I think my first post got bounced. Argh.] Just tried to compile my project with GCC 4.3 and Boost 1.40. (It compiles and works just fine with Boost 1.38.) As part of a home-built thread-locking shared pointer thing, we have this code: /// Constructor from pointer to complete type template<class Y> explicit shared_locking_ptr( Y * p ): px( p ), pn( p ) // Y must be complete { boost::detail::sp_enable_shared_from_this( pn, p, p ); } which now produces this result: ../util/thread/shared_locking_ptr.hpp:57:9: warning: cannot pass objects of non-POD type ‘class boost::detail::shared_count’ through ‘...’; call will abort at runtime In Boost 1.38, the relevent code in shared_ptr.hpp was this AFAICT: #ifdef _MANAGED [ ... ] #else // _MANAGED [...] inline void sp_enable_shared_from_this( shared_count const & /*pn*/, ... ) { } #endif // _MANAGED In 1.40, it's been changed to #ifdef _MANAGED [...] #else // _MANAGED inline void sp_enable_shared_from_this( ... ) { } #endif // _MANAGED Does anyone know why the change? Has anybody else seen this problem? It seems to me that GCC is correct, and that although it's an empty function so it doesn't matter anyway, the earlier version is preferable. Alternately, does anyone know of a way to silence GCC's warning? -- Dave Steffen, Ph.D - Software Engineer Numerica Corporation (www.numerica.us <http://www.numerica.us/> ) 4850 Hahns Peak Drive, Suite 200 Loveland, Colorado 80538 main (970) 461-2000 x 227 direct (970) 612-2327 fax (970) 461-2004 Email: dave.steffen(a)numerica.us

4 4

[iostreams][bug] Uncaught exception in destructor when using file_descriptor
by Sylvester-Bradley, Gareth 19 Sep '09

19 Sep '09

https://svn.boost.org/trac/boost/ticket/2932 I hope it's appropriate to ping the list about this issue, which was reported 4 months ago and has not been fixed in 1.39.0 or on the trunk. If closing a file descriptor fails, file_descriptor::impl::~impl() (or file_descriptor_impl::~file_descriptor_impl() on the trunk) throws an exception. This has the potential to happen during stack unwinding, causing immediate std::terminate(). Since the fix appears to be a trivial addition of try { /*...*/ } catch (...) {} it'd be a shame if this wasn't fixed in 1.40.0. Cheers, Gareth ************************************************************************ The information contained in this message or any of its attachments may be confidential and is intended for the exclusive use of the addressee(s). Any disclosure, reproduction, distribution or other dissemination or use of this communication is strictly prohibited without the express permission of the sender. The views expressed in this email are those of the individual and not necessarily those of Sony or Sony affiliated companies. Sony email is for business use only. This email and any response may be monitored by Sony to be in compliance with Sony's global policies and standards

2 2

Policy related to the time between a library is accepted and released?
by vicente.botet 18 Sep '09

18 Sep '09

Hi, On "Past Review Results and Milestones" (http://www.boost.org/community/review_schedule.html) we see the following There are 3 libraries accepted more than 1 year ago that are commited on trunk but not yet on release . * Property Tree Marcin Kalicinski May 20, 2006 * Forward (fast-track) Tobias Schwinger John Torjo December 3, 2007 - December 7, 2007 * Factory (fast-track) Tobias Schwinger John Torjo December 17, 2007 - December 21, 2007 There are 2 libraries accepted more than 1 year ago but not yet commited on trunk. * Time Series Eric Niebler August 17, 2007 * Floating Point Utilities Johan Råde Mars 8, 2008 There are 2 libraries accepted provisionally more than 1 year ago but without any outcome. * Switch Steven Watanabe January 13, 2008 * Phoenix Joel de Guzman Hartmut Kaiser September 21, 2008 - September 30, 2008 I understand that the authors have a lot of other things to do, but one year seems to me a good delay. Should't Boost have a policy related to the time between a library is accepted and released? If yes, which one? Best regards, Vicente

1 0

Need help with workaround for MSVC bug
by Emil Dotchevski 18 Sep '09

18 Sep '09

On MSVC, the following correct code produces error C2896: 'void operator ||(T,void (__cdecl *)(tag<X>))' : cannot use function template 'void bar(tag<X>)' as a function argument. struct foo { }; template <int X> struct tag { }; template <int X> void bar( tag<X> ) { } template <class T,int X> void operator||(T, void(*)(tag<X>)) { } int main() { foo()||bar<1>; } My goal is to have an operator|| overload that deduces tag<X> implicitly, but without using parenthesis, that is, foo()||bar<1>() wouldn't be satisfactory. Doesn't seem possible, but still I decided to ask. Any ideas? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

6 8

[type_traits] warning free is_signed on g++
by Edd Dawson 18 Sep '09

18 Sep '09

Hello, When using boost::is_signed<> on types such as unsigned int and unsigned long, various recent versions of g++ (MinGW 4.4.0 and Apple's 4.0.1, at least) spit out a warning: warning: comparison of unsigned expression < 0 is always false Would there be any harm in changing boost::detail::is_signed_helper in boost/type_traits/is_signed.hpp as follows? template <class T> struct is_signed_helper { typedef typename remove_cv<T>::type no_cv_t; // BOOST_STATIC_CONSTANT(bool, value = (static_cast<no_cv_t>(-1) < 0)); BOOST_STATIC_CONSTANT(bool, value = (static_cast<no_cv_t>(-1) < 1)); }; This change gets rid of the warnings emitted by g++. Kind regards, Edd

3 2

Boost on MSVC without Microsoft Extensions
by Craig Henderson 17 Sep '09

17 Sep '09

I am trying to build a client program using Boost on MSVC8 with the "Disable Language Extensions" /Za compilation flag. visual.hpp contains the following code // disable Win32 API's if compiler extentions are // turned off: // #ifndef _MSC_EXTENSIONS # define BOOST_DISABLE_WIN32 #endif win32.hpp contains: #ifndef BOOST_DISABLE_WIN32 // WEK: Added #define BOOST_HAS_FTIME #define BOOST_WINDOWS 1 #endif So, the preprocessor defines BOOST_DISABLE_WIN32 and doesn't define BOOST_WINDOWS. This doesn't sound right, and causes problems with Boost.ASIO where the Windows header files are conditionally included using #if defined(BOOST_WINDOWS) || defined(__CYGWIN__) which clearly evaluates FALSE. I consider this a bug in the boost config compiler detection rather than the asio library. Has anyone compiled with /ZA on MSVC? Thanks -- Craig Craig Henderson <http://craighenderson.co.uk/> http://www.craighenderson.co.uk http://www.siteupdatenotification.com

2 1

[task] new version 0.3.0
by k-oli＠gmx.de 17 Sep '09

17 Sep '09

I've uploaded a new version of boost.task - I hope someone will give me some feedback. regards, Oliver

1 0

cannot pass objects of non-POD type ‘class boost::detail::shared_count’ through ‘...’; call will abort at runtime
by Dave Steffen 17 Sep '09

17 Sep '09

Peter Dimov wrote: > I wrote: >> >>( Just tried to compile my project with GCC 4.3 and Boost 1.40. (It >> compiles and works just fine with Boost 1.38.) >> >> As part of a home-built thread-locking shared pointer thing, we have >> this code: [...] > > The signature of sp_enable_shared_from_this has changed, it now takes a > pointer to a shared_ptr as its first argument. Look at the current > shared_ptr constructor: > > template<class Y> > explicit shared_ptr( Y * p ): px( p ), pn( p ) // Y must be complete > { > boost::detail::sp_enable_shared_from_this( this, p, p ); > } > > Relying on implementation details has its maintenance costs. :-) Yeah. There are actually much better ways to do this now, like Boost threads and some other things, that weren't available when we started the project. It's also true that some refactoring would make the whole point moot, but I was really hoping to avoid tackling that on the current contract. > You'll probably need to refactor shared_locking_ptr to contain (or > privately derive from) a shared_ptr. ... which, arguably, we could have done in the first place. I'm inclined to refactor the whole issue out of our code at this point. :-) Anyway, thanks for the reply. I'm off to refactor. -- Dave Steffen - Software Engineer Numerica Corporation (www.numerica.us <http://www.numerica.us/> ) 4850 Hahns Peak Drive, Suite 200 Loveland, Colorado 80538 main (970) 461-2000 x 227 direct (970) 612-2327 fax (970) 461-2004 Email: dave.steffen(a)numerica.us k

1 0

[DateTime] valgrind warns on uninitialized jump
by Christoph Duelli 17 Sep '09

17 Sep '09

[from strings_from_facet.hpp, line 52] for (int m=0; m < 12; m++) { tm tm_value; tm_value.tm_mon = m; stringstream_type ss; ostream_iter_type oitr(ss); std::use_facet<time_put_facet_type>(locale).put(oitr, ss, ss.fill(), &tm_value, &*outfmt.begin(), &*outfmt.begin()+outfmt.size()); months.push_back(ss.str()); } valgrind (3.5.0, run on Linux, gcc 4.1.2, libstdc++ 6.0.8) reports: ==13166== 1 errors in context 1 of 1: ==13166== Conditional jump or move depends on uninitialised value(s) ==13166== at 0x41D793D: strftime_l (in /lib/libc-2.4.so) ==13166== by 0x40EE600: std::__timepunct<char>::_M_put(char*, unsigned int, char const*, tm const*) const (in /usr/lib/libstdc++.so.6.0.8) ==13166== by 0x40AC9DA: std::time_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::do_put(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, tm const*, char, char) const (in /usr/lib/libstdc++.so.6.0.8) ==13166== by 0x40AAD95: std::time_put<char, std::ostreambuf_iterator<char, std::char_traits<char> > >::put(std::ostreambuf_iterator<char, std::char_traits<char> >, std::ios_base&, char, tm const*, char const*, char const*) const (in /usr/lib/libstdc++.so.6.0.8) The "error" goes away when tm_value.tm_hour is initialized to 0. (No idea why. Might be a bug in libstdc++) Best regards

1 0

Formal Review of Boost.Polygon is halfway through and no actual reviews so far
by Fernando Cacciola 17 Sep '09

17 Sep '09

Dear Developers, The formal review of the Boost.Polygon is halfway through and, while there was some useful discussion, there are still no "actual" reviews (where you clearly vote for inclusion and rejection). If you are interested in a geometric oriented library please try to make the time to post a formal review by the end of September 2 :) Best regards Fernando Cacciola Review Manager

4 7

Boost Review - changes to code being reviewed during the review?
by Paul A. Bristow 17 Sep '09

17 Sep '09

During most reviews, authors make changes to the code being reviewed. Some have questioned if this is 'allowed'. IMO, this is not only allowed but highly desirable - otherwise we will never get anywhere! But it can lead to confusion about exactly what is being reviewed. Now that we have SVN that keeps all changes and allows reasons to be recorded in the log, would it be useful for reviewers to quote the revision of the code that they are reviewing? Reviewers might include updates to say if the authors changes had solved problems, or changed their views. Paul --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

1 0

Graph cut questions
by David Doria 17 Sep '09

17 Sep '09

1) If I do this: (with any of the max_flow algorithms, kolmogorov is just used as an example) double flow = kolmogorov_max_flow(g, SourceNode, SinkNode); I get the value of the max flow, but how do I tell which nodes of g belong to the "source side" of the graph and which nodes belong to the "sink side"? (thinking of it as a min cut rather than a max flow problem) 2) Is it possible to tell the max flow algorithm to use multiple sources/sinks? 3) The max_flow functions seem to require a source and sink to be specified. Shouldn't you be able to find the minimum cut that partitions the graph into two parts even without specifying a source/sink? 4) Currently you must use a bidirectional graph, and specify an edge_reverse_t in the graph traits, then set the reverse edge for every edge. a) this is pretty complicated for someone who is unfamiliar with generic programming. b) If an undirected graph is used, the algorithm should automatically take care of adding these reverse edges if they are required for the cut to be performed. Can these be considered as feature requests if they are not currently possible? I have not found a more promising graph library for c++, so it would be nice if BGL could be molded into the one everyone would like to use! Thanks, David

2 4

Re: [boost] [GIL] image rescale algorithms
by Est 16 Sep '09

16 Sep '09

Nicolas, One last, small thing. I would rename bicubic_filter in filters.hpp to mitchell_filter. Bicubic filter is a common name for bspline or photoshop style filters and mitchell is different. I think rgba32f_pixel_t is a good model for hdr pixels. I don't see the 0..1 range in floating point channels as limits. And GIL does not enforce them in any way. They only define a mapping between integer and floating point channels. In this case (rescale), clamping is an "artifact" of using integer channels and filters with possibly negative weights. I did some informal profiling, on a dual core machine, using the bicubic filter, I got this Big images: rescale serial took 9167.86 milliseconds (9.16786 sec) rescale parallel took 5055.94 milliseconds (5.05594 sec) Small images: rescale serial took 1923.46 milliseconds (1.92346 sec) rescale parallel took 1104.4 milliseconds (1.1044 sec) Est.

2 1

[GIL] image rescale algorithms
by Nicolas Lelong 16 Sep '09

16 Sep '09

Hi, I'm still working on updating my image management codebase, and I noticed that GIL does come only with by a very limited image rescaling/resampling algorithm (in gil/extension/numeric/resample.hpp) which does proper filtering for upsampling an image. As I need more robust image resampling, I came up with a source code for GIL, inspired by FreeImage implementation<http://freeimage.cvs.sourceforge.net/viewvc/freeimage/FreeImage/Source/Free…>; this code is available here :: http://code.google.com/p/rotoglup-scratchpad/source/browse/trunk/#trunk/rtg… This implementation is certainly not as generic as it could be, and could certainly benefit from 'gil concept checking' and various improvements ; I tried to make the code more 'readable' than 'efficient', and as I'm not really at ease with template metaprogramming, I may have missed a few points. For example, I think the mechanism I use to select the intermediate pixel format (used to store the averaged pixels during resizing) may be improved, and that there must be a way to let the user select a better pixel format if needed. I came up with virtual rescale view type, that allows to seamlessly rescale virtual views of any kind - it is not very efficient, but can be proved useful. I tried, as much as possible, to provide access to separable rescale functions (X & Y) so that users can control when/how (or whether) they should allocate the intermediate view for image rescaling. Feel free to use this work, and I'd be very happy to have some feedback on things that could be improved. The main functions defined are, in rescale.hpp<http://code.google.com/p/rotoglup-scratchpad/source/browse/trunk/rtgu/image…>:: // horizontal rescale only, rescale src view into dst view, matching dst view width template <typename SrcView, typename DstView, typename Filter> inline void rescale_cols(const SrcView& src, const DstView& dst, const Filter& filter); // vertical rescale only, rescale src view into dst view, matching dst view height template <typename SrcView, typename DstView, typename Filter> inline void rescale_rows(const SrcView& src, const DstView& dst, const Filter& filter); // rescale src view into dst view, matching dst view dimensions template <typename SrcView, typename DstView, typename Filter> inline void rescale(const SrcView& src, const DstView& dst, const Filter& filter); in rescale_any_view.hpp<http://code.google.com/p/rotoglup-scratchpad/source/browse/trunk/rtgu/image…>:: template <typename ViewTypes, typename Filter> inline void rescale_any_view(any_image_view<ViewTypes>& src, any_image_view<ViewTypes>& dst, const Filter& filter); in rescale_virtual_view.hpp<http://code.google.com/p/rotoglup-scratchpad/source/browse/trunk/rtgu/image…>:: // view factories template <typename SourceView, typename Filter> typename rescale_x_view_type<SourceView>::view_t rescale_x_view(SourceView const& view, typename SourceView::coord_t dst_width, const Filter& filter); template <typename SourceView, typename Filter> typename rescale_y_view_type<SourceView>::view_t rescale_y_view(SourceView const& view, typename SourceView::coord_t dst_height, const Filter& filter); template <typename SourceView, typename Filter> typename rescale_view_type<SourceView>::view_t rescale_view(SourceView const& view, typename SourceView::coord_t dst_width, typename SourceView::coord_t dst_height, const Filter& filter); and a few filters<http://code.google.com/p/rotoglup-scratchpad/source/browse/trunk/rtgu/image…>are provided. Cheers, Nicolas. **

2 4

Boost regression failure
by Christopher Jefferson 16 Sep '09

16 Sep '09

I hope I have reported this problem to the right place, apologises if I am wrong. I am currently unable to execute the regression tester (run.py). The important part of the error seems to be: error: Unable to find file or target named error: 'test_check.cpp' error: referred from project at error: '../libs/serialization/test' It was suggested on IRC this was introduced by: r56224 | ramey | 2009-09-16 00:23:51 +0400 (Wed, 16 Sep 2009) | 2 lines I enclose my full bjam.log: notice: found boost-build.jam at /Users/hudson/temp-test/boost/boost- build.jam notice: loading Boost.Build from /Users/hudson/temp-test/tools_bb notice: Searching /etc /Users/hudson /Users/hudson/temp-test/tools_bb / Users/hudson/temp-test /Users/hudso n/temp-test/tools_bb /Users/hudson/temp-test/tools_bb/kernel /Users/ hudson/temp-test/tools_bb/util /Users/ hudson/temp-test/tools_bb/build /Users/hudson/temp-test/tools_bb/ tools /Users/hudson/temp-test/tools_bb/co ntrib /Users/hudson/temp-test/tools_bb/. for site-config configuration file site-config.jam . notice: Loading site-config configuration file site-config.jam from / Users/hudson/temp-test/tools_bb/site- config.jam . notice: Searching /Users/hudson /Users/hudson/temp-test/tools_bb / Users/hudson/temp-test /Users/hudson/tem p-test/tools_bb /Users/hudson/temp-test/tools_bb/kernel /Users/hudson/ temp-test/tools_bb/util /Users/hudso n/temp-test/tools_bb/build /Users/hudson/temp-test/tools_bb/tools / Users/hudson/temp-test/tools_bb/contrib /Users/hudson/temp-test/tools_bb/. for user-config configuration file user-config.jam . notice: Loading user-config configuration file user-config.jam from / Users/hudson/user-config.jam . notice: will use '/usr/bin/g++' for darwin, condition <toolset>darwin-4.0.1 notice: using strip :: <toolset>darwin-4.0.1 :: /usr/bin/strip notice: using archiver :: <toolset>darwin-4.0.1 :: /usr/bin/libtool notice: available sdk :: <toolset>darwin-4.0.1/<macosx- version>10.3 :: /Developer/SDKs/MacOSX10.3.9.sdk notice: available sdk :: <toolset>darwin-4.0.1/<macosx- version>10.4 :: /Developer/SDKs/MacOSX10.4u.sdk notice: available sdk :: <toolset>darwin-4.0.1/<macosx- version>10.5 :: /Developer/SDKs/MacOSX10.5.sdk ===============MPI Auto-configuration=============== Found recent LAM-MPI or Open MPI wrapper compiler: mpic++ MPI compilation flags: -D_REENTRANT -I/usr//include MPI link flags: -Wl,-u,_munmap -Wl,-multiply_defined,suppress -L/usr// lib -lmpi_cxx -lmpi -lopen-rte -lope n-pal -lutil MPI build features: <define>_REENTRANT <include>/usr//include <library-path>/usr//lib <find-shared-library>mpi_cxx <find-share d-library>mpi <find-shared-library>open-rte <find-shared-library>open- pal <find-shared-library>util <linkf lags>-Wl,-u,_munmap <linkflags>-Wl,-multiply_defined,suppress MPI launcher: mpirun -np ==================================================== notice: iostreams: using prebuilt zlib notice: iostreams: using prebuilt bzip2 notice: [python-cfg] Configuring python... notice: [python-cfg] Checking interpreter command "python"... notice: [python-cfg] running command '"python" -c "from sys import *; print 'version=%d.%d\nplatform=%s\np refix=%s\nexec_prefix=%s\nexecutable=%s' % (version_info [0],version_info[1],platform,prefix,exec_prefix,ex ecutable)" 2>&1' notice: [python-cfg] ...requested configuration matched! notice: [python-cfg] Details of this Python configuration: notice: [python-cfg] interpreter command: "python" notice: [python-cfg] include path: "/System/Library/Frameworks/ Python.framework/Versions/2.5/include/pyt hon2.5" notice: [python-cfg] library path: "/System/Library/Frameworks/ Python.framework/Versions/2.5/lib/python2 .5/config" "/System/Library/Frameworks/Python.framework/Versions/2.5/ lib" notice: [python-cfg] framework directory is "/System/Library/ Frameworks/Python.framework" warning: Building Boost.Regex with the optional Unicode/ICU support disabled. note: Please refer to the Boost.Regex documentation for more information note: this is a strictly optional feature. warning: Graph library does not contain optional GraphML reader. note: to enable GraphML support, set EXPAT_INCLUDE and EXPAT_LIBPATH to the note: directories containing the Expat headers and libraries, respectively. error: Unable to find file or target named error: 'test_check.cpp' error: referred from project at error: '../libs/serialization/test'

2 1

doxygen doc / STL container unit test
by Stefan Strasser 16 Sep '09

16 Sep '09

I have two questions regarding boost library development: 1. this page: http://www.boost.org/doc/libs/1_35_0/doc/html/boostbook/getting/started.html explains how to set up the boost documentation system and write BoostBooks. what I find missing is how to generate the typical boost class synposis with doxygen. I also can't find doxygen configuration files or anything of that sort in the boost tree. how do you go about integrating automatically generated documentation into a BoostBook? 2. boost implements quite a few STL containers. is there a unit test that can test my STL container for conformity? say, I have a container that models the concept of a std::list, I'd like to change a typedef to my type, run the test and know that it behaves like advertised. Does anything like that already exist? thank you

5 10

[1.40.0] Compilation errors in Visual Studio
by Adam Badura 16 Sep '09

16 Sep '09

I experienced compilation problems with Boost 1.40. I am using Visual Studio 2005 and 2008. On both Boost compiles and links fine but is unusable in other code due to compilation errors. Currently I have access to errors produced on 2008 and it would be troublesome to get errors for 2005 (but if needed I will do it) - however the are the same (as to the message): 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(70) : error C2039: 'long_long_type' : is not a member of 'boost' 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(70) : error C2065: 'long_long_type' : undeclared identifier 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(70) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template 1>d:\libraries\boost_1_40_0\boost\integer_fwd.hpp(73) : error C2913: explicit specialization; 'boost::integer_traits' is not a specialization of a class template and so on... It is hard for me to tell which header causes the error but if requested I will look for this. 1.39 was just fine in both environments. The external (non-Boost) code did not change in the mean time. Any help? Adam Badura

7 10

[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

(no subject)
by Berserker 16 Sep '09

16 Sep '09

Dmitry Goncharov wrote: > The difficulty that your example demonstrates is caused by the nature > of template template parameters. scoped_ptr should not be blamed for that. I agree, moreover I think that the advantages of this patch (often required in the list) justify the 1% use cases of Andrey Semashev's sample that in my opinion can be simplified in this way: template<typename T, typename P> void make_ptr(P &p) { p.reset(new T()); } _________________________________________________________________ Scopri tutti i servizi Windows Live, guarda i video http://www.windowslive.it/videoGallery.aspx

1 0

Re: [boost] scoped_ptr deleter
by Berserker 15 Sep '09

15 Sep '09

Andrey Semashev wrote: > I'd opt for this change if it wouldn't affect the interface in the breaking way. > Otherwise, I like the way it is. I just tested your sample and thanks to the default template value (boost::checked_deleter) it does compile. Are you sure it breaks the interface? _________________________________________________________________ Scopri tutti i servizi Windows Live, guarda i video http://www.windowslive.it/videoGallery.aspx

3 2

[lexical_cast] lexical_cast does not throw bad_lexical_cast
by Carlos Rafael Giani 15 Sep '09

15 Sep '09

Hi, I've noticed that sometimes lexical_cast does not throw bad_lexical_cast. Instead, it throws 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::bad_lexical_cast> >'. A catch clause expecting a bad_lexical_cast fails here. What seems confusing to me is that the lexical_cast docs do mention "catch (bad_lexical_cast &)" as correct code (http://www.boost.org/doc/libs/1_39_0/libs/conversion/lexical_cast.htm) The solution that worked for me was to catch boost::exception instead. Am I missing something here? I consulted the documentation, but still have no answer. It also seems that I am not alone with this problem; http://www.nabble.com/Porting-from-boost_1_33-to-boost_1_36-exception-td197… and http://archives.free.net.ph/message/20090715.183116.374b4777.en.html at least indicate this for me. regards, Carlos Rafael Giani

2 1

enabling/disabling floating point exceptions
by Gennadiy Rozental 15 Sep '09

15 Sep '09

Hi guys, I am looking to complete cross platform implementation of enabling/disabling logic in boost::execution_monitor. It looks like there is no standard interface available. I'm using _controlfp interface now on Windows. I also found these non-standard extensions: * feenableexcep/fedisableexcept available with glib 2.2 * fesettrapenable avaialble in Dinkumware (implementation of STL?) and HP * sun has something called fex_set_handling. not sure when it's available though * header fpu_control.h. Not sure where it's available though. * MAC OS X has something called _MM_SET_EXCEPTION_MASK in xmmintrin.h It also seems that in some cases the switch is compile time only (using compilation option). Would anyone care to extend this list/comment on it's applicability and/or correctness? Another change I am considering is to split floating point exception catching from other system exceptions. It seems perfectly valid scenario to set catch_system_error to false (thus avoid catching access violations etc) but still willing to catch and process floating point exception. What do you think? Gennadiy

4 4

Re: [boost] scoped_ptr deleter
by Berserker 15 Sep '09

15 Sep '09

Stewart, Robert wrote: > I'm sorry, I read your post too quickly, seeing "shared_ptr" > where you wrote "scoped_ptr." No problem :) > That, of course, requires nothing more than a static member > function in the supplied deleter type as your proposal implies. I suggested a "deleter" (default boost::checked_deleter) instead of a static function because imho an operator()(T *p) is a preferable approach (it doesn't require a "specific" function name) and moreover boost::checked_deleter is already there :) I really hope this patch will be applied. _________________________________________________________________ Gossip, Sport, Notizie... Accendi la Messenger TV! http://www.messenger.it/messengerTV.aspx

1 0

scoped_ptr deleter
by Berserker 15 Sep '09

15 Sep '09

I know it has been asked in the past, but I still don't understand why scoped_ptr lacks this feature. The "noncopyable nature" of scoped_ptr allows to support deleters with simply an extra template parameter (default value is boost::checked_deleter): this change doesn't require extra memory overhead (like in shared_ptr) and it consists of 2 lines. template<class T, class D = boost::checked_deleter> // first patch line class scoped_ptr { // ... public: ~scoped_ptr() { // ... deleter()(ptr); // second patch line, instead of boost::checked_delete } }; Any hope to apply this patch? _________________________________________________________________ Gossip, Sport, Notizie... Accendi la Messenger TV! http://www.messenger.it/messengerTV.aspx

3 2

Re: [boost] scoped_ptr deleter
by Berserker 15 Sep '09

15 Sep '09

A fix to my previous post, the first patch line should be: class D = boost::checked_deleter<T> instead of: class D = boost::checked_deleter Obvously the same implementation is applicable to boost::scoped_array using boost::checked_array_deleter _________________________________________________________________ Le tue Emoticon ti sembrano poche? Scaricane di nuove! http://intrattenimento.it.msn.com/emoticon/

1 0

fixed documentation
by Frank Birbacher 14 Sep '09

14 Sep '09

Hello! I made two small changes to docs: https://svn.boost.org/svn/boost/sandbox-branches/birbacher/fix_documentation c56200 spelling in docs for graph c56201 enhancement for asio docs ip v4 and v6 to_bytes() I will notify the maintainers of the projects. Frank

1 0