- Boost - lists.boost.org

[interprocess][move] enum template argument fails to be a valid base class
by vicente.botet 22 Apr '10

22 Apr '10

I have find a possible bug on the move emulation on " Boost::Container::Vector with Enum Template Argument - Not Legal Base Class" http://stackoverflow.com/questions/2678476/boostcontainervector-with-enum-t… As rv inherits from the movable class template <class T> class rv : public T { rv(); ~rv(); rv(rv const&); void operator=(rv const&); }; it doesn't works for enum types. With gcc 3.4. I get ../../../boost/interprocess/detail/move.hpp:79: error: base type `Test::Types' fails to be a struct or class type. I don't know if this is a know issue with the move emulation. I have tried to add a specialization for is_movable namespace boost { namespace interprocess { // get inside boost template<> class is_movable<Test::Types> // add custom specialization of is_movable : public mpl::bool_<false> {}; }} but this doesn't works neither. I have tried to specialize the rv template with template <> class rv<Test::Types> { Test::Types v; rv(); ~rv(); rv(rv const&); void operator=(rv const&); operator Test::Types() const {return v;} }; and it compiles but the execution fails. Is there any workaround to this issue or better yet a generic solution? Best, _____________________ Vicente Juan Botet Escribá http://viboes.blogspot.com/

2 3

Re: [boost] [Bind] How do I get bind to deduce the return type of for_each?
by Thomas Jordan 21 Apr '10

21 Apr '10

On Mon, Apr 19, 2010 at 1:04 PM, Thomas Jordan <thomasjordan_at_[hidden]> wrote: > Thomas Jordan wrote: >> [snip] >> I was hoping I could accomplish the objective of passing an algorithm into an algorithm jgenerically, just doing everything at point of call using just >> Boost.bind, the std::algorithms (wrapped) and using if necessary some boost.function functors to help type deduction. Are we saying this isn't possible? > ----------------------------------------- > Roland Bock replied: > > ************************************ > > <snip> > Â for_each(vov.begin(), vov.end(), > Â Â Â Â bind(for_each< vocType::iterator, function<void (myClass&)> >, > Â Â Â Â Â Â bind<vocType::iterator>(&vocType::begin, _1), > Â Â Â Â Â Â bind<vocType::iterator>(&vocType::end, _1), > Â Â Â Â Â Â protect(bind(&myClass::func, _1)) > Â Â Â Â Â Â ) > Â Â Â Â ); > } > // ----------------------------------------------------------- OvermindDL1 responded: You should use Boost.Phoenix, it can do what Bind and Lambda and others can, plus more, including the above with no issues. _____________________________________ Thanks for the suggestion. I will take a look at Phoenix. I have been drawn to Boost::bind because it is small, self-contained, relatively easy to understand and surprise-free. I like the extra power of Lambda - it is beautiful for relatively simple operator expressions and function bindings, however, when I tried to do anything more complex, e.g., multiple Lambda sub-expressions separated by commas, it started to go wrong for me. I found it difficult to predict what would happen, esp. with regard argument binding, order of evaluation, side-effects, etc. Even when I saw the result, I wasn't sure how it had got there. This could just be due to my lack of experience, holes in the documentation, or even compiler issue. Also, the syntax what is bit prickly. I am not trying to start a 'which is best Boost functional library' thread, but such issues, if present, would (sadly) steer me away from Phoenix too. I just couldn't recommend it to your average C++ programmer at my workplace. Also, I got the impression Boost::bind is in TR1, therefore is likely to be in the next standard, whereas Lambda expressions would be best handled by core-language extensions (also mooted for the standard)? Finally, if Boost::Phoenix is so good (I don't doubt it that it is), why is is buried away under another library, and are there any plans to consolidate/deprecate any/all of these libraries? Best regards, Tom.

2 2

[GGL] [geometry] Inexplicable speed benefit when using Visual C++ 2010
by Christian Buchner 21 Apr '10

21 Apr '10

Hi everybody, my first attempt to post to this list bounced, so I am trying again. My employer is an early adopter of the Boost Generic Geometry Library [GGL] in an engineering application related to mobile radio communicatons. We use it to estimate and optimize the coverage of 4G radio networks. Our code uses a lot of multi-polygon unions to estimate the amount of ground covered (and not covered) by radio beams and iteratively improves the antenna parameters. We've been compiling and shipping our application with Visual C++ 2008 so far. We found that GCC 4.4 on Linux was about 100% faster than Visual C++ 2008 on Linux without modifying the code. This bothered us quite a bit as both compilers were allowed to use full optimization. We found that by optimizing (globaly overloading) the new and delete operators to re-use allocated memory fragments on Windows we were able to get nearly 50% speed benefit, so we attributed much of the performance difference to sub-optimal memory heap management of Visual C++ 2008. Then we tried recompiling the project with Visual C++ 2010 Ultimate Release Candidate (RC). The speed gain of the algorithm was 900% (not joking) and the results still appear to be correct. Now this is surreal and no one here in the office has found a reasonable explanation yet without going into the metaphysical domain. Would anyone with knowledge of compiler and runtime internals be able to make an educated guess as to how such a speed gain of factor 10 is possible? Is anyone else seeing similar speedups in boost or in the geometry library when compiling with Visual C++ 2010 RC (HINT: it's a free download, so anyone can try it out until end of June 2010). Christian

10 13

[circular_buffer] Patch to fix two-phase name lookup issue in space_optimized
by Doug Gregor 21 Apr '10

21 Apr '10

Hello Boosters, In the space_optimized circular buffer, the two calls to invalidate_iterators_except require a preceding "this->". The actual invalid_iterators_except() function is only accessible through a dependent base, so we need to make the invalid_iterators_except name dependent. The DEC compiler tried to tell us this at one point, but we ignored it. Patch is attached. - Doug

3 3

Volunteering to fix inspection issues
by Jeremiah Willcock 21 Apr '10

21 Apr '10

I am willing to do another sweep for tabs, files not ending in newlines, easy-to-fix broken links, etc. in the trunk and/or release branch. Should I do that? I did this before, but do not remember the procedure fully. I'm assuming that I do the fixes in the trunk then (maybe) merge them into the release branch using SVN. Is that the right procedure? Are there any limits on which libraries I should do fixes in (other than the inspection code itself which purposely has issues)? Should I pull changes over to the release branch for cosmetic things (after testing them on the trunk)? -- Jeremiah Willcock

4 7

Re: [boost] [utility/result_of] decltype-based implementation breaking valid code on msvc-10
by Christophe Henry 21 Apr '10

21 Apr '10

> Eric Niebler wrote: > >> I suspect the real problem is in a buggy implementation of decltype on >> msvc-10. For the upcoming boost release, I suggest that we stick with >> the non-decltype implementation of result_of on msvc-10, or risk >> massively breaking users' code, not to mention proto, spirit and >> xpressive on that compiler. > > MSVC10 isn't even released yet. > Why bother with a non-stable compiler? > I start having a bit of experience with decltype and VC compilers (sigh) through my eUML front-end for MSM and I can give you one reason: because it's probably not just VC10. I have here and there this problem (and others) with VC9 too. It might just happen in different conditions. Christophe

13 65

[move] Reason for BOOST_COPY_ASSIGN_REF?
by Chad Nelson 21 Apr '10

21 Apr '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I've been studying Boost.Move, with an eye toward using it to incorporate move semantics into the XInt library. Most of it looks pretty straightforward, but I don't understand the reason for the BOOST_COPY_ASSIGN_REF macro. If you already have a copy-constructor that takes a reference, what does it give you? Also, how close is it to being official? I'd like to use it, but if it's not going to be accepted any time soon, I can't justify it. - -- Chad Nelson Oak Circle Software, Inc. * * * -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvOY7AACgkQp9x9jeZ9/wRK1gCgvukakBrO37sCmHKwdhf9ebsI rt8AmwYk3WwDZkUiUKKXb76Jeuh3n3w4 =8EHR -----END PGP SIGNATURE-----

4 8

[containers] flat_set/flat_map could add insert_sorted(begin, end)
by Thorsten Ottosen 21 Apr '10

21 Apr '10

Hi Ion, I think the above member could be useful (taking an already sorted sequence), especially if the container needs to reallocate, in which case we may merge the two sequences [begin,end) [lower_bound(*begin),upper_bound(*(end-1))] and copy the unaltered prefix and suffix. Furthermore, even when we don't have to reallocate, we can bulk copy the suffix and simulate merging for the infix range. Any comments? -Thorsten

3 5

[filesystem] forward declaration headers
by Alexander Arhipenko 21 Apr '10

21 Apr '10

Hi boosters, I think it would be nice for boost filesystem to maintain forward declarations headers, e.g. <boost/filesystem/fwd.hpp>. Regards

1 0

Re: [boost] [Bind] How do I get bind to deduce the return type of for_each?
by Thomas Jordan 21 Apr '10

21 Apr '10

Thomas Jordan wrote: > Hi, > I have been trying to use Boost.bind to create an 'STL algorithm function object' to pass into another, 'higher order,' STL algorithm (e.g., to pass a for_each into a for_each). However, I am struggling to get bind to deduce the correct return type of the for_each function object. I include the relevant bits of the code below. > > class myClass > { > public: > int func(){return mValue;} > private: > int mValue; > }; > > //wrapper for STL for_each > struct myForEach > { > template <typename II, typename F> > F operator()(II begin, II end, F function) const > { > return std::for_each(begin, end, function); > } > }; > > typedef vector<myClass> vocType; > typedef vector<vocType> vovType; > > //overloaded member functions vocType::begin & end > typedef vocType::iterator (vocType::*fnPtr)(); > typedef const vocType::iterator (vocType::*constFnPtr)() const; > > vovType vov(10, vocType(10, myClass())); > > main() > { > for_each(vov.begin(), vov.end(), > bind< ? >(myForEach(), > bind(static_cast<fnPtr>(&vocType::begin),_1), > bind(static_cast<fnPtr>(&vocType::end),_1), > protect(bind(&myClass::func, _1))) > } > > I tried various things for bind<?>, but was only able to get the code to compile (eventually) on my Unix box when I substituted > bind< boost::_bi::protected_bind_t<boost::_bi::bind_t<int, boost::_mfi::mf0<int, myClass>, boost::_bi::list1<boost::arg<1> (*)()> > > > for > the bind<?>. I had guessed this might work from studying the compiler error messages. Obviously, this is not an ideal solution! > > Also, I only used the myForEach wrapper after having first attempted - and similarly failed - to bind the raw STL for_each. > > Is there any way I can help bind to deduce the correct return type - for either myForEach or std::for_each, or both? > > > --Roland Bock wrote------------------------------------------------------------------ In my experience it is easier to use a named functor object. Such as function<void (const vocType&)> functor = bind(&myClass::func, _1); std::for_each(vov.begin(), vov.end(), functor); Untested, but I am pretty sure something along these lines will work. Regards, Roland ------------------------------------------------------------------------------------------------- Thanks for the suggestion, Roland, I am sure you could get something like this to work easily enough. However, if I understand correctly your suggestion involves defining a separate functor - myClass - to take the vocType's, and which I guess wraps the inner call to for_each. I had hoped for a more generic solution which doesn't involve the creation of new functors. I was hoping I could accomplish the objective of passing an algorithm into an algorithm jgenerically, just doing everything at point of call using just Boost.bind, the std::algorithms (wrapped) and using if necessary some boost.function functors to help type deduction. Are we saying this isn't possible?

5 9