- Boost - lists.boost.org

[svn] creating branches?
by JOAQUIN M. LOPEZ MUÑOZ 11 Sep '08

11 Sep '08

Hello, Do I need a special permission to create branches in the Boost SVN repository under the branches/ folder (I have read/write permissions) ? I just tried and I'm getting the following: Error: MKACTIVITY of '/svn/boost/!svn/act/61476d52-5ac2-7d42-a98b-eb1ac421fec1': 403 Forbidden (http://svn.boost.org) My level of SVN expertise is "dumb rookie", so please bear with me if I'm doing something really stupid :) Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

3 6

Re: [boost] Improving the assignment operators of various Boosttypes
by Gevorg Voskanyan 11 Sep '08

11 Sep '08

David Abrahams wrote: > If you're asking whether such functions should be documented as nothrow > after the modification, I think they should: it could be useful > information for move-only types (with nonthrowing move ctors). Yes, documenting the operators as nothrow is what I had in mind, thanks! Best Regards, Gevorg

1 0

Re: [boost] Improving the assignment operators of various Boosttypes
by Gevorg Voskanyan 11 Sep '08

11 Sep '08

David Abrahams wrote: > on Thu Sep 11 2008, Gevorg Voskanyan wrote: [snip] > > AFAIU, a swapping assignment operator taking the parameter by const ref > adheres > > to the strong exception safety guarantee, whereas the one taking the parameter > > by value fulfills the nothrow guarantee. Not sure how practical and/or > relevant > > the difference in this context is, though. > > > > Is my observation above correct? > > Well, technically, yeah... although the expression that does the > assignment can still throw, so I don't think it makes much difference to > say that it's nothrow. In other words, if I give you > > f(std::string); // nothrow > g(std::string&); // strong guarantee > > For all practical purposes, you know that f and g have equivalent > exception behavior because std::string's copy ctor can throw. True, that's why I questioned the practicality of this difference :) Except perhaps for documenting a function's exception safety. Should it be considered while making aforementioned assignment operators in boost to take the argument by value? > I think this calculus might get more interesting when rvalue references > are involved, because you can actually write stronger conditional > guarantees. My early impression is that rvalue references are going to make life much more interesting :-) Thanks for your time, Dave! Best Regards, Gevorg

2 1

Re: [boost] Improving the assignment operators of various Boosttypes
by Gevorg Voskanyan 11 Sep '08

11 Sep '08

David Abrahams wrote: > on Thu Sep 11 2008, Gevorg Voskanyan wrote: [snip] > > AFAIU, a swapping assignment operator taking the parameter by const ref > adheres > > to the strong exception safety guarantee, whereas the one taking the parameter > > by value fulfills the nothrow guarantee. Not sure how practical and/or > relevant > > the difference in this context is, though. > > > > Is my observation above correct? > > Well, technically, yeah... although the expression that does the > assignment can still throw, so I don't think it makes much difference to > say that it's nothrow. In other words, if I give you > > f(std::string); // nothrow > g(std::string&); // strong guarantee > > For all practical purposes, you know that f and g have equivalent > exception behavior because std::string's copy ctor can throw. True, that's why I questioned the practicality of this difference :) Except perhaps for documenting a function's exception safety. Should it be considered while making aforementioned assignment operators in boost to take the argument by value? > I think this calculus might get more interesting when rvalue references > are involved, because you can actually write stronger conditional > guarantees. My early impression is that rvalue references are going to make life much more interesting :-) Thanks for your time, Dave! Best Regards, Gevorg

1 0

Re: [boost] Improving the assignment operators of various Boosttypes
by Gevorg Voskanyan 11 Sep '08

11 Sep '08

Giovanni Piero Deretta wrote: > If you do not want to deal with move emulation (which I've found very > brittle in complex expressions), a simple way to to gain the advantage > of T::operator=(T rhs) even when assigning from lvalues is something > like: > > templateT destructive_copy(T& x) { > using std::swap; > T result; > swap(result, x); > return x; > } > > which relies on NRVO to eliminate expensive copies: Shouldn't the last statement be return result; instead? Or maybe I am missing something? Best Regards, Gevorg

3 4

Re: [boost] Is self assignment test valid?
by David Abrahams 11 Sep '08

11 Sep '08

on Mon Sep 08 2008, "Niels Dekker - no return address" <noreply-AT-this.is.invalid> wrote: > Andrei Alexandrescu wrote: >> JoshuaMaurice (at) gm...com wrote: >>> As an aside, the way I've generally done it is as follows, which >>> I assume to be equivalent to the two previous examples. >>> >>> struct T >>> { >>> T& operator= (T const& x) >>> { >>> T(x).swap(*this); >>> return *this; >>> } >>> void swap(T& x); >>> }; >> >> That's the politically correct version. It turns out that, when a >> function needs to make a copy of its argument, it better takes it by >> value in the first place. That way, if an rvalue is passed in, the >> compiler can directly fuse the rvalue to the parameter thus saving a >> copy. > > Do you think this is still relevant when operator= is inline, and it's just > doing "T(x).swap(*this)"? Absolutely. The compiler is allowed to elide the implicit copy when the argument is an rvalue if the corresponding parameter is taken by-value. However, when you write T(x) and x is an lvalue (as it is inside the operator= above), the compiler is required to honor your explicit instruction to make a copy of x. > If so, I might consider submitting another ticket regarding > boost::function, which still copy-assigns in the "politically correct" > way at the moment. As so many of us do :-) Could you do that for all the other libraries too? I'm serious, I've been meaning to make a sweep across the source code to fix this. >> See http://www.erdani.org/publications/cuj-02-2003.html > > Thanks! Looking a the example of passing the result of MakeUrl() to the > function Connect(const String& url), you wrote: "For a compiler to optimize > away the copy, it has to do the Herculean job of (1) getting access to > Connect's definition (hard with separately compiled modules), (2) parse > Connect's definition to develop an understanding of it, and (3) alter > Connect's behavior so that the temporary is fused with finalUrl." > > Now is it still such a Herculean job for a compiler to do so for an /inline/ > assignment operator that's only just swapping a temporary copy? Honestly, I > haven't done any profiling on this, so I just hope you did so already :-) Yes, it's still a fairly herculean job. The compiler would have to prove that the entire program works exactly the same way with or without the copy, proving that nothing about the address or identity of the new T is significant. While it's possible that someone might implement that optimization for some cases where T's copy constructor, swap, and destructor are all inlined, that level of understanding is not typically developed in optimizers. In the case of copy-elision for by-value arguments and return values, the compiler is explicitly allowed to _assume_ there is no semantic difference between the original rvalue and its copy. That's low-hanging fruit for a compiler writer, that pays huge dividends. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

10 38

HP-UX_pa_risc_aCC test failure
by Emil Dotchevski 11 Sep '08

11 Sep '08

I'm looking at this failure: http://www.boost.org/development/tests/trunk/developer/output/HP-UX_pa_risc… The assertion is an indication that a particular function that throws an exception returned without throwing an exception. Does this platform support exception handling? If not, shouldn't BOOST_NO_EXCEPTIONS be #defined? Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

5 5

Re: [boost] Improving the assignment operators of various Boosttypes
by Gevorg Voskanyan 11 Sep '08

11 Sep '08

David Abrahams wrote: > on Wed Sep 10 2008, "Scott McMurray" wrote: > > > On Wed, Sep 10, 2008 at 21:23, Joe Gottman wrote: > >> Joel Falcou wrote: > >>> > >>> I may come late and maybe like an unwanted guest in this discussion but I > >>> am curious to know how i can know that for a given class of mine, the swap > >>> value operator= is better than the by const ref operator= ? > >>> > >> > >> My rule of thumb is that if your assignment operator might throw an > >> exception and you want assignment to fulfill the strong exception safety > >> guarantee (i.e. either the assignment succeeds or the target remains > >> unchanged) then you should consider the swapping operator=. > >> > > > > I would even go slightly more expansive than that and say "Use the > > swapping operator= unless you've explicitly decided you want less > > exception safety (like for efficiency reasons in std::vector)". > > > > It means one fewer place that needs updating when members change, and > > I suspect -- though I have no supporting data -- that the optimizer > > should make the swapping version "good enough" in most cases. > > Swapping and taking the parameter by value are orthogonal issues; the > latter has only to do with copy elision and not with exception safety. > Please see this thread: > http://groups.google.com/group/comp.lang.c++.moderated/browse_frm/thread/97… AFAIU, a swapping assignment operator taking the parameter by const ref adheres to the strong exception safety guarantee, whereas the one taking the parameter by value fulfills the nothrow guarantee. Not sure how practical and/or relevant the difference in this context is, though. Is my observation above correct? Best Regards, Gevorg

2 1

[review] Dataflow Review starts today, September 1st
by jarvi＠cs.tamu.edu 11 Sep '08

11 Sep '08

The review of Stjepan Rajko's Dataflow library starts today, September 1st, and will run until September 10th. --------------------------------------------------------- Description of the library: Dataflow is a generic library for dataflow programming. Dataflow programs can typically be expressed as a graph in which vertices represent components that process data, and edges represent the flow of data between the components. As such, dataflow programs can be easily reconfigured by changing the components and/or the connections. This review focuses on the Dataflow.Signals layer of the library. For its data transport mechanism, Dataflow.Signals uses Boost.Signals which can be used to make lasting dataflow connections based on function calls. Dataflow.Signals provides the following to facilitate signals-based dataflow networks: * A number of useful general-purpose components, and building blocks for implementing new components. * Various free functions and operators for connecting and using components. The library documentation provides some concrete examples of how Dataflow.Signals layer can be used. Some examples are: * Implementing distributed dataflow applications using Dataflow.Signals and Boost.Asio * An image processing network using Dataflow.Signals and Boost.GIL * A GUI dataflow editor (located in the Dataflow.Blueprint documentation) While the Dataflow library contains other layers, only the Dataflow.Signals layer is ready for review. Reviewers are welcome to provide feedback for any part of the library, but please be aware that the documentation and implementation for the other layers may be lacking (for example, there is the generic support layer, which provides concepts applicable to different dataflow frameworks, and can be used to develop generic dataflow code, as well as the Dataflow.Blueprint layer which provides run-time reflection and modeling of dataflow networks in a Boost Graph Library graph for any dataflow framework with implemented Dataflow library support). For the time being, please consider these other layers as implementation details or proof-of-concept examples, as appropriate. The library is accessible as a tarball at: http://www.boostpro.com/vault/index.php?&directory=Dataflow The documentation can be accessed here: http://www.dancinghacker.com/code/dataflow/ The documentation particular to the Dataflow.Signals layer under review: http://www.dancinghacker.com/code/dataflow/dataflow/signals.html Dataflow depends on many existing Boost libraries, such as Fusion and MPL. The Dataflow.Signals layer builds functionality over Boost.Signals. The Dataflow library has been tested using a recent version of the Boost trunk, as well as the 1.35 release. Tests and examples have been built successfuly on OS X (GCC 4.0, 4.2), Linux (GCC 4.2), and Windows (MSVC 8.0 and to some degree MinGW GCC 4.2). --------------------------------------------------------- --------------------------------------------------------- Questions you may want to answer in your review: - What is your evaluation of the design? - What is your evaluation of the implementation? - What is your evaluation of the documentation? - What is your evaluation of the potential usefulness of the library? - Did you try to use the library? With what compiler? Did you have any problems? - How much effort did you put into your evaluation? A glance? A quick reading? In-depth study? - Are you knowledgeable about the problem domain? In particular, please remember to answer the following question explicitly: - Do you think the library should be accepted as a Boost library? Jaakko Järvi Review Manager

16 49

[exception] library update
by Emil Dotchevski 10 Sep '08

10 Sep '08

I've finished a major refactoring of the Exception library: 1) Thanks to Peter Dimov's boost/detail/sp_typeinfo.hpp, it now works with or without RTTI support. 2) I would like to thank Dave and Robert for complaining about the added weight to boost/throw_exception.hpp. I managed to reduce that cost to less than 400 lines total, all contained in boost/exception/exception.hpp which now does not #include anything (not even standard headers.) If there are more concerns about this issue, let's discuss them now. The latest documentation can be viewed at http://svn.boost.org/svn/boost/trunk/libs/exception/doc/boost-exception.html. Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode

5 10