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

[functional] [overloaded_function] polymorphic functions?
by Lorenzo Caminiti 27 Mar '12

27 Mar '12

Hello all, I spent some time trying to make overloaded_function support polymorphic functions but I had little success :( 1) I was able to do this (see code below): overloaded_function< void (int) , functor<poly, void (generic)> > o(f, p); o(321); o(3.21); o("cba"); But I don't like it because I explicitly have to pass the functor type poly. I wanted instead to only use generic to tag the template parameters in the signature: overloaded_function< void (int) , void (generic) > o(f, p); o(321); o(3.21); o("cba"); I'd consider this acceptable but I wasn't able to program this because I loose p's type (poly) in base so base cannot hold a reference to the functor p... Is there a way around this? (Some type-erasure magic maybe??) 2) I don't think this can work with function templates because in order to get a pointer to a function template you have to instantiate it: g<char*> Now I can get the function pointer but it's not polymorphic anymore... 3) I don't think there is any way to implement make_overloaded_function with polymorphic types because I can't re-construct the function signature from the functor given that its operator contains template parameters... I have no idea on how to work around this... If you have suggestions for 1, 2, or 3), they are welcome. Otherwise, it seems that supporting polymorphic functions in overloaded_function is not really feasible... The little I got so far: #include <boost/function.hpp> #include <boost/type_traits/function_traits.hpp> #include <iostream> void f(int x) { std::cout << x << std::endl; } template<typename T> void g(T x) { std::cout << x << std::endl; } struct poly { template<typename T> void operator()(T x) { std::cout << x << std::endl; } }; template<typename F> struct base { template<typename G> base(G g) : f_(g) {} typename boost::function_traits<F>::result_type operator()( typename boost::function_traits<F>::arg1_type arg1 ) { return f_(arg1); } private: boost::function<F> f_; }; struct generic; template<typename Ftor, typename F> struct functor; template<typename Ftor, typename R> struct base< functor<Ftor, R (generic)> > { base(Ftor& ftor) : ftor_(ftor) {} template<typename Arg1> R operator()(Arg1 arg1) { return ftor_(arg1); } private: Ftor& ftor_; }; template<typename F1, typename F2> struct overloaded_function : base<F1>, base<F2> { template<typename G1, typename G2> overloaded_function(G1 g1, G2 g2) : base<F1>(g1), base<F2>(g2) {} using base<F1>::operator(); using base<F2>::operator(); }; int main() { f(123); g("xyz"); boost::function<void (char*)> gg = g<char*>; poly p; p(1.23); p("abc"); overloaded_function< void (int) , functor<poly, void (generic)> > o(f, p); o(321); o(3.21); o("cba"); return 0; } Thanks a lot. --Lorenzo

4 5

Looking for some "real world" extended precision integer arithmetic tests
by John Maddock 23 Mar '12

23 Mar '12

Folks, I'm continuing to add to the multiprecision arithmetic library in the sandbox (under "big_number"), and I've just added a Boost licensed fixed-precision integer type which on Win32 at least looks to be very competitive with GMP for reasonable numbers of bits (up to about 1024), see http://svn.boost.org/svn/boost/sandbox/big_number/libs/multiprecision/doc/h… However, as we all know there are lies damn lies and performance stats ;-) Plus the test results I have above ignore the effect of memory allocations (needed by libtommath and GMP, but not the fixed_int code - which in theory should make it faster still). So I'd be really interested to put the type through it's paces with some real world code that really thrashes an extended precision integer type. Any suggestions? Anything in Boost? Thanks in advance, John.

5 38

[algorithm] aesthetic question about cxx11
by lcaminiti 22 Mar '12

22 Mar '12

Hello all, I have an aesthetic question. Boost.Algorithm puts C++11 algorithms like all_of into a directory boost/algorithm/cxx11. Would the directory name boost/algorithm/cpp11 be preferred? I think for file names .cpp and .hpp are Boost choice over .cxx and .hxx. But for directory names instead cxx11 is Boost choice over cpp11? Similarly, shall macros that refer to C++11 be named BOOST_..._CPP11_... or BOOST_..._CXX11_...? In general, shall Boost refer to C++11 as cpp11/CPP11 or cxx11/CXX11? Given that .cpp/.hpp is Boost choice for file names over .cxx/.hxx, I'd think cpp11/CPP11 would be Boost choice over cxx11/CXX11... P.S. I have a similar situation in Boost.Contract where I want to put macros to parse C++11 keywords (override, final, etc) in a separated directory and I want to name that directory cxx11 or cpp11 consistently with other Boost libraries (so users don't have to remember different conventions). Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-algorithm-aesthetic-question-about… Sent from the Boost - Dev mailing list archive at Nabble.com.

10 21

[config] local types as template params
by Lorenzo Caminiti 22 Mar '12

22 Mar '12

Hello all, Is it possible to add a macro BOOST_CONFIG_LOCAL_TYPES_AS_TEMPLATE_PARAMS to Boost.Config to indicate if local types can be passed as template parameters? 1) Boost.Closure (formerly, Boost.Local) implements some optimizations when local types can be passed as template parameters. 2) C++11 always allows to pass local types as template parameters. 3) Local types cannot be passed as template parameters on C++03 instead but some C++03 compilers MSVC 8 (and older?) allow it anyway. // If it is possible to pass local types (classes, etc) as template parameters. // This is not possible in pure C++03 but it is possible in some C++03 // extensions (MSVC 8.0) and with C++11 (GCC >= 4.5.x -std=c++0x). #if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 4)) && \ defined(__GXX_EXPERIMENTAL_CXX0X__) // From GCC 4.5.x when -std=c++0x specified. # define BOOST_LOCAL_TYPES_AS_TEMPLATE_PARAMS #elif defined(_MSC_VER) // For (all?) MSVC (tested on MVSC 8.0). # define BOOST_LOCAL_TYPES_AS_TEMPLATE_PARAMS #endif All, can you please try to compile the following example on different compilers/versions and let me know the outcome? If this example compiles successfully then the specific compiler supports local types as template parameters: #include <algorithm> #include <iostream> int main() { struct s { void operator()(int x) { std::cout << x << std::endl; } } l; int nums[] = {1, 2, 3}; std::for_each(nums, nums + 3, l); return 0; } For example, this compiles on GCC >= 4.5.x w/ C++0x extensions enabled and on MSVC 8.0- does it compile on all MSVC versions? Thanks. --Lorenzo

8 12

Re: [boost] size() type
by Olaf van der Spek 18 Mar '12

18 Mar '12

Hi, Any progress on these tickets? Would be nice to have a solution. size() return type should be size_type, not difference_type: https://svn.boost.org/trac/boost/ticket/5971 data() for iterator_range: https://svn.boost.org/trac/boost/ticket/5930 Greetings, -- Olaf

4 15

[range] adaptors and member functions pointers
by Yanchenko Maxim 17 Mar '12

17 Mar '12

Hi, While transforming and filtering sequences, it's pretty common to call the elements' member functions, so I think it's worth adding some syntactic sugar for range adaptors in order to achieve cleaner syntax. E.g. if we have a class struct Foo { std::string description() const; }; and we want to get all non-empty descriptions, we could just write this clean code: foo_list | transformed(&Foo::description) | filtered(&std::string::size) To enable this syntax, the attached patch should be applied to boost/range/adaptor/argument_fwd.hpp (diff against 1.47.0). Is there any interest to add this to Boost.Range? Thanks, Maxim

7 9

[git] neglected aspects
by Steven Samuel Cole 14 Mar '12

14 Mar '12

Hi all, First post here, so please bear with me. A lot has been said in the last year on the subject of a possible migration from svn to git. However, after reading pretty much every message on the issue on this list (sic!), I have the impression that some of the most important aspects did not get the consideration they require. I would therefore like to add my outside perspective. SUMMARY: 1. an svn --> git migration does cause some major, but one-time disruption. However, svn right now causes minor, but continuous disruption on a daily basis - which often goes unnoticed. 2. git's distributed concept is nothing less than one generation ahead of centralized VCSs like svn. The benefits usually do not become apparent until git is actually used in practice. 3. at the moment, boost is significantly missing out on fresh enthusiasm that new contributors could bring into the project; svn and the policies it mandates are partly too blame for that. 4. svn trunk (i.e. boost library) maintainers are too limited by the svn concept in their decision which changes they merge at what point in time and may be pressured into rushing suboptimal decisions; this can make maintenance work painful and frustrating. git greatly alleviates that problem. 5. IMO, it's not 'if', it is 'when'. The longer a migration is delayed, the longer boost development will be slowed down without even noticing. DETAILS: I am aware that some of my points technically are mentioned on the boost git wiki page at https://svn.boost.org/trac/boost/wiki/Git/WhyGit, but they still seem somewhat neglected. This is probably not surprising as many participants in the discussion 1. presumably are established boost contributors and thus share a 'from the inside' view of the subject and 2. are only marginally affected by svn's conceptual problems This is what happened here in the last couple of days: I needed a tool for a job in my current project and I couldn't find one, so I thought about what components I need to build my own. A little web research - Boost.Iostreams looks perfect for the purpose. You have all been through what comes next, be it with boost or with other open source software: Download the latest release, install the libraries, start reading the docs, run some sample code, etc. While reading, I spot a typo in an HTML doc, then another in an include file comment, a third one in another file... the fourth one at the latest makes me think - this is open source, I should sync the latest sources, fix all those typos as I come across them while reading and contribute them back to the project. A quick read on submitting bugs on boost.org, svn co yadi yadi, fix the typos locally. Of course I don't have write privileges to the repo, so the best I can do for now is create a patch and attach that to a bug report. Within minutes, someone takes care of the bug, comments and takes ownership. Excellent! Smithers, money fight! I go back to reading, find more typos. My patch has not been committed to the trunk yet, so my local changes are still sitting there on my local hard drive. If I do another svn diff > file_2.patch, the patch will also contain the changes I have already attached to the bug report. What are my options now ? Revert my changes, base the new ones on the head revision and send another patch ? Create a new patch file and manually remove the diffs of the old changes I already sent ? How will the upstream maintainer know which changes are based on what version ? Also, I notice a few other things that in my opinion could be done better to facilitate adoption of the iostreams library. I would be willing to do the work and I would in the perfect position as I am walking in the shoes of an adopter right now - but these are separate from the typo fixes and they are larger issues; considering I can't check my changes in, would I really want to have them sit on my local harddrive, waiting possibly for months for someone upstream to review and hopefully merge them ? A couple of hours later: I get an email from boost bugs/svn; the upstream maintainer has committed my changes. However, I actually receive not one, but two emails, because the upstream guy chose to split my patch into changes on documentation and changes on source code (which presumably required extra work on his part). I do an svn up and now have to deal with conflicts between my local changes and the new commits: I make a note of my second set of changes and overwrite my local files with the new repo versions, then bring the second set back in. Uff! That's a lot of work just to fix some typos! And these are just cosmetic issues in discrete chunks that do not require any testing; contributing changes to source code would take even more effort and more caution - build and test on several platforms, peer review, etc. Also, the upstream maintainer jumped on the bug report right away and integrated my changes within hours. This is the ideal situation (thanks again Daniel, great job! :-) - usually, things don't happen so quickly - especially around major release time. HOW THIS IS DONE IN GIT: 1. google 'github iostreams' --> click first search result: https://github.com/boost-lib/iostreams (this can be even reduced to 'gh: iostreams' by integrating github into chrome search engines, but that's another story...) 2. on githup website, click 'fork', wait a few seconds --> this auto-creates my personal online github iostreams repo 3. on my local machine, open a shell, enter 'git clone ', copy & paste the repo .git url shown on the website in there and run e.g. 'git clone git(a)github.com:<username>/iostreams.git' --> this creates a local fork of my personal online iostreams repo + the mailing list probably changes the line above to 'hidden' + there is github/desktop integration and a plethora of gui clients 4. i change local files and commit to the local repo. once a set of changes is complete, i push them online into my personal online repo; once my work has reached some maturity, I send a pull request to the upstream maintainer of the official iostreams repo, aka the keeper of the trunk. disclaimer: I have omitted one-time steps to set up local git, github.com account, ssh keys, lastpass integration, yadi yadi. these steps are abundantly documented online, done in minutes and required only once. THE GIT ADVANTAGE: I don't have to wait for the first set of changes to be merged into the trunk before I resync, resolve conflicts and base the second set on the new head revision; I simply create a new branch for a new change set and send a new pull request once my work is complete. The upstream maintainer has no peer pressure to merge any changes in: He/she is sitting on the head revision and is looking at a number of pull requests for change sets in various personal forks like mine; these are more like 'change offers' the maintainer is free to merge in if he/she so chooses (cherry-picking) - or postpone if this is not the time because for example a major release is due and they seem too risky. I as a contributor do not really care so much: Of course I am stoked if my work actually makes it into the project eventually, but the point in time when this happens technically does not matter to me - pending changes will not get in my way if the merge takes a little longer. This is the major difference between svn and git - and I can not stress this advantage enough: I am decoupled from, but still connected to the official trunk. I can make arbitrary changes and group them in any way I see fit. I offer them to upstream and move on to new development. As a side effect, this also provides an overview impression of quality and continuity of the work of a potential new contributor. Of course it is technically correct that svn also supports the concepts of forks and branches, but in terms of tooling and mentality, they are considered much more heavy-weight than in git and might get created a couple of times a year - while in git, they might come and go a couple of times a day. Finally, the 'series of tubes' metaphor IMO does not really hit it. Subversion to me seems more like a freight train where the waggons move at different speeds, so they constantly bump into the car behind and in front of them; movement of the entire train is jerky. Git on the other hand is a bunch of space ships linked by hyperelastic tractor beams: Even if one travels out as far as the delta quadrant, the upstream connection will always make sure the collective does benefit from any new development it brings back from there. [snipped several paragraphs about cultural and other aspects; maybe some other time.] # ssc

24 81

Is there interest in static code analysis?
by Antony Polukhin 14 Mar '12

14 Mar '12

Because of some interest on this topic, I would like to clarify some things: Of course you can have some trial version and use it by yourself, BUT more mature solution would be to find a "boost's liason contact". This contact will interact with the company, provide access to reports for developers. In that case all developers can get access to reports without downloading/installing the trial version and use static analysis tool for a longer time. That case will also require from a "boost's liason contact" to look carefully through the license for that tool and agree to it as a maintainer of a whole boost project (I am not permitted to take such solutions). Best regards, Antony Polukhin

3 6

Boost B-Tree Library Status
by Joel 12 Mar '12

12 Mar '12

Beman et al, Is the Boost B-tree Library still on track to be proposed? The reception at BoostCON 2011 was quite warm, IIRC. http://github.com/boostcon/2011_presentations/raw/master/tue/proposed_b_tre… Activity on github seems to be dried up. https://github.com/Beman/Boost-Btree Also, how well do you think it would work with large keys and small payloads (512 byte keys, a few integers for payload). Thanks! Joel

3 3

[numeric] Applying trivial bugfix
by Antony Polukhin 06 Mar '12

06 Mar '12

Hi, There are a lot of feature requests to support compilation with disabled exceptions #5731, #5076, #5393, #5800. Fix is trivial and well known: replace throw x; with BOOST_THROW_EXCEPTION(x); in a converter_policies.hpp file. But the library maintainer does not like BOOST_THROW_EXCEPTION because of code bloat. Can I apply another trivial fix: struct def_overflow_handler { void operator() ( range_check_result r ) // throw(negative_overflow,positive_overflow) { #ifndef BOOST_NO_EXCEPTIONS if ( r == cNegOverflow ) throw negative_overflow() ; else if ( r == cPosOverflow ) throw positive_overflow() ; #else if ( r == cNegOverflow ) ::boost::throw_exception(negative_overflow()) ; else if ( r == cPosOverflow ) ::boost::throw_exception(positive_overflow()) ; #endif } } ; Adding this will fix all the tickets and allow some of the dependent libraries to build with disabled exceptions. Boost.Lexical_cast tests will cover Boost.Numeric usage cases with disabled exceptions. Best regards, Antony Polukhin

4 7