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

bad include guards
by Steven Watanabe 26 Jan '17

26 Jan '17

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

5 8

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

29 Apr '14

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

9 16

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

18 Nov '12

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

17 20

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

03 Nov '11

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

6 13

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

25 May '11

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

5 9

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

21 Feb '11

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

5 11

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

16 Feb '11

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

14 27

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

23 Jan '11

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

4 9

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

15 Apr '10

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

3 2

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

[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

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

[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

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

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

[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

[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

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

[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

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

23 Jul '09

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

11 30

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

18 Jul '09

Dear Phil, >Having said all that, I must say that I actually use the code that I >wrote quite rarely. I now tend to use UTF8 everywhere and treat it as >a sequence of bytes. Because of the properties of UTF8 I find it's >rare to need to identify individual code points. For example, if I'm >scanning for a matching " or ) I can just look for the next matching >byte, without worrying about where the character boundaries are. Using UTF-8 can work well if you are only targeting American and Western Europe for non-literary use. If you need to support the rest of the world you really need to move to UTF-32 due to the large number of characters and the grapheme and glyph handling [e.g. in Urdu you can type 3 characters and they are displayed as a single combined glyph, and the cursor should never be placed between them]. Even in UTF-8 things can get a bit tricky. For example, where do you break the line if you needed in the middle of: joe)jack -> joe) jack joe(jack -> joe (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

[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

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

[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

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

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

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

[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::value>::type* d=0) { check_compatible(); 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

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

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

[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

[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

[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::value>::type* d=0) { check_compatible(); 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

[interprocess] problem compiling
by manmohan.m＠nokia.com 30 Jun '09

30 Jun '09

Hello, I'm trying to use boost::interprocess in my code. The environment being used is S60 armv5 WINSCW (RVCT compiler) . Since it's a header only library, I presumed including it in my USERINCLUDE (i.e placing interprocess inside my local \inc), would suffice the purpose. But there were some dependencies e.g. some include files were not to be found. I managed to solve the interdependencies by including the missing files locally. But when I try to use the sample code for managed_shared_memory (given on the doc page for boost::interprocess), it's giving me errors regarding template-instantiation in ..\inc\boost\interprocess\mem_algo\rbtree_best_fit.hpp. To be precise, the error that I got is attached in the text file. It's too verbose to be written here. The usage is that my main() consists of the following #include "boost/interprocess/managed_shared_memory.hpp" #include "boost/interprocess/containers/vector.hpp" #include "boost/interprocess/allocators/allocator.hpp" int main () { using namespace boost::interprocess; //Shared memory front-end that is able to construct objects //associated with a c-string. Erase previous shared memory with the name //to be used and create the memory segment at the specified address and initialize resources shared_memory_object::remove("MySharedMemory"); managed_shared_memory segment (create_only ,"MySharedMemory" ,65536); //segment size in bytes return 0; } The underlined statement is the point of instatiation and this is creating the above said errror. Could somebody please point out what am I missing? Is there something else that I need to do in order to use boost::interprocess? Thanks & Regards Manmohan P.S.: Boost is already ported under the environment, but not all modules. I could see all the major includes under system include path "R:\epoc32\include\osextensions\stdapis\boost".

1 0

[serialization] impossible to extend xml_iarchive?
by Kenny Riddile 29 Jun '09

29 Jun '09

Here I am again...still trying to add a seemingly trivial bit of functionality to xml_iarchive by following the directions at: http://www.boost.org/doc/libs/1_39_0/libs/serialization/doc/derivation.html In my last post (http://lists.boost.org/boost-users/2009/06/49028.php) I was getting several unresolved externals from basic_xml_grammar<char>. I figured I needed to simply explicitly instantiate this template like the others. The first problem with that is that basic_xml_grammar.ipp isn't in boost/archive/impl/ like the other ipp's are. It's in serialization's source directory, which I, like most people, had thrown away after building Boost. So after I copied that file into my own codebase so I could include it and explicitly instantiate basic_xml_grammar<char>, I then got a single unresolved external complaining about basic_xml_grammar<char>::init_chset() not being defined. After some more digging, I found that that particular method is defined in basic_xml_grammar.cpp which is also in serialization's source directory. Even after all that, I'm still getting some other linker errors that nobody here can figure out after hours of trying, but the aforementioned issues alone suggest to me that it isn't currently possible to extend xml_iarchive by following the instructions in the documentation. -Kenny Riddile

1 0