November 2012 - Boost - lists.preview.boost.org

[Range] Proposal: a sub-maintainer of Boost.Range
by Michel Morin 05 Jan '13

05 Jan '13

Dear Neil, Dear Nate, First I'd like to say thank you for your library, Neil. It is a very useful library and it's great fun to writing codes with range adaptors. Boost.Range is one of the most important Boost libraries that are not yet added to the Standard. I know that Neil has made an effort to make time for developing the library, but recently making time for development seems difficult. And there are several open tickets of trivial bugs (e.g. #5603, #6110). Considering this situation, I'd like to make a proposal about Boost.Range: ** Adding a sub-maintainer to Boost.Range ** This reduces author's maintenance burden and also helps more stable development of the library. I recommend Nathan Ridge as a sub-maintainer of Boost.Range. His knowledge, experiences and contribution to Boost are great. If both of Neil and Nate accept the proposal, and if Nate needs some support for the start-up, I'll try my best to support him. I also believe that Jeff will also support him ;) Neil, what do you think about this proposal? I would appreciate and respect any of your reply. Yours sincerely, Michel

11 42

[config] Proposed BOOST_NOEXCEPT_NOTHROW macro
by Beman Dawes 03 Jan '13

03 Jan '13

The three current BOOST_NOEXCEPT* macro variants miss the case where C++03 code has a "throw()" throw-specifier. Classes that derive from standard library exceptions need this to avoid breaking code on C++03 compilers. I'm not enamored with the BOOST_NOEXCEPT_NOTHROW name, so feel free to offer suggestions for alternate names. Here is the full set of macros: #ifdef BOOST_NO_NOEXCEPT # define BOOST_NOEXCEPT # define BOOST_NOEXCEPT_NOTHROW throw() <---- new macro # define BOOST_NOEXCEPT_IF(Predicate) # define BOOST_NOEXCEPT_EXPR(Expression) false #else # define BOOST_NOEXCEPT noexcept # define BOOST_NOEXCEPT_NOTHROW noexcept <---- new macro # define BOOST_NOEXCEPT_IF(Predicate) noexcept((Predicate)) # define BOOST_NOEXCEPT_EXPR(Expression) noexcept((Expression)) #endif Unless there are objections, I'll commit the changes Wednesday afternoon Eastern US time. --Beman

7 11

Re: [boost] Heads up - string_ref landing
by Yanchenko Maxim 19 Dec '12

19 Dec '12

Marshall. low <mclow.lists. at> gmail.com> writes: > Please let me know what you think! As probably everyone, we have our own device for this. Here are some points and experience we gathered. 1. This class is essentially just an iterator_ range<char*> (modulo template for const/wchar_t), so it should either inherit from it or have corresponding converting ctors/operators. In this sense Olaf/Gennadiy's remarks are pretty valid. OTOH size is needed very frequently and having it precomputed is a good thing, so conversion approach seems to be better (but then we lose passing by reference as iterator_range, type_traits etc). I'm not sure what's more important. 2. Given the above, the name is misleading as it's not a reference to std::string. We use name char_range. 3. It's worth having a static constructor 'literal' (templated with size) to construct char_ranges from literals - as the compiler knows their size in compile time (minus zero terminator). It can be a constexpr too. Same manner - static function 'from_array', embrasing an array of chars in whole, assuming there is no zero terminator - useful for working with structures representing messages in char-based protocols with fixed-width fields. 4. (hack) We had to add a member function 'assign' (this is just operator=) to make boost::tokenizer return char_ranges. I don't like this part at all as it contradicts the meaning of say std::vector::assign, so I'd prefer another solution, probably in form of a customization point in boost::tokenizer. Thanks, Maxim

20 115

[graph] A* search applied to knight's tour
by Dave Abrahams 15 Dec '12

15 Dec '12

Hi, I was just trying to work up an example for a class I'm teaching, to illustrate implicit graphs. The following shows how far I've gotten: https://gist.github.com/4153918 This is attempting to apply Warnsdorff's heuristic (choose the next move with the least out-degree) using A* search. I'm running into several problems having to do with the requirements of astar_search_no_init. In particular, the requirement that we can assign an index to every vertex is quite painful, since enumerating all the possible vertices in the search space is difficult. Any advice here? I suppose I could keep a real map and simply assign indices in the order vertices are encountered, but that seems pretty ugly to me. Any hints? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

2 4

[Interprocess] Experimental Win32 Mutexes
by Brink, Robert (GE Aviation, US) 13 Dec '12

13 Dec '12

I'm running Boost 1.52 on Windows 7, Visual Studio 2010. I noticed in sync\interprocess_mutex.hpp there is a windows mutex implementation that is hidden behind the BOOST_INTERPROCESS_FORCE_GENERIC_EMULATION macro. The comment indicates that it is "Experimental". Could someone shed some light on what is Experimental about it and what the general plans for this feature are? I was having a problem with many processes all spin-locking when allocating shared memory that I traced down to the old mutex implementation for shared memory. I enabled the experimental feature in my local build ( by commenting out the above macro in the detail\workaround.hpp file) and it seems to fix my problems. My performance is much improved. But what are my risks for using this implementation? I'm a little nervous to depend on something marked as "Experimental". Thanks Rob Brink

3 5

Heads up - string_ref landing
by Marshall Clow 12 Dec '12

12 Dec '12

I'm about to check in some new functionality into the string_algo library; an implementation of string_ref. A string_ref is a non-owning reference to a string. It is implemented as a {pointer, length} pair, and is exceedingly useful when parsing, and manipulating strings in "read-only" ways. The header will be in boost/algorithm/string_ref.hpp, but I welcome discussion about where it should live. Ideally, I think it should be just "boost/string_ref.hpp". Basic sanity tests will be checked in with the header file - I have tested on clang, clang11, and gcc. One reason for checking this in now is to get the tests run on lots of different systems. Docs will be coming soon, but http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3442.html is the proposal for "a future version of C++" ;-) Please let me know what you think! -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

18 45

Using c++11 features in clang
by Marshall Clow 10 Dec '12

10 Dec '12

In response to a some questions on the boost-users list (and boost bug reports), I wrote up this: http://marshall.calepin.co/llvmclang-and-standard-libraries-on-mac-os-x.html I don't know if this should be a FAQ entry for Boost, or for clang. Suggestions/comments/edits welcome. -- Marshall Marshall Clow Idio Software <mailto:mclow.lists@gmail.com> A.D. 1517: Martin Luther nails his 95 Theses to the church door and is promptly moderated down to (-1, Flamebait). -- Yu Suzuki

3 3

[algorithm][hex] function hex_char_to_int in unnamed namespace in header file
by Felipe Magno de Almeida 10 Dec '12

10 Dec '12

Hello, AFAIK, unnamed namespaces are dangerous in headers. There is a commentary just above the function definition: // this needs to be in an un-named namespace because it is not a template // and might get included in several compilation units. This could cause // multiple definition errors at link time. But it seems the better thing would be to define it inline. It is exactly because it can be used in several translation units that it can cause an ODR violation if defined in a unnamed namespace AFAIK. Regards, -- Felipe Magno de Almeida

3 8

Boost.Test updates in trunk: need for (mini) review?
by Gennadiy Rozenal 09 Dec '12

09 Dec '12

Hi, It's been a long while since I merged any changes into boost release and by now there are whole bunch of new features there. Some are small, but some others are big ones such that they can change the way people use the library. I'd like to list them here (excluding bug fixes and removal of deprecated interfaces) and ask what should we do with these. Specifically let me know if you think these require some kind of (mini) review from community, but any other comments are welcome as well. So here we go: I. New testing tool BOOST_CHECKA This tool is based on excellent idea from Kevlin Henney. I chose the name CHECKA for this tool due to the lack of better name, but I am open to suggestions. This testing tool capable of replacing whole bunch of existing other tools like BOOST_CHECK_EQUAL, BOOST_CHECK_GT etc. Usage is the most natural you can wish for: BOOST_CHECKA( var1 - var2 >= 12 ); And the output will include as much information as we can get: error: in "foo": check var1 - var2 >= 12 failed [23-15<12] II. New "data driven test case" subsystem New data driven test case subsystem represent a generalization of parameterized test case and test case template and eventually will replace both. The idea is to allow user to specify an arbitrary (monomorphic or polymorphic) set of samples and run a test case on each of the samples. Samples can have different arity, thus you can have test cases with multiple parameters of different types. For now we support following dataset kinds (aside of generators none of dataset constructions routines performs *any* copying): a) singleton - dataset constructed out of single sample data::make(10) - singleton dataset with integer sample data::make("qwerty") - singleton dataset with string sample b) array - dataset constructed out of C array int a[] = {1,2,3,4,5,6}; data::make(a) - dataset with 6 integer values c) collection - dataset constructed out of C++ forward iterable collection std::vector<double> v{1.2, 2.3, 3.4, 5.6 }; data::make(v) - dataset with 6 double values d) join - dataset constructed by joining 2 datasets of the same type int a[] = {1,2,3}; int b[] = {7,8,9}; data::make(a) + data::make(b) - dataset with 6 integer values e) zip - dataset constructed by zipping 2 datasets of the same size, but not necessarily the same type This dataset has an arity which is sum of argument dataset arities. int a[] = {1,2,3}; char* b[] = {"qwe", "asd", "zxc"}; data::make(a) ^ data::make(b) dataset with 3 samples which are pairs of int and char*. f) grid - dataset constructed by "multiplying" 2 datasets of the same different sizes and types type This dataset has an arity which is sum of argument dataset arities. int a[] = {1,2,3}; char* b[] = {"qwe", "asd"}; double c[] = {1.1, 2.2}; data::make(a) * data::make(b) * data::make(c) dataset with 12 samples which are tuples of int and char* and double. g) xrange generator dataset which produes samples in some range data::xrange( 0., 3., 0.4 ) - dataset with 8 double samples data::xrange<int>((data::begin=9, data::end=15)) - dataset with 6 int samples data::xrange( 1., 7.5 ) - dataset with 7 double samples data::xrange( 5, 0, -1 ) - dataset with 5 int samples h) random - generator dataset with unlimited number of random samples data::random(data::distribution = std::normal_distribution<>(5.,2)) dataset with random double numbers following specified distribution data::random(( data::engine = std::minstd_rand(), data::distribution = std::discrete_distribution<>(), data::seed = 20UL )); dataset with random int numbers following specified distribution While all this interfaces can be used by itself to build complex datasets with various purposes, primary use case it was developped for is new data driven test case interface: BOOST_DATA_TEST_CASE( test_name, dataset, parameter_names... ) Here are couple examples: int samples1[] = {1,2,3}; BOOST_DATA_TEST_CASE( t1, samples1, sample ) { BOOST_CHECKA( foo(sample) > 0 ); } Above test case is going to be executed 3 times with different sample values char* strs[] = {"qwe", "asd", "zxc", "mkl" }; BOOST_DATA_TEST_CASE( t1, data::xrange(4) ^ strs ^ data::random(), intval, str, dblval ) { MyObj obj( dblval, str ); BOOST_CHECKA( obj.goo() == intval ); } Above test case will be executed 4 times with different values of parameters intval, str, and dblval. Polymorphic datasets are still being developed, but should appear soon(ish). III. Auto-registered test unit decorators. Previously is was not possible and/or convenient to assign attributes to the automatically registered test units. To alleviate this I've introduced a notion of test unit decorator. These can be "attached" to any test unit similarly to like it is done in other languages Following decorators already implemented: label - adds labels to a test unit expected_failures - set expected failures for a test unit timeout - sets timeout for a test unit description - sets a test unit description depends_on - sets a test unit dependency enable_if/disable_if - facilitates a test unit status change fixture - assigns fixture to a test units Test unit description is new test unit attribute, which is reported by new list_content command line argument described below. Usage of labels covered below as well. enable_if/disable_if allow new, much more flexible test management. By adding enable_if/disable_if decorators to the test unit you can conditionally select which test units to run at construction time based on some compile time or run-time parameters. And we finally we have suite level fixtures which are set by attaching fixture decorator to a test suite (suite level fixtures executed once per test suite). Attachment of decorator is facilitated by using of BOOST_TEST_DECORATOR. Note that you can use any of '+', '-', '*' symbols to attach decorator (and any number of '*'): BOOST_TEST_DECORATOR( + unittest::fixture<suite_fixture>() ) BOOST_AUTO_TEST_SUITE( my_suite1 ) { } BOOST_TEST_DECORATOR( - unittest::timeout( 100 ) - unittest::expected_failures( 1 ) - unittest::enable_if( 100 < 50 ) ) BOOST_AUTO_TEST_CASE( my_test5 ) BOOST_TEST_DECORATOR( **** unittest::label( "L3" ) **** unittest::description( "suite description" ) **** unittest::depends_on( "my_suite2/my_test7" ) ) BOOST_AUTO_TEST_CASE( my_test11 ) IV Support for "run by label" plus more improvements for filtered runs Previously you only had an ability to filter test unit to execute by name. Now you can attach labels to test units and create collections to run which are located in arbitrary positions in test tree. For example you can have special label for performance test cases, which is attached to all test units which are responsible for testing performance of your various components. Or you might want to collect exception safety tests etc. To filter test units by level you still use --run_test CLA. Labels are dented by @prefix: test.exe --run=@performance You can now repeat --run_test argument to specify multiple conditions: test.exe --run=@performance,@exception_safety --run=prod/subsystem2 In addition run by name/label now recognizes dependencies. So if test unit A depends on test unit B and test unit B is disabled/is not part of current run test unit A will not run as well. Finally you now have an ability to specify "negative" conditions, by prefixing name or label with ! test.exe --run=!@performance This will run all test units which are not labeled with "performance". V. Support for failure context In many scenarios it is desirable to specify an additional information to a failure, but you do not need to see it if run is successful. Thus using regular print statements is undesirable. This becomes especially important when you develop common routine, which performs your testing and invoke it from multiple test units. In this case failure location is no help at all. To alleviate this problem two new tools are introduced: BOOST_TEST_INFO BOOST_TEST_CONTEXT BOOST_TEST_INFO attaches context to next assertion which is executed. For example: BOOST_TEST_INFO( "a=" << a ); BOOST_CHECKA( foo(a) == 0 ); BOOST_CHECK_CONTEXT attaches context to all assertions within a scope: BOOST_CHECK_CONTEXT( "Starting test foo from subset " << ss ) { BOOST_CHECKA( foo(ss, a) == 1 ); BOOST_CHECKA( foo(ss, b) == 2 ); } VI. Two new command line arguments: list_context, wait_for_debugger Using list_context you can see a full or partial test tree of your test module. wait_for_debugger allows to force test module to wait till you attach debugger. VII. Colored output. Using new CLA --color_output you can turn on colored output for error and information messages VIII New production testing tools interface introduced This feature was covered in details in my presentation in BoostCon 2010. The gist if this is an ability to use Boost.Test testing tools interfaces in production (nothing to do with testing) code. User supplied implementation is plugged in IX. Number of smaller improvements: * Notion of framework shutdown. Allows to eliminate some fake memory leaks * Added checkpoints at fixture entry points, test case entry point and test case exit point for auto registered test cases * New FPE portable interfaces introduced and FPE handling is separated from system errors handling. You can detect FPE even if catch_system_error is false * Added an ability to erase registered exception translator * execution_monitor: new interface vexecute - to be used to monitor nullary functions with no result values * test_tree_visitor interface extended to facilitate visitors applying the same action to all test units * execution_monitor use typeid to report "real" exception type if possible. * New ability to redirect leaks report into a file Thank you for your time, Gennadiy

21 66

[config] Macro for null pointer
by Edward Diener 08 Dec '12

08 Dec '12

I have found something like this to be helpful, when working with multiple compilers: #include <boost/config.hpp> #if defined(BOOST_NO_NULLPTR) #define BOOST_XXX_NULLPTR 0 #else #define BOOST_XXX_NULLPTR nullptr #endif where XXX is some local name for my own use. And then use BOOST_XXX_NULLPTR in places where a null pointer is needed. Would this be a candidate for a BOOST_NULLPTR macro in the config library instead ? Edward Diener

16 63

[iterator] UB when implicitly using default constructed counting_iterator<unsigned>
by Peter Sommerlad 07 Dec '12

07 Dec '12

Hi Jeffrey, hi all, I believe the usability of counting iterator could be improved, by value-initializing its Iterator type in the default constructor, because integral types won't be initialized by its default constructor. This can lead to hard to recognize user errors, e.g., when wrapping such a counting iterator with a filter iterator. counting_iterator is special in that sense, because to my understanding it is intended to adapt integral types to become iterators. And a default initialized scalar type, isn't. I suggest a one line change: counting_iterator() { } should become counting_iterator() : super_t(Incrementable()) { } The following example program shows the interesting UB, because the 3rd argument of make_filter_iterator, default constructs a counting_iterator<unsigned>(). Any thoughts? Objections? Teachings... Regards Peter. =====>8 #include <iostream> #include <boost/iterator/filter_iterator.hpp> #include <boost/iterator/counting_iterator.hpp> #include <algorithm> #include <iterator> #include <functional> struct is_prime{ bool operator()(unsigned int val) const { if (val < 2) return false; using std::placeholders::_1; auto ce=boost::make_counting_iterator(val); return ce==std::find_if_not(boost::make_counting_iterator(2u),ce, bind(std::modulus<unsigned>{},val,_1)); } }; int main(){ std::copy_n(boost::make_filter_iterator(is_prime{},boost::make_counting_iterator(1u) // if the following line is omitted we have undefined behavior, because of uninitialized unsigned value // ,boost::make_counting_iterator(std::numeric_limits<unsigned>::max()) // must be different from above value ),40,std::ostream_iterator<unsigned>{std::cout,", "}); } =====8< -- Prof. Peter Sommerlad Institut für Software: Bessere Software - Einfach, Schneller! HSR Hochschule für Technik Rapperswil Oberseestr 10, Postfach 1475, CH-8640 Rapperswil http://ifs.hsr.ch http://cute-test.com http://linticator.com http://includator.com tel:+41 55 222 49 84 == mobile:+41 79 432 23 32 fax:+41 55 222 46 29 == mailto:peter.sommerlad@hsr.ch

3 2

[compond_file_binary] Gauging interest in a possible library submission.
by А В 06 Dec '12

06 Dec '12

Hi, all. Is there any interest in a cross-platform C++ library which allows to create/read/write binary compound files? Briefly, compound file is filesystem for storing files and directories within a single file on a disk. Initially compound file format is developed by Microsoft and now is the part of Microsoft's Open Specifications Documentation. Compound files are used across various platforms and applications, and not restricted by some specific domain. In general, any application can store information in such a way. I've found on the Internet interest in such library and decided to implement it. Additional information can be found here: Article on the Wikipedia: http://en.wikipedia.org/wiki/Compound_File_Binary_Format Benefits of Compound Files: http://msdn.microsoft.com/en-us/library/windows/desktop/aa378938(v=vs.85).a… [MS-CFB] Open specification for compound files: http://msdn.microsoft.com/en-us/library/dd942138.aspx Regards, Alexander Voitenko.

11 26

[BGL] status of maximum adjacency search
by Fernando Vilas 03 Dec '12

03 Dec '12

Hi, What remains to get ticket 6780 ready to commit? -- Thanks, Fernando Vilas fvilas(a)iname.com

2 2

Re: [boost] [locale] [filesystem] Windows local 8 bit encoding
by Thiel, Bjoern 30 Nov '12

30 Nov '12

Hi Artyom, > Currently win32 API supports only UTF-8 encodings, so you need to one of: > > - compile with ICU > - select std backend (because the default without ICU on windows is win32) > - disable win32 backend (in build options) so only std backend would be used. But you should note that under > Windows only MSVC has std backend support, for gcc and ANSI encodings you need ICU, Is there reason why win32 and std backend behave differently here? Using std locale get_system_locale() method works for code pages of the form 'windows-XXX'. Others e.g. 'Shift_JIS' should fail. And if you want the CURRENT locale on Microsoft Windows, I simply can't see how to get that. But why not add generator.generate( void ) giving exactly that. Best regards Bjoern.

5 7

[mpl] Determining when a type is a placeholder expression
by Edward Diener 30 Nov '12

30 Nov '12

Is there any way to determine when a type is an MPL placeholder expression ? I can determine whether a type is a metafunction class ( it has a class template called 'apply' ), but I can't think of any sure way to determine whether or not a type is a placeholder expression. Ideally if a type in one of my templates is an MPL lambda expression ( its either a metafunction class or placeholder expression ) I want to invoke it with some compile-time data, otherwise I want to do something else with that type. Of course a less elegant solution is to have another template boost::mpl::bool_ parameter telling which it is but I was hoping to avoid it if I can figure it out myself.

2 1

i am not able to login in to the Trac
by Nilesh Raghuvanshi 29 Nov '12

29 Nov '12

Hi, please help me out with this. how to get to know my username and password. Thanks & regards Nileshkumar K R

3 3

[context] guarded_stack_allocator
by Jeremiah Willcock 29 Nov '12

29 Nov '12

I don't know if I've missed an earlier mailing list post on this topic, but why was guarded_stack_allocator removed from Boost.Context in the trunk? What should be used instead? The simple_stack_allocator that is an example, or some other general-purpose (no-guard-page) allocation function? -- Jeremiah Willcock

2 1

[result_of] fails with clan (C++11)
by Oliver Kowalke 29 Nov '12

29 Nov '12

Hello, clang (c++11 support) fails on code like: BOOST_STATIC_ASSERT(( is_same< void, typename result_of< Fn() >::type >::value)); with error: no type named 'type' in 'boost::result_of<void (&())(X &)>' is_same< void, typename result_of< Fn() >::type >::value)); ~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~ ../boost/static_assert.hpp:48:50: note: expanded from macro 'BOOST_STATIC_ASSERT' # define BOOST_STATIC_ASSERT( B ) static_assert(B, #B) ^ Do you know why it fails? (other compilers like gcc, intel, msvc compile the code) regards, Oliver

6 19

boost::shared_ptr and serialization
by Klaus - Peter Weber 28 Nov '12

28 Nov '12

Hi, I am trapped in an assertion from boost::serialization and maybe someone here has an idea how to solve this. I am using Visual Studio 2008 with Boost 1.49.0 having a simple class in a shared library like : class CTest : public ICTest { friend class boost::serialization::access; template<class Archive> void serialize( Archive & ar, const unsigned int version) { ar & boost::serialization::base_object<ICTest>(*this); ar & i; }; public : CTest::CTest():i(0){}; void setI( int _i){ i = _i;}; int getI( void){ return i;}; int i; }; and an interface class like : class ICTest { friend class boost::serialization::access; template<class Archive> void serialize( Archive & ar, const unsigned int version){}; public : virtual ~ICTest(){}; virtual void setI( int _i) = 0; virtual int getI( void) = 0; }; For the CTest class is not exported and not accessible directly from out of the shared lib, an interface is provided : MY_DLL_EXPORT_MACRO ICTest* CreateCTestClassInstance( void) { return new CTest(); } typedef boost::shared_ptr<ICTest> pICTest; Instantiating the interface in my program and using CTest class instance: pICTest p1( CreateCTestClassInstance()); p1->setI( 1); works fine, so far so good. A Problem occures when I try to serialize CTest class like : { std::ofstream ofs( fileNameTXT); boost::archive::text_oarchive ar( ofs); ar & p1; // causes an assertion } This results in an assertion (->BOOST_ASSERT(false);) in basic_serializer_map.cpp in line 102. It seems to me, there is a problem with finding the derived class in the basic_serializer_map. Instantiation of CTest class directly terminates with no error, which means, the serialization basically works correctly. Does anyone have an idea how to serialize an interface class correctly ? Peter

2 1

Date_Time : Error in time_duration.hpp
by GAURAV GUPTA 28 Nov '12

28 Nov '12

Hello, I have encountered some errors in Boost, while running some static analyzer tool. It is reported in boost/date_time/time_duration.hpp The error is: *boost::date_time::time_duration has user-written copy constructor but no corresponding user-written assignment operator.* *Is it valid to apply the following patch.* diff -Naur a/boost/date_time/time_duration.hpp b/boost/date_time/time_duration.hpp --- a/boost/date_time/time_duration.hpp 2012-10-11 00:35:03.000000000 +0530 +++ b/boost/date_time/time_duration.hpp 2012-11-26 18:29:16.000000000 +0530 @@ -251,6 +251,9 @@ return ticks_; } + private: + time_duration &operator=(const time_duration<T, rep_type>& other); + protected: explicit time_duration(impl_type in) : ticks_(in) {} impl_type ticks_; * * -- Regards, Gaurav

3 5

Algorithm : Error in find_iterator.hpp
by GAURAV GUPTA 28 Nov '12

28 Nov '12

Hello, I have encountered some errors in Boost, while running some static analyzer tool. It is reported in boost/algorithm/string/find_iterator.hpp The error is: *boost::date_time::time_duration has user-written copy constructor but no corresponding user-written assignment operator.* *Is it valid to apply the following patch.* diff -Naur a/boost/algorithm/string/find_iterator.hpp b/boost/algorithm/string/find_iterator.hpp --- a/boost/algorithm/string/find_iterator.hpp 2011-01-11 01:06:38.000000000 +0530 +++ b/boost/algorithm/string/find_iterator.hpp 2012-11-26 18:19:39.000000000 +0530 @@ -119,6 +119,9 @@ increment(); } + private: + find_iterator & operator=( const find_iterator& Other ); + private: // iterator operations @@ -288,6 +291,8 @@ increment(); } } + private: + split_iterator & operator=( const split_iterator& Other ); private: -- Regards, Gaurav

2 2

More on augmented trees
by Phil Endecott 28 Nov '12

28 Nov '12

Dear All, A while ago I posted a question about augmented trees: http://thread.gmane.org/gmane.comp.lib.boost.devel/235004 There has also been other discussion recently in this thread: http://thread.gmane.org/gmane.comp.lib.boost.devel/236103 Unfortunately I have been manically bug-hunting for the last few weeks [*] and wasn't able to follow-up properly until now. Here are my thoughts: I'm aware of 3 applications for augmented trees: - O(log N) indexing, insertion and deletion; "best of list and vector" (i.e. Countertree). - Similar where the "value" of each node is variable, so one can accumulate over any range in O(log N) time (i.e. stl_ext_adv). - Interval trees. In the first two cases, the augmented value is the sum of the augmented values in the sub-nodes. In the last case, it's the maximum of them. Is anyone aware of any other applications that are not not very similar to those, e.g. where the augmentation is some other function of the sub-nodes? Question: with only three (or two, if the first is considered a special case of the second) different kinds of augmentation, is it worthwhile to try to distil out a generic augmented tree? Here is an interesting augmented tree implementation that attempts to be generic: http://kaba.hilvi.org/pastel/pastel/sys/redblacktree.htm This seems to work by exposing the tree structure in the iterator (i.e. the iterator has parent(), left() and right() methods that return other iterators), and by requiring a Customization class that is called to updated augmented data in a node when its children change. This looks to me to be a sensible approach, but I'm still not sure that it's better than just copy-and-paste when there are only two (or three) useful ways to apply it. Thoughts anyone? Regards, Phil. [*] My recent bug-hunting has really made me value the ease of working with open-source code like Boost. What might take 5 minutes with grep instead takes weeks of back-and-forth with "technical support" (or reverse-engineering with a disassembler) - literally 3 orders of magnitude less efficient.

2 1

[generic] possible new syntax
by Lorenzo Caminiti 27 Nov '12

27 Nov '12

Hello all, I have been in contact with Matt Calabrese to design a new syntax for Boost.Generic that leverages the preprocessor EDSL techniques introduced by Boost.Contract. See the "This Library" column in the links below for a side-by-side comparison with the existing Boost.Generic syntax and the N2914 syntax. *** It's important to finalize the syntax before I start implementing the macros that will parse it: Please tell me what you think of the new syntax and ask questions if you have any. *** Container concept: http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/n2914_conc… EmplacementContainer concept: http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/n2914_conc… Allocator concept: http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/n2914_conc… All N2914 concepts (that's a lot!): http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/n2914_conc… Code, notes, to-dos, etc: http://contractpp.svn.sourceforge.net/viewvc/contractpp/branches/n2914_conc… NOTES * I'm assuming the library will be renamed Boost.Concepts so I'm using BOOST_CONCEPTS_... and boost::concepts::... but Matt and I have not agreed on this. * Some extra commas `,` might be needed at the end of each function and axiom definition. In this case, it might also be possible to use { ... } instead of ( ... ) around function definitions (but not for axiom definitions) at the cost of users handling unwrapped commas in function definitions using BOOST_IDENTITY_TYPE or similar. * I'm assuming a C++11 preprocessor that can correctly handle empty macro parameters (workarounds will be provided when that's not the case). Thanks, --Lorenzo

1 0

boost::chrono problem with gcc-4.6.3
by Neo Apostol 27 Nov '12

27 Nov '12

Hello everyone. I use android-ndk (http://www.crystax.net/en/android/ndk/7) with boost-1.49. My code includes boost::chrono, and when I use gcc-4.4.3 everything goes fine, but when I swith on the gcc-4.6.3 (APP_USE_CPP0X := true) so than i get a strange mistake. C/C++ Problem 'u16string' in namespace 'std' does not name a type TestCore line 243, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u16string' in namespace 'std' does not name a type TestCore line 242, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u32string' in namespace 'std' does not name a type TestCore line 250, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u32string' in namespace 'std' does not name a type TestCore line 249, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u16string' in namespace 'std' does not name a type TestCore line 287, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u16string' in namespace 'std' does not name a type TestCore line 286, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u32string' in namespace 'std' does not name a type TestCore line 294, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u32string' in namespace 'std' does not name a type TestCore line 293, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u16string' in namespace 'std' does not name a type TestCore line 331, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u16string' in namespace 'std' does not name a type TestCore line 330, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u32string' in namespace 'std' does not name a type TestCore line 338, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u32string' in namespace 'std' does not name a type TestCore line 337, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u16string' in namespace 'std' does not name a type TestCore line 375, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp C/C++ Problem 'u16string' in namespace 'std' does not name a type TestCore line 374, external location: /Users/user/Mobile/android-ndk-crystax/sources/boost/boost/ratio/ratio_io.hpp ............................................... Does somebody can help me?

2 2

[range] iterator_range operators are too greedy
by Gennadiy Rozental 27 Nov '12

27 Nov '12

Hi, iterator_range operators are defined like this: template< class IteratorT, class ForwardRange > inline bool operator==( const ForwardRange& l, const iterator_range<IteratorT>& r ) { return boost::equal( l, r ); } These needs to be restricted with enable_if on type of first argument. I have a scenario where I want to define operator== for my own type and want to be able to use it with iterator_range as second argument. Above definition makes it impossible. Gennadiy

6 12