- Boost - lists.boost.org

[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

[boost::context] reusing stacks
by Valentin Milea 27 Nov '12

27 Nov '12

Hi, I'm working on a tiny coroutine library based on boost::context. For performance reasons I'd rather keep a pool of stacks instead allocating/deallocating every time. Is it legal to reuse a stack for a different context? namespace ctx = boost::context; ctx::fcontext_t fcm, *fc; void f1(intptr_t) { std::cout << "f1" << std::endl; ctx::jump_fcontext(fc, &fcm, 0); } void f2(intptr_t) { std::cout << "f2" << std::endl; ctx::jump_fcontext(fc, &fcm, 0); } int main(int argc, char * argv[]) { ctx::guarded_stack_allocator alloc; std::size_t size = ctx::guarded_stack_allocator::default_stacksize(); void *sp = alloc.allocate(size); fc = ctx::make_fcontext(sp, size, f1); std::cout << "main: jump 1" << std::endl; ctx::jump_fcontext(&fcm, fc, 0); fc = ctx::make_fcontext(sp, size, f2); // legal? std::cout << "main: jump 2" << std::endl; ctx::jump_fcontext(&fcm, fc, 0); std::cout << "main: done" << std::endl; return 0; }

2 6