- Boost - lists.boost.org

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

13 Feb '12

> > I am > > thinking of disabling the assignment not because I think it does not belong > > to references, but because there are two ways of implementing it, and > > implementing it either way would surprise a different group of > > programmers. > > And this would be a "run-time surprise". Instead my choice (not necessarily > > the best one) is to provide a "compile-time surprise". > > If value semantics are achievable for this kind of optional, I think > it's better to supply that and let the people who don't expect value > semantics be surprised at runtime. It is very difficult to provide a non-surprising/non-controversial behavior. While I am not happy with my solution, I would also have concerns about "run-time surprise" because: First, there are two ways of implementing optional reference assignment (rebinding or not rebinding) and it seams (from the past discussions in this group) that either is equally counter-intuitive, and it is not clear which one to choose. It would have to be an absolutely arbitrary choice. People are strongly convinced about their views and it is not possible to come up with a reasonable compromise. In fact it is the optional reference assignment that prevented the addition of Optional to ISO C++ the first time (http://lists.boost.org/Archives/boost/2005/10/95120.php) Second, it is difficult to say about value semantics here. References themselves are not really value semantic (at least according to my understanding of the term): they have shallow copy constructor and deep copy assignment. Even if it is disputable for native references, it is more so for optional references, which removes the "special" aspects of references, like extending the life-time of a temporary, reference semantics, or no-storage requirement. We would be building value semantics on a non-value-semantic type. Or in other words, I am concerned that we would only be providing "value-semantics syntax" but not "value-semantics semantics". But we would violate the axioms of value semantic types (like the "separation of the value"). Regards, &rzej

1 0

Boost.Application (Pre Alpha) Release 2 available
by Renato Tegon Forti 13 Feb '12

13 Feb '12

Hi All! There is a new version of "Boost.Application" available in SF (http://sourceforge.net/projects/boostapp/) >> Boost.Application_pre_alpha_2.zip (http://sourceforge.net/projects/boostapp/files/Boost.Application_pre_alpha_ 2.zip/download) This version is based on received comments ! Please, install it: 1) Copy: Boost.Application_pre_alpha_2\boost\application To: boost_1_48_0\boost and, Boost.Application_pre_alpha_2\libs\application To: boost_1_48_0\libs 2) Build (bjam link=shared) . 3) And, to see what has changed, please see the tutorial in help (doc): boost_1_48_0\libs\application\doc\html\application\tutorial.html I will wait for comments! Thanks Renato

2 2

[iostreams] output_filter works only once
by Steven Samuel Cole 13 Feb '12

13 Feb '12

i am trying to use an boost::iostreams output filter to add a string to the beginning and the end of whatever i stream out. my code below works, but only the first time; the second time, the output seems to get lost somewhere, the write method doesn't even seem to get called. i thought at first i'm sending something to the stream that triggers its fail bit, but the stream seems good. the same problem occurs on mac and linux, with latest boost release (1.48) and svn trunk, with cout and a file sink as device. is that a bug ? or am i doing something wrong in my code ? #include <iostream> #include <sstream> #include <boost/iostreams/concepts.hpp> #include <boost/iostreams/device/file.hpp> #include <boost/iostreams/filtering_stream.hpp> #include <boost/iostreams/operations.hpp> using std::cout; using std::endl; using std::streamsize; using std::string; using std::stringstream; class add_string_output_filter : public boost::iostreams::multichar_output_filter { public: template<typename Sink> streamsize write(Sink& sink, const char* s, streamsize n) { string out_string = string(s); // remove trailing '\0' to prevent line break if (out_string[out_string.size()-1] = '\0') out_string = out_string.substr(0, out_string.size()-1); string pre_string("prepended string - "); string app_string(" - appended string"); stringstream sstrm; sstrm << pre_string << out_string << app_string << endl; // TODO: char* to string, back to char* ?!? return boost::iostreams::write(sink, sstrm.str().c_str(), sstrm.str().length()); } }; int main() { boost::iostreams::filtering_ostream out; out.push(add_string_output_filter()); out.push(cout); // string #01 is printed, // string #02 gets lost out << "string #01" << endl; out << "string #02" << endl; }

2 1

BoostCon/C++Now! Talk: How I Code and Why
by Gottlob Frege 13 Feb '12

13 Feb '12

I talked about this last year, and this year I've submitted the proposal, so If you volunteered last year (and are still interested) and/or are interested in helping with a particular/peculiar talk at BoostCon/C++Now this year, then read on, and contact me offline: I'm planning on giving a talk, entitled "How I Code and Why". It is not meant to be presumptuous and tell you how *you* should code, but instead just explains how I code - day-to-day - and how I came to these patterns/conclusions. But who cares just about how *I* code, people want to hear how other members of the Boost community - people they've come to know and respect via the boost lists - code. So I'm hoping to have a few co-conspirators on stage with me, and have each explain a fundamental guiding principle that they follow in their every day code, how they came to adopt this principle and why they find it valuable. For example, I will tell the simple story ('epiphany') of why my favourite comment word is 'otherwise', and how this relates to advice you may have heard or read before. I like the flavour of [ simple, real world, specific ] ---> [ general principle ] The goal is to bring a more real world down to earth picture to the sometimes lofty fundamentals found in books and lectures. Instead of a book explaining how a guiding principle makes sense *in theory*, it would be great (I think) to hear how respected members of the community apply these principles in real life. So, if you want to participate, email me, and we will see what we can figure out. (And/or I might just have to track you down based on promises made last year!) Not sure how many people we need. I'm thinking 5-15 mins per 'principle', and I think you only need to present one (I think the weight of picking *just one* principle makes it all the more interesting). Anyhow, we can work out the details as we go along. Tony PS. this is not (yet?!) an accepted talk, but I have a bit of chicken/egg thing here: ie it would help to have a few people on board to show that the talk is viable, and thus be accepted.

1 0

PCL - Portable C++ Library
by Fernando Pelliccioni 12 Feb '12

12 Feb '12

Hi all, ( Maybe it's an OFF-TOPIC (Sorry) ) At the GoingNative2012 conference, Herb Sutter said that the main disadvantage of C++ today is the lack of a standard library (like dotNet or Java frameworks) He called people to propose additions, like REST Webservices, Async I/O, XML/JSON, ... On the other hand, a member of the public claimed for a desired feature for C++. The answer (can't remember if it was Herb or Bjarne) was to send the paper to WG21 and attend committee meetings to defend his proposal. This is what almost everyone already know about the way WG21 works. I'm not a member of the Committee, or of any company/organization that has an interest in it (Boost, Google, Microsoft, Apple,...) The question is, how I can do to attend meetings? I have no time available or money to pay me the trip myself. Consequently, I see no possibility to attend meetings, then, I have no possibility to defend an idea. Am I wrong? Perhaps this question is for the Committee members (Beman, Dave, Andrew ...) Is there a way to send a proposal and defend it without having to attend meetings? On the other hand, I would like to have access to the discussions (mailing list). or... Is it just for members? Thanks and best regards, Fernando Pelliccioni.

10 24

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

12 Feb '12

> I see your point but, IMHO, optional<T&> is too different from normal > references to attempt to draw this association. After all, > optional<T&> is an object in the sense it has internal state and you > can take its address while T& is not (one may call it an alias of an > object). It is therefore logical that optional<T&>::operator= operates > on the object (i.e. on the optional contents) and hypothetical > T&::operator= operates on the referred object. > > 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. > > Again, I tend to see optional<T&> as an object, with no apparent > reason why it cannot be assigned to. I understand (I think) your point of view. Let me clarify one thing. I am thinking of disabling the assignment not because I think it does not belong to references, but because there are two ways of implementing it, and implementing it either way would surprise a different group of programmers. And this would be a "run-time surprise". Instead my choice (not necessarily the best one) is to provide a "compile-time surprise". With your view of optional reference (if I got it right it is a pointer with a somewhat different syntax) your expectation of rebinding assignment comes as natural. With a different model of optional reference a non-rebinding assignment comes as more natural. I believe that optional<reference_wrapper<T>> would serve your purpose best. Or would it also introduce the lack of uniformity?

3 3

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

12 Feb '12

When decompiling my code I noticed a bunch of unnessesary code caused by boost::optional. 1) deconstruction typedef boost::optional<int> optional_int; void deconstruct_boost_optional(optional_int& o){ o.~optional_int(); } One would expect this to do nothing. Instead gcc 4.6.0 with O3 generates: if(m_initialized){ // do nothing m_initialized = false; } 00000000 <deconstruct_boost_optional(boost::optional<int>&)>: 0: 8b 44 24 04 mov 0x4(%esp),%eax 4: 80 38 00 cmpb $0x0,(%eax) 7: 74 03 je c <deconstruct_boost_optional(boost::optional<int>&)+0xc> 9: c6 00 00 movb $0x0,(%eax) c: f3 c3 repz ret This one could be easily fixed by removing the bit that sets m_initialized to false, since we're deconstructing anyway. 2) assignment also generates these problems: void assign_boost_optional(optional_int& o){ o=13; } Here there's a semantic issue: we have to decide to use the copy constructor or operator=. This is also wasteful for POD types or any type which has_trivial_copy<>. 3) Even more expensive is if we want to copy an optional<int> void assign_boost_optional(optional_int& a,optional_int& b){ a=b; } 00000000 <assign_boost_optional(boost::optional<int>&, boost::optional<int>&)>: 0: 8b 44 24 04 mov 0x4(%esp),%eax 4: 8b 54 24 08 mov 0x8(%esp),%edx 8: 80 38 00 cmpb $0x0,(%eax) b: 74 0b je 18 <assign_boost_optional(boost::optional<int>&, boost::optional<int>&)+0x18> d: 80 3a 00 cmpb $0x0,(%edx) 10: 75 16 jne 28 <assign_boost_optional(boost::optional<int>&, boost::optional<int>&)+0x28> 12: c6 00 00 movb $0x0,(%eax) 15: c3 ret 16: 66 90 xchg %ax,%ax 18: 80 3a 00 cmpb $0x0,(%edx) 1b: 74 09 je 26 <assign_boost_optional(boost::optional<int>&, boost::optional<int>&)+0x26> 1d: 8b 52 04 mov 0x4(%edx),%edx 20: c6 00 01 movb $0x1,(%eax) 23: 89 50 04 mov %edx,0x4(%eax) 26: f3 c3 repz ret 28: 8b 52 04 mov 0x4(%edx),%edx 2b: 89 50 04 mov %edx,0x4(%eax) 2e: c3 ret Three possible branches! Theoretically single 64 bit copy do the job. I'm tempted to say: it would be best if for any T has_trivial_copy< optional<T> > iff has_trivial_copy<T>. It might make a sense to make an exception for huge T, where the copying an unused T is more expensive than the branching. 4) has_trivial_destructor<T> should impl has_trivial_destructor< optional<T> > , but this is hard to implement without specialization of optional. Checking has_trivial_destructor might take care of the complexity of optional<T&> since has_trivial_destructor< T& >. I'd be willing to fix #1. The other issues need some discussion. Chris

14 39

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