- Boost - lists.boost.org

Building 1.52.0 with g++ 4.7.2
by Richard Hadsell 01 Feb '13

01 Feb '13

I am having trouble building Boost 1.52.0 libraries with g++ 4.7.2 on Linux Fedora 14. I was able to build it with 4.7.1, and I think our Systems guys configured 4.7.2 the same as 4.7.1, so I need help. This is in my user-config: using gcc : 4.7.2 : /opt/gcc-4.7.2/bin/g++ :<compileflags>"-fPIC -fno-strict-aliasing -fno-tree-ccp"<linkflags>"-fPIC -fno-strict-aliasing -fno-tree-ccp" ; This is my command line: bin/bjam --user-config=user-config.LINUX_INTF14X threading=multi instruction-set=core2 address-model=64 variant=release link=static,shared --stagedir=stageF14X And this is the result (snipped out redundant info): Building the Boost C++ Libraries. Performing configuration checks - x86 : no - power : no - arm : no - mips1 : no error: No best alternative for libs/context/build/asm_context_sources next alternative: required properties:<abi>aapcs<architecture>arm<binary-format>elf<toolset>gcc not matched next alternative: required properties:<abi>aapcs<architecture>arm<binary-format>elf<toolset>qcc not matched [snip] next alternative: required properties:<abi>ms<address-model>64<architecture>x86<binary-format>pe<target-os>windows not matched - has_icu builds : no warning: Graph library does not contain MPI-based parallel components. note: to enable them, add "using mpi ;" to your user-config.jam - iconv (libc) : no - iconv (separate) : no - icu : no - icu (lib64) : no - Boost.Locale needs either iconv or ICU library to be built. [snip] - Boost.Locale needs either iconv or ICU library to be built. - gcc visibility : no - long double support : no warning: skipping optional Message Passing Interface (MPI) library. note: to enable MPI support, add "using mpi ;" to user-config.jam. note: to suppress this message, pass "--without-mpi" to bjam. note: otherwise, you can safely ignore this message. error: No best alternative for libs/context/build/asm_context_sources next alternative: required properties:<abi>aapcs<architecture>arm<binary-format>elf<toolset>gcc not matched [snip] -- Dick Hadsell 203-992-6320 Fax: 203-992-6001 Reply-to: hadsell(a)blueskystudios.com Blue Sky Studios http://www.blueskystudios.com 1 American Lane, Greenwich, CT 06831-2560

2 2

[container] static_vector: fixed capacity vector update
by Andrew Hundt 01 Feb '13

01 Feb '13

*static_vector is a hybrid of boost::container::vector and boost::array with fixed capacity. Adam Wulkiewicz and I have updated static_vector with improvements from the list discussion and reorganized it for possible inclusion into boost.container. Overview: static_vector is a sequence container with contiguous storage that can change in size like boost::container::vector. It also includes static allocation, low overhead, and fixed capacity similar to boost::array. Synopsis: template* *<* * typename Value, * * std::size_t Capacity, * * typename Strategy = strategy::def<https://svn.boost.org/svn/boost/sandbox/static_vector/doc/html/static_vecto…> <Value> * *>* *class static_vector; Example: // static_vector of ints, fixed capacity: 3 boost::container::static_vector<int,3> three; // size: 0 three.push_back(1); // size: 1 three.push_back(2); // size: 2 three.push_back(3); // size: 3 //three.reserve(4); // no effect, fixed capacity: 3 //three.push_back(3); // size: 4, undefined behavior three.pop_back(); // size: 2 three.shrink_to_fit(); // no effect, fixed capacity: 3 Documentation: https://svn.boost.org/svn/boost/sandbox/static_vector/doc/html/index.html Source: https://svn.boost.org/svn/boost/sandbox/static_vector/ Discussions from boost.devel archive: http://goo.gl/PKEpB [google groups] Changes: - C++11 support - moved to boost::container namespace - strategy based error handling (“strategy” is aka “policy”) - bounds checks are asserts by default but can be switched to exceptions - memory is uninitialized until objects are inserted - internal size is currently the same as Strategy::size_type - expanded documentation and unit tests - optimizations based on type traits - boost::interprocess support ------------------------------------------------ ------------------------------------------------ Major questions from prior list discussions and the related design decisions: ------------------------ Q1: static_vector design *a) combination of fixed capacity vector and adjustable size array b) vector with small size optimization, possibly with configuration of what “small size” means. A1: (a) is implemented by static_vector, leaving the (b) as future work for a separate class. ------------------------ Q2: Is it best to implement push_back() and similar functions with or without bounds check? Main use cases: *a) no bounds check on each insertion because it is an undesirable use of resources b) vector emulation where static_vector is a drop in replacement and optimization so bounds checking is essential to minimize the amount of code that must be changed. A2: (a) no bounds check is the default for static_vector. A vector emulation strategy can be implemented for (b). ------------------------ Q3: Should a failed bounds check trigger an assertion or an exception? Main use cases: a) bounds check is too much overhead, but assert() allows for testing in debug mode b) vector emulation, so bad_alloc should be thrown when the capacity is exceeded c) exceptions are desired when bounds checking, but bad_alloc would cause the wrong behavior because freeing up memory will not allow the possibility of a larger capacity as it would in a vector. A3: (a) failed bounds checks trigger an assertion, and the user can implement the necessary strategy and traits to achieve (b) or (c). ------------------------------------------------ ------------------------------------------------ New/Unanswered Questions: ------------------------ Q4: Should the current static_vector actually be in the detail namespace, with policy specializations providing the actual interface to several classes with different desired functionality? This could be similar to what was suggested by Nate Ridge: On Sat, Oct 15, 2011 at 5:16 PM, Nathan Ridge <zeratul976(a)hotmail.com> wrote: > Now the implementor of these classes can implement them like this: > > typedef boost::detail::static_vector<T, AssertPolicy> capacity_array; > typedef boost::detail::static_vector<T, ThrowPolicy> stack_vector; It also seems to be backed by the fundamental interface differences between the various classes (static_vector, std::vector, AutoBuffer/hybrid_vector) as outlined by Dave Abrahams: On Wed, Oct 19, 2011 at 1:26 PM, Dave Abrahams <dave(a)boostpro.com> wrote: > I see a container that can never store more than N items, for some > reasonably small N, as fundamentally, semantically different from one > that is highly likely to be able to store any M items you have to deal > with, and for which you can't determine a hard limit N ahead of time > (no, max_size() doesn't count—that's typically just > numeric_limits<size_t>::max()). I grant you that we don't have a very > strict way of expressing this difference in a specification, but I think > that's just missing. I wouldn't, except in very special circumstances, > consider one of those containers to be a suitable replacement for the > other, despite the similarity of the specification text. Would you? This would mean that the official interfaces can be specific to various common use cases and a bit simpler. An additional benefit here is that simpler interfaces are more welcoming to a wider range of developers. On the other hand, the current design makes the official interface configurable so they could customize it without being as concerned about changes in the detail implementation. If everyone will want something different for their specific use case, leaving the design as is may make the most sense. Furthermore, a reasonable default provides a simpler interface while permitting advanced configuration for those who need it. ------------------------ Q5: Should the static_vector Strategy concept (a) remain as is (b) add the Capacity as an additional template parameter (c) permit Standard Library Allocators as a strategy Currently, the default traits assume that the Strategy defines types normally defined by Allocator and provides a capacity check failure callback. Also, a different strategy and traits specialization can be used to configure the class as desired, such as modifying the size_type based on the Capacity. Consequently, leaving the Strategy as is (a) remains fairly reasonable. Adding an additional Capacity template parameter (b) to the Strategy concept would take the Strategy further from the Allocator concept, but ensure configuration of size_type based on the capacity is easy and consistent. We believe (c) does not make sense despite allowing static_vector to be more compatible with vector due to the fundamental interface differences discussed in Q4. Option (c) makes more sense for a class like AutoBuffer/hybrid_vector than it does for static_vector. Thus, the question ultimately becomes one concerning the tradeoff between options (a) and (b). ------------------------ Q6: Should static_vector_traits be part of the public interface or remain in the detail namespace? This would make some of the functionality in Q5a part of the official interface, but restrict future changes. In Boost.Container traits are defined in the detail namespace so we were hoping to find out the reasoning for this choice. The direction of the design discussion for Q4 could also make this a moot point. ------------------------ Q7: Does static_vector provide significant benefits over boost::container::vector with a stack Allocator template parameter? This has been discussed previously and we believe the answer is yes for the reasons outlined in Q4 and the documentation, but we wanted to bring it up again in case someone wanted to play devil’s advocate. ------------------------ That covers all the basics of the updated static_vector implementation and some of the biggest outstanding design questions. We appreciate any and all questions, design ideas, or issues you can come up with, so fire away. :-) Regards, Andrew Hundt* Adam Wulkiewicz

7 22

[GitHelp] varray (aka static_vector) to modular boost
by Andrew Hundt 01 Feb '13

01 Feb '13

I'm trying to bring varray over to github with modular boost, but since we just moved it from static_vector to varray the history is split between two directories. I have been able to run git svn on each directory independently and then pull the static_vector one into the varray one on a separate branch. I then want to stack all the versions so that they are continuous, but I am not sure how to do this. my steps so far: git svn clone http://svn.boost.org/svn/boost/sandbox/varray varray git svn clone http://svn.boost.org/svn/boost/sandbox/static_vector varray2 cp -a varray varray3 # backup # git pull command here that brings it into another branch Also, I'd be happy to take suggestions of better ways to accomplish this. I've noticed that all the dates on github.com/boostorgrepository changes are getting old and are up to nearly a month now, have the updates stopped working? Cheers! Andrew Hundt

2 2

[iterator] Constness of counting_iterator
by Claas 01 Feb '13

01 Feb '13

Hi all! I was wondering why the dereference operator of counting_iterator<T> returns a constant reference to T instead of a reference to T. Naively I would expect counting_iterator<T>::reference to be T& and counting_iterator<const T>::reference to be const T&. I suppose however that there was good reason to implement counting_iterator the way it is implemented. Could anyone kindly point this reason out to me? Regards Claas

2 1

Re: [boost] [variant] Please vote for behavior
by Markus Klein 01 Feb '13

01 Feb '13

On Fri, Jan 25, 2013 at 10:21 AM, Dave Abrahams <dave(a)boostpro.com> wrote: > Yes. IIUC the question here is whether the invariant of variant [;-)] > shall be weakened to accommodate efficient move semantics, thereby > breaking some code, or not, at some cost (the specific costs to be > incurred by various strategies presently under discussion). I'm new to this list, so I won't be offended if you correct me on any rookie mistakes. Concerning the invariant of variant: Why not provide a specialization of boost::optional for variant, which supports move Semantics? Users who don't want their invariant harmed, can use boost::variant as is. Users who need to squeeze out performance could use an optional<variant> and would be explicitly aware of the new null state they introduced for this. Markus www.clean-cpp.org

6 12

[asio] ssl::stream::async_handshake handler not called
by Alex 01 Feb '13

01 Feb '13

Hi guys, If ssl client cannot read data from server (SSL_connect: error in SSLv2/v3 read server hello A), handshake handler is not called. Is this by design? Or, probably, it should be called with error anyway. Thanks in advance. Alex

1 0

Is there any interest in static constructors?
by Alexander Stoyan 01 Feb '13

01 Feb '13

Hello community, I have implemented static constructors for my personal needs. They guarantee construction of static data prior main execution, and allow control the order of static initialization. The code now implemented and tested for VS2012 and GCC. I couldn't find anything like this in the boost library but consider it to be useful for C++ developers. More detailed approach on my blog page: http://alexander-stoyan.blogspot.com/2013/01/static-constructors-in-c.html Feedbacks are very appreciated. Thank you. ______________________________ With best regards, Alexander Stoyan

2 1

Re: [boost] [filesystem] thread safety on msvc 2010
by Jacob Schloss 31 Jan '13

31 Jan '13

> Message: 9 > Date: Mon, 28 Jan 2013 11:05:07 -0500 > From: Beman Dawes <bdawes(a)acm.org> > To: boost(a)lists.boost.org > Subject: Re: [boost] [filesystem] thread safety on msvc 2010 > Message-ID: > < > CAAygHNO8u+gvpGABgJR-KxSP-EqvhyRWRCSKKwx_7chH2hesSg(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Some critical points to getting a patch accepted are that it applies > only to the affected platform (i.e. Windows) and that it includes test > cases that fail with the current code but pass with the patch applied. > If it works for you with msvc 2010, I can test with other versions and > compilers. > > Thanks, > > --Beman > > Ok, I have some test code I could submit. Is it all right to use boost::threads in the test so it is cross platform? It might be a while (have trip for work soon) until I have time to pull svn (or git, looks like that move is happening soon) and make the patch, but I will try to follow up on this when I get back. Thanks, Jacob PS: Sorry if this broke threading. I just switched off of the digest

2 1

Query of interest for a container output library
by meta221 31 Jan '13

31 Jan '13

Hello, lately I've been working on a library that can output different kinds of containers to standard output streams. The library is currently completely generic and can output any object that models the input range concept or Boost.Fusion's sequence concept. It doesn't restrict itself to std containers. If an object looks like a sequence, then it is a sequence in the eyes of the library. The library uses different open and close characters for different kinds of containers. For example the output of the following: std::cout << std::vector<int> {1,2,3} << '\n'; std::cout << std::set<int> {1,2,3} << '\n'; std::cout << std::map<int,int> { {1,2}, {2,3}, {3,1} } << '\n'; is: [1,2,3] {1,2,3} {(1,2), (2,3), (3,1)} In the example std::vector is interpreted as an ordered_dynamic container and std::set and std::map are interpreted as associative_dynamic containers by the library. The library recursively outputs the contents of each container, so because std::map::value_type is a std::pair (which models Boost.Fusion's sequence concept) it can also output that. std::pair is interpreted as an ordered_fixed container by the library. The library picks the appropriate category for each type being outputted by using Boost.MPL to introspect the type of the object being outputted. In the future I would like to extend the library to offer facilities to help users implement a operator<< (std::ostream&, T) function for arbitrary types but I haven't really given that a lot of thought yet. The library's name is currently Boost.Stringize but I don't really like that name and I'm really open for suggestions. Overall I think this library would make a good addition to Boost as it simplifies things for the end user. If a user wants to output a vector, he/she shouldn't have to iterate over it. It should be as simple as outputting an int. In Python a user can just "print [1,2,3]". Why can't we have something similar in C++? Is there any interest for this library in Boost? Thanks, Tal Zion -- View this message in context: http://boost.2283326.n4.nabble.com/Query-of-interest-for-a-container-output… Sent from the Boost - Dev mailing list archive at Nabble.com.

7 10

[string_ref] type erasure to support arbitrary strings
by Andreas Pokorny 31 Jan '13

31 Jan '13

Hi, When I made a first glance of the proposal I expected that string_ref is some kind of type erasing non owning holder of a reference to an arbitrary string class. The imperfect silver bullet for the diversity of string types. Take a project that uses c++ libraries using std::string, Qt GUI and maybe a module that works with chunked strings (string composed out of a list of usually equally sized blocks of memory). At the boundaries of the software modules copies have to occur. Frequently the interface expects some kind of constant references to a certain string type. Most of the time the callee just wants to process the complete string or just a part of the string. So there might not even be the necessity to have random access hence no need for a contiguous copy of the string contents. Thats why I would prefer a facility that only requires that the source string is a forward range of characters in an arbitrary encoding. I do not think that it makes sense to only address contiguous sequences of characters. regards Andreas Pokorny

5 8