July 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

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

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

[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

[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

[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

[unordered] please don't allocate memory in the default constructor
by Thorsten Ottosen 10 Sep '09

10 Sep '09

Hi Jeremy, I think this a really bad idea to allocate in the default construtor. The user can always call rehash() on the empty container, just like when we call reserve() for vector. Thanks -Thorsten

5 8

Re: [boost] Proposal: MapReduce library (single machine)
by Mateusz Berezecki 31 Aug '09

31 Aug '09

Hi , I've just joined this mailing list because of this particular discussion :-) >> 2) have a plan so that the library can eventually range from >> working on 1 multi-core system to distributed >This is the eventual goal, and I have designed the library to be extensible >to be able to do this in the future. With the policy based designed, making >use of the open source projects that you mention should be non-intrusive; >the library allows the user to supply a handler for the intermediate files >(to use kosmosfs or hypertable, for example) I'm going to give it a spin as it happens I'm already having a half-baked distributed backend lacking a mapreduce library for both hypertable and KFS and report back. But this is interesting! Can't stop thinking about it now :-) best, Mateusz

2 1

[rfc] cppgui
by Felipe Magno de Almeida 27 Aug '09

27 Aug '09

I've been working the past two years, on and off, unfortunately more often not, in a GUI library. But I have gotten back to it. And I wanted to make it usable. I believe there are some great things in it. This library has a named parameter interface which is extensible by the backend implementation. I've been working on a QT port, which have been fairly easy so far. My intention is to rework some parts of it, finish most widgets and the surface concept I've been working on and submit to review to boost. But I wanted some ideas on the controller interface and whatever might be useful too in improving the design before submitting. The library is in http://www.assembla.com/wiki/show/cppgui There's a svn and trac there that I use. The library requires the boost/funcitonal/factory.hpp library reviewed and accepted (?), which is not yet part of any boost distribution to compile. You will also need fusion to compile. I've tested with GCC 4.4.0/4.3.3 with QT and win32 with visual C++ 9.0. But should be pretty portable, including qt in visual C++. The gtk code does not compile :(. There are some very primitive documentation in the site, and some examples in the svn. Thanks in advance, -- Felipe Magno de Almeida

14 47

[unordered] allocators and EBO
by Thorsten Ottosen 24 Aug '09

24 Aug '09

Hi James, (Sorry I called you Jeremy in the other post). When the allocator is empty, you should avoid storing them as members in different internal structures, and make the allcator a base class of some of these structures. Thanks -Thorsten

2 2

[fusion] Minor interface change
by Joel de Guzman 23 Aug '09

23 Aug '09

Hi Y'all, Heads up. There will be a minor interface change. vector0 will now be a template: vector0<> to better reflect MPL. This also addresses Boost Trac ticket #1608: https://svn.boost.org/trac/boost/ticket/1608 Please adjust your code accordingly, or holler if you have any complaints. Unless there are objections, I'll commit the code as soon as all the relevant regression tests pass. Regards, -- Joel de Guzman http://www.boostpro.com http://spirit.sf.net

2 3

[ptr_container] new_clone overload
by Frank Mori Hess 20 Aug '09

20 Aug '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've noticed that ptr_container/clone_allocator.hpp contains an undocumented overload of new_clone that accepts a pointer-to-const: template< class T > inline T* new_clone( const T* r ); It is annoying because it doesn't support a pointer-to-non-const argument, resulting in a compile error if you try. Any chance one of the following could be done? 1) remove it 2) add a pointer-to-non-const overload 3) change it to template< class T > T* new_clone( T* r ); 4) or if you care about always returning a pointer-to-non-const change it to template< class T > typename remove_const<T>::type * new_clone( T* r ); -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpxsyoACgkQ5vihyNWuA4WnCACgwzxlNxG8z8NAln6Ra8+fNHsn Yr8AoL5a8Bdvkoya1p99GcS1W8N2WSjk =rSZQ -----END PGP SIGNATURE-----

2 5

Review Wizard Status Report for June 2009
by Ronald Garcia 20 Aug '09

20 Aug '09

============================================== Review Wizard Status Report for June 2009 ============================================== News ==== Futures: Williams variant Accepted; Gaskill variant Rejected Boost 1.38 Released New Libraries: Revised Libraries: Boost.Range Extension Accepted Polynomial Library Rejected Boost 1.39 Released Constrained Value Review - Review Result Pending Older Issues ============ The Time Series Library, accepted in August 2007, has not yet been submitted to SVN. Eric Niebler and John Phillips are working on making the changes suggested during the review. The Floating Point Utilities Library, has not yet been submitted to SVN. It is slated to be integrated with the Boost.Math library. The Switch Library, accepted provisionally in January 2008, has not yet been submitted for mini-review and full acceptance. The Phoenix Library, accepted provisionally in September 2008, has not yet been submitted for mini-review and full acceptance. A rewrite of Phoenix, basing it on the Proto metaprogramming library, has just begun. General Announcements ===================== As always, we need experienced review managers. The review queue has been growing substantially but we have had few volunteers, so manage reviews if possible and if not please make sure to watch the review schedule and participate. Please take a look at the list of libraries in need of managers and check out their descriptions. In general review managers are active boost participants or library contributors. If you can serve as review manager for any of them, email Ron Garcia or John Phillips, "garcia at osl dot iu dot edu" and "phillips at mps dot ohio-state dot edu" respectively. We are also suffering from a lack of reviewers. While we all understand time pressures and the need to complete paying work, the strength of Boost is based on the detailed and informed reviews submitted by you. A recent effort is trying to secure at least five people who promise to submit reviews as a precondition to starting the review period. Consider volunteering for this and even taking the time to create the review as early as possible. No rule says you can only work on a review during the review period. A link to this report will be posted to www.boost.org. If you would like us to make any modifications or additions to this report before we do that, please email Ron or John. If you're a library author and plan on submitting a library for review in the next 3-6 months, send Ron or John a short description of your library and we'll add it to the Libraries Under Construction below. We know that there are many libraries that are near completion, but we have hard time keeping track all of them. Please keep us informed about your progress. Review Queue ============ * Lexer * Shifted Pointer * Logging * Log * Join * Pimpl * Thread Pool * Endian * Meta State Machine * Conversion * Sorting * GIL.IO * AutoBuffer * String Convert -------------------- Lexer ----- :Author: Ben Hanson :Review Manager: Eric Neibler :Download: `Boost Vault <http://boost-consulting.com/vault/index.php?action=downloadfile&filename=bo… >`__ :Description: A programmable lexical analyser generator inspired by 'flex'. Like flex, it is programmed by the use of regular expressions and outputs a state machine as a number of DFAs utilising equivalence classes for compression. Shifted Pointer --------------- :Author: Phil Bouchard :Review Manager: Needed :Download: `Boost Vault <http://www.boost-consulting.com/vault/index.php?&direction=0&order=&directo… >`__ :Description: Smart pointers are in general optimized for a specific resource (memory usage, CPU cycles, user friendliness, ...) depending on what the user need to make the most of. The purpose of this smart pointer is mainly to allocate the reference counter (or owner) and the object itself at the same time so that dynamic memory management is simplified thus accelerated and cheaper on the memory map. Logging ------- :Author: John Torjo :Review Manager: Gennadiy Rozental :Download: http://torjo.com/log2/ :Description: Used properly, logging is a very powerful tool. Besides aiding debugging/testing, it can also show you how your application is used. The Boost Logging Library allows just for that, supporting a lot of scenarios, ranging from very simple (dumping all to one destination), to very complex (multiple logs, some enabled/some not, levels, etc). It features a very simple and flexible interface, efficient filtering of messages, thread-safety, formatters and destinations, easy manipulation of logs, finding the best logger/filter classes based on your application's needs, you can define your own macros and much more! Log --- :Author: Andrey Semashev :Review Manager: Needed :Download: `Boost Vault <http://tinyurl.com/cm9lum>`__ :Description: The library is aimed to help adding logging features to applications. It provides out-of-box support for many widely used capabilities, such as formatting and filtering based on attributes, sending logs to a syslog server or to Windows Event Log, or simply storing logs into files. It also provides basic support for the library initialization from a settings file. The library can also be used for a wider range of tasks and implement gathering and processing statistical information or notifying user about application events. Join ---- :Author: Yigong Liu :Review Manager: Needed :Download: http://channel.sourceforge.net/ :Description: Join is an asynchronous, message based C++ concurrency library based on join calculus. It is applicable both to multi-threaded applications and to the orchestration of asynchronous, event-based applications. It follows Comega's design and implementation and builds with Boost facilities. It provides a high level concurrency API with asynchronous methods, synchronous methods, and chords which are "join-patterns" defining the synchronization, asynchrony, and concurrency. Pimpl ----- :Author: Vladimir Batov :Review Manager: Needed :Download: | `Boost Vault <http://www.boost-consulting.com/vault/index.php?action=downloadfile&filenam… >`__ | http://www.ddj.com/cpp/205918714 (documentation) :Description: The Pimpl idiom is a simple yet robust technique to minimize coupling via the separation of interface and implementation and then implementation hiding. This library provides a convenient yet flexible and generic deployment technique for the Pimpl idiom. It's seemingly complete and broadly applicable, yet minimal, simple and pleasant to use. Thread Pool ----------- :Author: Oliver Kowalke :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo… >`__ :Description: The library provides: - thread creation policies: determines the management of worker threads: - fixed set of threads in pool - create workerthreads on demand (depending on context) - let worker threads ime out after certain idle time - channel policies: manages access to queued tasks: - bounded channel with high and low watermark for queuing tasks - unbounded channel with unlimited number of queued tasks - rendezvous syncron hand-over between producer and consumer threads - queueing policy: determines how tasks will be removed from channel: - FIFO - LIFO - priority queue (attribute assigned to task) - smart insertions and extractions (for instance remove oldest task with certain attribute by newst one) - tasks can be chained and lazy submit of taks is also supported (thanks to Braddocks future library). - returns a task object from the submit function. The task it self can be interrupted if its is cooperative (means it has some interruption points in its code -> ``this_thread::interruption_point()`` ). Endian ------ :Author: Beman Dawes :Review Manager: Needed :Download: http://mysite.verizon.net/beman/endian-0.10.zip :Description: Header boost/integer/endian.hpp provides integer-like byte-holder binary types with explicit control over byte order, value type, size, and alignment. Typedefs provide easy-to-use names for common configurations. These types provide portable byte-holders for integer data, independent of particular computer architectures. Use cases almost always involve I/O, either via files or network connections. Although data portability is the primary motivation, these integer byte- holders may also be used to reduce memory use, file size, or network activity since they provide binary integer sizes not otherwise available. Meta State Machine ------------------ :Author: Christophe Henry :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?direction=0&order=&director… >`__ :Description: Msm is a framework which enables you to build a Finite State Machine in a straightforward, descriptive and easy-to-use manner . It requires minimal effort to generate a working program from an UML state machine diagram. This work was inspired by the state machine described in the book of David Abrahams and Aleksey Gurtovoy "C++ Template Metaprogramming" and adds most of what UML Designers are expecting from an UML State Machine framework: * Entry and Exit Methods * Guard Conditions * Sub state machines (also called composite states in UML) * History * Terminate Pseudo-State * Deferred Events * Orthogonal zones * Explicit entry into sub state machine states * Fork * Entry / Exit pseudo states * Conflicting transitions Conversion ---------- :Author: Vicente Botet :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=co… >`__ :Description: Generic explicit conversion between unrelated types. Boost.Conversion provides: * a generic ``convert_to`` function which can be specialized by the user to make explicit conversion between unrelated types. * a generic ``assign_to`` function which can be specialized by the user to make explicit assignation between unrelated types. * conversion between ``std::complex`` of explicitly convertible types. * conversion between ``std::pair`` of explicitly convertible types. * conversion between ``boost::optional`` of explicitly convertible types. * conversion between ``boost::rational`` of explicitly convertible types. * conversion between ``boost::interval`` of explicitly convertible types. * conversion between ``boost::chrono::time_point`` and ``boost::ptime``. * conversion between ``boost::chrono::duration`` and ``boost::time_duration``. Sorting ------- :Author: Steven Ross :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=al… >`__ :Description: A grouping of 3 templated hybrid radix/comparison-based sorting algorithms that provide superior worst-case and average-case performance to std::sort: integer_sort, which sorts fixed-size data types that support a rightshift (default of >>) and a comparison (default of <) operator. float_sort, which sorts standard floating-point numbers by safely casting them to integers. string_sort, which sorts variable-length data types, and is optimized for 8-bit character strings. All 3 algorithms have O(n(k/s + s)) runtime where k is the number of bits in the data type and s is a constant, and limited memory overhead (in the kB for realistic inputs). In testing, integer_sort varies from 35% faster to 8X as fast as std::sort, depending on processor, compiler optimizations, and data distribution. float_sort is roughly 7X as fast as std::sort on x86 processors. string_sort is roughly 2X as fast as std::sort. GIL.IO ------ :Author: Christian Henning :Review Manager: Needed :Download: `GIL Google Code Vault <http://gil-contributions.googlecode.com/files/rc2.zip >`__ :Description: I/O extension for ``boost::gil`` which allows reading and writing of/in various image formats ( tiff, jpeg, png, etc ). This review will also include the Toolbox extension which adds some common functionality to gil, such as new color spaces, algorithms, etc. AutoBuffer ---------- :Author: Thorsten Ottosen :Review Manager: Needed :Download: `Here <http://www.cs.aau.dk/~nesotto/boost/ auto_buffer.zip>`__ :Description: Boost.AutoBuffer provides a container for efficient dynamic, local buffers. Furthermore, the container may be used as an alternative to std::vector, offering greater flexibility and sometimes better performance. String Convert -------------- :Author: Vladimir Batov :Review Manager: Needed :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=bo… >`__ :Description: The library takes the approach of boost::lexical_cast in the area of string-to-type and type-to-string conversions, builds on the past boost::lexical_cast experience and advances that conversion functionality further to additionally provide: * throwing and non-throwing conversion-failure behavior; * support for the default value to be returned when conversion fails; * two types of the conversion-failure check -- basic and better/safe; * formatting support based on the standard I/O Streams and the standard (or user-defined) I/O Stream-based manipulators (like std::hex, std::scientific, etc.); * locale support; * support for boost::range-compliant char and wchar_t-based string containers; * no DefaultConstructibility requirement for the Target type; * consistent framework to uniformly incorporate any type-to-type conversions. It is an essential tool with applications making extensive use of configuration files or having to process/prepare considerable amounts of data in, say, XML, etc. Libraries under development =========================== Please let us know of any libraries you are currently developing that you intend to submit for review. Mirror ------ :Author: Matus Chochlik :Download: | http://svn.boost.org/svn/boost/sandbox/mirror/doc/index.html | `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=mi… >`__ :Description: The aim of the Mirror library is to provide useful meta-data at both compile-time and run-time about common C++ constructs like namespaces, types, typedef-ined types, classes and their base classes and member attributes, instances, etc. and to provide generic interfaces for their introspection. Mirror is designed with the principle of stratification in mind and tries to be as less intrusive as possible. New or existing classes do not need to be designed to directly support Mirror and no Mirror related code is necessary in the class' definition, as far as some general guidelines are followed Most important features of the Mirror library that are currently implemented include: * Namespace-name inspection. * Inspection of the whole scope in which a namespace is defined * Type-name querying, with the support for typedef-ined typenames and typenames of derived types like pointers, references, cv-qualified types, arrays, functions and template names. Names with or without nested-name-specifiers can be queried. * Inspection of the scope in which a type has been defined * Uniform and generic inspection of class' base classes. One can inspect traits of the base classes for example their types, whether they are inherited virtually or not and the access specifier (private, protected, public). * Uniform and generic inspection of class' member attributes. At compile-time the count of class' attributes and their types, storage class specifiers (static, mutable) and some other traits can be queried. At run-time one can uniformly query the names and/or values (when given an instance of the reflected class) of the member attributes and sequentially execute a custom functor on every attribute of a class. * Traversals of a class' (or generally type's) structure with user defined visitors, which are optionally working on an provided instance of the type or just on it's structure without any run-time data. These visitors are guided by Mirror through the structure of the class and optionally provided with contextual information about the current position in the traversal. I'm hoping to have it review ready in the next few months. Interval Template Library ------------------------- :Author: Joachim Faulhaber :Description: The Interval Template Library (Itl) provides intervals and two kinds of interval containers: Interval_sets and interval_maps. Interval_sets and maps can be used just as sets or maps of elements. Yet they are much more space and time efficient when the elements occur in contiguous chunks: intervals. This is obviously the case in many problem domains, particularly in fields that deal with problems related to date and time. Interval containers allow for intersection with interval_sets to work with segmentation. For instance you might want to intersect an interval container with a grid of months and then iterate over those months. Finally interval_maps provide aggregation on associated values, if added intervals overlap with intervals that are stored in the interval_map. This feature is called aggregate on overlap. It is shown by example: :: typedef set<string> guests; interval_map<time, guests> party; guests mary; mary.insert("Mary"); guests harry; harry.insert("Harry"); party += make_pair(interval<time>::rightopen(20:00, 22:00),mary); party += make_pair(interval<time>::rightopen_(21:00, 23:00),harry); // party now contains [20:00, 21:00)->{"Mary"} [21:00, 22:00)->{"Harry","Mary"} //guest sets aggregated on overlap [22:00, 23:00)->{"Harry"} As can be seen from the example an interval_map has both a decompositional behavior (on the time dimension) as well as a accumulative one (on the associated values). StlConstantTimeSize ------------------- :Author: Vicente J. Botet Escriba :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=consta… >`__ :Description: Boost.StlConstantTimeSize Defines a wrapper to the stl container list giving the user the chioice for the complexity of the size function: linear time, constant time or quasi-constant. In future versions the library could include a similar wrapper to slist. InterThreads ------------------- :Author: Vicente J. Botet Escriba :Download: `Boost Vault <http://www.boostpro.com/vault/index.php?action=downloadfile&filename=in… >`__ :Description: Boost.InterThreads extends Boost.Threads adding some features: * thread decorator: thread_decorator allows to define setup/cleanup functions which will be called only once by thread: setup before the thread function and cleanup at thread exit. * thread specific shared pointer: this is an extension of the thread_specific_ptr providing access to this thread specific context from other threads. As it is shared the stored pointer is a shared_ptr instead of a raw one. * thread keep alive mechanism: this mechanism allows to detect threads that do not prove that they are alive by calling to the keep_alive_point regularly. When a thread is declared dead a user provided function is called, which by default will abort the program. * thread tuple: defines a thread groupe where the number of threads is know statically and the threads are created at construction time. * set_once: a synchonizer that allows to set a variable only once, notifying to the variable value to whatever is waiting for that. * thread_tuple_once: an extension of the boost::thread_tuple which allows to join the thread finishing the first, using for that the set_once synchronizer. * thread_group_once: an extension of the boost::thread_group which allows to join the thread finishing the first, using for that the set_once synchronizer. (thread_decorator and thread_specific_shared_ptr) are based on the original implementation of threadalert written by Roland Schwarz. Boost.InterThreads extends Boost.Threads adding thread setup/cleanup decorator, thread specific shared pointer, thread keep alive mechanism and thread tuples.

13 49

[flat_set/flat_map] request for new constructor that accepts a sorted sequence
by Thorsten Ottosen 20 Aug '09

20 Aug '09

Hi Ion, It would be veyr nice to have the following constructor: template< class Iter > flat_container( Iter, Iter, bool /*tag*/ ); which allows one to give the container an already sorted sequence (this would be the precondition). -Thorsten

2 4

[C++0x] Report from Frankfurt committee meeting
by Beman Dawes 17 Aug '09

17 Aug '09

The C++ standards committee met in Frankfurt, Germany, last week. Key actions: * Concepts have been removed from C++0x. The committee is very much in favor of Concepts. But Concepts are seen as so important that they have to be right. And the strong consensus was that getting Concepts right, for any reasonable definition of "right", would add several years to the schedule. There was also a consensus that an implementation of a compiler that could compile the entire standard library is part of the definition of "right". While ConceptGCC has been a great help, it isn't there as far as validating "right". Personally, I think Clang may end up being the compiler that eventually validates Concepts. * The range-based for loop and some other library features that were dependent on Concepts will be retained by recasting them to no longer depend on Concepts. See a paper in the upcoming post-meeting mailing to see how range-based for loops will work. * A second Committee Draft (CD2) will need go out for public comment in the Spring or Summer 2010, given the amount of change required to remove Concepts. The C++0x final schedule will thus slip about one year. * No committee action was taken as to how Concepts will eventually make it into C++. While there was a bit of discussion about doing a Concepts Technical Report (TR), there was no such proposal made. Committee members seem to lean toward letting the two rival Concept teams go back to work outside of the committee process. The expectation being they will come back to the committee when they are ready to restart the standardization process. Hopefully the lessons learned about Concepts during the committee process will be taken advantage of, so future standardization of Concepts will be smoother. My personal opinion is that removing Concepts will speed the arrival of conforming C++0x compilers. GCC, for example, has already implemented much of C++0x, so their key developers are no longer faced with the difficult task of turning ConceptGCC into a production compiler, and can concentrate on remaining major features like lambdas. Although Concepts would have added a lot to C++ and Boost, Concepts would also have presented major migration challenges. I'm thinking that for most Boost libraries, migration to C++0x will now be easier and less disruptive. We need to focus on the bright side. --Beman

18 35

Vault access for Boost.Debug
by Zachary Turner 11 Aug '09

11 Aug '09

Hello, I'd like to request access to the vault. I'm going to upload a proof-of-concept of some of the things I mentioned earlier in my thread about Boost.Debug. This early version gives simple stack traces in limited scenarios, only supports Windows, and isn't designed very well. Here's an example of a program using it in its current form: void test_func(int argc, int argc2, char* argv[]) { stack_trace trace(10); //Maximum depth of 10 levels std::cout << trace.string() << std::endl; } int main(int argc, char* argv[]) { test_func(argc, argc, argv); return 0; } and an example of the stack trace printed as a result of this program: void test_func(int, int, char**) [f:/dev/stack_trace/main.cpp:10] int main(int, char**) [f:/dev/stack_trace/main.cpp:23] int __tmainCRTStartup() [f:/dd/vctools/crt_bld/self_x86/crt/src/crtexe.c:406] int mainCRTStartup() [f:/dd/vctools/crt_bld/self_x86/crt/src/crtexe.c:389] It also currently supports printing the names of all the arguments, but it was hackish and I left it out until it undergoes some redesign. There is currently no documentation, but as this is just a proof of concept I'm currently only looking for people to help out with actual code and/or provide input, so I think that's ok for now. Thanks

5 6

enum / string translation
by Zachary Turner 11 Aug '09

11 Aug '09

I wrote some code to perform both compile-time and runtime translation between enums and their corresponding string values. The only direction that isn't possible is string->enum at compile time. Is there any interest in this? You can use it as follows: typedef enum { ValueA1, ValueA2 } EnumA; typedef enum { ValueB1, ValueB2 } EnumB; BEGIN_ENUM_MAP_DECLS() BEGIN_ENUM_MAP(EnumA, a_map) ENUM_MAP(ValueA1) //maps ValueA1 to the string "ValueA1", provides both compile-time and run-time lookups. ENUM_MAP_NAME(ValueA2, "custom name") //maps ValueA2 to the string "custom name", provides both compile-time and run-time lookups END_ENUM_MAP() BEGIN_ENUM_MAP(EnumB, b_map) ENUM_MAP(ValueB1) ENUM_MAP(ValueB2) END_ENUM_MAP() END_ENUM_MAP_DECLS() void foo() { //value -> string, compile time BOOST_STATIC_ASSERT(enum_map<EnumA>::value_lookup[ValueA2] == "custom name"); //value -> string, runtime EnumB some_value = get_enum_b_from_external_source(); std::cout << "some_value = " << enum_map<EnumB>::name_lookup[some_value] << std::endl; //prints either 'some_value = ValueB1', or 'some_value = ValueB2' //string -> value, runtime EnumA value = enum_map<EnumA>::name_lookup["custom name"]; BOOST_ASSERT(value == ValueA2); } One particularly useful application of this that I've found is with regards to boost::program_options. You can provide an overload of boost::program_options::validate that uses boost::enable_if with boost::is_enum thus providing automatic support for entry of friendly names corresponding to enumerations on the command line or in a config file. Obviously there's many other easily identifiable uses as well. However, this is a common enough problem that I wonder if anyone else has already attempted something like this, and if so maybe I can look at their code first, or just scrap mine altogether and reuse something existing. If not, I'm sure there is plenty of room for improvement in mine but if it could fit somewhere in boost (perhaps boost/utility) I'd be willing to submit it and make necessary improvements. Unfortunately I don't think it's technically possible to have a simple syntax, even through preprocessor magic, that requires you to only specify the name of each enumerated value once, and end up providing both a definition of the enumeration as well as the mapping from string<->value, but if someone comes up with a way that would obviously be ideal.

7 16

[move] moving temporaries of copyable types
by klaus triendl 10 Aug '09

10 Aug '09

Hi, I've recently taken a look at the Boost.Move library and it seems that it is only possible to make 1) either non-copyable types movable or 2) make copyable types move-aware by explicitly moving them. Now, I've discovered for myself that it is possible for pre-c++09 compilers to make copyable types *implicitly* movable by detecting temporaries that can be moved. So, my question is whether this is well-known and this feature was deliberately excluded from Boost.Move or nobody has discovered it yet. It would be great to have support for copy- and (implicit) move-semantics. Klaus Triendl

5 9

[proto]: rewriting POOMA and Blitz++
by Chandrashekhar Kumar 10 Aug '09

10 Aug '09

Hello, At some time Eric expressed that all the expression template based libraries of boost (notably Phoenix, Spirit) has to be re-written using proto. I think that this target is kind of achieved by now. Can something be done along the similar lines for re-writing the top-notch libraries like POOMA and Blitz++ as a complete examples of proto applications? Does anyone has idea about how huge this undertaking can be? Thanks, Chandra

4 7

"I want everything" should build "out of the box" (on Windows)
by KTC 09 Aug '09

09 Aug '09

Users on Microsoft Windows should be able to build boost with everything, both in terms of all supported variants and all boost libraries, with a single command to bjam assuming they have all the optional supporting libraries available. An user download boost, and want to build all the libraries that require building go read the Getting Started Guide <.../getting_started/windows.html#invoke-bjam> and see the after getting bjam they use the command bjam --build-dir=build-directory toolset=toolset-name --build-type=complete stage So they enter that into the command prompt and see lots of warnings and notes about missing optional components. The warnings and notes itself is fine and informative. Actually, it's incomplete as it stand as it doesn't tell the user about Boost.IOStreams optional component requirement of bzip2 & zlib headers. Okay, the user go and install all the optional components the warnings and notes tell them. After installing Python, ICU (building it first), Expat (building it first), and MPI (say MS-MPI), they try again. This time with the command becoming bjam --toolset=... --build-dir=... --build-type=complete -sHAVE_ICU=1 -sICU_PATH="..." -sEXPAT_INCLUDE="..." -sEXPAT_LIBPATH="..." -sBZIP2_SOURCE="..." -sZLIB_SOURCE="..." stage Nope, MPI requires modification of user-config.jam or building it on its own with --with-mpi. Why? No other optional components build that way. So they look to see how they do that, and does it. Second attempt and ... nope. New to 1.39 is the errors error: link=shared together with runtime-link=static is not allowed error: such property combination is either impossible error: or too dangerious to be of any use due to the changes made as a result of <http://lists.boost.org/Archives/boost/2009/04/150675.php>. (Recently noted on <http://groups.google.com/group/boost-list/browse_thread/thread/2a7bd07468b5…>.) While catching those errors is good, maybe it should be fixed as well such that it doesn't come up in the first place if someone do a --build-type=complete with ICU. So now the users have to build Boost.Regex separately from the rest of the library (after finding how to pass the link= & runtime-link= options). By the way, at this point I would like to point out how it's strange that -sHAVE_ICU=1 mean to build with ICU, but so is -sHAVE_ICU=0 .... :S And ... nope, even separately Boost.Regex still wouldn't build without errors. No one told them they need to rename icuin.lib, icuind.lib, icuind.pdb & icudt.lib from ICU to icui18n.lib, icui18nd.lib, icui18nd.pdb & icudata.lib respectively. With Boost.Regex built, we turn to the rest of the library with --without-regex. After waiting a while, we discover ... nope, Most of the library is built but not Boost.Graph. Sorry, this time no one told them they need to change Boost.Graph's Jamfile.v2 file with "<find-shared-library>expat" to "<find-shared-library>libexpatwMT" and adding "<define>XML_STATIC". Boost is great, it's free, it's flexible and I understand it's developed for free by volunteers, but its "installation" for someone that want every libraries could be improved. :-) Regards, KTC -- Only two things are infinite, the Universe and Stupidity. And I'm not quite sure about the former. - Albert Einstein

15 56

[Interprocess::Semaphore] Deadlock on more producers - one consumer problem
by Cosimo Calabrese 09 Aug '09

09 Aug '09

Hi to all, I've a buffer of 10 positions; 4 producers put elements on the buffer and only 1 consumer pick them; the producers generate elements very fastly, but the consumer picks the element very slowly. I've decided to synchronize the producers and the consumer with a boost::interprocess semaphore initialized to 10. Before to put an element in the buffer, the producer execute a wait() in the semaphore; the 4 producers put quickly 10 elements in the buffer, so they all block on the wait(). When the consumer picks an element from the buffer, it performs a post() on the semaphore. Here is the problem: the post() unlocks only one of the 4 producers. Consider this scenario: - the producers are all in wait state; the semaphore counter is 0; - the consumer picks an element and perform a post(), that unlocked the producer_1; the semaphore counter is 1; - the producer_1 is unlocked but it doesn't produce any element; the other producers are locked; - the consumer picks the other 9 elements in the buffer and perform the 9 post() on the semaphore, but the semaphore counter becomes 2, 3, 4, ... 10, and so the semaphore doesn't signal the other producers, that remains in lock state(). --> DEADLOCK. Is there a way to unlock all the producers with the boost::interprocess::semaphore? Or I have mistaken the approach of the problem? Thanks to all, Cosimo Calabrese.

5 27

[1.40] timeline?
by John Maddock 07 Aug '09

07 Aug '09

Do we have a revised timeline for 1.40 yet? I'm asking because the regex lib is ready for a substantial update (provided trunk tests cycle OK obviously!). Thanks, John.

6 13

Boost.Plot? - Scalable Vector Graphics
by Paul A. Bristow 07 Aug '09

07 Aug '09

Jake Voytko started this library during a 2007 GSoC and I have now expanded it quite a bit, and begun to use it for my own purposes (including preparing the plot for the Boost.Math library functions and statistical distributions). Before I do any more work on it, I'd appreciate feedback from Boosters on how useful they think it might be, perhaps as a Boost library? Although it still has plenty of wrinklies (the calculation of positioning of titles, legends, axes labels and ticks labels is intricate - to say the least). And there are not-a-few nasty warts (this may be the 1st version to throw away?), so it is in no way review-ready. But I believe it is working well enough for you to try to use it - and to give me feedback. There are of course hundreds of programs for plotting. What is special about *this* library is that it is in C++ and it has a Boost license. It allows you to add just a few lines of code to the end of your C++ program to take data from any STL container (all or part) and produce a plot as a Scale Vector Graph (.svg) file. (No need to export data to a file and suck into Excel ;-) Applause!) .svg files can be displayed by all good Internet Browsers (and even by IE8 with an Adobe add-in). They are very small but high quality, highly zip compressible, and equally suitable for printing to viewing on mobiles (only the features of Tiny SVG are used.). It takes as little code as svg_2d_plot my_plot; my_plot .plot(map1, "Series 1").stroke_color(blue) .plot(map2, "Series 2").stroke_color(red") .autoscale(map1); my_plot.write("./2d_simple.svg"); but you can have hours of fun trying out hundreds of options to produce some rather fancy plots. For your amusement, attached are a few (mostly contrived) examples (with tasteless garish colors just to highlight the possible options). There are also lots and lots of other examples. (Note that the 20 plots occupy a mere 30 kb when zipped). Unusually, there is lots (too much? - 6Mbyte hyperlinked and indexed PDF!) of documentation, produced using the C++ in QuickBook with Doxygen reference info and John Maddock's auto-indexing. But there are hundreds of options, so you will need all the help you can get from tutorials, examples and indexes. A novel feature is the built-in handling of an 'uncertain' type (based on Evan Marshal Manning, C/C++ Users Journal, March 1996 page 29 to 38) including a double 'most likely' value, an 'uncertainty' estimate, roughly standard deviation, and an estimate of 'degrees of freedom'. This can be used to display confidence ellipses and label values "1.23 +-0.01 (21)", for example. (Of course, you can make much better confidence estimates using the Boost.Math library). You can view and can get code from the Boost sandbox https://svn.boost.org/svn/boost/sandbox/SOC/2007/visualization Docs are available to build as html and pre-built as pdf (patience - 6 Mbyte!) https://svn.boost.org/svn/boost/sandbox/SOC/2007/visualization/libs/svg_plot /doc/pdf/svg_plot.pdf or http://tinyurl.com/coqlbg (or ask if you want zips instead). Paul PS Thanks to all those who have offered support, especially John Maddock of course. It has stress-tested the Quickbook - Doxygen indexing system ;-) I haven't managed to make the index work perfectly yet and I'm sure it can be improved. PPS If I were doing this again, I would not use 'derived' trick to permit re-use of functions by 1D, 2D and boxplots - it causes the Intellisense of MS VisualStudio IDE 'Intelligence Circuits' to melt (and sometimes crash - workaround - delete the .ncb file) making the nice 'goto definition' feature ineffective and makes debugging difficult (as does the use of set and get functions). I suspect it makes compile times longer too. There must be a better way - suggestions welcome. But I *would* use the chaining feature - I think it makes a very nice syntax for the user - but tell me what you think. --- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow(a)hetp.u-net.com

14 36

[BGL] To customize the graph traversing
by Cosimo Calabrese 06 Aug '09

06 Aug '09

Hi to all, I'm studying the BGL, and I've a question. I've noticed that: - the traversing algorithms, like breadth first search, only decide how to traverse the graph, but do not perform specific calculations; - if I want to perform any calculation during the traverse, I can do it passing a custom visitor to the algorithm. But the question is: how can I customize the traverse method? The algorithms always explore enterely the graph. EXAMPLE: every edge (u, v) of a graph have a property "edge_can_traverse_t" that says on which of adjacent edges starting from v I can continue the traverse. _C _F o| /| o / o / A---->B---->D o o o >G \ \ \ \ _\| _\| E H ----------------------------------------- | edge | property edge_can_traverse_t | | | (vector<edge>) | ----------------------------------------- | (A,B) | (B,D) , (B,E) | | (B,C) | empty | | (B,D) | (D,F) , (D,H) | | (B,E) | empty | | (D,F) | empty | | (D,G) | empty | | (D,H) | empty | ----------------------------------------- For example, if I come from the (A,B) edge, I want that the algorithm consider only the (B,D) and (B,E) edge, and skip the (B,C) edge. The solution I found is to modify the breadth_first_search algorithm, adding a predicate to the visitor and performing a control when the algorithm examines the outer edges of the current vertex. Something like this: //============================================================================== // PREDICATE (in the visitor) //============================================================================== template <class IncidenceGraph, class PredecessorMap> bool can_traverse_edge( edge_descriptor e, IncidenceGraph &g, PredecessorMap p ) { typedef graph_traits<IncidenceGraph>::vertex_descriptor VertexDescriptor; VertexDescriptor u = source( e, g ); // select the source of the edge EdgeDescriptor eFrom = edge( p(u), u ); // select the previous visited edge if ( e is contained in the edge_can_traverse_t property of eFrom ) return true; else return false; } //------------------------------------------------------------------------------ //============================================================================== // breadth_first_visit //============================================================================== template <class IncidenceGraph, class Buffer, class BFSVisitor, class ColorMap> void customized_breadth_first_visit (const IncidenceGraph& g, typename graph_traits<IncidenceGraph>::vertex_descriptor s, Buffer& Q, BFSVisitor vis, ColorMap color) { [.....] put(color, s, Color::gray()); vis.discover_vertex(s, g); Q.push(s); while (! Q.empty()) { Vertex u = Q.top(); Q.pop(); vis.examine_vertex(u, g); for (tie(ei, ei_end) = out_edges(u, g); ei != ei_end; ++ei) { if ( !vis.can_traverse_edge( *ei ) ) continue; [.....] } //------------------------------------------------------------------------------ Does it exist a better mechanism to control the traverse with the BGL? Or I must implement my solution? Best Regards, Cosimo Calabrese.

3 13

Interest in a "Heterogenous Container" system?
by Christian Schladetsch 04 Aug '09

04 Aug '09

Hello, After a discussion on a different thread, I came up with an implementation allowing containers to store and retrieve heterogenous instances, and provide correct deep cloning of those containers. A working motivational example is here http://tinyurl.com/larqyy. I have yet to do a comparison with container<boost::any>. This is just an initial proof-of-concept, and there remains a lot of work to do if it were to be a complete proposal. Before I did that work (especially since I have another proposal in the wings), I wanted to ask if there would be any interest in a completed system? The system is based on a modified ptr_container branch (also in the sandbox - I've contacted Thorsten about this), and and allocator adaptor system to deal with cloning. It allows one to place object pointers into a container using syntax such as: /// a vector of heterogenous objects template <class Alloc = std::allocator<char>, class Base = common_base > struct vector; heterogenous::vector<> v; v.push_back<T0>(); // add a default-constructed object of type T0 v.push_back<T1>(a0,a1,...,an); // add an object of type T1, passig a0..an as ctor arguments T1 &obj = v.ref_at<T1>(1); // get a reference of type T1& to the object at index 1 or throw bad_cast heterogenous::vector<> v2 = v; // copy the container; concrete types are preserved assert(v2.is_type_at<T1>(1)); There are many outstanding issues; it may not fly in the end, it may not work for all container types and semantics, but I would like some early opinion on whether it is even worth my pursuing further. One initial issue that may break any interest is that instances put into the container must be of a type T that derives from heterogenous::base<T>. Regards, Christian.

11 29

[Range] Boost and N2930?
by Beman Dawes 04 Aug '09

04 Aug '09

N2930, Range-Based For Loop Wording (Without Concepts), provides begin() and end() non-member function templates for standard library types. It also provides general range access non-member templates: // 24.7 range access [iterator.range] template<typename C> auto begin(C& c) -> decltype(c.begin()); template<typename C> auto begin(const C& c) -> decltype(c.begin()); template<typename C> auto end(C& c) -> decltype(c.end()); template<typename C> auto end(const C& c) -> decltype(c.end()); template<typename T, size_t N> T* begin(T (&array)[N]); template<typename T, size_t N> T* end(T (&array)[N]); (Until the official WG21 site gets updated, you can see a copy of n2930 at http://mysite.verizon.net/beman/n2930.html) Should Boost.Range and/or RangeEx be modified and/or extended in light of N2930? Can Boost.Range, RangeEx, or some other Boost component help developers and users who want to take advantage of N2930 in C++03 now, and do so in a way that transitions smoothly to C++0x as language and library available? --Beman

3 2

[function] should it require rtti?
by Emil Dotchevski 03 Aug '09

03 Aug '09

Line 223 in function_base.hpp uses typeid. Can this be avoided? If not, perhaps it can be refactored to use the workaround found in sp_typeinfo.hpp? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

5 5

Re: [boost] [xpressive] Performance Tuning?
by raindog＠macrohmasheen.com 03 Aug '09

03 Aug '09

I would be very interested in seeing this too as your numbers look extremely good ------Original Message------ From: OvermindDL1 Sender: boost-bounces(a)lists.boost.org To: boost(a)lists.boost.org ReplyTo: boost(a)lists.boost.org Sent: Jul 17, 2009 3:30 PM Subject: Re: [boost] [xpressive] Performance Tuning? On Wed, Jul 15, 2009 at 6:57 AM, OvermindDL1<overminddl1(a)gmail.com> wrote: > /* snip */ So has anyone tried the code I posted to see how it compared? _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Sent from my Verizon Wireless BlackBerry

27 154

Release branch regression testing failures
by Beman Dawes 03 Aug '09

03 Aug '09

Stale tests have been cleared, and there is a fresh release branch regression test report up at: http://beta.boost.org/development/tests/release/developer/summary.html Libraries reporting errors on more than one platform are: bimap - all platforms failing build - all non-Linux platforms failing math - all platforms failing numeric/interval - two platforms failing optional - two platforms failing python - Linux platforms failing spirit - all platforms failing type_traits - all platforms failing units - two platforms failing I'd appreciate it if the developers involved would clear these tests in the next few days. Thanks, --Beman

10 12

There's a serious problem with the Boost Community :(
by Jon Biggar 03 Aug '09

03 Aug '09

Even though this is a complaint, let me start off by stating that I'm a happy user of Boost libraries for over six years, and don't intend to stop. That said, here's the problem: simple patches submitted languish without action or response for far too long. I submitted a patch for bjam with ticket #2552 back in November, including test cases to verify that it operates correctly. But despite requesting over several release cycles since then, no action has been taken and I haven't even gotten a response. It's a pain in the butt to have to keep reintegrating the same patch, release after release so I can keep working on code that I hope to one day submit to for inclusion in a Boost release. The Boost Community *really* needs a mechanism to ensure that patches submitted are acknowledged, vetted, and if found worthy, integrated into a release in a timely manner. Not doing so discourages contribution. Let me suggest that the Community set up something like the review queue, where a few volunteers could regularly select the next patch, request comments from the community and then champion getting the patch integrated into the next Boost release. I understand that library owners have a stake in the design vision and integrity of their library's code, so the community will have to figure out a policy where patches with minimal impact on a library's integrity can be quickly integrated without requiring a lot of the primary library owner's or maintainer's time, but will still get integrated or rejected in a timely manner. -- Jon Biggar jon(a)floorboard.com jon(a)biggar.org jonbiggar(a)gmail.com

4 5

request: BOOST_NO_SFINAE_EXPR macro
by Mathias Gaunard 01 Aug '09

01 Aug '09

It would be very nice if Boost.Config provided the BOOST_NO_SFINAE_EXPR macro, that would be defined if the compiler does not support SFINAE applied to expressions. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2634.html GCC supports this feature since 4.4 both for C++03 and C++0x for example.

3 7

issues when compiling boost with visual c++ 8 and 9
by Sean Farrow 01 Aug '09

01 Aug '09

Hi: The following is the output I am currently getting with the current trunk when trying to compile with visual c++ 9, tried with visual c++ 8 and got a similar error: C:/Program Files/boost/tools/build/v2/tools\msvc.jam:1040: syntax error at keyword = C:/Program Files/boost/tools/build/v2/build\toolset.jam:38: in toolset.using rule msvc.init unknown in module toolset. C:/Program Files/boost/tools/build/v2\build-system.jam:465: in process-explicit-toolset-requests C:/Program Files/boost/tools/build/v2\build-system.jam:545: in load C:\Program Files\boost\tools\build\v2/kernel\modules.jam:283: in import C:\Program Files\boost\tools\build\v2\kernel\bootstrap.jam:138: in boost-build C:\Program Files\boost\boost-build.jam:17: in module scope Hope this helps. Sean.

3 3

Please Help: Experienced very bad performance with Multi-index
by Jarolin, Robert 31 Jul '09

31 Jul '09

Below is a sample program that I am running. If I create a multi-index as defined below, the performance as the number of entries increases gets to the point of being unusable. Examples: Num Entries Time to insert last entry Time to insert all entries 100 452 usecs 30.4 millisecs 1000 4.6 millisecs 2.4 seconds 10000 52.2 millisecs 266.92 seconds (over 4.5 minutes) This performance does not seem to be correct to me. Deletions from a multiindex based on a key, were taking super long as well (not shown in the below program). To delete all 1000 entries based on being below a certain ordered value was taking over 2 minutes. Is there something that is wrong with the below program that is causing these issues? Thanks for any help. XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Cut Here XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX #if !defined(NDEBUG) #define BOOST_MULTI_INDEX_ENABLE_INVARIANT_CHECKING #define BOOST_MULTI_INDEX_ENABLE_SAFE_MODE #endif #include <boost/multi_index_container.hpp> #include <boost/multi_index/member.hpp> #include <boost/multi_index/ordered_index.hpp> #include <boost/multi_index/hashed_index.hpp> #include <algorithm> #include <iostream> #include <iterator> #include <string> #include <sys/time.h> using boost::multi_index_container; using namespace boost::multi_index; using namespace std; struct ErRecord { int value1; std::string value2; int value3; int value4; ErRecord() : value1(0), value2(""), value3(0), value4(0) { } ErRecord(int _value1, const std::string& _value2, const int _value3, int _value4) : value1(_value1), value2(_value2), value3(_value3), value4(_value4) { } }; //@@== Tags struct value1 {}; struct value2 {}; struct value4 {}; struct value3 {}; typedef multi_index_container < ErRecord, indexed_by < ordered_non_unique < tag<value1>, BOOST_MULTI_INDEX_MEMBER(ErRecord, int, value1) >, ordered_non_unique < tag<value2>, BOOST_MULTI_INDEX_MEMBER(ErRecord, std::string, value2) >, ordered_non_unique < tag<value3>, BOOST_MULTI_INDEX_MEMBER(ErRecord, int, value3) >, ordered_non_unique < tag<value4>, BOOST_MULTI_INDEX_MEMBER(ErRecord, int, value4) > > > ErRecordMap; int main(int argc, char* argv[]) { int numloops = 100; if (argc > 1) numloops = atoi(argv[1]); ErRecordMap em; char buf[50]; int i = 0; int sec; int usec; unsigned long long u64; struct timeval tv_start, tv_end; struct timeval tv_before, tv_after; gettimeofday( &tv_start, 0 ); while (1) { sprintf(buf, "value2-%d", i); gettimeofday( &tv_before, 0 ); em.insert(ErRecord(i, string(buf), i, i)); gettimeofday( &tv_after, 0 ); if( i == numloops ) { sec = tv_after.tv_sec - tv_before.tv_sec; usec = tv_after.tv_usec - tv_before.tv_usec; if (usec < 0) { sec--; usec += 1000000; } u64 = sec * 1000000 + usec; cout << "Time to insert last entry: " << sec << ":" << usec << endl; } ++i; if( i > numloops ) { break; } } gettimeofday( &tv_end, 0 ); sec = tv_end.tv_sec - tv_start.tv_sec; usec = tv_end.tv_usec - tv_start.tv_usec; if (usec < 0) { sec--; usec += 1000000; } u64 = sec * 1000000 + usec; cout << "total: " << numloops << "," << sec << ":" << usec << endl; cout << "average: " << numloops << "," << u64/numloops << "usec" << endl; return 0; } XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Cut Here XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

3 9

Boost.Build tests on OSX
by Vladimir Prus 31 Jul '09

31 Jul '09

In the current release state, there are three Boost.Build tests that fail on OSX, and I neither have access to OSX right now nor won't have access to it in future. Could somebody who already has Boost.Build setup, to to tools/build/v2/test and run three commands: python library_chain.py --verbose python library_order.py --verbose python searched_lib.py --verbose And send me the output? Thanks, Volodya

2 3

Re: [boost] 0MQ messaging in Boost
by dhruva 31 Jul '09

31 Jul '09

Hello, Apologies for replying to the chain with no context as I just enabled the mail delivery on this list (was using the web front end). I have a need for a robust and fast peer to peer messaging service in C++. If it has extra language bindings, it makes it better so that I can ask clients to write their own subscribers in any language. I thought of using memcache but that does not work in a pure windows (server and client) environment. MPI seems to be more for distributing work load and not for distributed computing (I confess I still have not understood the differences). 0MQ (zeroMQ) appears to be the best available library from what I know. Since I use Boost and intend to use as much of it as possible to streamline the code and interface, I prefer a solution from Boost distribution. Message Queue is more a pattern and IMO feel it fits into Boost. The same way Boost::Accumulators use Boost::Math, 0MQ could use ASIO and extend ASIO to help application programmers with a MQ implementation. The fact that 0MQ does not use Boost today should not guide the decision on whether to incorporate 0MQ into Boost or not? 0MQ can use the most suitable parts of Boost (ASIO and maybe many more libraries) so that it exposes a similar Boost like interface to the user. Note: Along similar lines, I had posted regarding a distributed lock manager. Message queue and distributed lock manager using ASIO can be great libraries for cluster programming. Boost can become one single requirement for enterprise programming in the distributed/cloud environment. regards, dhruva Yahoo! recommends that you upgrade to the new and safer Internet Explorer 8. http://downloads.yahoo.com/in/internetexplorer/

1 0

Re: [boost] 0MQ messaging in Boost
by Brian Wood 31 Jul '09

31 Jul '09

Yigong Liu writes: > Hello Pieter, > Could you please have a look of "Channel", a message passing library i have > been developing in boost, for a comparison with 0MQ? > website: http://channel.sourceforge.net/ > design doc: > http://channel.sourceforge.net/boost_channel/libs/channel/doc/design.html > download: Hi, Yigong, The following section from the Channel documentation doesn't do much for me. 7.2 compare STL and ChannelSome mapping between STL and Channel's concepts: - containers (sequence, assoc) <=> name spaces (linear/hier/assoc) - elements in container <=> names (unit/element in name space) - iterator_range (target of algorithms) <=> name binding set (sender->receiver(s), receiver->sender(s)) target of dispatchers - algorithms <=> dispatchers Brian Wood Ebenezer Enterprises www.webEbenezer.net "Then Samuel took a rock and set it up between Mizpah and Shen. He named it Ebenezer [Rock of Help] and said, 'Until now the L-RD has helped us.'"

2 1

Subversion upgrade on svn.boost.org
by Doug Gregor 30 Jul '09

30 Jul '09

Hi all, We'd like to upgrade Subversion on svn.boost.org from the old version it is currently using (1.4.2) to version 1.6.2, so that Boost can make use of some of the new and useful features introduced in Subversion 1.5 and 1.6. Since this upgrade will involve an upgrade of the repository, it is likely to take a while---we'll probably have to block out 8 or more hours, during which Subversion will be inaccessible. We would like to perform the Subversion upgrade soon (within the next few days). Are we at a point in Boost's development cycle where we can tolerate a day of down-time to perform this upgrade? - Doug

10 19

Re: [boost] 0MQ messaging in Boost
by Brian Wood 30 Jul '09

30 Jul '09

Maciej Sobczak writes: > A high-level solution - and the one that is reasonably portable - would > need to be coupled/supplemented with serializer/deserializer, which > actually already exists in Boost. In this context the integration with > Boost would indeed make it an interesting exercise, except for the fact > that the Boost serialization library is not very fast. I opened trac 2945 to suggest a performance improvement related to associative containers that could be fairly easily addressed. It doesn't seem to be much of a priority at this point. > My personal and humble opinion is that such a couple would fall out of > your intended/typical benchmarks. How would you promote it then? Who > would constitute the target audience? Companies with no qualms about throwing money at faster hardware? Brian Wood Ebenezer Enterprises www.webEbenezer.net "Then Samuel took a rock and set it up between Mizpah and Shen. He named it Ebenezer [Rock of Help] and said, 'Until now the L-RD has helped us.'"

1 0

Re: [boost] 0MQ messaging in Boost
by Pieter Hintjens 30 Jul '09

30 Jul '09

James Mansion wrote: > This component would be much higher level than anything else in Boost, > except perhaps quickbook and the preprocessor. > I think it should be considered, but with some caution. What is the > intended approach to on-the-wire etc - is it going to be rewritten as > an amqp 1.0 system, for example? These are good questions. 0MQ is high-level in some respects but it is not a competitor to Qpid or OpenAMQ, it's a brokerless library that is fully integrated into client apps. The new 0MQ API looks simply like a socket that can pass messages between points. The wire level protocol is very simple, it does not compare with AMQP (which I'm well aware of, being one of the original designers). You can check the 0MQ protocol (SPB) here: http://rfc.zeromq.org/. One of our projects was to integrate 0MQ with AMQP, but as a very thin and fast client stack. Thus, it would work with OpenAMQ, Qpid, RabbitMQ and in fact provide Boost apps with a fast way to use AMQP networks. There's an experimental branch that does this. @Yigong Liu, regarding Channel: you're definitely looking at the same questions as us. 0MQ perhaps has more focus on performance, it aims at markets where latency has to be in the microseconds. There is also the intention of implementing more complex messaging patterns, but those tend to need brokers. Concretely, we'll: * Look at making 0MQ with Asio * Make the 0MQ licensing work for Boost * Make a proof of concept showing Boost working with 0MQ Which should make things more concrete. Cheers Pieter

4 3

[serialization] Trac issue #2508
by Richard Hazlewood 30 Jul '09

30 Jul '09

Hi Robert, We've been digging a little deeper with this issue; it appears the static warning mechanism is not behaving as expected. Details appended to the issue. HTH.

1 0

AlRangeExandrescu?
by David Abrahams 30 Jul '09

30 Jul '09

Hi Neil, I'm sure someone already spoke to you about this, but just in case: Andrei Alexandrescu gave a very interesting presentation at BoostCon that was based on a "ranges only" approach that should eliminate issues like this one: 2: return type specification for find() etc =========================================== There where no major objection to the mechanism, but some found the syntax ugly. I believe the suggested syntax (e.g.) boost::find[_f,_e]( range, x ) boost::find[_f+1,_e]( range, x ) He says he's implemented a superset of the STL algorithms with it so we know the expressive power is fairly complete. I was wondering if you had given any thought to making use of his insights? Especially considering that RangeEx hasn't been used to fully cover a generic domain (I think), it might make sense. -- David Abrahams BoostPro Computing http://boostpro.com

20 94

0MQ messaging in Boost
by Pieter Hintjens 30 Jul '09

30 Jul '09

Hi, I'm part of the 0MQ team in FastMQ, we're making a free low latency messaging library in C++ and Dhruva suggested it could be useful in Boost. The current stable 0MQ/1.0 is probably too complex to use in Boost but the forthcoming 0MQ/2.0 has a simpler socket-style API (sends messages rather than bytes) and runs with no external components. Dhruva is probably better placed than me to explain how 0MQ could help Boost users. One issue we've already discussed is licensing: currently 0MQ is LGPL, but we'd be prepared to change the license on 0MQ/2.0 to BSL (or dual-license it) so it can be included in Boost. Please excuse in advance my ignorance: I'm neither a developer nor user of 0MQ, but acting as community front-end. Cheers, Pieter Hintjens FastMQ

5 4

[serialization] Latest changes broke module-singleton
by Hartmut Kaiser 29 Jul '09

29 Jul '09

Hi all, I believe the latest changes to the serialization library in trunk broke the encapsulation of module singletons. Module singletons are now accessed across module boundaries (i.e data stored in a different module are looked up locally). A polymorphic class registered using BOOST_CLASS_EXPORT() gets registered in the archive's basic_serializer_map, which is stored in a module-singleton. Ok so far. Now, if this type is serialized by a different module via its base class (which is the usual scenario for us, as all serialization code lives in one place) this code tries to look up the type in the archive's module-singleton (basic_serializer_map) of its own module (I saw this for instance at boost/archive/detail/oserializer.npp, line 413). But the data is stored not there but in the original module, where the type is implemented. As a result the assertion at libs/serialization/src/basic_initializer_map.cpp, line 56 fires. Anything I could do about this? Regards Hartmut

2 6

proposed sorting library benchmark/tuning script
by Steven Ross 29 Jul '09

29 Jul '09

I have a Perl benchmark/tuning script for my sorting library that: 1) optimizes tuning constant values for the system and compiler tested on 2) runs a suite of tests using randomized inputs and compares weighted-average performance vs. std::sort, and at the same time verifies that results are identical. Do I need to convert this to a different scripting language or a C++ application so that everybody can use it? Perl is pretty standard, but not everybody has it installed.

1 0

null instruction ptr bugcheck in regexp
by Heidi Zhou 29 Jul '09

29 Jul '09

Hello! I am using boost regexp to do string/expression match. I got several dump files that have the same call stack when the crash happends. What my code does is copying user buffer (containing string to be mached) to an internal allocated buffer and then call boost regexp functions. From the dmp files, I can tell that register EBP is corrupted in the function boost::re_detail::abstract_protected_call::execute. Before this function, the value of EBP value is correct. Any idea what the cause is? Is there any similar problem that has been known already? Here is the callstack when crash happened. ============================================================================== > 00000000() nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::match_all_states() + 0x9a bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::match_startmark() + 0x194 bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::match_all_states() + 0x9a bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::match_prefix() + 0x39 bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::find_restart_any() + 0xe0 bytes C++ nlca_framework.dll!boost::re_detail::abstract_protected_call::execute() + 0x41 bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::protected_call() + 0x48 bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::find() + 0xa bytes C++ nlca_framework.dll!boost::regex_search<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,wchar_t,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >() + 0xac bytes C++ Heidi

2 3

null instruction ptr bugcheck in regexp
by Heidi Zhou 29 Jul '09

29 Jul '09

Hello! I am using boost regexp to do string/expression match. I got several dump files that have the same call stack when the crash happends. What my code does is copying user buffer (containing string to be mached) to an internal allocated buffer and then call boost regexp functions. >From the dmp files, I can tell that register EBP is corrupted in the function boost::re_detail::abstract_ protected_call::execute. Before this function, the value of EBP value is correct. Any idea what the cause is? Is there any similar problem that has been known already? At the end, it is the callstack when crash happened. Looking forward to hearing from you. Thank you in advance! Heidi ============================================================================== 00000000() nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::match_all_states() + 0x9a bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::match_startmark() + 0x194 bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::match_all_states() + 0x9a bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::match_prefix() + 0x39 bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::find_restart_any() + 0xe0 bytes C++ nlca_framework.dll!boost::re_detail::abstract_protected_call::execute() + 0x41 bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::protected_call() + 0x48 bytes C++ nlca_framework.dll!boost::re_detail::perl_matcher<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >::find() + 0xa bytes C++ nlca_framework.dll!boost::regex_search<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> >,std::allocator<boost::sub_match<std::_String_const_iterator<wchar_t,std::char_traits<wchar_t>,std::allocator<wchar_t> > > >,wchar_t,boost::regex_traits<wchar_t,boost::w32_regex_traits<wchar_t> > >() + 0xac bytes C++

1 0

Boost.StringAlgo:library defects?
by Mathias Gaunard 29 Jul '09

29 Jul '09

As I integrated my Unicode library with Boost.StringAlgo, I noticed a few issues: - The Finder concept seems inappropriate, since find_iterator<last_finderF> can't work as expected. I suggest building left-to-right and right-to-left searching directly into the Finder concept. - Certain functions that take ranges only take Range& and not const Range&. Interestingly enough, in the cases where I've found it does that a const Range& would have been enough. - Usage of the Finder concept is incompatible with its definition. Indeed, finders are passed by const reference, which means the operator() must be const, unlike in the examples. - Finders are explicitly calling boost::as_literal on the string to search for, which I believe should not be their responsibility but that of the callee (or not, but I would have expected a rationale at least). - Why is there no trim variant that simply returns a sub range of the input range? There are only ways to modify the sequence in-place or copy a trimmed one. - Algorithms such as find being pushed in the boost namespace is incompatible with, for example, updated version of Boost.Range (Boost.RangeEx). Since boost::algorithm::find is quite different from std::find, it should not be promoted to boost::find. Since the library is fairly old (2002), I assume some of these issues are known. Is there any plan to fix them?

2 1

proposal - Statistically robust function timing for performance decisions.
by Edward Grace 29 Jul '09

29 Jul '09

Dear All, Having developed what I think is an easy to use C++ library for the robust and statistically meaningful timing of functions I'm looking to place it under the terrifying glare of peer review and to find a home for it. My motivation for its development was simply to be able to state: "Function 'foo' is between 'x' percent and 'y' percent faster than function 'bar' at the 95% confidence level." since I wish to make reliable, automatic, informed decisions about function choice at run-time. While this looks like a trivial problem - it is not! Being able to determine some confidence limits on the relative speedup, particularly when other user processes are active, turns out to be quite challenging. I am aware of code snippets such as http://www.boost.org/doc/libs/1_34_1/libs/multi_index/perf/ test_perf.cpp based on wrap_code.cpp and, while it's better than many approaches, I'm dissatisfied with it. It's not as reliable as one might think at first blush. I am also aware of the timing code used internally in FFTW for selecting codelets - while it may be appropriate for this type of application I do not view it as a reliable general solution to the problem. I strongly suspect that many people reinvent the wheel regarding this problem and make decisions in an ad-hoc manner. There certainly doesn't seem to be a standard and reliable solution. I'm not sure whether Boost is an appropriate home for such a (compile time) library. Is this something anyone 'out there' would be interested in? If it's not the right place - does anyone have any suggestions other than sourceforge.net? I look forward to your responses. Regards, -ed P.S. A typical example of its use is presented in the output below. Here we time two simple and otherwise identical functions, one of which (a) iterates 1000 times, the other (b) 1005. Once we demand of the timer a nominal percentage precision approaching the difference in expected run-time (0.5%) they can be discriminated successfully. It should be noted that this was carried out simply using gettimeofday () while significant user processes were present! ================================== Calibrate overhead (0,1)? 1 Point estimate of clock overhead (t_c): 0.0975994 Potential jitter on t_c : 0.633371 Increasing precision until I can discriminate between function a and b. The nominal confidence interval represents the region: 1-alpha=0.95 Timing at a nominal precision of: 50% 0 1.82141<--- Uncertain. Timing at a nominal precision of: 10% 0 2.00391<--- Uncertain. Timing at a nominal precision of: 2% 0.383285 0.593955<--- Ok. Timing at a nominal precision of: 0.4% 0.411541 0.62412<--- Ok. Timing at a nominal precision of: 0.08% 0.448847 0.582617<--- Ok. Nominal confidence bounds on percentage speedup of A relative to B: 0.448847 [0.516456] 0.582617 ================================== ------------------------------------------------ "No more boom and bust." -- Dr. J. G. Brown, 1997

6 13

Problems with inspection output page for trunk
by Daniel James 29 Jul '09

29 Jul '09

---------- Forwarded message ---------- From: Jeremiah Willcock <jewillco(a)osl.iu.edu> Date: 2009/7/29 Subject: [Boost-docs] Problems with inspection output page for trunk The page at http://boost.cowic.de/rc/inspect-trunk.html is an error message, not a valid inspection report output. The version for the release branch is fine. Could you please take a look at it? Thank you. -- Jeremiah Willcock

1 0

[property_tree] RapidXML needs updating
by Preston A. Elder 29 Jul '09

29 Jul '09

Hi, There is an existing problem with the version of rapidxml included with boost::property_tree (from the trunk, I have this as an SVN external into my own repository for my own project in preparation for it getting into boost proper). If I have something like: <field> </field> The intention is obviously to have the value of field be a space. Since spaces are trimmed and condensed, something like: <field> </field> will not work. It seems that condensing of whitespace is happening AFTER the expansion of the &#xNN; expansion (similarly with &#NNN;). This is obviously an error, because otherwise there is no way for me to have a space as the first or last character (or have multiple spaces in a row). It seems this bug is coming from RapidXML itself. I noticed the version of RapidXML is 1.0. So I downloaded the new version of RapidXML (1.13), and made the necessary changes in xml_parser_read_rapidxml.hpp (namely changing first_child() to first_node() ) and the above problem is fixed. So I would like to request that whoever is maintaining this update the version of RapidXML to the latest one available from the RapidXML website. As an addendum, it would be REAL nice if one could use flags to turn on or off string condensing and trimming. RapidXML provides options for both. Oh, and you might also want to fix this warning: In file included from /sandbox/mantra/trunk/Mantra-I/boost/property_tree/detail/json_parser_read.hpp:18, from /sandbox/mantra/trunk/Mantra-I/boost/property_tree/json_parser.hpp:14, from /sandbox/mantra/trunk/Mantra-I/src/core/admin/command.cpp:20: /sandbox/boost/boost/spirit.hpp:18:4: warning: #warning "This header is deprecated. Please use: boost/spirit/include/classic.hpp" (Remember that I have property_tree as an SVN external pointing to the property_tree directory in boost's trunk, so the above IS current boost head code). Minor issue. PreZ :)

3 3

Building BJam and Boost in Sun's Virtual Box
by Monte Jones 28 Jul '09

28 Jul '09

Hi All, I need to be able to use Boost in a virtual environment, specifically, Sun's Virtual Box. I'm further limited in the company I am working for has not approved any Boost upgrades since 1.34 for use. I thought the best way to approach this would be to build Boost Jam and then Boost within the virtual box. Below is what I've done so far. Downloaded platform independent zip files for Boost Jam 3.14.1 and Boost 1.34.0 and saved into directory I called Boost cd Boost unzipped both files cd boost-jam-3.1.14 sh ./build.sh I received the following: ./build.sh: ^M: not found ./build.sh: ^M: not found ./build.sh: ^M: not found ./build.sh: {^M: not found ./build.sh: ^M: not found ./build.sh: syntax error at line 67: 'elif' unexpected I then attempted sh ./build.sh sunpro and got ./build.sh: ^M: not found ./build.sh: ^M: not found ./build.sh: ^M: not found ./build.sh: {^M: not found sunpro ./build.sh: sunpro^M: not found ./build.sh: syntax error at line 67: 'elif' unexpected Thinking I may need administrative privileges, I did su root and reran the same commands with the same results. I had previously built these versions on a Sun 4800 without problems. Could these errors be the result of running in a virtual box with WindowsXP as the base operating system and an Intel Pentium 4 CPU? Any advice would be greatly appreciated. Thanks, Mont

3 3

[asio] Closing posix::stream_descriptor sets it back to blocking
by Preston A. Elder 28 Jul '09

28 Jul '09

I have two posix::stream_descriptors to the same element, in this case, a dup() of the STDIN_FILENO, reated as such (basically): class MyClass { char buf[4096]; posix::stream_descriptor in; void read(const system::error_code &err, size_t xfer) { // Do something ... then ... in.async_read_some(buffer(buf, 4096), &read); } public: MyClass(io_service &svc) : in(svc, dup(STDIN_FILENO)) { in.async_read_some(buffer(buf, 4096), &read); } }; MyClass *myc; // ... io_service svc; void init() [ char buf[4096]; posix::stream_descriptor stdin(svc, dup(STDIN_FILENO)); stdin.async_read_some(buffer(buf, 4096), &read_func); while (!myc) sleep(1); } // ... void read_func(const system::error_code &err, size_t xfer) { // ... do some stuff ... myc = new MyClass(svc); } The reason I do this is a design one, and it's a lot more complicated than the above, but suffice to say there are lots of other factors involved, and I cannot just pass around the stdin object and send it to the constructor of my MyClass. Making multiple dup's of STDIN_FILENO is really not a problem. And having them in posix::stream_descriptors means they even get cleaned up nicely. That's all well and good, but the problem comes in with how stream_descriptor handles non-blocking I/O. When I do my async_read_some on the stdin object (created in init()), it sets non-blocking I/O, and then sets a flag inside the stdin object. When I create the in object inside of MyClass, it thinks the socket is non-blocking, but when I call the async_read_some function on THAT object, it again sets the FD to non-blocking I/O and sets the internal flag. A little redundant but I can deal with this. In reality that flag should be set by finding out what the blocking state is rather than assuming it's blocking. Here is where the problems start. When the stdin object is destructed (goes out of scope), it CHANGES the blocking state to blocking (because the internal flag says it's non-blocking) before it closes the FD. The code that does this is in detail/reactive_descriptor_service.hpp in both reactive_descriptor_service::destroy() and reactive_descriptor_service::close(). Because both objects are dup's of the same source FD, they all share blocking state, and this now sets my in object inside of MyClass to blocking I/O - without changing the internal flag. Meaning that when I DO get some data, and call MyClass::read, and then go to call async_read_some, now this will be a blocking call because reactive_descriptor_service::async_read_some() sees the flag already set indicating we are non-blocking, and will not re-do it. There is no reason to change the blocking state on a descriptor you are just about to close or destroy. The very idea seems just wrong, you're about to make the descriptor invalid, yet you take the time to change it's blocking state before it becomes invalid? To what purpose? Additionally, there is no way to manually OVERRIDE this internal state with boost calls. For example, executing the following: posix::stream_descriptor::non_blocking_io nb(true); in.command(nb); Will just set a FLAG inside the reactive_descriptor_service that says the user wants the handle to go to non-blocking mode when the next blocking action takes place. It does not alter the state immediately. And since the internal flag state (which is now wrong) is checked first, setting this flag has no effect. The only thing in the end I can do is manually call ioctl myself in my code the first time MyClass::read() is invoked. This then basically makes the blocking state match the internal flag of the 'in' object and from then on everything is fine. But this is klugy. So I would like to request the asio maintainer either a) STOP setting the object back to blocking on close/destroy, given that it serves no purpose when you're just about to close the damn descriptor anyway. b) Set the internal blocking state flag based on the actual blocking state on construction, rather than just assuming it's non-blocking. And c) provide a way to actually change the blocking state of the descriptor, rather than just setting a flag saying we want it changed when you next go to do a blocking I/O operation. There may be a good reason to make such a request, such as the user knowing the state has changed without the reactive_descriptor_service having any knowledge of it, such as in this case. PreZ :)

1 0

[1.40][release][bug-spring] Release Notes
by Daniel James 28 Jul '09

28 Jul '09

Hi all, Since we're moving towards the release, this would be a great time to add your release notes to the site. As always, if you can't or don't want to update the website, reply to this email and I'll do it for you. Also, if you've fixed anything in the bug sprint that's worth mentioning, it should probably be in there. Daniel

2 2

proposal for tree container
by Kasper Peeters 28 Jul '09

28 Jul '09

Hi all, On a regular basis, users of my 'tree.hh' library ask me whether I would be interested in submitting it to boost. As you may have guessed from the name, tree.hh is a templated n-ary tree container class in the spirit of the STL, but of course deviating from it in the sense of offering various ways of iterating over the tree. More info at http://www.aei.mpg.de/~peekas/tree/ Back in 2002 I tried to estimate the interest for inclusion in boost, see http://lists.boost.org/Archives/boost/2002/10/37383.php The most serious criticism back then was the 'lack of abstraction' (for more details please consult the original thread), and I didn't have the time to address that. Given the continuing interest by users of tree.hh to propose it for inclusion in boost, I would like to give this another shot and see what's the current opinion. While I would be happy to clean up the code, I do not have the time to do a substantial rewrite (along the lines suggested in 2002), but would be interested to help someone else do that. License-wise, tree.hh is now available under GPL-2 or 3, but all of the above of course implies that I'd be willing to re-license. Cheers, Kasper

10 13

[test] Documentation license
by Daniel James 27 Jul '09

27 Jul '09

Hi, Would it be possible to add copyright and license info to the test documentation? thanks, Daniel

1 0

Generalized concept usage in Boost libraries
by Mathias Gaunard 27 Jul '09

27 Jul '09

With Concepts removed from C++Ox, people have been disappointed that this chance of making C++ template code generate better error messages was given up. Yet, there is no need for C++0x concepts in order to achieve this. Indeed, we have Boost.ConceptCheck that already makes things a bit simpler. Plus, by extending it with SFINAE for expressions, which allows to detect whether a type models a concept at compile-time, we get almost the same quality in error messages as with C++0x concepts. It would even allow to do concept-based overloading, but since SFINAE for expressions is not an universally supported feature, code shouldn't rely on that. Should all Boost libraries be modified in order to include concept checking, and should it become part of the programming policy? From what I can see, it seems most libraries don't make use of Boost.ConceptCheck at all.

5 7

C++ standards committee meeting schedule
by Beman Dawes 27 Jul '09

27 Jul '09

The schedule for upcoming C++ standards committee meeting is: Oct 19-24, 2009 Santa Cruz CA, USA: Dinkumware Mar 8-13, 2010 Pittsburgh, PA, USA: CERT (date tentative) Jul 12-17, 2010 Rapperswil, Switzerland: HSR Hochschule fr Technik Nov 8-13, 2010 Batavia, IL, USA: Fermilab If you are interested in helping with C++ standardization or submitting a TR2 proposal, a great way to get started is to attend a meeting. Let me know if you are interested. --Beman

5 8

sorting floats by casting to integer
by Steven Ross 27 Jul '09

27 Jul '09

I've been investigating why float_sort is so much faster than std::sort on x86 processors, and why sorting integers is so much faster than float_sort, and came to the conclusion that floating-point comparisons are extremely slow on x86. Based upon that, I've written a different sorting approach that copies the input array of floats, casting them to integers, and sorts them as integers, dealing with the negative floats sorting in reverse order issue, completely eliminating floating-point comparisons. It takes O(n) additional memory, and is somewhat less general, as a different approach is required for key plus data sorting (as non-float data can't be safely cast this way), but it obtains integer-sorting speeds. On some problems it is as much as 120X as fast as std::sort. I doubt average results will be quite that good, but they could easily be well over 10X as fast. Does this sound like it's appropriate for Boost? If so, I'll add it to my proposed Boost.Algorithm.Sorting library, which is complete, aside from this issue. Example source (not templated yet): #define DATATYPE float #define CAST_TYPE int inline void float_as_integer_sort(std::vector<DATATYPE> &input) { if(input.size() < 2) return; std::vector<CAST_TYPE> cast_vec; cast_vec.resize(input.size()); unsigned neg_index = 0; int pos_index = input.size() - 1; //Casting to integer and presorting into negative and positive for(unsigned u = 0; u < input.size(); ++u) { int cast_val = float_mem_cast<DATATYPE, CAST_TYPE>(input[u]); if(cast_val < 0) cast_vec[neg_index++] = cast_val; else cast_vec[pos_index--] = cast_val; } assert((pos_index + 1) == neg_index); //Sort the negatives integer_sort(&(cast_vec[0]), &(cast_vec[neg_index])); //Then the positives integer_sort(&(cast_vec[neg_index]), &(cast_vec[0]) + cast_vec.size()); //casting back negatives for(unsigned u = 0; u < neg_index; ++u) std::memcpy(&(input[neg_index - u - 1]), &(cast_vec[u]), sizeof(DATATYPE)); //Then positives for(unsigned u = neg_index; u < cast_vec.size(); ++u) std::memcpy(&(input[u]), &(cast_vec[u]), sizeof(DATATYPE)); }

9 24

boost trunk issues
by Sean Farrow 25 Jul '09

25 Jul '09

Hi: is There an issue updating the boost trunk, When trying to update, I get the error: Error OPTIONS of 'http://svn.boost.org/svn/boost/trunk': 200 OK (http://svn.boost.org) I've done an svn cleanup. Any help appreciated. Sean.

4 3

[pool][Ticket #2359]Performance impact of bug fix
by Peter Hurley 25 Jul '09

25 Jul '09

The bug fix implemented for this ticket has a significant (approx 25~35%) performance impact when using fast_pool_allocator for the shared_ptr<> allocator, as in, static fast_pool_allocator<T> pool; shared_ptr<T> a(T,Tdestroyer,pool); Background: Although http://svn.boost.org/trac/boost/ticket/2359 has an extensive analysis and discussion of the problem, the key issue was that static non-local fast_pool_allocators did *not* force the prior construction of the underlying singleton_pool instance (class template static data members have unordered initialization). The fix implemented was to call singleton_pool<...>::is_from(0); in the ctors of fast_pool_allocate to enforce the proper construction order (for global ctors). Of course, this fix effects all scope & lifetime fast_pool_allocators. Problem: However, is_from() performs other, non-trivial work as well. From singleton_pool.hpp, template <...> struct singleton_pool { . . static bool is_from(void * const ptr) { pool_type & p = singleton::instance(); details::pool::guard<Mutex> g(p); return p.p.is_from(ptr); } Although the impact at startup is neglible, the copy ctor of fast_pool_allocator is called during the construction -and- the destruction of *every* shared_ptr<T> a(P,D,A). (Because the shared_ptr needs to rebind the allocator from <T> to sp_counted_impl_pda<P,D,A> ). The net effect is that the pool is locked and accessed *twice* every time a shared_ptr is constructed or destructed. Because of the locking overhead, even in a single-threaded environment, shared_ptr<T> a(P,D,fast_pool_allocator<T> > does not out-perform shared_ptr<T> a(P,D)! This situation is especially painful in a contentious MP environment. One solution (although by-no-means exhaustive) would be to only perform the bare minimum necessary to force prior construction of the singleton_pool instance. For example, in boost/pool/singleton_pool.hpp, template <...> struct singleton_pool { . . static void force_construction() { singleton::instance(); } and in boost/pool/pool_alloc.hpp fast_pool_allocator() { singleton_pool<fast_pool_allocator_tag, sizeof(T), UserAllocator, Mutex, NextSize>::force_construction(); } template <typename U> fast_pool_allocator( const fast_pool_allocator<U, UserAllocator, Mutex, NextSize> &) { singleton_pool<fast_pool_allocator_tag, sizeof(T), UserAllocator, Mutex, NextSize>::force_construction(); } Regards, Peter Hurley PS - Also, casual profiling (gcc,x86,windows) seems to indicate that using boost::detail::spinlock as the default lock from <boost/smart_ptr/detail/spinlock.hpp> would yield add'l performance benefits over details::pool::default_mutex. Faster yet would be a native locked_compare_exchange spinlock similar to the atomic_conditional_increment() implemented in the <sp_counted_base_***.hpp> headers...

1 0

Random numbers question
by Anant Rao 25 Jul '09

25 Jul '09

Hi, I'm using Mersenne Twister algo to generate random numbers on Windows and Linux using the same code. Boost ver 1.39. Here's the simple code I have: boost::mt19937 rng(43); boost::uniform_01<boost::mt19937> zeroone(rng); float randomNumber = zeroone(); If I run it multiple times, I get the same result on the same OS, as expected. However, the random numebrs are different between Windows and Linux. Is this the expected behavior? Is there anything I can do to get the same random numbers on Windowd and Linux? Thanks a lot, Anant

2 3

Request for Review - Boost Algorithm
by Marshall Clow 24 Jul '09

24 Jul '09

Boost.Algorithm is a collection of useful algorithms, most from the "Library in a week" session from BoostCon 2008. The code (and tests) are available in the sandbox. -- Marshall

4 4

[filesystem][spirit] problems with scoped enums with GCC 4.4 in C++0x mode
by Richard Webb 24 Jul '09

24 Jul '09

(forwarding from the Spirit list) As discussed in the thread @ http://www.nabble.com/-Spirit2--Regression-test-failures-on-GCC-4.4-in-C%2B…, the regression tests for Filesystem and Spirit 2 are pretty much all failing in GCC 4.4 in C++0x mode, due to problems with scoped enums and operator ==. Does anyone have any other ideas about the problem? Thanks, Richard Webb -- View this message in context: http://www.nabble.com/-filesystem--spirit--problems-with-scoped-enums-with-… Sent from the Boost - Dev mailing list archive at Nabble.com.

3 3

[TR1][Hash] New failures?
by John Maddock 24 Jul '09

24 Jul '09

Anyone any idea what's causing the TR1:Hash tests to fail on the release branch? The TR1 code hasn't changed so I assume that a change in Boost::hash has broken these? Cheers, John.

2 4

[python] "Boost.Python Build and Test HOWTO" doc suggestion
by Beman Dawes 24 Jul '09

24 Jul '09

In the Requirements section, change: Boost.Python requires Python 2.2 or newer. to: Boost.Python requires Python 2.2 or newer. Both the Python runtime and the development (i.e. header) packages must be installed. --Beman

1 0

[mpi][serialization] Compilation broken
by Juergen Hunold 24 Jul '09

24 Jul '09

Hi ! Boost.MPI is currently broken on trunk due to r54934 | ramey | 2009-07-13 23:37:49 +0200 (Mon, 13 Jul 2009) | 2 lines which removed D /trunk/boost/archive/detail/archive_pointer_iserializer.hpp D /trunk/boost/archive/detail/archive_pointer_oserializer.hpp and now MPI fails to compile with: gcc.compile.c++ /build/bjam/boost_1.40.0/libs/mpi/build/gcc-4.4/debug/content_oarchive.o $BOOST_ROOT/libs/mpi/src/content_oarchive.cpp:10:62: error: boost/archive/impl/archive_pointer_oserializer.ipp: No such file or directory It seems that the regression tests don't catch this because no regression tester has MPI configured... It would be nice if at least the Linux testers could install MPI on their machines... I don't know enough about MPI and/or serialization to fix this myself, I just have MPI installed to get less warnings from older Boost.Build versions... Yours, Jürgen -- * Dipl.-Math. Jürgen Hunold ! Ingenieurgesellschaft für * voice: ++49 511 262926 57 ! Verkehrs- und Eisenbahnwesen mbH * fax : ++49 511 262926 99 ! Lister Straße 15 * juergen.hunold(a)ivembh.de ! www.ivembh.de * * Geschäftsführer: ! Sitz des Unternehmens: Hannover * Prof. Dr.-Ing. Thomas Siefer ! Amtsgericht Hannover, HRB 56965 * PD Dr.-Ing. Alfons Radtke !

3 4

Important: Subversion upgrade on Saturday, July 25
by Doug Gregor 23 Jul '09

23 Jul '09

We will be upgrading Boost's Subversion server and the Boost Subversion repository to Subversion 1.6.3. This upgrade will bring the new features provided by the Subversion 1.5.x and 1.6.x released to Boost, including merge tracking: http://subversion.tigris.org/svn_1.5_releasenotes.html http://subversion.tigris.org/svn_1.6_releasenotes.html The upgrade will begin on Saturday, July 25 at 8:00AM EST, and is likely to take all day. During this upgrade, the Boost Subversion repository, Trac, and mailing list archives will be inaccessible. However, the Boost mailing lists should still function normally. I will send a note to the Boost list when the upgrade is complete. Thank you for your patience. - Doug

2 2

AlRangeExandrescu?
by Neil Groves 23 Jul '09

23 Jul '09

On Thu, Jul 23, 2009 at 3:03 PM, Thorsten Ottosen < thorsten.ottosen(a)dezide.com> wrote: > David Abrahams skrev: > >> Hi Neil, >> >> I'm sure someone already spoke to you about this, but just in case: Andrei >> Alexandrescu gave a very interesting presentation at BoostCon that was based >> on a "ranges only" approach that should eliminate issues like this one: >> >> 2: return type specification for find() etc >> =========================================== >> There where no major objection to the mechanism, but some found >> the syntax ugly. I believe the suggested syntax (e.g.) >> >> boost::find[_f,_e]( range, x ) >> >> boost::find[_f+1,_e]( range, x ) >> >> >> He says he's implemented a superset of the STL algorithms with it so we >> know the expressive power is fairly complete. >> > > If I remember correctly, he claims that his return of find() is the > "correct" one. I think that is plain wrong, as the syntax above shows that > there are many useful return ranges, perhaps with an obvious default. > > So the above is not an "issue" IMO, but a usable feature. > Yes, that is what I was trying to describe earlier. If we want a parameterisable return range, we need a parameter and an addition to the syntax, Perhaps the assumption that a parameterisable return range is desirable is at fault in which case Andrei's answer is the right one. I agree with Thorsten that the current RangeEx solution is superior because, the parameterisable return is optimally efficient whereas adapters applied to a more general range return type incurs overhead in space and time. I do fully intend to look at Andrei's work in more depth. My previous comment about studying the work briefly was not intended to indicate satisfaction with this state, merely that I am currently ignorant of the full ramifications of the proposed Range Concepts. > > -Thorsten > Neil Groves

1 0

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

23 Jul '09

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

11 30

slightly off topic- using GDB on cygwin to debug a DLL
by Robert Ramey 23 Jul '09

23 Jul '09

In the past I've used GDB under cygwin to debug serialization test failures for the gcc compiler. This has worked pretty well. However, now I have a couple of tests test_dll_simple and test_dll_exported that I want to debug. When I try this I get the following error message: gdb: unknown target exception 0xc0000135 at 0x7c964ed1 I'm thinking that this might be an indicator that "it" can't find the dlls which are part of the test as they are in a different place in the directory hierarchy than the test executable. Does anyone with experience with this have any suggestions as to what to do? Robert Ramey

2 1

Boost.Function comparison, again
by David Abrahams 23 Jul '09

23 Jul '09

The docs say: When comparing against an instance of reference_wrapper, the address of the object in the reference_wrapper is compared against the address of the object stored by the function object wrapper: a_stateful_object so1, so2; f = boost::ref(so1); assert(f == boost::ref(so1)); assert(f == so1); // Only if a_stateful_object is EqualityComparable assert(f != boost::ref(so2)); I take it from the above that so1 == so2 implies f == so2 function_equal(so1,so2) implies f == so2 ? Neither one of those is made entirely clear from the above. It appears that the library assumes a function object may be _stored_ by ref f = boost::ref(so1); for efficiency reasons, but will only be _compared_ by ref assert(f == boost::ref(so1)); because so1 is stateful. What is the rationale for this asymmetry? Is there a role for the is_stateless type trait in smoothing over these bumps? Seems to me that if you know the type is stateless, comparing addresses isn't very useful. TIA, -- Dave Abrahams BoostPro Computing http://www.boostpro.com

1 0

[uuid] proposed fix for windows_generator.hpp
by Christian Leutloff 22 Jul '09

22 Jul '09

Hi, In boost/uuid/windows_generator.hpp a conversion routine is used that does return a UUID but it is not the same as the one that was generated through the call to UuidCreate(). I have attached a test case that is showing the difference of the choosen implementationen and the expected one. The expected one was validated using the VS debugger, too. I would like that the provided convertion routines from the windows specific GUID/UUID structure to boost::uid and vice versa will be included in boost::uuid, too. I'm using the v13 version from the vault. Should I open a bug report for this issue? Bye Christian -- Christian Leutloff, Aachen, Germany ______________________________________________________ GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de

2 1

Static Libraries / Multiply Defined Symbols
by Audino, Jeremy 22 Jul '09

22 Jul '09

Using Visual Studio 2005, I have two independent static libraries making use of boost. When linking both into an executable I'm getting some multiply defined symbols. I suspect that since most of boost's implementation is header-only, symbols for the boost library functions are appearing in both libraries. I can get around this by specifying /FORCE:MULTIPLE when linking, but this isn't ideal. Is there a better way to get around this? Best Regards, Jeremy libNMRSD.lib(NMRSModule.obj) : error LNK2005: "public: __thiscall `bool __cdecl boost::interprocess::winapi::get_file_name_from_handle_function(void *,wchar_t *,unsigned int,unsigned int &)'::`7'::library_unloader::library_unloader(void *)" (??0library_unloader@?6??get_file_name_from_handle_function@winapi@interprocess@boost@@YA_NPAXPA_WIAAI@Z@QAE@0@Z) already defined in libDICOMTOOLSD.lib(Log.obj) libNMRSD.lib(NMRSModule.obj) : error LNK2005: "public: __thiscall `bool __cdecl boost::interprocess::winapi::get_file_name_from_handle_function(void *,wchar_t *,unsigned int,unsigned int &)'::`7'::library_unloader::~library_unloader(void)" (??1library_unloader@?6??get_file_name_from_handle_function@winapi@interprocess@boost@@YA_NPAXPA_WIAAI@Z@QAE@XZ) already defined in libDICOMTOOLSD.lib(Log.obj) libNMRSD.lib(NMRSModule.obj) : error LNK2005: "public: __thiscall `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`9'::handle_closer::handle_closer(void *)" (??0handle_closer@?8??unlink_file@winapi@interprocess@boost@@YA_NPBD@Z@QAE@PAX@Z) already defined in libDICOMTOOLSD.lib(Log.obj) libNMRSD.lib(NMRSModule.obj) : error LNK2005: "public: __thiscall `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`9'::handle_closer::~handle_closer(void)" (??1handle_closer@?8??unlink_file@winapi@interprocess@boost@@YA_NPBD@Z@QAE@XZ) already defined in libDICOMTOOLSD.lib(Log.obj) libNMRSD.lib(NMRSModule.obj) : error LNK2005: "public: __thiscall `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`11'::auto_ptr::auto_ptr(union `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`10'::mem_t *)" (??0auto_ptr@?L@??unlink_file@winapi@interprocess@boost@@YA_NPBD@Z@QAE@PATmem_t@?9??1234@YA_N0@Z@@Z) already defined in libDICOMTOOLSD.lib(Log.obj) libNMRSD.lib(NMRSModule.obj) : error LNK2005: "public: __thiscall `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`11'::auto_ptr::~auto_ptr(void)" (??1auto_ptr@?L@??unlink_file@winapi@interprocess@boost@@YA_NPBD@Z@QAE@XZ) already defined in libDICOMTOOLSD.lib(Log.obj) libNMRSD.lib(NMRSModule.obj) : error LNK2005: "public: union `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`10'::mem_t * __thiscall `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`11'::auto_ptr::get(void)const " (?get@auto_ptr@?L@??unlink_file@winapi@interprocess@boost@@YA_NPBD@Z@QBEPATmem_t@?9??2345@YA_N0@Z@XZ) already defined in libDICOMTOOLSD.lib(Log.obj) libNMRSD.lib(NMRSModule.obj) : error LNK2005: "public: union `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`10'::mem_t * __thiscall `bool __cdecl boost::interprocess::winapi::unlink_file(char const *)'::`11'::auto_ptr::operator->(void)const " (??Cauto_ptr@?L@??unlink_file@winapi@interprocess@boost@@YA_NPBD@Z@QBEPATmem_t@?9??1234@YA_N0@Z@XZ) already defined in libDICOMTOOLSD.lib(Log.obj) C:\home\jaudino\src\prs-removal\bin\translatorD.exe : fatal error LNK1169: one or more multiply defined symbols found Jeremy F. Audino Senior Software Development Engineer Philips Healthcare -- Nuclear Medicine Tel: 440-483-7444 E-mail: jeremy.audino(a)philips.com ________________________________ The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

3 3

FreeBSD regression testing
by Bruce Simpson 22 Jul '09

22 Jul '09

Hi all, Thanks to whomever cleaned up the old runs on this page: http://www.boost.org/development/tests/release/developer/summary.html I just wanted to ask: * what's the procedure here, are old runs cleaned up automatically? * Is there a preferred naming convention for the runs? We're aware of some issues with Boost.Build on 64-bit FreeBSD platforms at the moment. I'll be starting another run shortly, but will be performing it on i386, so as to avoid the FAILs we're seeing. I just merged a fix to FreeBSD's system gcc to deal with some issues in global 'using' declarations, that should bring FreeBSD-STABLE/i386 closer to the other platforms in terms of Boost stability. I would like to get a slice of FreeBSD cluster resources to run the Boost regression tests periodically, so I'll have a chat with the cluster admins about it. thanks, BMS

2 1

[threadpool] renmaed to task
by k-oli＠gmx.de 22 Jul '09

22 Jul '09

Hello, boost.threadpool is renamed to boost.task - the review schdule list should be updated soon. Oliver

1 0

[1.40.0] Release plans
by Beman Dawes 22 Jul '09

22 Jul '09

I've been missing in action for most of the month, working on C++ committee stuff. Sigh. Rather than set a new release schedule for 1.40.0 right now, I'm planning to spend the next week or so looking at the state of the release branch, and pestering folks as needed. As that process proceeds I'll get a better sense of what a reasonable schedule would be to finish the release. In the meantime, the release branch is still open for merges as long as they are stable on trunk tests. --Beman

1 0

[introspection] Status
by Richard Hazlewood 22 Jul '09

22 Jul '09

I see the vault contains some introspection helpers (for checking for member function existence). AFAICT these utilities are not currently in boost nor scheduled for review. Are there any plans to bring them forward? (There appears to be an overlap with some of the introspection utils in mpl - though only for member variables there.)

5 6

FW: [uuid] changes to fix warnings from the linker
by christian.leutloff＠web.de 22 Jul '09

22 Jul '09

Hi, thank you for the boost.uuid lib! Could you please add some more "inline"s to some of the methods to avoid warnings from the VS2008 compiler? I'm using the uuid implementation from uuid_alt_v13_pod.zip downloaded from http://www.boostpro.com/vault/index.php. This is one of the warnings: warning LNK4006: "bool __cdecl boost::uuids::operator<(class boost::uuids::uuid const &,class boost::uuids::uuid const &)" (??Muuids@boost@@YA_NABVuuid@01@0@Z) already defined in xxx.obj; second definition Here is the patch to fix the warnings: Index: boost/uuid/uuid.hpp =================================================================== --- boost/uuid/uuid.hpp (revision 65) +++ boost/uuid/uuid.hpp (working copy) @@ -152,28 +152,28 @@ x.swap(y); } -bool operator==(uuid const& lhs, uuid const& rhs) /* throw() */ +inline bool operator==(uuid const& lhs, uuid const& rhs) /* throw() */ { return (lhs.data_ == rhs.data_); } -bool operator!=(uuid const& lhs, uuid const& rhs) /* throw() */ +inline bool operator!=(uuid const& lhs, uuid const& rhs) /* throw() */ { return !(lhs == rhs); } -bool operator<(uuid const& lhs, uuid const& rhs) /* throw() */ +inline bool operator<(uuid const& lhs, uuid const& rhs) /* throw() */ { return (lhs.data_ < rhs.data_); } -bool operator>(uuid const& lhs, uuid const& rhs) /* throw() */ +inline bool operator>(uuid const& lhs, uuid const& rhs) /* throw() */ { return rhs < lhs; } -bool operator<=(uuid const& lhs, uuid const& rhs) /* throw() */ +inline bool operator<=(uuid const& lhs, uuid const& rhs) /* throw() */ { return !(lhs > rhs); } -bool operator>=(uuid const& lhs, uuid const& rhs) /* throw() */ +inline bool operator>=(uuid const& lhs, uuid const& rhs) /* throw() */ { return !(lhs < rhs); } @@ -191,7 +191,7 @@ } // As named in RFC 4122, 4.1.7 -uuid nil() { +inline uuid nil() { uuid u = uuid(); return u; } Index: boost/uuid/uuid_io.hpp =================================================================== --- boost/uuid/uuid_io.hpp (revision 65) +++ boost/uuid/uuid_io.hpp (working copy) @@ -22,7 +22,7 @@ namespace detail { -int get_showbraces_index() +static int get_showbraces_index() { static int index = std::ios_base::xalloc(); return index; Index: boost/uuid/uuid_namespaces.hpp =================================================================== --- boost/uuid/uuid_namespaces.hpp (revision 65) +++ boost/uuid/uuid_namespaces.hpp (working copy) @@ -42,7 +42,7 @@ namespace namespaces { /* Name string is a fully-qualified domain name */ -uuid dns() { +inline uuid dns() { uuid u = { /* 6ba7b810-9dad-11d1-80b4-00c04fd430c8 */ 0x6b, 0xa7, 0xb8, 0x10, 0x9d, 0xad, @@ -53,7 +53,7 @@ } /* Name string is a URL */ -uuid url() { +inline uuid url() { uuid u = { /* 6ba7b811-9dad-11d1-80b4-00c04fd430c8 */ 0x6b, 0xa7, 0xb8, 0x11, 0x9d, 0xad, @@ -64,7 +64,7 @@ } /* Name string is an ISO OID */ -uuid oid() { +inline uuid oid() { uuid u = { /* 6ba7b812-9dad-11d1-80b4-00c04fd430c8 */ 0x6b, 0xa7, 0xb8, 0x12, 0x9d, 0xad, @@ -75,7 +75,7 @@ } /* Name string is an X.500 DN (in DER or a text output format) */ -uuid x500() { +inline uuid x500() { uuid u = { /* 6ba7b814-9dad-11d1-80b4-00c04fd430c8 */ 0x6b, 0xa7, 0xb8, 0x14, 0x9d, 0xad, Bye Christian -- Christian Leutloff, Aachen, Germany ______________________________________________________ GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT! Jetzt freischalten unter http://movieflat.web.de

1 0

[1.40] release schedule?
by joaquin＠tid.es 22 Jul '09

22 Jul '09

Hi, The Google Calendar schedule for Boost 1.40 (http://www.boost.org/development/index.html ) says we're one day past the beta delivery date. How does this schedule still apply? Is it OK to make doc changes to the release branch? Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

2 1

[Date_Time] -proposal to overload tz_database::load_from_file method
by Slawomir Dors 21 Jul '09

21 Jul '09

Hi ! I'm using the Date_Time library on Windows. The "tz_database" has only one method to populate it with the data from "date_time_zonespec.csv" file. It is "load_from_file" method which takes a filename in std::string. I wonder if it's possible to overload that method so it could be more generic (and much more useful). It could take for example a reference to std::istream object. The idea is to avoid to save the data in a .csv file on a disk. I could then put the data in the resources of an .exe or .dll file, create some stream object derived from std::istream and load into the "tz_database" object. The second limitation of the existing version of "load_from_file" is that I can't use unicode string to provide the filename. What the Developers think about such small addition ? Cheers, Slawomir Dors

1 0

_WIN32_WINNT in thread\src\win32\thread.cpp and filesystem\src\operations.cpp
by James Mansion 21 Jul '09

21 Jul '09

Why does win32\thread.cpp unconditionally define _WIN32_WINNT and WINVER? That's a bit rude, especially when I go to lengths to set them properly in a file I pass as BOOST_USER_CONFIG. :-( This also applies in filesystem\src\operations.cpp: in that case it does check that _WIN32_WINNT isn't defined already, but there has been no inclusion of config.h so BOOST_USER+CONFIG has not been processed yet. I would have though that in both cases the correct response is to remove these explicit settings and just: #include <boost/config.h> James (Using 1.39.0 on Vista, BTW - and setting _WIN32_WINNT by detection in my waf script)

2 1

[smart_ptr] shared_ptr template type
by Frank Mori Hess 21 Jul '09

21 Jul '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I wonder if it might be better/possible to have a shared_ptr<T> that didn't assume its corresponding "raw" pointer type was T* but rather T. For example, what is now a shared_ptr<int> would be specified as a shared_ptr<int*>. The motivation would be to allow support for other classes as the "raw" pointer type. For example, I might want to have a shared_ptr<monitor<T*> > where the monitor<T*> has an operator->() which does automatic locking/unlocking of a mutex before/after forwarding the operator->() to the plain T pointer. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpWA5YACgkQ5vihyNWuA4UQOwCeI7sjr4/pByXIqRtactVfi8fk MUgAoLmstL+7V5NW+yYNXyDPlVog7VAI =JE48 -----END PGP SIGNATURE-----

8 29

[TypeTraits] Type traits for member pointers?
by Celtic Minstrel 20 Jul '09

20 Jul '09

I recently noticed that the Boost Type Traits library does not include any traits for member pointers apart from identification. For example, there are no "add member pointer" or "remove member pointer" traits, nor a trait to extract the containing type from a member pointer (ie extract Q from T Q::*). And there is no trait for decomposing member function pointers. It would appear that these traits could be added fairly easily; I was able to create them within a few minutes, and verify that they worked (with g++). Is there sufficient reason to add them to the library? For me, completeness seems like reason enough (unless it would be a lot of work). On the other hand, member pointers are, as far as I know, rarely used. So, um... thoughts? Is it a good idea? Should I post my code? --SPCD "Celtic Minstrel"

4 7

Re: [boost] Boost::Serialization Combined XML- and Binary-Serialization
by Daniel Kunz 20 Jul '09

20 Jul '09

Hallo, I found my failure with xml serialization. It works now! Thanks Robert Ramey! Now I just have my problems with binary serialization. Can somebody help me with this? Best regards. Daniel Robert Ramey wrote: >Try replacing >> boost::serialization::binary_object bo = >> boost::serialization::make_binary_object(minute, >with > boost::serialization::binary_object bo = > boost::serialization::make_binary_object(& minute, >Robert Ramey >Daniel Kunz wrote: >> Hello, >> I try to write an function, which can convert data via the >> serialization interface >> XML --> class --> binary AND >> binary --> class --> XML >> I read the documentation and in the mailing lists but I could not >> finish my functions. >> >> I have 2 problems: >> 1) the xml function delivers no xml data in my testfile output >> 2) I cannot add the binary structure to the existing xml-working >> classes >> With the binary serialization I didn't find many informations, but >> that informations I found I can't use with the classes I prepared for >> xml serialization >> Is it possible to combine that 2 serializations >> >> Here is my testing code I worked with so far. The finish >coding is >> similar with that class structure. >> >> The class structure: >> >> -------------------------------------------------------- >> goal.cpp >> -------------------------------------------------------- >> #include <string> >> #include <iostream> >> >> using namespace std; >> >> #include <boost/serialization/base_object.hpp> >> #include <boost/serialization/list.hpp> >> #include <boost/serialization/is_abstract.hpp> >> >> #include <boost/archive/xml_iarchive.hpp> >> #include <boost/archive/xml_oarchive.hpp> >> #include <boost/archive/binary_iarchive.hpp> >> #include <boost/archive/binary_oarchive.hpp> >> #include <boost/serialization/binary_object.hpp> >> namespace serialization >> { >> >> class Goal >> { >> public: >> enum Scored{home=0, visitors=1}; >> Goal(){}; >> Goal(const string _name, int &_minute, bool &_shootout, Scored >> &_scored, bool &_penality); >> ~Goal(){}; >> friend ostream & operator<<(ostream &os, const Goal &_goal); >> private: >> friend class boost::serialization::access; >> template<class Archive> >> void serialize(Archive & ar, const unsigned int version) >> { >> using boost::serialization::make_nvp; >> ar & make_nvp("Name", name); >> ar & make_nvp("Minute", minute); >> ar & make_nvp("Shootout", shootout); >> ar & make_nvp("Scored", scored); >> ar & make_nvp("Penality", penality); >> >> boost::serialization::binary_object bo = >> boost::serialization::make_binary_object(minute, >> sizeof(minute)); >> ar & bo; >> } >> string name; >> int minute; >> bool shootout; >> Scored scored; >> bool penality; >> }; >> } >> >> -------------------------------------------------------- >> stadium.h >> -------------------------------------------------------- >> #include <string> >> #include <iostream> >> >> using namespace std; >> #include <boost/serialization/base_object.hpp> >> #include <boost/serialization/list.hpp> >> #include <boost/serialization/is_abstract.hpp> >> >> #include <boost/archive/xml_iarchive.hpp> >> #include <boost/archive/xml_oarchive.hpp> >> #include <boost/archive/binary_iarchive.hpp> >> #include <boost/archive/binary_oarchive.hpp> >> >> namespace serialization >> { >> >> class Stadium >> { >> private: >> friend class boost::serialization::access; >> template<class Archive> >> void serialize(Archive & ar, const unsigned int version) >> { >> using boost::serialization::make_nvp; >> ar & make_nvp("Name", name); >> ar & make_nvp("City", city); >> ar & make_nvp("Spectators", spectators); >> } >> string name; >> string city; >> int spectators; >> public: >> Stadium(){}; >> Stadium(const string _name, const string _city, int >> &_spectators); friend ostream & operator<<(ostream &os, >> Stadium &_stadium); }; >> } >> >> -------------------------------------------------------- >> match.h >> -------------------------------------------------------- >> #include <list> >> #include <time.h> >> #include <string> >> #include <iostream> >> #include <cstdio> >> >> using namespace std; >> >> #include <boost/serialization/base_object.hpp> >> #include <boost/serialization/list.hpp> >> #include <boost/serialization/is_abstract.hpp> >> >> #include <boost/archive/xml_iarchive.hpp> >> #include <boost/archive/xml_oarchive.hpp> >> #include <boost/archive/binary_iarchive.hpp> >> #include <boost/archive/binary_oarchive.hpp> >> #include <boost/serialization/serialization.hpp> >> >> #include "goal.h" >> #include "stadium.h" >> >> namespace serialization >> { >> >> class Match >> { >> private: >> friend class boost::serialization::access; >> template<class Archive> >> >> void serialize(Archive & ar, const unsigned int version) >> { >> using boost::serialization::make_nvp; >> ar & make_nvp("Home", home); >> ar & make_nvp("Visitors", visitors); >> ar & make_nvp("Kickoff", kickoff); >> ar & make_nvp("Goals", goals); >> ar & make_nvp("Stadium", stadium); >> } >> string home; >> string visitors; >> time_t kickoff; >> typedef list<Goal> lGoals; >> lGoals goals; >> Stadium stadium; >> public: >> Match(){}; >> Match(const string _home, const string _visitors, time_t >> &_kickoff, Goal *_goals, int size, Stadium &_stadium); >> Match& operator = (Match &_match); >> friend ostream & operator<<(ostream &out, Match &_match); >> }; >> } >> >> -------------------------------------------------------- >> xml.cpp >> -------------------------------------------------------- >> #include <boost/archive/xml_iarchive.hpp> >> #include <boost/archive/xml_oarchive.hpp> >> >> #include <iomanip> >> #include <iostream> >> #include <fstream> >> #include <string> >> >> #include "goal.h" >> #include "stadium.h" >> #include "match.h" >> >> #include <boost/serialization/base_object.hpp> >> #include <boost/serialization/utility.hpp> >> #include <boost/serialization/list.hpp> >> #include <boost/serialization/is_abstract.hpp> >> >> using namespace std; >> >> void save_xml(const serialization::Match &m, const string &filename) >> { >> try >> { >> ofstream ofs(filename.c_str()); >> assert(ofs.good()); >> boost::archive::xml_oarchive oa(ofs); >> oa << boost::serialization::make_nvp("Match", m); >> } >> catch(exception &e) >> { >> cout << e.what() << endl; >> } >> } >> >> void restore_xml(serialization::Match &m, const string &filename) >> { >> try >> { >> ifstream ifs(filename.c_str()); >> boost::archive::xml_iarchive ia(ifs); >> ia >> boost::serialization::make_nvp("Match", m); >> } >> catch(exception &e) >> { >> cout << e.what() << endl; >> } >> } >> >> -------------------------------------------------------- >> binary.cpp >> -------------------------------------------------------- >> void save_bin(const serialization::Match &m, const string &filename) >> { >> try >> { >> std::ofstream ofs(filename.c_str()); >> boost::archive::binary_oarchive oa(ofs); >> //oa << m; >> } >> catch(exception &e) >> { >> cout << e.what() << endl; >> } >> } >> >> void restore_bin(serialization::Match &m, const string &filename) >> { >> try >> { >> std::ifstream ifs(filename.c_str()); >> boost::archive::binary_iarchive ia(ifs); >> //ia >> m; >> } >> catch(exception &e) >> { >> cout << e.what() << endl; >> } >> } >> >> >> I hope somone can help me. I don't know what I can do to complete that >> functions. >> >> Best regards >> Daniel

2 2

RFC - MapReduce library is now available in the Vault
by Craig Henderson 19 Jul '09

19 Jul '09

I have uploaded the first public release of my MapReduce library to the Boost Vault (I don't yet have write access to the sandbox). The ZIP file is very small, 38Kb, and can be downloaded here: http://tinyurl.com/boost-mapreduce-zip More general discussion about my implementation of MapReduce and associated Distributed File System is on my blog at http://craighenderson.co.uk/blog/ The library is fully functional on Windows with MSVC8, and compiles cleanly with GCC 3.4.4 on Cygwin (but not tested). I'd appreciate comments from anyone with other platforms/compilers on whether it builds & runs. I'll get the code into the sandbox asap, and would welcome patches to support other platforms. Documentation is included in the zip and provides a tutorial and example application. A full reference document of the classes in the library is not yet included, but I'm working on it. I would very much welcome all comments on the library and suggestions on its design and style. I am keen to progress this to submit for a formal review to become a part of Boost in the near future. Many thanks -- Craig Craig Henderson <http://craighenderson.co.uk/> http://www.craighenderson.co.uk http://www.siteupdatenotification.com

1 0

[array] Custom constructr/destructor
by Kasra 18 Jul '09

18 Jul '09

Hello, I have found an interesting problem regardin using custom allocators/deallocators for an array object. Say for example you want to initialise the array to some values and on destruction you want to do something with these values. This at the memoment is not possible. The solution is to create a new class which inherits from array. template<class T, std::size_t N> class array; template<class T, std::size_t N> class my_array: public array<T,N> { my_array() { ... } ~my_array() { ... } }; Which is not an ideal solution and results in code bloat. However a defenition like bellow: template<class T, std::size_t N, class PredCtor, class PredDtor> class array; Means the same code could be used for custom operations during construction and destruction. Is there any interest in such a change? If so maybe we could propose this for the standard. Yours truly, -- Kasra

2 1

program_options easy_init
by Zachary Turner 18 Jul '09

18 Jul '09

I'm just wondering if there's a specific reason why boost::program_options::options_description_easy_init::operator() takes arguments (const char*, value_semantic, const char*) instead of (const std::string&, value_semantic, const std::string&)? Nothing major, but it's annoying when you want to pass something like str1+str2 as one of the string arguments.

2 1

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

18 Jul '09

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

5 4

[graph] Graph and AdjacencyMatrix
by Andrew Sutton 18 Jul '09

18 Jul '09

There was a bug reported (#3266) that brings up a valid problem with the BGL concept hierarchy and the edge() function. It turns out that virtually every graph defines the edge() function, but only the AdjacencyMatrix concept actually requires it as part of its interface. This means that every algorithms (e.g., Kolomogrov's Max Flow) that uses the edge() function implicitly requires graphs to model the AdjacencyMatrix concept. Since we're addressing edge-related operations, we could also take this time to clean up some of the confusion on source, target, and edge descriptors. Specifically, source() and target() are always defined and that edge descriptors - even those for undirected graphs - imply directionality. Basically, it doesn't matter if the underlying graph implementation defines source and target, the adaptation to the BGL /has to/ in order for even the most basic algorithms to work correctly. I suggest that we modify the Graph concept to define the following valid expressions. edge(u, v, g) -> pair<edge_descriptor, bool> source(e, g) -> vertex_descriptor target(e, g) -> vertex_descriptor And the following semantics: source(edge(u, v, g), g) == u target(edge(u, v, g), g) == v edge, source, target = O(E) // upper bound on an edge list. Basically this requires the edge() function to preserve the source/target ordering of the vertices in the edge that it describes. I don't believe that any graph implementations or adaptors need to be modified in order to support these changes. We can then modify the AdjacencyMatrix concept to document a refinement of the edge function, specifically that it return in O(1) time. Does anybody see any obvious problems with these changes? Andrew Sutton andrew.n.sutton(a)gmail.com

2 4

[xpressive] Performance Tuning?
by Stewart, Robert 17 Jul '09

17 Jul '09

I was experimenting with Xpressive to see how it would compare with some custom, string-based numeric input parsing. The Xpressive code is over 175X slower than the custom code. Have I done anything to make it really slow? Can it be made faster? I have included the Xpressive code and the performance testing code below for your study. Can you spot anything I've done wrong? (BTW, I tried using Spirit.Qi for this -- with Boost 1.37 -- but never could get things to compile. I gave up and decided I'd wait until I can use a newer release before I fight that fight again. :-} ) FYI: bar::numeric_cast winds up calling strtod(), strtol(), etc. It is semantically equivalent to lexical_cast. #include <boost/xpressive/xpressive_static.hpp> #include <boost/xpressive/regex_actions.hpp> namespace foo { namespace op { template <class T> struct numeric_cast { typedef T result_type; template <class Value> T operator ()(Value const & _value) const { return bar::numeric_cast<T>(_value); } }; } struct direct_impl { typedef int64_t result_type; template <class Value> int64_t operator ()(Value const & _value) const { int64_t result(bar::numeric_cast<int64_t>(_value)); result *= 160000; return result; } }; struct to_price_impl { typedef int64_t result_type; template <class Value> int64_t operator ()(Value const & _value) const { int64_t result(0); if (_value) { double const value(bar::numeric_cast<double>(_value)); result = static_cast<int64_t>( std::floor(160000.0 * value + 0.5)); } return result; } template <class Value> int64_t operator ()(Value const & _numerator, Value const & _denominator) const { unsigned const numerator(bar::numeric_cast<unsigned>(_numerator)); unsigned const denominator(bar::numeric_cast<unsigned>(_denominator)); double const fraction((160000.0 * numerator) / denominator); return static_cast<int64_t>(std::floor(fraction + 0.5)); } template <class Value> int64_t operator ()(Value const & _whole, double const _fraction) const { int const whole(bar::numeric_cast<int>(_whole)); double const value(160000.0 * whole + _fraction); return static_cast<int64_t>(std::floor(value + 0.5)); } }; int64_t parse(std::string const & _value); boost::xpressive::function<direct_impl>::type const direct = {{}}; boost::xpressive::function<to_price_impl>::type const to_price = {{}}; BOOST_PROTO_DEFINE_FUNCTION_TEMPLATE( 1 , numeric_cast , boost::proto::default_domain , (boost::proto::tag::function) , ((op::numeric_cast)(typename)) ) } int64_t foo::parse(std::string const & _value) { using namespace boost::xpressive; if (_value.empty()) { return 0; } int64_t result; bool negative(false); sregex zero = as_xpr('0'); sregex sign = as_xpr('-') [ ref(negative) = true ] | as_xpr('+'); // ignore // ignore leading zeroes to avoid octal parsing sregex fraction = ( !zero >> (s1= +_d) >> !blank >> '/' >> !blank >> !zero >> (s2= +_d) ) [ ref(result) = to_price(s1, s2) ]; sregex real = ( *_d >> '.' >> *_d >> !((set= 'E', 'e', 'G', 'g') >> +_d) ) [ ref(result) = to_price(_) ]; // ignore leading zeroes to avoid octal parsing sregex whole_number = ( !zero >> (s1= +_d) >> +blank >> fraction ) [ ref(result) = to_price(s1, ref(result)) ]; // ignore leading zeroes to avoid octal parsing sregex integer = ( !zero >> (s1= +_d) ) [ ref(result) = direct(s1) ]; sregex price = *blank >> !sign >> (real | whole_number | fraction | integer) >> *space; smatch match; if (!regex_match(_value.begin(), _value.end(), match, price)) { throw price_parsing_failed(_value); } if (negative) { result = -result; } return result; } void test_performance() { Timer timer; std::string const input("1234.5678e10"); int64_t total(0); foo::parse(input); // prime the cache timer.start(); for (int i(0); i < 10000000; ++i) { int64_t price(foo::parse(input)); price += i; total += price; } timer.stop(); std::cout << timer.elapsed() << "s elapsed (total = " << total ')' << std::endl; } _____ Rob Stewart robert.stewart(a)sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.

9 34

Boost filesystem get_temporary_file()
by Craig Henderson 17 Jul '09

17 Jul '09

I cannot find any function in the Boost.Filesystem library to get a temporary filename. There has been some discussion about this functionality on the lists many years ago - did anything come of this? I need a cross-platform way to do this and was hoping boost would provide it :) Thanks -- Craig Craig Henderson <http://craighenderson.co.uk/> http://www.craighenderson.co.uk http://www.siteupdatenotification.com

2 1

[smart_ptr] copyable_ptr?
by Ross Levine 17 Jul '09

17 Jul '09

I was wondering if boost has considered a smart pointer that is similar to scoped_ptr but supports deep copy semantics. This would be useful in classes which use the pimpl idiom, as a common way to program these classes is with a scoped_ptr or auto_ptr, but then a copy constructor and copy assignment operator needs to be defined. Herb Sutter worked on an implementation at http://www.gotw.ca/gotw/062.htm, so there's precedent. Is there any interest for this?

6 6

[string algo] trim() requirements to high
by Thorsten Ottosen 16 Jul '09

16 Jul '09

Hi Pavol, It seems to me that trim() and its variants that currently take a Sequence argument can be made to work iterator ranges too. For example: boost::sub_range<std::string> foo = ...; trim_left( foo ); The requirement would be trim_left: forward range trim_right: bidirectional range trim: bidirectional range Am I missing something? -Thorsten

1 0

[Progress]
by Pierre 16 Jul '09

16 Jul '09

Hello, I have a suggestion over boost/progress.hpp. The class is very good. But I have a critic to announce. If we want to use the class to just keep an eye of the evolution of the process (we do not can just say we don't want a stream output (i'm right??)). I.E : to send the progress pourcentage to a graphical progress bar. So I purpose something like the following : A basic class to manage the evolution of a process. A class to display the evolution of the process that use the precedent one. It's possible I misunderstanding the progress_display class to tell it that we don't want stream output (example to feed a graphical progress bar). The body of the functions and classes will be something like : #include <iostream> #include <string> using namespace std; // CProgress --------------------------------------------------------// // CProgress manage the appropriate count_step of progress // Usage : // CProgress progress( COUNT ); // for(int i=0; i < COUNT; ++i, ++progress) //{ // ... //do something //} //-- you can access to internal data : // //cout<< "Count : " << my_progress_bar.count() << " pourcent " << my_progress_bar.count()/(float)my_progress_bar.expected_count()*100; class CProgress { public: explicit CProgress ( unsigned long expected_count=1 ) { restart ( expected_count ); } virtual void restart ( unsigned long expected_count ) // Effects: display appropriate scale // Postconditions: count()==0, expected_count()==expected_count { _count = _next_tic_count = _tic = 0; _expected_count = expected_count; if ( !_expected_count ) _expected_count = 1; // prevent divide by zero } // restart unsigned long operator+= ( unsigned long increment ) // Effects: Increment appropriate progress tic if needed. // Postconditions: count()== original count() + increment // Returns: count(). { if ( ( _count += increment ) >= _next_tic_count ) { inc_tic(); } return _count; } unsigned long operator++() { return operator+= ( 1 ); } //-- Accessor unsigned long count() const { return _count; } unsigned long expected_count() const { return _expected_count; } protected: unsigned long _count, _expected_count, _next_tic_count; unsigned int _tic; private: virtual void inc_tic() { _next_tic_count = static_cast<unsigned long> ( ( _tic/50.0 ) *_expected_count ); } // inc_tic }; // CProgress_display --------------------------------------------------------// // CProgress_display displays an appropriate indication of // progress at an appropriate place in an appropriate form. // Usage : // CProgress_display my_progress_bar( fileList.size() ); // for (list<string>::const_iterator it = fileList.begin(); it != fileList.end(); ++it, ++my_progress_bar) // the CProgress_display::operator++ take in charge the display of the progression (***) // { // const string & filename = *it; // ... // do something // } // //0% 10 20 30 40 50 60 70 80 90 100% //|----|----|----|----|----|----|----|----|----|----| //************************** ... class CProgress_display : public CProgress { public: explicit CProgress_display ( unsigned long expected_count, std::ostream & os = std::cout, const std::string & s1 = "\n", //leading strings const std::string & s2 = "", const std::string & s3 = "" ) // os is hint; implementation may ignore, particularly in embedded systems : m_os ( os ), m_s1 ( s1 ), m_s2 ( s2 ), m_s3 ( s3 ) { restart ( expected_count ); } void restart ( unsigned long expected_count ) // Effects: display appropriate scale // Postconditions: count()==0, expected_count()==expected_count { CLTU_Progress::restart ( expected_count ); //-- Initialize the base class m_os << m_s1 << "0% 10 20 30 40 50 60 70 80 90 100%\n" << m_s2 << "|----|----|----|----|----|----|----|----|----|----|" << std::endl // endl implies flush, which ensures display << m_s3; } // restart private: std::ostream & m_os; // may not be present in all imps // string is more general, safer than const char *, and efficiency or size are not issues const std::string m_s1, m_s2, m_s3; // formatting display void inc_tic() { // use of floating point ensures that both large and small counts // work correctly. static_cast<>() is also used several places // to suppress spurious compiler warnings. unsigned int tics_needed = static_cast<unsigned int> ( ( static_cast<double> ( _count ) /_expected_count ) *50.0 ); do { m_os << '*' << std::flush; } while ( ++_tic < tics_needed ); _next_tic_count = static_cast<unsigned long> ( ( _tic/50.0 ) *_expected_count ); if ( _count == _expected_count ) { if ( _tic < 51 ) m_os << '*'; m_os << std::endl; } } // display_tic }; _________ I'm sure the community will be open to discuss about it. Talk to you, Best, Pierre

2 2

boost.uuid is_pod failure
by Tim Blechmann 16 Jul '09

16 Jul '09

hi all, using boost.uuid from uuid_alt_v13_pod.zip, i get some static assertion failures of is_pod<boost::uuid> --- test_uuid.cpp~ 2008-12-06 02:27:38.000000000 +0100 +++ test_uuid.cpp 2009-07-15 10:59:01.016387917 +0200 @@ -22,6 +22,8 @@ #include <string> #include <vector> + +BOOST_STATIC_ASSERT(boost::is_pod<boost::uuid>::value); int test_main(int, char*[]) { i am not sure, whether it is a problem of is_pod or uuid, though ... best, tim -- tim(a)klingt.org http://tim.klingt.org Lesser artists borrow, great artists steal. Igor Stravinsky

3 3

Bug sprint aftermath questions.
by Marshall Clow 16 Jul '09

16 Jul '09

Now the bug sprint is over - I have a few questions..... * Was the bug sprint worth doing? * If so, is it worth doing again? How soon? Regularly? How often? * What worked really well? * What didn't work well? I'm also looking for general comments.... Facts: * We went from 797 open tickets to 706. (that's a change of 12%) * A lot of very old tickets were dealt with; the oldest Trac ticket is now from 2005 (instead of 2001). * There's still several tickets that have patches waiting to be applied. * The Trac system had a few problems ("locked database") and is still having spam problems, but worked reasonably well. -- -- Marshall Marshall Clow Idio Software <mailto:marshall@idio.com> It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.

10 13

Behavior change in path operator /
by Gérald Fauvelle 16 Jul '09

16 Jul '09

Hi all, I'm updating my boost version from 1.33 to 1.38... That's a big step, and I've found a difference in operator / of filesystem::path. In 1.33, when I was doing : path a = path("d:/toto/titi"); path b = path("d:/tata/tutu"); path c = a/b; I had c == "d:/tata/tutu" So if b was a complete (or absolute) path, the result was b, whatever value has "a". I don't know if this behavior was correct or not, but we were using it this way, it was fine. Now with 1.38, I have : c == "d:/toto/titi/d:/tata/tutu" That is at first different from previous behavior, and also obviously wrong for a path syntax on Windows at least. It seems also that in 1.33 a path like this would raise an exception. I've tried to find when, in what version, this change occured, but couldn't find it in release notes. Was this change made intentionanly, if yes, what is the reason for that? And if I want previous behavior, I have 2 solutions. Fix my code, of fix boost code. I'm afraid that if I fix boost code I could break some boost functionnalities, or can I do it with no problem ? Thanks, Gérald

2 2

[convert] Now with Boost.Parameter interface.
by Vladimir.Batov＠wrsa.com.au 16 Jul '09

16 Jul '09

I've incorporated, uploaded to the Vault and started playing with the Boost.Parameter-based interface that Andrey Semashev was insisting from the set-go. And it is definitely growing on me and I like int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true); instead of the original int i = convert<int>::from(str, 0) >> new_locale >> dothrow; I think people generally did not like locales and dothrow behaving like manipulators. The more I use the Boost.Parameter-based interface the more I am inclined to push it further and apply it to manipulators as well. I.e. int i = convert<int>::from(str)(radix_ = 16); instead of the original direct handling of std manipulators. int i = convert<int>::from(str) >> std::hex; Something, again, Andrey was advocating from the start. Now it feels like allowing io-stream manipulators exposes too much implementation detail and raises some unwarranted expectations. That raises a few questions that I am hoping people could help me with: 1. Both interfaces (for locale and dothrow) are currently supported: #1 int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true); #2 int i = convert<int>::from(str, 0) >> new_locale >> dothrow; Should I remove #1? 2. Both interfaces #1 int i = convert<int>::from(str, 0) >> std::hex; #2 int i = convert<int>::from(str, 0)(radix_ = 16); are currently supported. Should I move away from direct manipulator support and remove #1? 3. I only managed to figure out how to supply only one Boost.Parameter at a time like int i = convert<int>::from(str, 0)(locale_ = new_locale)(throw_ = true); I understand how to achieve int i = convert<int>::from(str, 0)((locale_ = new_locale, throw_ = true)); (with double quotes) but do not want to go there as it looks somewhat unorthodox. I cannot figure out how to achieve the following int i = convert<int>::from(str, 0)(locale_ = new_locale, throw_ = true); (a list inside single quotes). I remember Andrey mentioning I could do that with a Boost.Parameter macro but I admit of not being bright enough to figure it out by myself. Any help would be greatly appreciated. Thanks, Vladimir.

15 49

Re: [boost] gcc-4.4.0 and boost::optional is giving (spurious?) strict-aliasing warnings
by Giovanni Piero Deretta 15 Jul '09

15 Jul '09

On Thu, May 7, 2009 at 3:37 AM, Kim Barrett <kab.conundrums(a)verizon.net> wrote: > At 7:17 PM -0300 5/5/09, Brad Spencer wrote: >> > > In boost/aligned_storage.hpp, the class template > boost::aligned_storage defines its address member function thusly: > > void* address() { return this; } > const void* address() const { return this; } > I'm not 100% sure, but this could be very wrong as, IIRC, there is no guarantee that for non PODS the address of the first element (i.e. aligned_storage.data_) is the same as 'this'. but why doesn't aligned storage implements address() as: void * address { return this.data_.data_.buf; } BTW, I see that boost optional actually uses its own implementation of aligned storage, whose address member function returns a pointer to a char buffer, so it shouldn't be a problem. > There is code in boost/optional/optional.hpp (and probably the other > libs you mention) which looks like: > > internal_type* get_object() { > return static_cast<internal_type*>(m_storage.address()); > } > > What this leads, after some expansion, to something roughly equivalent > to > > static_cast<internal_type*>( > static_cast<void*>( > <a pointer to an instance of aligned_storage> )) > > which I believe is not strict aliasing safe. It is effectively a cast > from aligned_storage* to internal_type*, with a trip through void* > along the way. That trip through void* does not make the conversion > satisfy the strict aliasing rules. > IIRC aliasing rules talk about dynamic types of objects: roughly, you can access a memory location only with a type which is the same as the *dynamic type* of that location or as a char array. Boost optional does an explicit placement new of the stored type on the buffer which changes the dynamic type of the buffer so it should be safe from a standard point of view. Before reusing the buffer It invokes the destructor of the type, which ends the object lifetime. That said, gcc has been known to miscompile placement new from time to time (but it should be more or less fixed on recent versions: it pretty much acts as a compiler optimization barrier). In the end, IMHO the warning is spurious and could be safely ignored (modulo compiler bugs). > [Note that it is not the cast itself that violates the strict aliasing > rules, it is the later dereference of the pointer resulting from the > cast.] > > [Note that I'm pretty sure that switching from static_cast to > reinterpret_cast doesn't help.] > > One of the escape hatches provided by the strict aliasing rules > involves ensuring that there is a union type in scope at the point of > the conversion which contains both of the involved types. [The > "visible union" rule of 6.5.2.3#5.] I do not think this rule actually help you: you can't still read from a field different from the last written to (except for some exceptions like structures with common initial sequences.) Most compilers give additional guarantees, though. > Another escape hatch offered by the strict aliasing rules involves > memcpy and memmove. [6.5#6] I think that the following implementation of > aligned_storage::address will satisfy the strict aliasing rules: > > void* address() { > void* data = data_.data_.buf; > return memmove(data, data, sizeof(*data)); > } > > And I think gcc will optimize away the memmove, at least at sufficient > optimization levels. But note that I have not tested this at all. > > [Hm, using a size of 0 or 1 or some similar small value might be > sufficient to quiet the compiler; I'm not certain whether it is > sufficient to satisfy the letter of the C standard.] I do not see how this helps, first of all sizeof(*data) is illegal (sizeof(void) doesn't make any sense, gcc defines it as 1 as an extension), then how copying one byte will fix aliasing problems? > > The idea is that memmove (and memcpy, but that requres non-overlapping > source and destination, which we don't have here) is defined by the > aliasing rules to strip away the type of the destination, in a way > that a simple cast does not. I do not think it really strips away the type of the destination: in fact it is often unsed to bit cast from integers to float and back: if a memcpy(&some_float, &some_integer, sizeof(int32_t)) really did change the type of some_float, it would break a lot of code (you could no longer threat some_float as a float). What is guarateed is that some_float will contain the same bit pattern of some_integer, while still maintaining the float type. It assumes that the bit pattern of the source is a valid pattern for the destination type, otherwise it is UB. > > [And yes, I agree that this is rather grotesque.] > Aliasing rules really are a mess. -- gpd

3 3

Boost::Serialization Combined XML- and Binary-Serialization
by Daniel Kunz 15 Jul '09

15 Jul '09

Hello, I try to write an function, which can convert data via the serialization interface XML --> class --> binary AND binary --> class --> XML I read the documentation and in the mailing lists but I could not finish my functions. I have 2 problems: 1) the xml function delivers no xml data in my testfile output 2) I cannot add the binary structure to the existing xml-working classes With the binary serialization I didn't find many informations, but that informations I found I can't use with the classes I prepared for xml serialization Is it possible to combine that 2 serializations Here is my testing code I worked with so far. The finish coding is similar with that class structure. The class structure: -------------------------------------------------------- goal.cpp -------------------------------------------------------- #include <string> #include <iostream> using namespace std; #include <boost/serialization/base_object.hpp> #include <boost/serialization/list.hpp> #include <boost/serialization/is_abstract.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/archive/binary_oarchive.hpp> #include <boost/serialization/binary_object.hpp> namespace serialization { class Goal { public: enum Scored{home=0, visitors=1}; Goal(){}; Goal(const string _name, int &_minute, bool &_shootout, Scored &_scored, bool &_penality); ~Goal(){}; friend ostream & operator<<(ostream &os, const Goal &_goal); private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { using boost::serialization::make_nvp; ar & make_nvp("Name", name); ar & make_nvp("Minute", minute); ar & make_nvp("Shootout", shootout); ar & make_nvp("Scored", scored); ar & make_nvp("Penality", penality); boost::serialization::binary_object bo = boost::serialization::make_binary_object(minute, sizeof(minute)); ar & bo; } string name; int minute; bool shootout; Scored scored; bool penality; }; } -------------------------------------------------------- stadium.h -------------------------------------------------------- #include <string> #include <iostream> using namespace std; #include <boost/serialization/base_object.hpp> #include <boost/serialization/list.hpp> #include <boost/serialization/is_abstract.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/archive/binary_oarchive.hpp> namespace serialization { class Stadium { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { using boost::serialization::make_nvp; ar & make_nvp("Name", name); ar & make_nvp("City", city); ar & make_nvp("Spectators", spectators); } string name; string city; int spectators; public: Stadium(){}; Stadium(const string _name, const string _city, int &_spectators); friend ostream & operator<<(ostream &os, Stadium &_stadium); }; } -------------------------------------------------------- match.h -------------------------------------------------------- #include <list> #include <time.h> #include <string> #include <iostream> #include <cstdio> using namespace std; #include <boost/serialization/base_object.hpp> #include <boost/serialization/list.hpp> #include <boost/serialization/is_abstract.hpp> #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <boost/archive/binary_iarchive.hpp> #include <boost/archive/binary_oarchive.hpp> #include <boost/serialization/serialization.hpp> #include "goal.h" #include "stadium.h" namespace serialization { class Match { private: friend class boost::serialization::access; template<class Archive> void serialize(Archive & ar, const unsigned int version) { using boost::serialization::make_nvp; ar & make_nvp("Home", home); ar & make_nvp("Visitors", visitors); ar & make_nvp("Kickoff", kickoff); ar & make_nvp("Goals", goals); ar & make_nvp("Stadium", stadium); } string home; string visitors; time_t kickoff; typedef list<Goal> lGoals; lGoals goals; Stadium stadium; public: Match(){}; Match(const string _home, const string _visitors, time_t &_kickoff, Goal *_goals, int size, Stadium &_stadium); Match& operator = (Match &_match); friend ostream & operator<<(ostream &out, Match &_match); }; } -------------------------------------------------------- xml.cpp -------------------------------------------------------- #include <boost/archive/xml_iarchive.hpp> #include <boost/archive/xml_oarchive.hpp> #include <iomanip> #include <iostream> #include <fstream> #include <string> #include "goal.h" #include "stadium.h" #include "match.h" #include <boost/serialization/base_object.hpp> #include <boost/serialization/utility.hpp> #include <boost/serialization/list.hpp> #include <boost/serialization/is_abstract.hpp> using namespace std; void save_xml(const serialization::Match &m, const string &filename) { try { ofstream ofs(filename.c_str()); assert(ofs.good()); boost::archive::xml_oarchive oa(ofs); oa << boost::serialization::make_nvp("Match", m); } catch(exception &e) { cout << e.what() << endl; } } void restore_xml(serialization::Match &m, const string &filename) { try { ifstream ifs(filename.c_str()); boost::archive::xml_iarchive ia(ifs); ia >> boost::serialization::make_nvp("Match", m); } catch(exception &e) { cout << e.what() << endl; } } -------------------------------------------------------- binary.cpp -------------------------------------------------------- void save_bin(const serialization::Match &m, const string &filename) { try { std::ofstream ofs(filename.c_str()); boost::archive::binary_oarchive oa(ofs); //oa << m; } catch(exception &e) { cout << e.what() << endl; } } void restore_bin(serialization::Match &m, const string &filename) { try { std::ifstream ifs(filename.c_str()); boost::archive::binary_iarchive ia(ifs); //ia >> m; } catch(exception &e) { cout << e.what() << endl; } } I hope somone can help me. I don't know what I can do to complete that functions. Best regards Daniel

2 1

Re: [boost] [log] Review-ready version in the Vault
by Michael C. Stricklin 15 Jul '09

15 Jul '09

The latest version of boost.log (from the repository) fails to compile under gcc 4.1.0 (although it does fine under 4.1.2). I see the same errors compiling against both 1.38 and 1.39. The problems appears to lie with inherits from mpl. I can provide error logs if requested. Many Thanks, Mike Stricklin

5 5

[interprocess] flat_multiset/flat_multimap missing?
by Thorsten Ottosen 15 Jul '09

15 Jul '09

Hi Ion, It would be nice if these containers were also avaiable. Thanks -Thorsten

1 0

[mpl] possible regression compiling with Visual C++
by Edd Dawson 15 Jul '09

15 Jul '09

Hi folks, The following code compiles fine against Boost 1.34.1 and 1.35.0, but apparently not anything later. I've tried 1.36.0 and 1.39.0. I'm compiling with Microsoft's Visual C++ 2005 and 2009 compilers (the express editions if it matters). #include <boost/mpl/remove.hpp> #include <boost/mpl/vector.hpp> #include <boost/preprocessor/repetition/enum_params.hpp> #include <boost/preprocessor/repetition/enum_params_with_a_default.hpp> template<BOOST_PP_ENUM_PARAMS_WITH_A_DEFAULT(BOOST_MPL_LIMIT_VECTOR_SIZE, typename T, void)> struct X { typedef typename boost::mpl::vector<BOOST_PP_ENUM_PARAMS(BOOST_MPL_LIMIT_VECTOR_SIZE, T)>::type template_parameters; // mpl::vector of template parameters typedef typename boost::mpl::remove < template_parameters, void > ::type template_parameters_no_voids; // voids removed }; int main() { X<int> x; return 0; } The error messages using Boost 1.39.0 and Visual C++ 2005: mpl_regression.cpp M:\libs\boost\1.39.0\boost/mpl/aux_/push_back_impl.hpp(45) : error C2664: 'boost::mpl::assertion_failed' : cannot convert parameter 1 from 'boost::mpl::failed ************(__thiscall boost::mpl::push_back_impl<Tag>::apply<Sequence,T>::REQUESTED_PUSH_BACK_SPECIALIZATION_FOR_SEQUENCE_DOES_NOT_EXIST::* ***********)(Sequence)' to 'boost::mpl::assert<false>::type' with [ Tag=boost::mpl::aux::vector_tag<20>, Sequence=boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>, T=boost::mpl::has_push_back_impl<boost::mpl::aux::vector_tag<20>> ] No constructor could take the source type, or constructor overload resolution was ambiguous M:\libs\boost\1.39.0\boost/mpl/push_back.hpp(32) : see reference to class template instantiation 'boost::mpl::push_back_impl<Tag>::apply<Sequence,T>' being compiled with [ Tag=boost::mpl::aux::vector_tag<20>, Sequence=boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>, T=boost::mpl::has_push_back_impl<boost::mpl::aux::vector_tag<20>> ] M:\libs\boost\1.39.0\boost/mpl/aux_/has_type.hpp(20) : see reference to class template instantiation 'boost::mpl::push_back<Sequence,T>' being compiled with [ Sequence=boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>, T=boost::mpl::has_push_back_impl<boost::mpl::aux::vector_tag<20>> ] M:\libs\boost\1.39.0\boost/mpl/aux_/push_back_impl.hpp(55) : see reference to class template instantiation 'boost::mpl::aux::has_type<T>' being compiled with [ T=boost::mpl::push_back<boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>,boost::mpl::has_push_back_impl<boost::mpl::aux::vector_tag<20>>> ] M:\libs\boost\1.39.0\boost/mpl/push_back.hpp(43) : see reference to class template instantiation 'boost::mpl::has_push_back_impl<Tag>::apply<Seq>' being compiled with [ Tag=boost::mpl::aux::vector_tag<20>, Seq=boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void> ] M:\libs\boost\1.39.0\boost/mpl/if.hpp(63) : see reference to class template instantiation 'boost::mpl::has_push_back<Sequence>' being compiled with [ Sequence=boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void> ] M:\libs\boost\1.39.0\boost/mpl/remove.hpp(48) : see reference to class template instantiation 'boost::mpl::if_<T1,T2,T3>' being compiled with [ T1=boost::mpl::has_push_back<boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>>, T2=boost::mpl::aux::remove_impl<boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>,void,boost::mpl::back_inserter<boost::mpl::clear_impl<boost::mpl::aux::vector_tag<20>>::apply<boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>>::type>>, T3=boost::mpl::aux::reverse_remove_impl<boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>,void,boost::mpl::front_inserter<boost::mpl::clear_impl<boost::mpl::aux::vector_tag<20>>::apply<boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>>::type>> ] mpl_regression.cpp(18) : see reference to class template instantiation 'boost::mpl::remove<P1,P2>' being compiled with [ P1=boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>, P2=void ] mpl_regression.cpp(23) : see reference to class template instantiation 'X<T0>' being compiled with [ T0=int ] M:\libs\boost\1.39.0\boost/mpl/aux_/push_back_impl.hpp(45) : error C2866: 'boost::mpl::push_back_impl<Tag>::apply<Sequence,T>::mpl_assertion_in_line_6' : a const static data member of a managed type must be initialized at the point of declaration with [ Tag=boost::mpl::aux::vector_tag<20>, Sequence=boost::mpl::vector20<int,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void,void>, T=boost::mpl::has_push_back_impl<boost::mpl::aux::vector_tag<20>> ] Is this a problem with more recent versions of Boost, or am I doing something wrong? It looks like it's complaining because an mpl::vector of maximal static size doesn't implement push_back, but it surely shouldn't need to for a remove operation? Kind regards, Edd

4 6

gcc4.3 warning for multiple scope_exits
by Kim Barrett 14 Jul '09

14 Jul '09

Boost.ScopeExit uses a tricky bit of code (from Steven Watanabe) to allow a macro expansion to contain code which will declare a variable exactly once, regardless of how many times the macro is used in a given scope. Unfortunately, gcc4.3 -Wall generates a warning for this code in the second and later uses of the macro in the same scope. The warning is comparisons like X<=Y<=Z do not have their mathematical meaning It is complaining about a statement that gets parsed as identifier < 0 > variable; Valid code, and correct in this particular case, but the warning is there never the less. I realize that boost doesn't have a no-warnings policy (dealing with compiler variations that lead to actual errors is hard enough), but since my team has a general policy of using -Werror and I've been proselytizing the use of scope_exit within our group, I was motivated to find a way to kill this warning. After studying Steven's trick (ouch! my brain hurts) I've come up with an extension of the same technique which avoids the warning, using the time honored approach of adding another level of indirection. Here's my patch: ---------- --- scope_exit.hpp.orig 2009-07-09 13:19:36.000000000 -0400 +++ scope_exit.hpp.new 2009-07-09 13:20:04.000000000 -0400 @@ -36,14 +36,21 @@ typedef void* declared; struct undeclared { declared dummy[2]; }; + template<int> + struct holder + { + declared value; + static const int apply_value = 0; + friend void operator>(int, const holder&) {} + }; + template<> struct declare<sizeof(undeclared)> { template<int> struct apply { - declared value; - friend void operator>(bool, const apply&) {} + static const int apply_value = 0; }; }; @@ -214,8 +221,9 @@ BOOST_PP_SEQ_FOR_EACH_I(BOOST_SCOPE_EXIT_AUX_MEMBER, id, seq) \ BOOST_SCOPE_EXIT_AUX_PARAMS_T_CTOR(id, seq) \ } BOOST_SCOPE_EXIT_AUX_PARAMS(id) BOOST_SCOPE_EXIT_AUX_PARAMS_INIT(id, seq)\ - boost::scope_exit::aux::declare<sizeof(boost_scope_exit_args)> \ - ::apply<0> boost_scope_exit_args; \ + boost::scope_exit::aux::holder< \ + boost::scope_exit::aux::declare<sizeof(boost_scope_exit_args)> \ + ::apply<0>::apply_value> boost_scope_exit_args; \ boost_scope_exit_args.value = &BOOST_SCOPE_EXIT_AUX_PARAMS(id); \ struct BOOST_SCOPE_EXIT_AUX_GUARD_T(id) { \ BOOST_SCOPE_EXIT_AUX_PARAMS_T(id)* boost_se_params_; \

2 4

[task] new version 0.2.2
by k-oli＠gmx.de 13 Jul '09

13 Jul '09

Hello, I've added boost.task-0.2.2 to boost.vault: - allow user-defined execution policies - private inheritance from noncopyable removed from task< R > and static_pool< R > copy-ctor and assignment-op private and unimplemented allowing correct move-semantics - worker_group removes all worker-threads in join_all() static_pool< R > does contain zero worker-threads after shutdown() or shutdown_now() - reintroduction of make_task() - internal refactoring/rework - documentation updated - tests updated - examples updated best regards, Oliver

1 0

MS VC 2010 Beta 1
by Dennis Yurichev 13 Jul '09

13 Jul '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi. Somebody already had a success on building Boost with new MS VC 2010 Beta 1? - -- My PGP public key: http://yurichev.com/dennis.yurichev.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpXG0UACgkQ1YPmFmJG++N68gCg2YD+xA03lNt4AKnKBd435h/C JP8AnRXr+MRktAzGLIFTWRUQJMHmySGl =ctCu -----END PGP SIGNATURE-----

2 1

program_options custom validators
by Zachary Turner 13 Jul '09

13 Jul '09

Hello, recently I was faced with a situation of writing a custom validator for a certain command line option I wanted to handle. The validator was supposed to check whether the value on the command line was in a certain range. After some head scratching, I realized there's no elegant way to do this with the current validation overload function. In the end I just ended up doing the validation after the options had been parsed. I was thinking about a good way to support this, and I thought that maybe the best way is to add an additional value semantic so that the validate function could instead be: template<class T, class validation_data> void validate(boost::any& v, const std::vector<std::string>& values, const validation_data& data, T* target_type, int); and we could write add_options() ("test", value<int>()->validate(boost::interval<int>(1, 10)) ); this would require the user to provide the following overload: void validate(boost::any& v, std::vector<std::string>& values, const boost::interval<int>& data, int* target_type, int); the default implementation of validate would all use some dummy type for validation_data, this way compilation would fail if user calls validate but does not provide the appropriate overload. And if the user does not want to provide additional validation data he can simply use the current syntax, but instead would provide the following validate() overload void validate(boost::any& v, const std::vector<std::string>& values, const no_validation_data& data, T* target_type, int); Thoughts? Zach

2 3

intrusive_ptr design question
by Zachary Turner 13 Jul '09

13 Jul '09

I was wondering from a design perspective, why was it decided that intrusive_ptr should rely on user-defined free functions intrusive_ptr_add_ref and intrusive_ptr_release to handle the reference counting? This makes it somewhat inconvenient, for some constant type T, to support having two different instances of intrusive_ptr<T>, each of which use a different reference counting strategy. If there's a clever way to allow this that I'm missing please advise.

9 20

type_traits/call_traits and function_traits : Why are they separate
by joel 12 Jul '09

12 Jul '09

Is there anything that prevent those three libraries (type_traits,call_traits and function_traits) to be merged in a single traits library ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

1 0

Re: [boost] [serialization][trunk] Latest patch for void_cast.cpp causes segfaults
by Hartmut Kaiser 11 Jul '09

11 Jul '09

> apparently the latest patch to > boost/libs/serialization/src/void_cast.cpp > (rev.53078, svn:date: 2009-05-18T06:25:56.023190Z, svn:author: ramey, > svn:log: fix errors in extended_type_info management) causes an > existing application to segfault during cleanup. The application was > working properly before. The attached patch fixes the issue. > > Ok to commit? Ping? Regards Hartmut

3 8

Debug Assertion Failed while trying to use read_graphviz
by Anna Kazeykina 11 Jul '09

11 Jul '09

Hello, I tried to compile and run in VS 2008 the following example illustrating how to use read_graphviz() function: #include <boost/graph/graphviz.hpp> #include <boost/graph/adjacency_list.hpp> #include <string> #include <sstream> using namespace boost; using namespace std; int main() { // Vertex properties typedef property < vertex_name_t, std::string, property < vertex_color_t, float > > vertex_p; // Edge properties typedef property < edge_weight_t, double > edge_p; // Graph properties typedef property < graph_name_t, std::string > graph_p; // adjacency_list-based type typedef adjacency_list < vecS, vecS, directedS, vertex_p, edge_p, graph_p > graph_t; // Construct an empty graph and prepare the dynamic_property_maps. graph_t graph(0); dynamic_properties dp; property_map<graph_t, vertex_name_t>::type name = get(vertex_name, graph); dp.property("node_id",name); property_map<graph_t, vertex_color_t>::type mass = get(vertex_color, graph); dp.property("mass",mass); property_map<graph_t, edge_weight_t>::type weight = get(edge_weight, graph); dp.property("weight",weight); // Use ref_property_map to turn a graph property into a property map boost::ref_property_map<graph_t*,std::string> gname(get_property(graph,graph_name)); dp.property("name",gname); // Sample graph as an std::istream; std::istringstream gvgraph("digraph { graph [name=\"graphname\"] a c e [mass = 6.66] }"); bool status = read_graphviz(gvgraph,graph,dp,"node_id"); return 0; } When I run the program I get the Debug Assertion Failed message (when I delete the line with read_graphviz everything is OK). Could you please help me with this problem? Thank you, Anna.

2 1

Build changes for 1.40
by Vladimir Prus 11 Jul '09

11 Jul '09

FYI, I've merged Boost.Build from trunk to release branch. The most important change is that now, on Unix, default build with act as if --layout=system is specified, creating libraries with no decoration that can be conveniently used. Other changes are documented at: http://beta.boost.org/users/news/version_1_40_0 Let me know if this causes any problems. - Volodya

1 0

Boost.Range too focused on iterators?
by j j 11 Jul '09

11 Jul '09

The boost range library makes ranges similar to the to the STL Container<http://www.sgi.com/Technology/STL/Container.html>concept. A Range provides *iterators* for accessing a half-open range [first,one_past_last) of elements and provides information about the number of elements in the Range. Wouldn't it be better if it could use *values* and iterators? eg template<class access> ostream& operator<<(ostream& out,const range<access>& in){ for(x temp=in.a;temp!=in.b;temp++)cout<<access()(temp); return out; } //Later on in code //prints a range of numbers cout<<Range<no_deref >(0,8); //no_deref is a function object that returns a reference to its argument. //prints the contents of a range of iterators. string a="Hello World!"; cout<<Range(a.begin(),a.end()) //defaults to deref which is a function object that derefences its argument with *

2 1

[sandbox.move] coexistence issues with boost.interprocess + small suggestion
by Jeffrey Hellrung 09 Jul '09

09 Jul '09

Hi, I suppose this is mostly addressed to Ion. It appears that containers in the move library in the boost sandbox can't coexist with containers from the boost.interprocess library. This isn't a problem for me currently (I can just use the containers from the move library), but it may be an indication of a larger problem with either or both libraries, so I figured it'd be worth sharing. I wasn't sure if this would be an appropriate trac ticket to file under boost.interprocess, as it involves technically non-boost code, but I can certainly do that if desired. So to be specific, the following program fails to compile (MSVC 2009, boost 1.39, include paths are boost root and $(BOOST_SVN)/boost-sandbox/move): -------- #include <boost/interprocess/containers/vector.hpp> #include <boost/container/vector.hpp> int main(int argc, char* argv[]) { boost::interprocess::vector< int > v1; // line 6 boost::container::vector< int > v2; // line 7 return 0; } -------- The compiler output is: -------- 1>.\main.cpp(7) : error C3083: 'container': the symbol to the left of a '::' must be a type 1>.\main.cpp(7) : error C2039: 'vector' : is not a member of 'boost' 1>.\main.cpp(7) : error C2065: 'vector' : undeclared identifier 1>.\main.cpp(7) : error C2062: type 'int' unexpected -------- Removing either the interprocess vector (include directive, variable declaration) pair or the move vector (include directive, variable declaration) pair produces a compilable program. Reversing the order of the include directives gives a different compiler error: -------- 1>E:\boost_1_39_0\boost/interprocess/containers/vector.hpp(24) : error C3083: 'interprocess_container': the symbol to the left of a '::' must be a type 1>E:\boost_1_39_0\boost/interprocess/containers/vector.hpp(24) : error C2039: 'vector' : is not a member of 'boost' 1>E:\boost_1_39_0\boost/interprocess/containers/vector.hpp(24) : error C2873: 'vector' : symbol cannot be used in a using-declaration 1>.\main.cpp(6) : error C2039: 'vector' : is not a member of 'boost::interprocess' 1>.\main.cpp(6) : error C2065: 'vector' : undeclared identifier 1>.\main.cpp(6) : error C2062: type 'int' unexpected -------- Any idea what's going on here? Am I just doing something really boneheaded, e.g., with the include paths? Additionally, I have a small suggestion for the move library. It would be somewhat more convenient if boost::is_movable<T> had a nested type typedef, e.g., if it inherited from mpl::bool_<...> or integral_constant< bool, ...>. As it stands, I don't think it can be used directly in MPL expressions such as mpl::and_. Thanks in advance, - Jeff

2 1

[Tuple] Addressing by named tag?
by Robert Jones 09 Jul '09

09 Jul '09

Am I correct in believing that tuples have to be accessed by element index, as in tuple.get<0>() Multi-Index container has a really nice facility to use named (well typed really) tags in these kind of expressions, but it seems tuples do not. Anyone fancy adding it to tuple? - Rob.

2 1

[convert] coversion between strings with different locales
by vicente.botet 09 Jul '09

09 Jul '09

Hi, I wanted to see how we can convert a double from a locale to another locale? Should I write double d =convert<string>::from(convert<double>::from(str)(_locale=f))(_locale=t); or I need double d = convert<double>::from(str)(_locale=f); convert<string>::from(d)(_locale=d); Or it si a better way? Best, _____________________ Vicente Juan Botet Escribá

2 3

[multi_array] Can only disable range checking by defining BOOST_DISABLE_ASSERTS macro
by John Reid 08 Jul '09

08 Jul '09

Defining BOOST_DISABLE_ASSERTS disables boost asserts over the entire compilation. It would be nice to have finer grained control over the range checking in multi_array via a boost.multi_array specific macro.

1 1

[Graph] component_index crash on big graph
by Sandeep Gupta 08 Jul '09

08 Jul '09

Hi, I am using the incremental connected component + component_index to find connected components in an undirected graph. However the program works fine on small small dataset but segfaults on large input. I tried to do some debugging and the best I could come up was that it fails on array_push_front cal at the boost/graph/detail/incremental_component.hpp:78. I have attached the source code and the accompanying small files that contain edgelist. The TrivialEdges.txt works fine but on ManyEdges.txt* the program segfaults. To the best of my understanding the input is sane. Would appreciate any help. * ManyEdges.txt is 320K so please download it from (* http://tinyurl.com/m9blyy) * THis is the dataset I stumbled upon. I apologies for not being able to trim down to smaller size. thanks sandeep

3 7

Universal user interface based only on C++ standard libraries
by Jonathan Enders 07 Jul '09

07 Jul '09

One feature I am always missing when programming in a non-interpreted language like C is the ability to interactively execute the program without writing an entire mechanism for that. This "interpreted when typed"-feature proves itself very useful in python for instance. Although it might be too hard if not impossible to make a "compiled and executed when typed"-feature for C it is possible to just give the user the ability to access a huge amount of the functionality of let's say an object. It's just a lot of work to make all the properties accessible and you might blemish the looks of your actually ui-independent class. A workaround can be applied to lessen the damage. It would consist of just a single function that the class has to implement. That function exports all the functionality (options) to a ui-system which takes care of the command handling and user interaction. This works to the point that it can actually completely replace the ui-design-process (well the ui-system still has to be initialized, 3 lines of code). The work to make the C++ standard library ui-accessible could be taken from the user in advance. As I don't know if any of that is of any relevance to the boost community I will leave it at that. It just seems like a big lack to me that the boost-libraries still have no means of user interaction. If there is any interest in the above I have a working sample which demonstrates what words can only poorly describe. Thanks

8 7

[config] polygon library long long, long double portability
by Simonson, Lucanus J 07 Jul '09

07 Jul '09

I use long long and long double in the configuration of my integer arithmetic traits. I'd like to guard those usages with boost macros to allow the code to compile on platforms that don't support long long and long double (replace with long and double respectively) but I can only find a BOOST_HAS_LONG_LONG macro (which is apparently not documented) and not a corresponding BOOST_HAS_LONG_DOUBLE. Is there some other macro I can use to detect BOOST_HAS_LONG_DOUBLE or a typedef I can use that is already set to long double if available and double otherwise? Thanks, Luke

9 31

[Config] Boost config, long long in xlc 10.1
by Ioannis Papadopoulos 07 Jul '09

07 Jul '09

Hi, 1. I see in config/compiler/vacpp.hpp that versions over 6 are not supported when BOOST_ASSERT_CONFIG is defined: #if (__IBMCPP_ > 600) # if defined(BOOST_ASSERT_CONFIG) # error "Unknown compiler version - please run the configure tests and report the results" # endif #endif Still Boost compiles fine with 10.1, so maybe the number should be changed to 1010, unless there is some other reason that I'm missing. 2. long long is supported through a flag, -qlonglong which also defines _LONG_LONG to be 1. As far as I understand this is not taken into account. Thanks!

2 2

[algorithm] - defect due to accidental ADL
by Neil Groves 07 Jul '09

07 Jul '09

Hello, I have been investigating an issue reported by a user of the RangeEx library proposal. The conclusion was that boost/algorithm/find.hpp suffers from accidental ADL. This was confirmed by protecting against accidental ADL in this file and the user confirming that this solved their problem. Would it be useful to the current maintainer if I went through the source code and fixed similar issues? I would be happy to provide the files for the maintainer to commit. Alternatively is it possible to have agreement and then write access to the repository to fix this problem? Thank you in anticipation, Neil Groves

2 1

[Boost-serialization] Missing file
by K. Noel Belcourt 07 Jul '09

07 Jul '09

Hi, It looks like trunk tests are failing with this error. error: Unable to find file or target named error: 'test_shared_ptr_multi_base.cpp' error: referred from project at error: '../libs/serialization/test' -- Noel

1 0

[pool] Doubling algorithm
by Martin Scheffler 07 Jul '09

07 Jul '09

I just stumbled across an old problem: The maximum size of new allocations cannot be limited in boost::pool. I have a pool that grows to hundreds of megabytes. The pool doubles its allocation size every time it runs out of free space. Because Windows wants to allocate consecutive free space, I get out of memory errors even when my program only uses ~500 mb of main memory. If I could limit the amount of memory to allocate this would not be a problem. This was already discussed here: http://lists.boost.org/Archives/boost/2008/10/143763.php Has anything happened since then? Is boost::pool currently maintained? Or are there alternative memory pool libraries I could use? Thank you! Martin Scheffler

2 1

Ticket Resolutions
by Beman Dawes 07 Jul '09

07 Jul '09

I'd like to add "notabug" as a ticket resolution choice. The use would be for tickets that complain about something that is in fact true, but is by design rather than being a bug. In the past, I've marked these as "invalid". But I dislike doing so because it sounds as if I'm saying there is something wrong with the ticket itself. Comments? --Beman

6 6

Boost.Build question
by Zachary Turner 07 Jul '09

07 Jul '09

I notice the cxxflags for passing command line options to the C++ compiler. However, I need to build the boost libraries themselves in such a way that I can pass command line options to the linker. Is this possible somehow? Thanks

2 1

[gil] gcc 4.4.0 namespace fix (second attempt)
by Philipp Schwaha 06 Jul '09

06 Jul '09

Hi! please excuse if this message is posted twice, but my first attempt seems to have gone missing ... I hope this is an appropriate place (and time ;) ) for this. I found a few namespace issues concerning GIL and gcc 4.4.0 while working on a project and have (hopefully) fixed them (patch attached - svn revision 54347). Cheers, Philipp Index: boost/gil/color_base.hpp =================================================================== --- boost/gil/color_base.hpp (revision 54347) +++ boost/gil/color_base.hpp (working copy) @@ -85,7 +85,7 @@ // grayscale pixel values are convertible to channel type operator Element () const { return _v0; } - template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,1>& c) : _v0(at_c<0>(c)) {} + template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,1>& c) : _v0(gil::at_c<0>(c)) {} }; @@ -107,13 +107,13 @@ homogeneous_color_base(Element v0, Element v1) : _v0(v0), _v1(v1) {} template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,2>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)) {} // Support for l-value reference proxy copy construction template <typename E2, typename L2> homogeneous_color_base( homogeneous_color_base<E2,L2,2>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)) {} // Support for planar_pixel_iterator construction and dereferencing template <typename P> homogeneous_color_base(P* p,bool) : @@ -155,15 +155,15 @@ homogeneous_color_base(Element v0, Element v1, Element v2) : _v0(v0), _v1(v1), _v2(v2) {} template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,3>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)) {} // Support for l-value reference proxy copy construction template <typename E2, typename L2> homogeneous_color_base( homogeneous_color_base<E2,L2,3>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)) {} // Support for planar_pixel_iterator construction and dereferencing template <typename P> homogeneous_color_base(P* p,bool) : @@ -212,17 +212,17 @@ homogeneous_color_base(Element v0, Element v1, Element v2, Element v3) : _v0(v0), _v1(v1), _v2(v2), _v3(v3) {} template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,4>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)), - _v3(at_c<mapping_transform<Layout,L2,3>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)), + _v3(gil::at_c<mapping_transform<Layout,L2,3>::value>(c)) {} // Support for l-value reference proxy copy construction template <typename E2, typename L2> homogeneous_color_base( homogeneous_color_base<E2,L2,4>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)), - _v3(at_c<mapping_transform<Layout,L2,3>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)), + _v3(gil::at_c<mapping_transform<Layout,L2,3>::value>(c)) {} // Support for planar_pixel_iterator construction and dereferencing template <typename P> homogeneous_color_base(P* p,bool) : @@ -278,19 +278,19 @@ homogeneous_color_base(Element v0, Element v1, Element v2, Element v3, Element v4) : _v0(v0), _v1(v1), _v2(v2), _v3(v3), _v4(v4) {} template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,5>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)), - _v3(at_c<mapping_transform<Layout,L2,3>::value>(c)), - _v4(at_c<mapping_transform<Layout,L2,4>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)), + _v3(gil::at_c<mapping_transform<Layout,L2,3>::value>(c)), + _v4(gil::at_c<mapping_transform<Layout,L2,4>::value>(c)) {} // Support for l-value reference proxy copy construction template <typename E2, typename L2> homogeneous_color_base( homogeneous_color_base<E2,L2,5>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)), - _v3(at_c<mapping_transform<Layout,L2,3>::value>(c)), - _v4(at_c<mapping_transform<Layout,L2,4>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)), + _v3(gil::at_c<mapping_transform<Layout,L2,3>::value>(c)), + _v4(gil::at_c<mapping_transform<Layout,L2,4>::value>(c)) {} // Support for planar_pixel_iterator construction and dereferencing template <typename P> homogeneous_color_base(P* p,bool) : Index: boost/gil/color_base_algorithm.hpp =================================================================== --- boost/gil/color_base_algorithm.hpp (revision 54347) +++ boost/gil/color_base_algorithm.hpp (working copy) @@ -101,7 +101,7 @@ template <typename ColorBase, int K> struct kth_semantic_element_reference_type { BOOST_STATIC_CONSTANT(int, semantic_index = (mpl::at_c<typename ColorBase::layout_t::channel_mapping_t,K>::type::value)); typedef typename kth_element_reference_type<ColorBase,semantic_index>::type type; - static type get(ColorBase& cb) { return at_c<semantic_index>(cb); } + static type get(ColorBase& cb) { return gil::at_c<semantic_index>(cb); } }; /// \brief Specifies the return type of the constant semantic_at_c<K>(color_base); @@ -109,7 +109,7 @@ template <typename ColorBase, int K> struct kth_semantic_element_const_reference_type { BOOST_STATIC_CONSTANT(int, semantic_index = (mpl::at_c<typename ColorBase::layout_t::channel_mapping_t,K>::type::value)); typedef typename kth_element_const_reference_type<ColorBase,semantic_index>::type type; - static type get(const ColorBase& cb) { return at_c<semantic_index>(cb); } + static type get(const ColorBase& cb) { return gil::at_c<semantic_index>(cb); } }; /// \brief A mutable accessor to the K-th semantic element of a color base Index: boost/gil/pixel.hpp =================================================================== --- boost/gil/pixel.hpp (revision 54347) +++ boost/gil/pixel.hpp (working copy) @@ -143,11 +143,11 @@ private: static void check_gray() { BOOST_STATIC_ASSERT((is_same<typename Layout::color_space_t, gray_t>::value)); } - template <typename Channel> void assign(const Channel& chan, mpl::false_) { check_gray(); at_c<0>(*this)=chan; } - template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return at_c<0>(*this)==chan; } + template <typename Channel> void assign(const Channel& chan, mpl::false_) { check_gray(); gil::at_c<0>(*this)=chan; } + template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return gil::at_c<0>(*this)==chan; } public: - pixel& operator= (channel_t chan) { check_gray(); at_c<0>(*this)=chan; return *this; } - bool operator==(channel_t chan) const { check_gray(); return at_c<0>(*this)==chan; } + pixel& operator= (channel_t chan) { check_gray(); gil::at_c<0>(*this)=chan; return *this; } + bool operator==(channel_t chan) const { check_gray(); return gil::at_c<0>(*this)==chan; } }; ///////////////////////////// Index: boost/gil/image_view_factory.hpp =================================================================== --- boost/gil/image_view_factory.hpp (revision 54347) +++ boost/gil/image_view_factory.hpp (working copy) @@ -102,7 +102,7 @@ BOOST_STATIC_ASSERT((!is_planar<HomogeneousView>::value && view_is_basic<HomogeneousView>::value)); BOOST_STATIC_ASSERT((boost::is_pointer<typename HomogeneousView::x_iterator>::value)); - return &at_c<0>(view(0,0)); + return &gil::at_c<0>(view(0,0)); } /// \ingroup ImageViewConstructors @@ -430,7 +430,7 @@ typedef typename type::xy_locator locator_t; typedef typename type::x_iterator x_iterator_t; typedef typename iterator_adaptor_get_base<x_iterator_t>::type x_iterator_base_t; - x_iterator_t sit(x_iterator_base_t(&at_c<K>(src(0,0))),src.pixels().pixel_size()); + x_iterator_t sit(x_iterator_base_t(&gil::at_c<K>(src(0,0))),src.pixels().pixel_size()); return type(src.dimensions(),locator_t(sit, src.pixels().row_size())); } }; @@ -444,7 +444,7 @@ typedef typename view_type<channel_t, gray_layout_t, false, false, view_is_mutable<View>::value>::type type; static type make(const View& src) { typedef typename type::x_iterator x_iterator_t; - return interleaved_view(src.width(),src.height(),(x_iterator_t)&at_c<K>(src(0,0)), src.pixels().row_size()); + return interleaved_view(src.width(),src.height(),(x_iterator_t)&gil::at_c<K>(src(0,0)), src.pixels().row_size()); } }; @@ -494,7 +494,7 @@ template <typename P> kth_channel_deref_fn(const kth_channel_deref_fn<K,P>&) {} result_type operator()(argument_type srcP) const { - return result_type(at_c<K>(srcP)); + return result_type(gil::at_c<K>(srcP)); } }; Index: boost/gil/bit_aligned_pixel_reference.hpp =================================================================== --- boost/gil/bit_aligned_pixel_reference.hpp (revision 54347) +++ boost/gil/bit_aligned_pixel_reference.hpp (working copy) @@ -145,7 +145,7 @@ // Construct from another compatible pixel type bit_aligned_pixel_reference(const bit_aligned_pixel_reference& p) : _bit_range(p._bit_range) {} - template <typename BF, typename CR> bit_aligned_pixel_reference(packed_pixel<BF,CR,Layout>& p) : _bit_range(static_cast<data_ptr_t>(&at_c<0>(p)), at_c<0>(p).first_bit()) { + template <typename BF, typename CR> bit_aligned_pixel_reference(packed_pixel<BF,CR,Layout>& p) : _bit_range(static_cast<data_ptr_t>(&gil::at_c<0>(p)), gil::at_c<0>(p).first_bit()) { check_compatible<packed_pixel<BF,CR,Layout> >(); } @@ -169,8 +169,8 @@ private: static void check_gray() { BOOST_STATIC_ASSERT((is_same<typename Layout::color_space_t, gray_t>::value)); } - template <typename Channel> void assign(const Channel& chan, mpl::false_) const { check_gray(); at_c<0>(*this)=chan; } - template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return at_c<0>(*this)==chan; } + template <typename Channel> void assign(const Channel& chan, mpl::false_) const { check_gray(); gil::at_c<0>(*this)=chan; } + template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return gil::at_c<0>(*this)==chan; } }; ///////////////////////////// Index: boost/gil/gil_concept.hpp =================================================================== --- boost/gil/gil_concept.hpp (revision 54347) +++ boost/gil/gil_concept.hpp (working copy) @@ -618,7 +618,7 @@ typedef typename kth_element_const_reference_type<ColorBase,num_elements-1>::type CR; #if !defined(_MSC_VER) || _MSC_VER > 1310 - CR cr=at_c<num_elements-1>(cb); ignore_unused_variable_warning(cr); + CR cr=gil::at_c<num_elements-1>(cb); ignore_unused_variable_warning(cr); #endif // functions that work for every pixel (no need to require them) @@ -655,8 +655,8 @@ typedef typename kth_element_reference_type<ColorBase, 0>::type CR; #if !defined(_MSC_VER) || _MSC_VER > 1310 - CR r=at_c<0>(cb); - at_c<0>(cb)=r; + CR r=gil::at_c<0>(cb); + gil::at_c<0>(cb)=r; #endif } Index: boost/gil/planar_pixel_iterator.hpp =================================================================== --- boost/gil/planar_pixel_iterator.hpp (revision 54347) +++ boost/gil/planar_pixel_iterator.hpp (working copy) @@ -109,8 +109,8 @@ reference operator->() const { return **this; } // PERFORMANCE_CHECK: Remove? - bool operator< (const planar_pixel_iterator& ptr) const { return at_c<0>(*this)< at_c<0>(ptr); } - bool operator!=(const planar_pixel_iterator& ptr) const { return at_c<0>(*this)!=at_c<0>(ptr); } + bool operator< (const planar_pixel_iterator& ptr) const { return gil::at_c<0>(*this)< gil::at_c<0>(ptr); } + bool operator!=(const planar_pixel_iterator& ptr) const { return gil::at_c<0>(*this)!=gil::at_c<0>(ptr); } private: friend class boost::iterator_core_access; @@ -119,8 +119,8 @@ void advance(ptrdiff_t d) { static_transform(*this,*this,std::bind2nd(detail::plus_asymmetric<ChannelPtr,ptrdiff_t>(),d)); } reference dereference() const { return this->template deref<reference>(); } - ptrdiff_t distance_to(const planar_pixel_iterator& it) const { return at_c<0>(it)-at_c<0>(*this); } - bool equal(const planar_pixel_iterator& it) const { return at_c<0>(*this)==at_c<0>(it); } + ptrdiff_t distance_to(const planar_pixel_iterator& it) const { return gil::at_c<0>(it)-gil::at_c<0>(*this); } + bool equal(const planar_pixel_iterator& it) const { return gil::at_c<0>(*this)==gil::at_c<0>(it); } }; namespace detail { @@ -184,7 +184,7 @@ template <typename IC, typename C> inline std::ptrdiff_t memunit_distance(const planar_pixel_iterator<IC,C>& p1, const planar_pixel_iterator<IC,C>& p2) { - return memunit_distance(at_c<0>(p1),at_c<0>(p2)); + return memunit_distance(gil::at_c<0>(p1),gil::at_c<0>(p2)); } template <typename IC> Index: boost/gil/packed_pixel.hpp =================================================================== --- boost/gil/packed_pixel.hpp (revision 54347) +++ boost/gil/packed_pixel.hpp (working copy) @@ -77,19 +77,19 @@ template <typename P> packed_pixel(const P& p, typename enable_if_c<is_pixel<P>::value>::type* d=0) { check_compatible<P>(); static_copy(p,*this); } packed_pixel(int chan0, int chan1) : _bitfield(0) { BOOST_STATIC_ASSERT((num_channels<packed_pixel>::value==2)); - at_c<0>(*this)=chan0; at_c<1>(*this)=chan1; + gil::at_c<0>(*this)=chan0; gil::at_c<1>(*this)=chan1; } packed_pixel(int chan0, int chan1, int chan2) : _bitfield(0) { BOOST_STATIC_ASSERT((num_channels<packed_pixel>::value==3)); - at_c<0>(*this)=chan0; at_c<1>(*this)=chan1; at_c<2>(*this)=chan2; + gil::at_c<0>(*this)=chan0; gil::at_c<1>(*this)=chan1; gil::at_c<2>(*this)=chan2; } packed_pixel(int chan0, int chan1, int chan2, int chan3) : _bitfield(0) { BOOST_STATIC_ASSERT((num_channels<packed_pixel>::value==4)); - at_c<0>(*this)=chan0; at_c<1>(*this)=chan1; at_c<2>(*this)=chan2; at_c<3>(*this)=chan3; + gil::at_c<0>(*this)=chan0; gil::at_c<1>(*this)=chan1; gil::at_c<2>(*this)=chan2; gil::at_c<3>(*this)=chan3; } packed_pixel(int chan0, int chan1, int chan2, int chan3, int chan4) : _bitfield(0) { BOOST_STATIC_ASSERT((num_channels<packed_pixel>::value==5)); - at_c<0>(*this)=chan0; at_c<1>(*this)=chan1; at_c<2>(*this)=chan2; at_c<3>(*this)=chan3; at_c<4>(*this)=chan4; + gil::at_c<0>(*this)=chan0; gil::at_c<1>(*this)=chan1; gil::at_c<2>(*this)=chan2; gil::at_c<3>(*this)=chan3; gil::at_c<4>(*this)=chan4; } packed_pixel& operator=(const packed_pixel& p) { _bitfield=p._bitfield; return *this; } @@ -106,11 +106,11 @@ // Support for assignment/equality comparison of a channel with a grayscale pixel static void check_gray() { BOOST_STATIC_ASSERT((is_same<typename Layout::color_space_t, gray_t>::value)); } - template <typename Channel> void assign(const Channel& chan, mpl::false_) { check_gray(); at_c<0>(*this)=chan; } - template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return at_c<0>(*this)==chan; } + template <typename Channel> void assign(const Channel& chan, mpl::false_) { check_gray(); gil::at_c<0>(*this)=chan; } + template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return gil::at_c<0>(*this)==chan; } public: - packed_pixel& operator= (int chan) { check_gray(); at_c<0>(*this)=chan; return *this; } - bool operator==(int chan) const { check_gray(); return at_c<0>(*this)==chan; } + packed_pixel& operator= (int chan) { check_gray(); gil::at_c<0>(*this)=chan; return *this; } + bool operator==(int chan) const { check_gray(); return gil::at_c<0>(*this)==chan; } }; ///////////////////////////// Index: libs/gil/test/performance.cpp =================================================================== --- libs/gil/test/performance.cpp (revision 54347) +++ libs/gil/test/performance.cpp (working copy) @@ -81,9 +81,9 @@ T* first=(T*)_v.row_begin(0); T* last=first+_v.size()*3; while(first!=last) { - first[0]=at_c<0>(_p); - first[1]=at_c<1>(_p); - first[2]=at_c<2>(_p); + first[0]=boost::gil::at_c<0>(_p); + first[1]=boost::gil::at_c<1>(_p); + first[2]=boost::gil::at_c<2>(_p); first+=3; } } @@ -99,9 +99,9 @@ T1* first=(T1*)_v.row_begin(0); T1* last=first+_v.size()*3; while(first!=last) { - first[0]=at_c<2>(_p); - first[1]=at_c<1>(_p); - first[2]=at_c<0>(_p); + first[0]=boost::gil::at_c<2>(_p); + first[1]=boost::gil::at_c<1>(_p); + first[2]=boost::gil::at_c<0>(_p); first+=3; } } @@ -116,12 +116,12 @@ void operator()() const { std::size_t size=_v.size(); T1* first; - first=(T1*)at_c<0>(_v.row_begin(0)); - std::fill(first,first+size,at_c<0>(_p)); - first=(T1*)at_c<1>(_v.row_begin(0)); - std::fill(first,first+size,at_c<1>(_p)); - first=(T1*)at_c<2>(_v.row_begin(0)); - std::fill(first,first+size,at_c<2>(_p)); + first=(T1*)boost::gil::at_c<0>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<0>(_p)); + first=(T1*)boost::gil::at_c<1>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<1>(_p)); + first=(T1*)boost::gil::at_c<2>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<2>(_p)); } }; @@ -135,12 +135,12 @@ void operator()() const { std::size_t size=_v.size(); T1* first; - first=(T1*)at_c<0>(_v.row_begin(0)); - std::fill(first,first+size,at_c<2>(_p)); - first=(T1*)at_c<1>(_v.row_begin(0)); - std::fill(first,first+size,at_c<1>(_p)); - first=(T1*)at_c<2>(_v.row_begin(0)); - std::fill(first,first+size,at_c<1>(_p)); + first=(T1*)boost::gil::at_c<0>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<2>(_p)); + first=(T1*)boost::gil::at_c<1>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<1>(_p)); + first=(T1*)boost::gil::at_c<2>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<1>(_p)); } }; @@ -191,9 +191,9 @@ for_each_nongil_t(const View& v_in,const F& f_in) : _v(v_in), _f(f_in) {} void operator()() const { T1 *first0, *first1, *first2, *last0; - first0=(T1*)at_c<0>(_v.row_begin(0)); - first1=(T1*)at_c<1>(_v.row_begin(0)); - first2=(T1*)at_c<2>(_v.row_begin(0)); + first0=(T1*)boost::gil::at_c<0>(_v.row_begin(0)); + first1=(T1*)boost::gil::at_c<1>(_v.row_begin(0)); + first2=(T1*)boost::gil::at_c<2>(_v.row_begin(0)); last0=first0+_v.size(); while(first0!=last0) { *first0++=0; @@ -261,12 +261,12 @@ copy_nongil_t(const View1& v1_in,const View2& v2_in) : _v1(v1_in), _v2(v2_in) {} void operator()() const { std::size_t size=_v1.size(); - T1* first10=(T1*)at_c<0>(_v1.row_begin(0)); - T1* first11=(T1*)at_c<1>(_v1.row_begin(0)); - T1* first12=(T1*)at_c<2>(_v1.row_begin(0)); - T2* first20=(T2*)at_c<0>(_v2.row_begin(0)); - T2* first21=(T2*)at_c<1>(_v2.row_begin(0)); - T2* first22=(T2*)at_c<2>(_v2.row_begin(0)); + T1* first10=(T1*)boost::gil::at_c<0>(_v1.row_begin(0)); + T1* first11=(T1*)boost::gil::at_c<1>(_v1.row_begin(0)); + T1* first12=(T1*)boost::gil::at_c<2>(_v1.row_begin(0)); + T2* first20=(T2*)boost::gil::at_c<0>(_v2.row_begin(0)); + T2* first21=(T2*)boost::gil::at_c<1>(_v2.row_begin(0)); + T2* first22=(T2*)boost::gil::at_c<2>(_v2.row_begin(0)); std::copy(first10,first10+size,first20); std::copy(first11,first11+size,first21); std::copy(first12,first12+size,first22); @@ -282,9 +282,9 @@ void operator()() const { T1* first=(T1*)_v1.row_begin(0); T1* last=first+_v1.size()*3; - T2* first0=(T2*)at_c<0>(_v2.row_begin(0)); - T2* first1=(T2*)at_c<1>(_v2.row_begin(0)); - T2* first2=(T2*)at_c<2>(_v2.row_begin(0)); + T2* first0=(T2*)boost::gil::at_c<0>(_v2.row_begin(0)); + T2* first1=(T2*)boost::gil::at_c<1>(_v2.row_begin(0)); + T2* first2=(T2*)boost::gil::at_c<2>(_v2.row_begin(0)); while(first!=last) { *first0++=first[0]; *first1++=first[1]; @@ -303,9 +303,9 @@ void operator()() const { T1* first=(T1*)_v2.row_begin(0); T1* last=first+_v2.size()*3; - T2* first0=(T2*)at_c<0>(_v1.row_begin(0)); - T2* first1=(T2*)at_c<1>(_v1.row_begin(0)); - T2* first2=(T2*)at_c<2>(_v1.row_begin(0)); + T2* first0=(T2*)boost::gil::at_c<0>(_v1.row_begin(0)); + T2* first1=(T2*)boost::gil::at_c<1>(_v1.row_begin(0)); + T2* first2=(T2*)boost::gil::at_c<2>(_v1.row_begin(0)); while(first!=last) { first[0]=*first0++; first[1]=*first1++; @@ -369,12 +369,12 @@ F _f; transform_nongil_t(const View1& v1_in,const View2& v2_in,const F& f_in) : _v1(v1_in),_v2(v2_in),_f(f_in) {} void operator()() const { - T1* first10=(T1*)at_c<0>(_v1.row_begin(0)); - T1* first11=(T1*)at_c<1>(_v1.row_begin(0)); - T1* first12=(T1*)at_c<2>(_v1.row_begin(0)); - T1* first20=(T2*)at_c<0>(_v2.row_begin(0)); - T1* first21=(T2*)at_c<1>(_v2.row_begin(0)); - T1* first22=(T2*)at_c<2>(_v2.row_begin(0)); + T1* first10=(T1*)boost::gil::at_c<0>(_v1.row_begin(0)); + T1* first11=(T1*)boost::gil::at_c<1>(_v1.row_begin(0)); + T1* first12=(T1*)boost::gil::at_c<2>(_v1.row_begin(0)); + T1* first20=(T2*)boost::gil::at_c<0>(_v2.row_begin(0)); + T1* first21=(T2*)boost::gil::at_c<1>(_v2.row_begin(0)); + T1* first22=(T2*)boost::gil::at_c<2>(_v2.row_begin(0)); T1* last10=first10+_v1.size(); while(first10!=last10) { *first20++=T2(*first12++*0.1f); @@ -394,9 +394,9 @@ void operator()() const { T1* first1=(T1*)_v1.row_begin(0); T1* last1=first1+_v1.size()*3; - T1* first20=(T2*)at_c<0>(_v2.row_begin(0)); - T1* first21=(T2*)at_c<1>(_v2.row_begin(0)); - T1* first22=(T2*)at_c<2>(_v2.row_begin(0)); + T1* first20=(T2*)boost::gil::at_c<0>(_v2.row_begin(0)); + T1* first21=(T2*)boost::gil::at_c<1>(_v2.row_begin(0)); + T1* first22=(T2*)boost::gil::at_c<2>(_v2.row_begin(0)); while(first1!=last1) { *first20++=T2(first1[2]*0.1f); *first21++=T2(first1[1]*0.2f); @@ -414,9 +414,9 @@ F _f; transform_nongil_t(const View1& v1_in,const View2& v2_in,const F& f_in) : _v1(v1_in),_v2(v2_in),_f(f_in) {} void operator()() const { - T1* first10=(T1*)at_c<0>(_v1.row_begin(0)); - T1* first11=(T1*)at_c<1>(_v1.row_begin(0)); - T1* first12=(T1*)at_c<2>(_v1.row_begin(0)); + T1* first10=(T1*)boost::gil::at_c<0>(_v1.row_begin(0)); + T1* first11=(T1*)boost::gil::at_c<1>(_v1.row_begin(0)); + T1* first12=(T1*)boost::gil::at_c<2>(_v1.row_begin(0)); T2* first2=(T1*)_v2.row_begin(0); T1* last2=first2+_v1.size()*3; while(first2!=last2) { Index: libs/gil/test/pixel.cpp =================================================================== --- libs/gil/test/pixel.cpp (revision 54347) +++ libs/gil/test/pixel.cpp (working copy) @@ -63,8 +63,8 @@ // test homogeneous algorithms - fill, max, min static const int num_chan = num_channels<typename C2::pixel_t>::value; - static_fill(C2::_pixel, at_c<0>(C1::_pixel)+1); - error_if(at_c<0>(C2::_pixel) != at_c<num_chan-1>(C2::_pixel)); + static_fill(C2::_pixel, boost::gil::at_c<0>(C1::_pixel)+1); + error_if(boost::gil::at_c<0>(C2::_pixel) != boost::gil::at_c<num_chan-1>(C2::_pixel)); C2::_pixel = C1::_pixel; error_if(static_max(C2::_pixel) != static_max(C1::_pixel)); @@ -107,7 +107,7 @@ error_if(C1::_pixel!=C2::_pixel); static_generate(C2::_pixel, set_to_one()); - error_if(at_c<0>(C2::_pixel) != 1); + error_if(boost::gil::at_c<0>(C2::_pixel) != 1); // Test swap if both are mutable and if their value type is the same // (We know the second one is mutable) @@ -313,7 +313,7 @@ bgr8_pixel_t bgr8(rgb8); error_if(bgr8[0] == rgb8[0]); error_if(dynamic_at_c(bgr8,0) == dynamic_at_c(rgb8,0)); - error_if(at_c<0>(bgr8) == at_c<0>(rgb8)); + error_if(boost::gil::at_c<0>(bgr8) == boost::gil::at_c<0>(rgb8)); error_if(semantic_at_c<0>(bgr8) != semantic_at_c<0>(rgb8)); error_if(get_color(bgr8,blue_t()) != get_color(rgb8,blue_t()));

3 2

[gil] gcc 4.4 fix
by Christian Henning 06 Jul '09

06 Jul '09

Hi there, on 2009-06-25 Philipp Schwaha posted a fix for some namespace issues with gcc 4.4. I just got the latest trunk but the issues remain. Could someone please commit the fix? http://article.gmane.org/gmane.comp.lib.boost.devel/191191 Thanks, Christian

1 0

[iterator] zip_iterator equality comparison
by Jeremiah Willcock 05 Jul '09

05 Jul '09

It is standard in STL to have two ranges that are zipped together (such as in the two-input-sequence version of std::transform at http://www.sgi.com/tech/stl/transform.html) where the first range has begin and end iterators and other ranges have only begin iterators. However, boost::zip_iterator does not support this capability because it compares all iterators in the iterator tuple. Therefore, it is not possible to write std::transform on two sequences by using a zip_iterator to join the sequences. Allowing this by only comparing the first elements in the iterator tuples would simplify the code for zip_iterator, although it would no longer allow the zipping of zero sequences unless that was special-cased. Is this a reasonable feature to allow? I could probably put together a patch for it in the next few days if people wanted it. -- Jeremiah Willcock

1 0

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

05 Jul '09

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

4 6

Library namespace guidelines
by Neil Groves 05 Jul '09

05 Jul '09

Boosters, I have read both the "Library Requirments and Guidelines" and specifically examined the "Boost Header Policy" and the section on naming consistency but have yet to understand how I should choose to use namespaces for the next version of Boost.Range, that incorporates the accepted Boost.RangeEx proposal. It feels indecent and naughty (in a bad way!) to be putting the library into the top-level boost namespace. More importantly I am concerned that general functions such as "find" will clash when combined with other boost libraries both now and in the future. Would the ideal scenario for new libraries be to have a library related namespace under boost in a manner akin to Boost.Filesystem? Is there already a strategy that is well-known that I am ignorant of? Is there an existing strategy to migrate libraries that pollute the top-level boost namespace that maximises backward compatibility? Any assistance with this matter would be greatly appreciated. Thank you in anticipation, Neil Groves

2 2

[proto] grammar compile error
by Felipe Magno de Almeida 05 Jul '09

05 Jul '09

Hello, When I have a grammar like this: struct create_table_grammar : boost::proto::shift_left < boost::proto::shift_left < boost::proto::terminal<tags::create> , boost::proto::terminal<tags::table> > , boost::proto::terminal<const char*> > {}; And this expression: create << table << "lala"; Where create and table are terminals with the respective tags. I have this compile error: examples/test1.cpp: In function ‘int main()’: examples/test1.cpp:12: error: no match for ‘operator<<’ in ‘sql::keywords::create << sql::keywords::table’ If I don't inner expressions, then (create << table) works. But I can't define a more restricted grammar this way. I want create << table to work only when preceded with another specific expression. I wanted create << table to be enabled, but to disable everything else except (create << table) << ""; Is this possible? Thanks, -- Felipe Magno de Almeida

3 7

is_base_of<int, int> behaviour.
by John Maddock 03 Jul '09

03 Jul '09

Folks, Some time ago we made is_base_of<int,int>::value true, for reasons that escape me, and the TR1 followed this. However, C++0X makes is_base_of<non_class, non_class>::value to be false, which seems all round more logical to me. While I'm sorting out what is_base_of<T, const T> does, it's a good time to fix this as well. Are there any objections to changing the behaviour of is_base_of to match C++0X? Cheers, John.

2 1

v2.0 of Identification library
by joel 03 Jul '09

03 Jul '09

I've uploaded an updated version of the identification library in the Vault some weeks ago and IIRC I forgot to mention it. From the doc : "Boost.Identification is a library which aims at providing a simple solution for building a textual representation of a type as a string that can be manipulated at run-time. Such a feature is often desirable when someone wants to dynamically debug large template class instantiation or use a easy to use `type string representation` to use in serialization process or exception display. Those tasks are often done using the typeid operator but its output is compiler dependant and often produce strings which are usually hard to decipher." Comments and remarks are most welcome. I'll also ask vicente to add it to the Library In Progress wiki page. Thanks in advance. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35

6 8

boost::spirit -- semantic values
by Anand 03 Jul '09

03 Jul '09

I couldn't find a way to associate a semantic value with a non-terminal. Bison/yacc allows this. For example, here is a rule in Bison that says an expression can be the sum of two subexpressions: expr: expr '+' expr { $$ = $1 + $3; } ; The action says how to produce the semantic value of the sum expression from the values of the two subexpressions. Having semantic values for non-terminals is useful to build an expression tree. For, e.g, I can create a new node in the tree by passing in the semantic values of child nodes in the action. expr: expr '+' expr { $$ = makeNode($1, $3, "+"); } ; In this case the semantic value for each expression is of type Node*. Spirit provides parse trees and ASTs and also semantic actions that take the first last iterator pair. But is there some way I can associate a semantic value with each non-terminal and pass in these semantic values to the action for the rule. Thanks, Anand

2 1

Units of data
by Zachary Turner 03 Jul '09

03 Jul '09

Has anyone extended (even privately) Boost.Units to include support for units of data (bits, bytes, KB, MB, etc)? It seems like this would be a useful addition to Boost.Units. Assuming no, what is the minimum amount of work required to do this myself? There's not a lot of info in the docs on how to define new base units, although I've already begun looking over the source code to try to come up with something.

3 12

[BGL] on using visitor in dijkstra_shortest_path
by Sandeep Gupta 02 Jul '09

02 Jul '09

Hi, The example code for extending dijkstra via gives compilation errors. Attached below is the snippet code and the error messages using gcc-4.3.3 and boost_138_0. typedef boost::adjacency_list<vecS, vecS, bidirectionalS > graphImpl_t; //----taken for doc--- template <class PredecessorMap> class record_predecessors : public dijkstra_visitor<> { public: record_predecessors(PredecessorMap p) : m_predecessor(p) { } template <class Edge, class Graph> void edge_relaxed(Edge e, Graph& g) { // set the parent of the target(e) to source(e) put(m_predecessor, target(e, g), source(e, g)); } protected: PredecessorMap m_predecessor; }; template <class PredecessorMap> record_predecessors<PredecessorMap> //error: expected constructor, destructor, or type conversion before ‘<’ token make_predecessor_recorder(PredecessorMap p) { return record_predecessors<PredecessorMap>(p); } ///---end doc-------------- ..... ... vector<vertex_t> p(num_vertices(gg)); dijkstra_shortest_paths(gg, src, predecessor_map(preds).weight_map(weights).distance_map(dists).visitor(make_predecessor_recorder(&p[0]))); Thanks in advance. -sandeep

3 7

[ann] Urdl - a library for downloading web content
by Christopher Kohlhoff 02 Jul '09

02 Jul '09

Hi all, I have just released a new Boost.Asio-based library, Urdl, which can be used for accessing and downloading web content. <http://think-async.com/Urdl> <http://sourceforge.net/projects/urdl> It currently has limited support for the protocols "http", "https" and "file". It provides an easy-to-use extension to standard C++ iostreams and an asynchronous interface for use with Boost.Asio. In addition to (hopefully) being useful, it is intended as an example of using the Boost.Asio and Boost.System libraries. If you're writing protocol implementations using Asio, you might also be interested in how it uses coroutines to simplify the expression of asynchronous control flow. (Note: here coroutines refers to a macro-based system similar to <http://www.chiark.greenend.org.uk/~sgtatham/coroutines.html>, not Giovanni Deretta's GSoC project). Cheers, Chris

11 20

Fixed point implicity
by Soren Holstebroe 02 Jul '09

02 Jul '09

Hi, I'm generalizing my fixed point class and have come across a few design decisions. 1. Return type of additive arithmetic operation between integers and fixed points Example: a 16 bit integer is added to a 16 bit fixed point with 8 bit fraction. I see three possible return types: 16 bit integer, 16:8 fixed point and promoted 32:8 fixed point If return type is 16 bit integer, the fraction is lost. Clearly not an option. If return type is 16:8 fixed point overflow is possible. A return type of 32:8 would eliminate overflow, but promotion quickly becomes problematic for larger integer types, lets say a 32 bit integer added to a fixed point. In that case we would need a 64 bit integer which could cripple performance on many systems. Another problem with promotion is that the arithmetic expression typically would be in a context where the expression is assigned to a fixed point of the type present in the expression. In that case we have an overflow problem again. I think I favor keeping the return type in 16:8. The user would then have to use an explicit cast to avoid overflow. 2. Return type of additive arithmetic operation between float and fixed points Example: fixed_point<int, 16>(10.5) + 5.5f (integer is representing type, 16 bit is the bit reserved for the fraction) What would you expect the return type to be? I think I favor returning a float. The accuracy of the fixed point is compromised anyway. 3. Return type of additive arithmetic operation between different fixed point types Example: fixed_point<int, 16>(10.5) + fixed_point<int, 8>(10.5) Like in case 1 there is the choice between losing precision, risking overflow or promoting (ex. to fixed_point<boost::int_t<16 + 8>::fast, 16>) I think I favor to simply disallow implicit arithmetic between different fixed point types. This would require the user to cast either type. The problem with that choice is less transparent use of the fixed_point type, since changing a type could break existing code where the previous type was in a valid arithmetic operation with another fixed point type. 4. Similar problems exist for multiplication and division If a fixed_point is multiplied with an integer there is a risk of overflow. If a fixed_point is multiplied with another fixed_point there is a risk of overflow and precision will be lost. If a fixed_point is divided by an integer there is a risk of loss of precision. If a fixed_point or integer is divided by another fixed_point there is a risk of overflow and loss of precision. Soren

5 8

Messages lost
by Chard 02 Jul '09

02 Jul '09

I made two posts to this group on 30 June, around 21:00 UTC. Both received acknowledgements, but neither have appeared. A post to the users group, made at about the same time, appeared there immediately. New messages later than my posting time are appearing, so it doesn't look like it's back-log. Are there any known problems? Apologies if this should be directed elsewhere, but at the moment there doesn't seem to be a route open to www.boost.org (to find out); certainly from my ISP...sigh. (Posting this one at 21:30 UTC)

2 2

[task] 0.2.1 Doesn't compile on VC7.1 / older gcc
by Chard 02 Jul '09

02 Jul '09

Hi Oli, As documented, you're testing MS compilation with VC9. We're currently tied to VC7.1 and as we use a threadpool heavily (Philipp Henkel's) I have a particular interest in seeing an 'official' boost threadpool. So forgive me if I keep these coming ;-) There is another VC7.1 compiler conformance issue: static_pool now has the contained pool_base class. The pool_base::submit method constructs a handle<>, however, this has the VC7.1 'friend access to contained class' problem. The handle<> (non-default) constructor is private, granting friend access to static_pool, however, static_pool<>::pool_base requires access, and VC7.1 barfs. I couldn't figure out the friend syntax (that works) to add to class handle<>, so for now I'm working with handle<> (hacked as) public. (Note: earlier versions of gcc, e.g. 3.4.4, will exhibit this problem, too.) I thought this would've been the syntax: # if BOOST_WORKAROUND(BOOST_MSVC, <= 1300) template <typename Channel> friend class static_pool<Channel>::pool_base; # endif but it doesn't appear to be legal. Is this type of declaration even possible? An alternative would be to move (some or all of) the functionality to the outer static_pool class, and route the inner pool_base class to it, e.g. template< typename R > handle< R > static_pool::pool_base::submit( boost::detail::thread_move_t< task< R > > t_) { static_pool::submit(*this, _t); } template< typename R > static handle< R> static_pool::submit(pool_base &pb_, boost::detail::thread_move_t< task< R > > t_) { ... } Or, perhaps just the handle creation line. However, it may be tidier just to have a detail::create_handle (that is the handle<> friend), seeing as you are just trying to say nobody else should be constructing a handle. Regards, and keep up the good work...

2 1

[task] 0.1 => 0.2.1 removes make_task
by Chard 02 Jul '09

02 Jul '09

Task version 0.1 => 0.2.1 comment. make_task appears to have been removed and the multiple argument mechanism migrated to the task constructor. AFAICT this has removed functionality because the make_task helper had the benefit of determining the return value of the task. The task class is templated on the return type, so the user if forced to declare it (okay, not a great deal, but then we have conveniences like make_pair). e.g. 0.1: task::async(threadpool, task::make_task(TaskFunc)); 0.2.1 (argument order exchanged in 0.2.1): task::async(move(task::task<void>(TaskFunc)), threadpool); I assume the reasoning behind this was the cut-over to using move semantics; if this is the case then the constructor: explicit task( Fn fn, BOOST_ENUM_TASK_MAKE_TASK_FUNC_ARGS(n)) \ : task_( new detail::task_wrapper< \ typename result_of< Fn( BOOST_PP_ENUM_PARAMS(n, A)) >::type, \ function< typename result_of< Fn( BOOST_PP_ENUM_PARAMS(n, A)) >::type() > \ >( bind( fn, BOOST_PP_ENUM_PARAMS(n, a)) ) ) \ {} may as well not use result_of; is this not just the template argument, R ? Could make_task have been preserved, but modified to return the move-type ?

2 1

boost::interprocess - lnk2005 error due to compiler/linker bug in msvc8
by willem hengeveld 01 Jul '09

01 Jul '09

when using boost::interprocess under win32, i ran into the following problem: in boost/interprocess/detail/win32_api.hpp several static inline functions have a function local class for releasing resources, like 'unlink_file', which defines 2 classes: handle_closer, and auto_ptr due to a compiler bug, as discussed here: http://www.eggheadcafe.com/conversation.aspx?messageid=32706692&threadid=32… you get a LNK2005 error <symbol> already defined in <object> when using boost::interprocess from multiple .cpp files a solution is to use boost::shared_ptr instead of local classes in win32_api.hpp, like this: boost::shared_ptr<void> hiPSAPI = boost::shared_ptr<void>(load_library("PSAPI.DLL"), free_library); attached is the complete patch willem

3 2

[swap] please update documentation with the header I need to include
by Thorsten Ottosen 01 Jul '09

01 Jul '09

-Thorsten

8 20

Re: [boost] Fixed point integer proposal
by Soren Holstebroe 01 Jul '09

01 Jul '09

> > Some years ago I wrote a fixed point template for transparent fixed point > > integer arithmetics and conversion. > > To me, "fixed point" => !"integer". Obviously fixed point is not an integer in mathematical sense. What I meant was that a fixed point represented by an integer shares some of the same computational properties: Arithmetic is faster than floats on most architectures. Adding (and accumulating) fixed points or multiplying by an integer is exact. Conversion to integer is fast. > particular, saturating or otherwise detecting overflows seemed to be > required. Saturation and overflow detection can be specified as a policy. For me there are two important design criteria: 1st priority is that computational performance matches integer performance. 2nd priority is that it is possible to make a seamless float type and the fixed point type exchange. Adding saturation handling and overflow checks, that are not natively supported by the underlying integer is of lower priority for me. In my fixed point class I implemented overflow check as an optional policy. That way you can add all the overhead checks you want in your debug configuration and strip it in your release build. As of saturation (I assume it's computer graphics people that want that feature) it should be straight forward to implement that as a policy too in the same way as the overflow check. In my option I see little practical use of a saturation policy. Saturation code would kill performance and people would be better off using MMS registers for native saturation. > recall that someone was actually working on that. It was also > suggested that I ought to provide all of the features that <cmath> > provides for floating point. It makes sense to support rounding, abs and mod. I don't see a practical need to natively support trigonometry functions. A conversion to float and back has to be fine. Soren

5 10

[config] problem with sys/select.h on Linux/Unix
by Iain K. Hanson 01 Jul '09

01 Jul '09

Hi, boost config seems to be indirectly including sys/select.h on Linux. This causing me a problem in my sockets library where I have my own declarations of select, fd_set etc which cause duplicate symbols errors. No only can I not use config but also any boost lib as they all use config :-(. Can someone please suggest a fix for this? Out of curiosity, why does config use select.h? regards /ikh -- "I disapprove of what you say, but I will defend to the death your right to say it," Evelyn Beatrice Hall who wrote under the pseudonym S.G. Tallentyre in a biography of Voltaire. #include <std_disclaimer>

2 4

[serialization] Memoryleak in void_caster::recursive_register
by Runar Undheim 01 Jul '09

01 Jul '09

// implementation of void caster base class BOOST_SERIALIZATION_DECL(void) void_caster::recursive_register(bool includes_virtual_base) const { void_cast_detail::set_type & s = void_cast_detail::void_caster_registry::get_mutable_instance(); s.insert(this); // generate all implied void_casts. void_cast_detail::set_type::const_iterator it; for(it = s.begin(); it != s.end(); ++it){ if(m_derived == (*it)->m_base) new void_caster_shortcut( (*it)->m_derived, m_base, m_difference + (*it)->m_difference, includes_virtual_base ); if((*it)->m_derived == m_base) new void_caster_shortcut( m_derived, (*it)->m_base, m_difference + (*it)->m_difference, includes_virtual_base ); } } The new void_caster_shortcut in void_caster::recursive_register give memory leak. The leak is only at startup of program, so it doesn't eat any memory while the program is running. But it makes it difficult to find other memory leaks when the program contain several leaks you don't care about. - Runar

2 2

[gil] gcc 4.4.0 namespace fix
by Philipp Schwaha 01 Jul '09

01 Jul '09

Hi! I hope this is an appropriate place (and time ;) ) for this. I found a few namespace issues concerning GIL and gcc 4.4.0 while working on a project and have (hopefully) fixed them (patch attached - svn revision 54347). Cheers, Philipp Index: boost/gil/color_base.hpp =================================================================== --- boost/gil/color_base.hpp (revision 54347) +++ boost/gil/color_base.hpp (working copy) @@ -85,7 +85,7 @@ // grayscale pixel values are convertible to channel type operator Element () const { return _v0; } - template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,1>& c) : _v0(at_c<0>(c)) {} + template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,1>& c) : _v0(gil::at_c<0>(c)) {} }; @@ -107,13 +107,13 @@ homogeneous_color_base(Element v0, Element v1) : _v0(v0), _v1(v1) {} template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,2>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)) {} // Support for l-value reference proxy copy construction template <typename E2, typename L2> homogeneous_color_base( homogeneous_color_base<E2,L2,2>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)) {} // Support for planar_pixel_iterator construction and dereferencing template <typename P> homogeneous_color_base(P* p,bool) : @@ -155,15 +155,15 @@ homogeneous_color_base(Element v0, Element v1, Element v2) : _v0(v0), _v1(v1), _v2(v2) {} template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,3>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)) {} // Support for l-value reference proxy copy construction template <typename E2, typename L2> homogeneous_color_base( homogeneous_color_base<E2,L2,3>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)) {} // Support for planar_pixel_iterator construction and dereferencing template <typename P> homogeneous_color_base(P* p,bool) : @@ -212,17 +212,17 @@ homogeneous_color_base(Element v0, Element v1, Element v2, Element v3) : _v0(v0), _v1(v1), _v2(v2), _v3(v3) {} template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,4>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)), - _v3(at_c<mapping_transform<Layout,L2,3>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)), + _v3(gil::at_c<mapping_transform<Layout,L2,3>::value>(c)) {} // Support for l-value reference proxy copy construction template <typename E2, typename L2> homogeneous_color_base( homogeneous_color_base<E2,L2,4>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)), - _v3(at_c<mapping_transform<Layout,L2,3>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)), + _v3(gil::at_c<mapping_transform<Layout,L2,3>::value>(c)) {} // Support for planar_pixel_iterator construction and dereferencing template <typename P> homogeneous_color_base(P* p,bool) : @@ -278,19 +278,19 @@ homogeneous_color_base(Element v0, Element v1, Element v2, Element v3, Element v4) : _v0(v0), _v1(v1), _v2(v2), _v3(v3), _v4(v4) {} template <typename E2, typename L2> homogeneous_color_base(const homogeneous_color_base<E2,L2,5>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)), - _v3(at_c<mapping_transform<Layout,L2,3>::value>(c)), - _v4(at_c<mapping_transform<Layout,L2,4>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)), + _v3(gil::at_c<mapping_transform<Layout,L2,3>::value>(c)), + _v4(gil::at_c<mapping_transform<Layout,L2,4>::value>(c)) {} // Support for l-value reference proxy copy construction template <typename E2, typename L2> homogeneous_color_base( homogeneous_color_base<E2,L2,5>& c) : - _v0(at_c<mapping_transform<Layout,L2,0>::value>(c)), - _v1(at_c<mapping_transform<Layout,L2,1>::value>(c)), - _v2(at_c<mapping_transform<Layout,L2,2>::value>(c)), - _v3(at_c<mapping_transform<Layout,L2,3>::value>(c)), - _v4(at_c<mapping_transform<Layout,L2,4>::value>(c)) {} + _v0(gil::at_c<mapping_transform<Layout,L2,0>::value>(c)), + _v1(gil::at_c<mapping_transform<Layout,L2,1>::value>(c)), + _v2(gil::at_c<mapping_transform<Layout,L2,2>::value>(c)), + _v3(gil::at_c<mapping_transform<Layout,L2,3>::value>(c)), + _v4(gil::at_c<mapping_transform<Layout,L2,4>::value>(c)) {} // Support for planar_pixel_iterator construction and dereferencing template <typename P> homogeneous_color_base(P* p,bool) : Index: boost/gil/color_base_algorithm.hpp =================================================================== --- boost/gil/color_base_algorithm.hpp (revision 54347) +++ boost/gil/color_base_algorithm.hpp (working copy) @@ -101,7 +101,7 @@ template <typename ColorBase, int K> struct kth_semantic_element_reference_type { BOOST_STATIC_CONSTANT(int, semantic_index = (mpl::at_c<typename ColorBase::layout_t::channel_mapping_t,K>::type::value)); typedef typename kth_element_reference_type<ColorBase,semantic_index>::type type; - static type get(ColorBase& cb) { return at_c<semantic_index>(cb); } + static type get(ColorBase& cb) { return gil::at_c<semantic_index>(cb); } }; /// \brief Specifies the return type of the constant semantic_at_c<K>(color_base); @@ -109,7 +109,7 @@ template <typename ColorBase, int K> struct kth_semantic_element_const_reference_type { BOOST_STATIC_CONSTANT(int, semantic_index = (mpl::at_c<typename ColorBase::layout_t::channel_mapping_t,K>::type::value)); typedef typename kth_element_const_reference_type<ColorBase,semantic_index>::type type; - static type get(const ColorBase& cb) { return at_c<semantic_index>(cb); } + static type get(const ColorBase& cb) { return gil::at_c<semantic_index>(cb); } }; /// \brief A mutable accessor to the K-th semantic element of a color base Index: boost/gil/pixel.hpp =================================================================== --- boost/gil/pixel.hpp (revision 54347) +++ boost/gil/pixel.hpp (working copy) @@ -143,11 +143,11 @@ private: static void check_gray() { BOOST_STATIC_ASSERT((is_same<typename Layout::color_space_t, gray_t>::value)); } - template <typename Channel> void assign(const Channel& chan, mpl::false_) { check_gray(); at_c<0>(*this)=chan; } - template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return at_c<0>(*this)==chan; } + template <typename Channel> void assign(const Channel& chan, mpl::false_) { check_gray(); gil::at_c<0>(*this)=chan; } + template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return gil::at_c<0>(*this)==chan; } public: - pixel& operator= (channel_t chan) { check_gray(); at_c<0>(*this)=chan; return *this; } - bool operator==(channel_t chan) const { check_gray(); return at_c<0>(*this)==chan; } + pixel& operator= (channel_t chan) { check_gray(); gil::at_c<0>(*this)=chan; return *this; } + bool operator==(channel_t chan) const { check_gray(); return gil::at_c<0>(*this)==chan; } }; ///////////////////////////// Index: boost/gil/image_view_factory.hpp =================================================================== --- boost/gil/image_view_factory.hpp (revision 54347) +++ boost/gil/image_view_factory.hpp (working copy) @@ -102,7 +102,7 @@ BOOST_STATIC_ASSERT((!is_planar<HomogeneousView>::value && view_is_basic<HomogeneousView>::value)); BOOST_STATIC_ASSERT((boost::is_pointer<typename HomogeneousView::x_iterator>::value)); - return &at_c<0>(view(0,0)); + return &gil::at_c<0>(view(0,0)); } /// \ingroup ImageViewConstructors @@ -430,7 +430,7 @@ typedef typename type::xy_locator locator_t; typedef typename type::x_iterator x_iterator_t; typedef typename iterator_adaptor_get_base<x_iterator_t>::type x_iterator_base_t; - x_iterator_t sit(x_iterator_base_t(&at_c<K>(src(0,0))),src.pixels().pixel_size()); + x_iterator_t sit(x_iterator_base_t(&gil::at_c<K>(src(0,0))),src.pixels().pixel_size()); return type(src.dimensions(),locator_t(sit, src.pixels().row_size())); } }; @@ -444,7 +444,7 @@ typedef typename view_type<channel_t, gray_layout_t, false, false, view_is_mutable<View>::value>::type type; static type make(const View& src) { typedef typename type::x_iterator x_iterator_t; - return interleaved_view(src.width(),src.height(),(x_iterator_t)&at_c<K>(src(0,0)), src.pixels().row_size()); + return interleaved_view(src.width(),src.height(),(x_iterator_t)&gil::at_c<K>(src(0,0)), src.pixels().row_size()); } }; @@ -494,7 +494,7 @@ template <typename P> kth_channel_deref_fn(const kth_channel_deref_fn<K,P>&) {} result_type operator()(argument_type srcP) const { - return result_type(at_c<K>(srcP)); + return result_type(gil::at_c<K>(srcP)); } }; Index: boost/gil/bit_aligned_pixel_reference.hpp =================================================================== --- boost/gil/bit_aligned_pixel_reference.hpp (revision 54347) +++ boost/gil/bit_aligned_pixel_reference.hpp (working copy) @@ -145,7 +145,7 @@ // Construct from another compatible pixel type bit_aligned_pixel_reference(const bit_aligned_pixel_reference& p) : _bit_range(p._bit_range) {} - template <typename BF, typename CR> bit_aligned_pixel_reference(packed_pixel<BF,CR,Layout>& p) : _bit_range(static_cast<data_ptr_t>(&at_c<0>(p)), at_c<0>(p).first_bit()) { + template <typename BF, typename CR> bit_aligned_pixel_reference(packed_pixel<BF,CR,Layout>& p) : _bit_range(static_cast<data_ptr_t>(&gil::at_c<0>(p)), gil::at_c<0>(p).first_bit()) { check_compatible<packed_pixel<BF,CR,Layout> >(); } @@ -169,8 +169,8 @@ private: static void check_gray() { BOOST_STATIC_ASSERT((is_same<typename Layout::color_space_t, gray_t>::value)); } - template <typename Channel> void assign(const Channel& chan, mpl::false_) const { check_gray(); at_c<0>(*this)=chan; } - template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return at_c<0>(*this)==chan; } + template <typename Channel> void assign(const Channel& chan, mpl::false_) const { check_gray(); gil::at_c<0>(*this)=chan; } + template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return gil::at_c<0>(*this)==chan; } }; ///////////////////////////// Index: boost/gil/gil_concept.hpp =================================================================== --- boost/gil/gil_concept.hpp (revision 54347) +++ boost/gil/gil_concept.hpp (working copy) @@ -618,7 +618,7 @@ typedef typename kth_element_const_reference_type<ColorBase,num_elements-1>::type CR; #if !defined(_MSC_VER) || _MSC_VER > 1310 - CR cr=at_c<num_elements-1>(cb); ignore_unused_variable_warning(cr); + CR cr=gil::at_c<num_elements-1>(cb); ignore_unused_variable_warning(cr); #endif // functions that work for every pixel (no need to require them) @@ -655,8 +655,8 @@ typedef typename kth_element_reference_type<ColorBase, 0>::type CR; #if !defined(_MSC_VER) || _MSC_VER > 1310 - CR r=at_c<0>(cb); - at_c<0>(cb)=r; + CR r=gil::at_c<0>(cb); + gil::at_c<0>(cb)=r; #endif } Index: boost/gil/planar_pixel_iterator.hpp =================================================================== --- boost/gil/planar_pixel_iterator.hpp (revision 54347) +++ boost/gil/planar_pixel_iterator.hpp (working copy) @@ -109,8 +109,8 @@ reference operator->() const { return **this; } // PERFORMANCE_CHECK: Remove? - bool operator< (const planar_pixel_iterator& ptr) const { return at_c<0>(*this)< at_c<0>(ptr); } - bool operator!=(const planar_pixel_iterator& ptr) const { return at_c<0>(*this)!=at_c<0>(ptr); } + bool operator< (const planar_pixel_iterator& ptr) const { return gil::at_c<0>(*this)< gil::at_c<0>(ptr); } + bool operator!=(const planar_pixel_iterator& ptr) const { return gil::at_c<0>(*this)!=gil::at_c<0>(ptr); } private: friend class boost::iterator_core_access; @@ -119,8 +119,8 @@ void advance(ptrdiff_t d) { static_transform(*this,*this,std::bind2nd(detail::plus_asymmetric<ChannelPtr,ptrdiff_t>(),d)); } reference dereference() const { return this->template deref<reference>(); } - ptrdiff_t distance_to(const planar_pixel_iterator& it) const { return at_c<0>(it)-at_c<0>(*this); } - bool equal(const planar_pixel_iterator& it) const { return at_c<0>(*this)==at_c<0>(it); } + ptrdiff_t distance_to(const planar_pixel_iterator& it) const { return gil::at_c<0>(it)-gil::at_c<0>(*this); } + bool equal(const planar_pixel_iterator& it) const { return gil::at_c<0>(*this)==gil::at_c<0>(it); } }; namespace detail { @@ -184,7 +184,7 @@ template <typename IC, typename C> inline std::ptrdiff_t memunit_distance(const planar_pixel_iterator<IC,C>& p1, const planar_pixel_iterator<IC,C>& p2) { - return memunit_distance(at_c<0>(p1),at_c<0>(p2)); + return memunit_distance(gil::at_c<0>(p1),gil::at_c<0>(p2)); } template <typename IC> Index: boost/gil/packed_pixel.hpp =================================================================== --- boost/gil/packed_pixel.hpp (revision 54347) +++ boost/gil/packed_pixel.hpp (working copy) @@ -77,19 +77,19 @@ template <typename P> packed_pixel(const P& p, typename enable_if_c<is_pixel<P>::value>::type* d=0) { check_compatible<P>(); static_copy(p,*this); } packed_pixel(int chan0, int chan1) : _bitfield(0) { BOOST_STATIC_ASSERT((num_channels<packed_pixel>::value==2)); - at_c<0>(*this)=chan0; at_c<1>(*this)=chan1; + gil::at_c<0>(*this)=chan0; gil::at_c<1>(*this)=chan1; } packed_pixel(int chan0, int chan1, int chan2) : _bitfield(0) { BOOST_STATIC_ASSERT((num_channels<packed_pixel>::value==3)); - at_c<0>(*this)=chan0; at_c<1>(*this)=chan1; at_c<2>(*this)=chan2; + gil::at_c<0>(*this)=chan0; gil::at_c<1>(*this)=chan1; gil::at_c<2>(*this)=chan2; } packed_pixel(int chan0, int chan1, int chan2, int chan3) : _bitfield(0) { BOOST_STATIC_ASSERT((num_channels<packed_pixel>::value==4)); - at_c<0>(*this)=chan0; at_c<1>(*this)=chan1; at_c<2>(*this)=chan2; at_c<3>(*this)=chan3; + gil::at_c<0>(*this)=chan0; gil::at_c<1>(*this)=chan1; gil::at_c<2>(*this)=chan2; gil::at_c<3>(*this)=chan3; } packed_pixel(int chan0, int chan1, int chan2, int chan3, int chan4) : _bitfield(0) { BOOST_STATIC_ASSERT((num_channels<packed_pixel>::value==5)); - at_c<0>(*this)=chan0; at_c<1>(*this)=chan1; at_c<2>(*this)=chan2; at_c<3>(*this)=chan3; at_c<4>(*this)=chan4; + gil::at_c<0>(*this)=chan0; gil::at_c<1>(*this)=chan1; gil::at_c<2>(*this)=chan2; gil::at_c<3>(*this)=chan3; gil::at_c<4>(*this)=chan4; } packed_pixel& operator=(const packed_pixel& p) { _bitfield=p._bitfield; return *this; } @@ -106,11 +106,11 @@ // Support for assignment/equality comparison of a channel with a grayscale pixel static void check_gray() { BOOST_STATIC_ASSERT((is_same<typename Layout::color_space_t, gray_t>::value)); } - template <typename Channel> void assign(const Channel& chan, mpl::false_) { check_gray(); at_c<0>(*this)=chan; } - template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return at_c<0>(*this)==chan; } + template <typename Channel> void assign(const Channel& chan, mpl::false_) { check_gray(); gil::at_c<0>(*this)=chan; } + template <typename Channel> bool equal (const Channel& chan, mpl::false_) const { check_gray(); return gil::at_c<0>(*this)==chan; } public: - packed_pixel& operator= (int chan) { check_gray(); at_c<0>(*this)=chan; return *this; } - bool operator==(int chan) const { check_gray(); return at_c<0>(*this)==chan; } + packed_pixel& operator= (int chan) { check_gray(); gil::at_c<0>(*this)=chan; return *this; } + bool operator==(int chan) const { check_gray(); return gil::at_c<0>(*this)==chan; } }; ///////////////////////////// Index: libs/gil/test/performance.cpp =================================================================== --- libs/gil/test/performance.cpp (revision 54347) +++ libs/gil/test/performance.cpp (working copy) @@ -81,9 +81,9 @@ T* first=(T*)_v.row_begin(0); T* last=first+_v.size()*3; while(first!=last) { - first[0]=at_c<0>(_p); - first[1]=at_c<1>(_p); - first[2]=at_c<2>(_p); + first[0]=boost::gil::at_c<0>(_p); + first[1]=boost::gil::at_c<1>(_p); + first[2]=boost::gil::at_c<2>(_p); first+=3; } } @@ -99,9 +99,9 @@ T1* first=(T1*)_v.row_begin(0); T1* last=first+_v.size()*3; while(first!=last) { - first[0]=at_c<2>(_p); - first[1]=at_c<1>(_p); - first[2]=at_c<0>(_p); + first[0]=boost::gil::at_c<2>(_p); + first[1]=boost::gil::at_c<1>(_p); + first[2]=boost::gil::at_c<0>(_p); first+=3; } } @@ -116,12 +116,12 @@ void operator()() const { std::size_t size=_v.size(); T1* first; - first=(T1*)at_c<0>(_v.row_begin(0)); - std::fill(first,first+size,at_c<0>(_p)); - first=(T1*)at_c<1>(_v.row_begin(0)); - std::fill(first,first+size,at_c<1>(_p)); - first=(T1*)at_c<2>(_v.row_begin(0)); - std::fill(first,first+size,at_c<2>(_p)); + first=(T1*)boost::gil::at_c<0>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<0>(_p)); + first=(T1*)boost::gil::at_c<1>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<1>(_p)); + first=(T1*)boost::gil::at_c<2>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<2>(_p)); } }; @@ -135,12 +135,12 @@ void operator()() const { std::size_t size=_v.size(); T1* first; - first=(T1*)at_c<0>(_v.row_begin(0)); - std::fill(first,first+size,at_c<2>(_p)); - first=(T1*)at_c<1>(_v.row_begin(0)); - std::fill(first,first+size,at_c<1>(_p)); - first=(T1*)at_c<2>(_v.row_begin(0)); - std::fill(first,first+size,at_c<1>(_p)); + first=(T1*)boost::gil::at_c<0>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<2>(_p)); + first=(T1*)boost::gil::at_c<1>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<1>(_p)); + first=(T1*)boost::gil::at_c<2>(_v.row_begin(0)); + std::fill(first,first+size,boost::gil::at_c<1>(_p)); } }; @@ -191,9 +191,9 @@ for_each_nongil_t(const View& v_in,const F& f_in) : _v(v_in), _f(f_in) {} void operator()() const { T1 *first0, *first1, *first2, *last0; - first0=(T1*)at_c<0>(_v.row_begin(0)); - first1=(T1*)at_c<1>(_v.row_begin(0)); - first2=(T1*)at_c<2>(_v.row_begin(0)); + first0=(T1*)boost::gil::at_c<0>(_v.row_begin(0)); + first1=(T1*)boost::gil::at_c<1>(_v.row_begin(0)); + first2=(T1*)boost::gil::at_c<2>(_v.row_begin(0)); last0=first0+_v.size(); while(first0!=last0) { *first0++=0; @@ -261,12 +261,12 @@ copy_nongil_t(const View1& v1_in,const View2& v2_in) : _v1(v1_in), _v2(v2_in) {} void operator()() const { std::size_t size=_v1.size(); - T1* first10=(T1*)at_c<0>(_v1.row_begin(0)); - T1* first11=(T1*)at_c<1>(_v1.row_begin(0)); - T1* first12=(T1*)at_c<2>(_v1.row_begin(0)); - T2* first20=(T2*)at_c<0>(_v2.row_begin(0)); - T2* first21=(T2*)at_c<1>(_v2.row_begin(0)); - T2* first22=(T2*)at_c<2>(_v2.row_begin(0)); + T1* first10=(T1*)boost::gil::at_c<0>(_v1.row_begin(0)); + T1* first11=(T1*)boost::gil::at_c<1>(_v1.row_begin(0)); + T1* first12=(T1*)boost::gil::at_c<2>(_v1.row_begin(0)); + T2* first20=(T2*)boost::gil::at_c<0>(_v2.row_begin(0)); + T2* first21=(T2*)boost::gil::at_c<1>(_v2.row_begin(0)); + T2* first22=(T2*)boost::gil::at_c<2>(_v2.row_begin(0)); std::copy(first10,first10+size,first20); std::copy(first11,first11+size,first21); std::copy(first12,first12+size,first22); @@ -282,9 +282,9 @@ void operator()() const { T1* first=(T1*)_v1.row_begin(0); T1* last=first+_v1.size()*3; - T2* first0=(T2*)at_c<0>(_v2.row_begin(0)); - T2* first1=(T2*)at_c<1>(_v2.row_begin(0)); - T2* first2=(T2*)at_c<2>(_v2.row_begin(0)); + T2* first0=(T2*)boost::gil::at_c<0>(_v2.row_begin(0)); + T2* first1=(T2*)boost::gil::at_c<1>(_v2.row_begin(0)); + T2* first2=(T2*)boost::gil::at_c<2>(_v2.row_begin(0)); while(first!=last) { *first0++=first[0]; *first1++=first[1]; @@ -303,9 +303,9 @@ void operator()() const { T1* first=(T1*)_v2.row_begin(0); T1* last=first+_v2.size()*3; - T2* first0=(T2*)at_c<0>(_v1.row_begin(0)); - T2* first1=(T2*)at_c<1>(_v1.row_begin(0)); - T2* first2=(T2*)at_c<2>(_v1.row_begin(0)); + T2* first0=(T2*)boost::gil::at_c<0>(_v1.row_begin(0)); + T2* first1=(T2*)boost::gil::at_c<1>(_v1.row_begin(0)); + T2* first2=(T2*)boost::gil::at_c<2>(_v1.row_begin(0)); while(first!=last) { first[0]=*first0++; first[1]=*first1++; @@ -369,12 +369,12 @@ F _f; transform_nongil_t(const View1& v1_in,const View2& v2_in,const F& f_in) : _v1(v1_in),_v2(v2_in),_f(f_in) {} void operator()() const { - T1* first10=(T1*)at_c<0>(_v1.row_begin(0)); - T1* first11=(T1*)at_c<1>(_v1.row_begin(0)); - T1* first12=(T1*)at_c<2>(_v1.row_begin(0)); - T1* first20=(T2*)at_c<0>(_v2.row_begin(0)); - T1* first21=(T2*)at_c<1>(_v2.row_begin(0)); - T1* first22=(T2*)at_c<2>(_v2.row_begin(0)); + T1* first10=(T1*)boost::gil::at_c<0>(_v1.row_begin(0)); + T1* first11=(T1*)boost::gil::at_c<1>(_v1.row_begin(0)); + T1* first12=(T1*)boost::gil::at_c<2>(_v1.row_begin(0)); + T1* first20=(T2*)boost::gil::at_c<0>(_v2.row_begin(0)); + T1* first21=(T2*)boost::gil::at_c<1>(_v2.row_begin(0)); + T1* first22=(T2*)boost::gil::at_c<2>(_v2.row_begin(0)); T1* last10=first10+_v1.size(); while(first10!=last10) { *first20++=T2(*first12++*0.1f); @@ -394,9 +394,9 @@ void operator()() const { T1* first1=(T1*)_v1.row_begin(0); T1* last1=first1+_v1.size()*3; - T1* first20=(T2*)at_c<0>(_v2.row_begin(0)); - T1* first21=(T2*)at_c<1>(_v2.row_begin(0)); - T1* first22=(T2*)at_c<2>(_v2.row_begin(0)); + T1* first20=(T2*)boost::gil::at_c<0>(_v2.row_begin(0)); + T1* first21=(T2*)boost::gil::at_c<1>(_v2.row_begin(0)); + T1* first22=(T2*)boost::gil::at_c<2>(_v2.row_begin(0)); while(first1!=last1) { *first20++=T2(first1[2]*0.1f); *first21++=T2(first1[1]*0.2f); @@ -414,9 +414,9 @@ F _f; transform_nongil_t(const View1& v1_in,const View2& v2_in,const F& f_in) : _v1(v1_in),_v2(v2_in),_f(f_in) {} void operator()() const { - T1* first10=(T1*)at_c<0>(_v1.row_begin(0)); - T1* first11=(T1*)at_c<1>(_v1.row_begin(0)); - T1* first12=(T1*)at_c<2>(_v1.row_begin(0)); + T1* first10=(T1*)boost::gil::at_c<0>(_v1.row_begin(0)); + T1* first11=(T1*)boost::gil::at_c<1>(_v1.row_begin(0)); + T1* first12=(T1*)boost::gil::at_c<2>(_v1.row_begin(0)); T2* first2=(T1*)_v2.row_begin(0); T1* last2=first2+_v1.size()*3; while(first2!=last2) { Index: libs/gil/test/pixel.cpp =================================================================== --- libs/gil/test/pixel.cpp (revision 54347) +++ libs/gil/test/pixel.cpp (working copy) @@ -63,8 +63,8 @@ // test homogeneous algorithms - fill, max, min static const int num_chan = num_channels<typename C2::pixel_t>::value; - static_fill(C2::_pixel, at_c<0>(C1::_pixel)+1); - error_if(at_c<0>(C2::_pixel) != at_c<num_chan-1>(C2::_pixel)); + static_fill(C2::_pixel, boost::gil::at_c<0>(C1::_pixel)+1); + error_if(boost::gil::at_c<0>(C2::_pixel) != boost::gil::at_c<num_chan-1>(C2::_pixel)); C2::_pixel = C1::_pixel; error_if(static_max(C2::_pixel) != static_max(C1::_pixel)); @@ -107,7 +107,7 @@ error_if(C1::_pixel!=C2::_pixel); static_generate(C2::_pixel, set_to_one()); - error_if(at_c<0>(C2::_pixel) != 1); + error_if(boost::gil::at_c<0>(C2::_pixel) != 1); // Test swap if both are mutable and if their value type is the same // (We know the second one is mutable) @@ -313,7 +313,7 @@ bgr8_pixel_t bgr8(rgb8); error_if(bgr8[0] == rgb8[0]); error_if(dynamic_at_c(bgr8,0) == dynamic_at_c(rgb8,0)); - error_if(at_c<0>(bgr8) == at_c<0>(rgb8)); + error_if(boost::gil::at_c<0>(bgr8) == boost::gil::at_c<0>(rgb8)); error_if(semantic_at_c<0>(bgr8) != semantic_at_c<0>(rgb8)); error_if(get_color(bgr8,blue_t()) != get_color(rgb8,blue_t()));

2 1