- Boost - lists.boost.org

Re: [boost] Discovering C++11 lambda argument and result types to construct boost::function
by Andrzej Krzemienski 11 Feb '12

11 Feb '12

> On comp.lang.c++.moderated I talked to Daniel Krügler about how to > discover argument and result types from C++11 lambdas in a template > context. The thread has the title "How to discover argument and result > types from lambda for constructing std::function?" > https://groups.google.com/d/topic/comp.lang.c++.moderated/qaMECIUlJp0...<http://www.google.com/url?sa=D&q=https://groups.google.com/d/topic/comp.lan…> > The task is to provide a function template "make_function" that takes > a C++11 lambda expression and returns a boost::function with the > correct signature to call the lambda. This may be extended to accept > any other callable type. The task you are attempting to solve looks very unusual to me. All the usages of a lambda I encountered so far are that you know the type of a callback in advance and define the lambda so that it matches the signature of the targeted callback. Sorry if this question is silly, but could you give me an example of where this deduction mechanism could be used? Regards, &rzej

2 1

Release testing failures for "tools/build"
by Steve M. Robbins 11 Feb '12

11 Feb '12

Hi, Build/branches/release [1] is failing almost all tests on almost all platforms. I checked several reports and they all point to the following, which should be trivial to fix. reason {{{ unexpected status returned by bjam }}} STDOUT {{{ /Volumes/scratch/kbelco/boost/boost/tools/build/v2/build/project.jam:266: unbalanced parentheses }}} [1] http://www.boost.org/development/tests/release/developer/build.html

1 0

[filesystem.v3] possible bug in replace_extension
by Frédéric Bron 10 Feb '12

10 Feb '12

replace_extension seems to have the wrong behaviour if the provided new extension does not start with a dot. The following program: #include <iostream> #include <boost/filesystem.hpp> int main() { boost::filesystem::path p("foo.bar"); std::cout<<p<<'\n'; p.replace_extension("foo"); std::cout<<p<<'\n'; return 0; } built with the following command line on linux 64 (with boost 1.48.0): $ g++-4.6.2 -DBOOST_DISABLE_ASSERTS -DBOOST_FILESYSTEM_VERSION=3 -DBOOST_FILESYSTEM_NO_DEPRECATED -o toto -I/soft/bal/usr/gcc-release/boost/include toto.cc -L/soft/bal/usr/gcc-release/boost/lib -lboost_filesystem -lboost_system produces the following output: "foo.bar" "foo" but should produce: "foo.bar" "foo.foo" as read from the documentation path& replace_extension(const path& new_extension = path()); Postcondition: extension() == replacement, where replacement is new_extension if new_extension.empty() || new_extension[0] == the dot character, otherwise replacement is the dot character followed by new_extension. Adding the dot before foo makes the program work: p.replace_extension(".foo"); This seemed to work with filesystem v2. Frédéric Bron

3 5

Re: [boost] [optional] generates unnessesary code for trivial types
by Hite, Christopher 10 Feb '12

10 Feb '12

I think paul Fultz wrote: > Actually, you could just take the optional_traits as the first parameter. So you define > optional<T> or optional<optional_traits<my_traits<T> > >. Then optional would be > specialized for optional_traits that will get the user-defined traits. That new optional might break old code: template<typename T> void print(const optional<T>& o){ if(o){ T copy=*o; std::cout<<copy; } } That copy is going to be a optional_traits<>. My method would also force you to add traits to the signature, but at least you wouldn't need to write two specializations: template<typename T,typename Traits> void print(const optional_with_traits<T, Traits >& o); Se have to ask ourselves if configuration is worth it. I think sometimes you don't find that out until it's too late and someone wants a option. Things I can think of making configurable: * bool type - a word might be faster on risk machines * use_trivial_destruction - there might be a case for overridding this * use_trivial_copy - cann't see a case for overriding this * bool_first * alignment - maybe 4 byte alignment is legal but 8 byte is faster * enable_assertions Chris

1 0

How to make tests building faster?
by Mateusz Łoskot 10 Feb '12

10 Feb '12

Hi, I'm trying to figure out if there is anything I could do to improve compile/link-time for tests of Boost.Geometry library. Currently, the tests follow fairly canonical approach in Boost: 1) Each .cpp file defines a single test program and all local test routines are executed from test_main() // test_feature_x.cpp void test1() {} // make use of BOOST_CHECK_* macros void test2() {} int test_main(int, char* []) { test1(); test2(); return 0; } 2) Jamfile per testing project builds and runs each program separately # features/Jamfile.v2 test-suite test-features : [ run test_feature_x.cpp ] [ run test_feature_y.cpp ] ; 3) Root mylib/test/Jamfile.v2 defines testing projects to build and run import testing ; project boost-mylib-test : ; build-project features ; build-project algorithms ; build-project abc ; In total, there are nearly 170 test programs in Boost.Geometry. Obviously, running the whole set of tests (b2 command issued in libs\geometry\test) is time consuming process. I'm wondering if there is any way to reorganise the tests to cut down the build (linking) time. My first idea is to decrease number of run entries (e.g. [ run test_feature_y.cpp ] ) in Jamfiles, by building related tests as single test suite program. Conceptually: [ run test_feature_x.cpp test_feature_y.cpp ] Currently, there is no use of Boost.Test features for tests organisation like BOOST_AUTO_TEST_CASE BOOST_TEST_SUITE etc. I wonder if use of any of the above would help in restructuring tests and decreasing number of programs to build. Another aspect of Boost.Geometry tests I'd like to improve is to improve tests report output. Currently, it is reported as *Passed* or *Failed*. I presume that using Boost.Test to group tests in suits with test cases would improve test report providing details about location of failure (which suite, which case, or even better). I'm looking for any piece of advice on the issues discussed above: - How to cut down build time of tests? - How to improve test output report (and keep it suitable for Boost regression testing framework)? - Is it advised to switch to use Boost.Test features to manage suites and test cases? (I tried to figure it out browsing tests of other libs, but it doesn't indicate any preferred practice). I'd be thankful for any insights. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net

10 34

Re: [boost] [optional] generates unnessesary code for trivial types
by Andrzej Krzemienski 10 Feb '12

10 Feb '12

> > int i = 1; > > int j = 2; > > optional<int&> oi = i; > > optional<int&> oj = j; > > i = j; > > The effect here is that i remains 1, j remains 2 and oi and oj both hold a > > reference to j. You may find it less surprising but if you think of > > optional reference as a regular reference that is initialized a bit later, > > the behavior is not what you would expect. > > Huh? How does oi come to hold a reference to j? Apologies, I meant to say int i = 1; int j = 2; optional<int&> oi = i; optional<int&> oj = j; oi = oj; Boost.Optional documentation explains it better: http://www.boost.org/doc/libs/1_48_0/libs/optional/doc/html/boost_optional/… Regards, &rzej

1 0

Re: [boost] [optional] generates unnessesary code for trivial types
by Andrzej Krzemienski 10 Feb '12

10 Feb '12

> I have a question though. Why prohibit opt = opt assignment? It looks > quite safe and has a fairly obvious behavior. If I have an optional > reference as a member of my class, the lack of assignment in optional > would force me to define a custom assignment operator for my class. > This seems to be an unnecessary requirement. Also, in the source code > I dealt with I often saw people writing something like opt = > optional<T>() to clear the value. This would break with references for > no apparent reason. First, let me show why opt = nval; is controversial. Current semantics for boost::optional<T&> is to rebind on assignment, which means that in the following code: int i = 1; int j = 2; optional<int&> oi = i; oi = j; The effect of this program is that i remains 1, j remains 2 and oi holds a reference to j. This is surprising to those that think of optional as delayed initialization. I lean towards disabling opt = opt because it is very similar to opt = nval; int i = 1; int j = 2; optional<int&> oi = i; optional<int&> oj = j; i = j; The effect here is that i remains 1, j remains 2 and oi and oj both hold a reference to j. You may find it less surprising but if you think of optional reference as a regular reference that is initialized a bit later, the behavior is not what you would expect. Note that if you store a normal reference to int as class member, you already have to write your assignment yourself. changing a normal reference to an optional reference should not come as something irregular.

3 2

Re: [boost] [git] neglected aspects
by David A. Greene 09 Feb '12

09 Feb '12

Thomas Heller <thom.heller(a)googlemail.com> writes: > On 02/08/2012 07:30 AM, Steven Samuel Cole wrote: >> 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! > > Great! Now with something like github you create your own fork, push > to that and eventually create a pull request and wait until it gets > applied ... as you described. The process didn't change. You just > named the steps differently. No. The fundamental part you're missing is that the source control utility (git in this case) handles it for you. There is no need to go outside the sournce control utility to make additional changes. >> 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 ? > > Simple. Update the bug you already filed with the patch containing all > fixes. What would be the options with git? Update the pull request? > Again, same thing, different name. No, not the same thing. Again, this is all happening within the source control utility. Steven is relating real issues with svn. I have encountered them many times. I have found that git eliminates them. >> Also, I notice a few other things that in my opinion could be done >> better to facilitate adoption of the iostreams library. > So with git you pushed them to your personal fork. Over time, your > fork and the upstream version eventually diverge. You have to maintain > your changes. Same thing when the changes lurk on your local svn > working. There are several advantages to a git fork over an svn local workarea. - You can make a new branch for each feature, keeping the code for logical features separate. You can submit them whenever you want, in whatever order you want. - You can share the forks and branches with others. - You can massage the fork/branch over time to respond to review feedback, all supported directly by the source control utility. IME, git rebase -i and git add -i are killer features for the code review process. >> 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). > > Frankly, I don't see how this would change with git. Actually, git would make things easier for the maintainer here. Either he/she could request the submitter to break up the patch, which is easily done with rebase -i/add -i or the maintainer could use the same tools to do it him/herself. >> 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. > > Same again. How is this significantly different to what you'd do with git? It's all within the utility. There's no need to back out patches (the second set of changes in this case) manually from the source and re-apply them manually after update. Because each feature is in its own (local) branch, updates of one branch don't conflict with unrelated features in other branches. Yes, you'll need to resolve conflicts but it's much less messy with this kind of separation. >> 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. > > Right, all that wouldn't change with having git as the tool of choice. It does, dramatically. git actually directly supports workflows that developers use when working on large projects. svn does not and there are all sorts of hacks out there to work around those problems. I've written a fair number myself. I don't need any of them with git. >> 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. > > Errm ... you can still do that with svn. just continue working. Make a > new patch, update the patch in the bug report you filed, yes trac can > do that. There really is no need to wait for anything. But now you're conflating multiple features. Many times I have a feature in-progress and another feature I'd like to work on that's unrelated to the first feature. I don't want to disturb the source tree of the first feature because I might have to update it (respond to feedback, etc.). I need to be able to test both features in isolation. >> 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; > > So, how is it really different from the current trac system? svn doesn't support distributed operation so it can't support cherry-picking from multiple developers. You have to go outside the tool (manual diff/patch) to do it. That is painful. > I think i miss something fundamental here. Yes, you are. You're missing that every operation Steven is talking about is directly supported in git. You use the source control tool to manage source changes, always. There's no need to ever do a manual diff/patch. git manages multiple changes for you and organizes them in a logical way. It is easy to change among them, apply some, test them, revert some of them and so on. It's incredibly easy and productive compared to doing the same in svn. > While there are shortcomings in the current process, they won't be > solved by changing tools. Many will be. -Dave

4 3

[thread] wrong guard for explicit bool operators (c++11)
by Juergen Hunold 09 Feb '12

09 Feb '12

Hi Vicente, your commit New Revision: 76951 URL: http://svn.boost.org/trac/boost/changeset/76951 Thread: Added explicit to operator bool for locks (11 hours ago) leads to the following errors when using gcc-4.6.1 in non-c++11 mode: $BOOST_ROOT/boost/thread/locks.hpp:1323:34: warning: explicit conversion operators only available with -std=c++0x or -std=gnu++0x [enabled by default] It seems that the guards checking for explicit conversion operators are wrong. -#ifndef BOOST_NO_EXPLICIT_CONVERSION_OPERATORS +#if defined(BOOST_NO_EXPLICIT_CONVERSION_OPERATORS) Patch attached. Ok to commit? Yours, Jürgen -- Dipl.-Math. Jürgen Hunold | IVE mbH Software-Entwickler | Lützerodestraße 10 Tel: +49 511 897668 33 | 30161 Hannover, Germany Fax: +49 511 897668 29 | http://www.ivembh.de juergen.hunold(a)ivembh.de | | Geschäftsführer: Sitz des Unternehmens: Hannover | Univ.-Prof. Dr.-Ing. Thomas Siefer Amtsgericht Hannover, HRB 56965 | PD Dr.-Ing. Alfons Radtke

3 2

IDL to C++11 Language Mapping
by Johnny Willemsen 09 Feb '12

09 Feb '12

Hi, Last year I posted a question on this list related to the IDL to C++11 Language Mapping for CORBA. We are currently working on creating such a new mapping and maybe there are people on this list that are interested in giving feedback. All details about this effort are online at http://osportal.remedy.nl (example code and a draft OMG specification) and http://www.orbzone.org for a discussion forum. Best regards, Johnny Willemsen Remedy IT http://www.theaceorb.nl

1 0