- Boost - lists.boost.org

[Iterator] Zip iterator for back_insert_iterators?
by Kris Rousey 12 Sep '08

12 Sep '08

I just tried to make a zip iterator out of two vector back_insert_iterators and got a very curious compile failure: /usr/include/boost/iterator/iterator_facade.hpp:653: error: invalid parameter type 'void' /usr/include/boost/iterator/iterator_facade.hpp:653: error: in declaration 'typename boost::detail::operator_brackets_result<Derived, Value, Reference>::type boost::iterator_facade<I, V, TC, R, D>::operator[](Difference) const' /usr/include/boost/iterator/iterator_facade.hpp:693: error: invalid parameter type 'void' /usr/include/boost/iterator/iterator_facade.hpp:693: error: in declaration 'Derived& boost::iterator_facade<I, V, TC, R, D>::operator+=(Difference)' /usr/include/boost/iterator/iterator_facade.hpp:699: error: invalid parameter type 'void' /usr/include/boost/iterator/iterator_facade.hpp:699: error: in declaration 'Derived& boost::iterator_facade<I, V, TC, R, D>::operator-=(Difference)' /usr/include/boost/iterator/iterator_facade.hpp:705: error: invalid parameter type 'void' /usr/include/boost/iterator/iterator_facade.hpp:705: error: in declaration 'Derived boost::iterator_facade<I, V, TC, R, D>::operator-(Difference) const' It seems that even though back_insert_iterator has an output_iterator tag, iterator_facade still trying to define random access operators. If assignment and incrementing are the only valid operations on an iterator (as is the case with output iterators), then doesn't it make sense to support a difference_type of void? Is this a curiosity of my stdlib implementation? A Boost.Iterator library oversight? A Boost.Iterator conscious design decision? Or a loose nut behind the keyboard trying something he shouldn't? I'm using version 1.35.0 on Ubuntu 8.04 x86_64 with g++ version 4.2.3. Here's the code I used to get this error: #include <iterator> #include <iostream> #include <boost/iterator/zip_iterator.hpp> #include <vector> #include <algorithm> using namespace std; using namespace boost; int main() { vector<int> ha1; vector<double> ha2; make_zip_iterator( make_tuple( back_inserter(ha1), back_inserter(ha2) ) ); return 0; } Thanks, Kris

2 5

[In_Place_Factory] Typo
by Manuel Jung 12 Sep '08

12 Sep '08

Hi, I found a typo: Here: http://www.boost.org/doc/libs/1_36_0/libs/utility/in_place_factories.html Chapter: Framework In the First example: struct C { template<class InPlaceFactory> C ( InPlaceFactory const& aFactoty ) //<----------Here! should be "aFactory" : contained_ ( uninitialized_storage() ) { aFactory.template apply<X>(contained_); } ~C() { contained_ -> X::~X(); delete[] contained_ ; } char* uninitialized_storage() { return new char[sizeof(X)] ; } char* contained_ ; } ; void foo() { C c( in_place(123,"hello") ) ; } Greetings Manuel

1 0

Re: [boost] HP-UX_pa_risc_aCC test failure
by Kotari, Preethi (STSD) 12 Sep '08

12 Sep '08

Hi, We are investigating this issue and will keep you updated with the progress. Thanks, Preethi > -----Original Message----- > From: boost-bounces_at_[hidden] > [mailto:boost-bounces_at_[hidden]] On Behalf Of Emil Dotchevski > Sent: Tuesday, September 09, 2008 3:29 PM > To: boost_at_[hidden] > Subject: [boost] HP-UX_pa_risc_aCC test failure > > I'm looking at this failure: > > http://www.boost.org/development/tests/trunk/developer/output/ > HP-UX_pa_risc_aCC-boost-bin-v2-libs-exception-test-throw_excep > tion_test-test-acc-pa_risc-debug.html > > 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.

1 0

Re: [boost] [hash] Is there any interest in cryptographic hash functions?
by Kasra (Math & ComSci) 12 Sep '08

12 Sep '08

I am back from being busy => I am free. I have thought about the design decisions: "It doesn't really make sense to hook this up to an fstream. Such a remove_file_securely() functionality should be implemented as free function." I disagree, say you have a file 'x' which you don't want the local police to be able to recover, and you have a 'xx' file which you don't want the FBI to be able to recover (a little too hard to achieve). Here the security differs, and thus the wipe method ought to be different. secure_wipe< aStream, onePassAlgorithm > x; // single overwrite secure_wipe< aStream, gutmannAlgorithm > xx; // 35 x overwrite "Well there are two classes of ciphers, block ciphers and stream ciphers. Block ciphers encrypt data by working on x bytes at a time. Stream ciphers on the other hand (like RC4) encrypt data continuously and don't need a padding parameter because they don't need to pad data to a multiple of some block size. So what you call a cipher is a stream cipher. I see now where you're going with this and I will think about it. " In general blocks cipher is an element of stream cipher which in turn is an element of cipher set. So I guess the terminology doesn't bother me much. But I think you know where I am coming from now. "I remember that table lookups generally are susceptible to cache timing attacks. That does not mean we shouldn't use the optimized rijndael version though." I totally agree with you, the cache-timing attack is believed to be impossible on more than 1 network loop. I have written the wrapper class for the optimised implementation. Conclusion: All of us like: * basic_crypto_stream. * optimised implementations Haven't agreed on yet but are thinking in the same lines: * block_cipher, stream_cipher, cipher thing Disagree on: * secure_wipe I agree 'secure_wipe' is not very useful for a memory buffer. A secure allocator works fine (i.e. memset() ). But on the other hand when it comes to files 'secure_wipe' is very useful. So we need to agree on the interface which the 'secure_wipe' task is achieved. With best regards, kasra

1 0

[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