October 2012 - Boost - lists.preview.boost.org

[Numeric Conversion] Documentation Notes/Questions
by Dave Abrahams 25 Nov '12

25 Nov '12

* First thing to note: the documentation makes this library less approachable than it could be. In order to even begin, one has to bury onesself in terminology (the "Definitions" section). A super-quick "hello, world" example and a very short tutorial at the beginning would help a *lot*. numeric_cast is arguably the most generally-useful interface of the whole library and yet it's not even discussed until the end of the docs. * It's not clear what the purpose of abt(x) is. In expressions, "x" usually means its value. When you introduce a mechanism like this, it would be a good idea to explain why it's needed. Most places, the use of "abstract" just seems to complicate things: "A ulp is a quantity whose abstract magnitude" what's wrong with "A ulp is a quantity whose magnitude" ?? The end of the section on "Range and Precision" begins to explain why you want "abstract," but it takes the reader a long time to get to it. * are next() and prev() always well-defined? Seems to me that an unlimited precision rational number type might not have them. Is that type not numeric? * How do size, width, and density relate to unlimited precision rationals? I imagine: size = infinity width = infinity density = ? * This is slightly ambiguous: "This definition allows for a concise definition of subranged as given in the last section." "final section" would be clearer. A link would help too. * This is unclear: "Abstract intervals are easier to compare and overlap since only boundary values need to be considered." an example would help. How can one kind of thing be "easier to overlap" than another? * Precision has a very non-generic description, being different for types with density 1 and other types. It's hard to see what use such a concept has, and as far as Google can tell it is not used anywhere outside the Definitions section * Description of unsigned types, I think, is wrong: Notice that a numeric type, such as a C++ unsigned type, can define that any V does not overflow by always representing not V itself but the abstract value U = [ V % (abt(h)+1) ], which is always in range. Seems to me that the abstract values represented by an unsigned integer type are not the set of whole numbers, but the set of whole numbers modulo whatever-the-max+1-is. That's a well-defined mathematical abstraction, isn't it? Is there a problem with that, such as multiplication not working properly (I don't think so)? * There seems to be a contradiction here: If V >= abt(l) and V <= abt(h), V is representable (can be represented) in the type T ... Given an abstract value V represented in the type T as v, the roundoff error of the representation is the abstract difference: ( abt(v)-V). If V is not representable in type T, can you write formulae using its representation in type T? Given what I read later, maybe you should have just said "exactly representable" in the first phrase. * s/at most/less than/?: Because a correctly rounded representation is always one of adjacents of the abstract value being represented, the roundoff is guaranteed to be at most 1ulp. * s/cannot be represented/cannot be exactly represented/ ?: The integer number -1 can be exactly represented in Int, Real and Whole, but cannot be represented in Cardinal, yielding negative overflow. * Uh-oh: Floating to Floating conversions are defined only if N is representable; if it is not, the conversion has undefined behavior. in many places you've used "representable" to mean "exactly representable," but I can't believe you mean that here; it would imply most double=>float conversions have undefined behavior. What does this mean, anyway? If an abstract value can be "inexactly representable," aren't all abstract values representable if there's at least one abstract value that's exactly representable? Just convert to that and you're done. I think you need to give some serious thought to the definition of "representable." * s/then/so/: R(X) & R(Y) == R(X), then X->Y is not subranged. Thus, all values of type X are representable in the type Y. (b) Y->X: R(Y) & R(X) == R(Y), then Y->X is not subranged. Thus, all * What's the difference between a policy and a "parameter that defines the conversion" in It can optionally take some policies which can be used to customize its behavior. The Traits parameter is not a policy but the parameter that defines the conversion. ?? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

4 4

[#pragma once]
by Sid Sacek 18 Nov '12

18 Nov '12

I've worked with the MSVC, Sun and GCC compilers. Each one of them supports #pragma once. Is there any reason to wrap this pragma within #ifdefs? Are there any compilers out there today that don't support this #pragma? #if defined( _MSC_VER ) && ( _MSC_VER >= 1020 ) # pragma once #endif Could we change this coding pattern so that it no longer looks like MSVC is being selfish? -Sid Sacek

17 20

[iterator] [property_map] Enhancement proposals
by Louis Dionne 12 Nov '12

12 Nov '12

Dear boost, First of all, let me quickly introduce myself as this is my first post here: I am a 20 years old programming enthusiast with interest for metaprogramming, functional programming and library design. I also have a strong will to contribute to open source projects since I love the philosophy behind it and it is a great way to develop new skills and to work with talented people. The object of this message is to collect feedback on several enhancement proposals I have prepared for two existing libraries: [boost.iterator] [boost.iterator.accessor_iterator] The accessor_iterator is an iterator adaptor that returns a reference to a member of its pointee when dereferenced. I see it as another step in the direction of easier iterator composition, which has helped me writting less code in the past. [boost.iterator.chained_output_iterator] The chained_output_iterator is an iterator adaptor allowing to apply a functional transformation to a value before outputing it into another output iterator. It is much like a function_output_iterator that would forward its result to another output iterator. It allows for cool stuff like creating a pipeline of operations without having to create temporary storage. [boost.property_map] [boost.property_map.accessor_property_map] The accessor_property_map is a property map returning a reference to a member of the key it is given. It is much like the accessor_iterator for property maps. [boost.property_map.chained_property_map] The chained_property_map is a tool for property map composition. It takes two property maps and uses a value in the first one as a key in the second one to perform its put, get, and operator[] operations. [boost.property_map.property_traits] I feel like the boost/property_map/property_map.hpp header is a little bit bloated and not quite as modular as it could be. For now, I propose that we move the code dealing with property_traits into the boost/property_map/property_traits.hpp header and that we provide metafunctions to check for adherence to property map types. By providing an include in the boost/property_map/property_map.hpp header, backward compatibility is maintained and we simply increase modularity. All the code is available on github: https://github.com/ldionne/boost-submissions To see how each class can be used, you may look at the unit tests for the corresponding class. If anything is accepted, I will be pleased to write documentation and examples for the concerned feature and to integrate it into the existing documentation. Looking forward to your feedback, Louis Dionne

2 11

filesystem::path passed to GTest's assertion leads to stack overflow because of infinite recursion
by Andrey Upadyshev 10 Nov '12

10 Nov '12

Hi all, I found an interesting bug with 'filesystem::path' used with GTest: https://svn.boost.org/trac/boost/ticket/7564 I just want to discuss the design of 'path' class which iterator contains the 'path' itself. Don't you think it's nice to fix thing? Best regards, Andrey Upadyshev P.S. Sorry if this is wrong mailing list. Just let me know and I'll repost the message to boost-users <boost-users(a)lists.boost.org> mailing list.

2 5

Release branch closed
by Marshall Clow 08 Nov '12

08 Nov '12

Boosters, The release branch is now closed for all commits, except by explicit permission of release managers. -- The Release Managers, Beman Dawes Daniel James Eric Niebler Rene Rivera Vladimir Prus Marshall Clow

4 5

[release][1.52.0] Release Notes
by Daniel James 06 Nov '12

06 Nov '12

Hello everyone, We're coming up to the beta release, so it's time to put together the release notes (although please don't feel you need to wait for me to start). As always you can send them to me, or if you want update them yourself in subversion. The files are at: https://svn.boost.org/svn/boost/website/public_html/live/feed/history/ The actual site won't get updated until I run the update script. You can see the release notes so far at: http://www.boost.org/users/history/version_1_52_0.html As usual, they're not finished yet, and some of the links might not work as the 1.52 documentation won't be uploaded until after the beta is released. thanks, Daniel

9 22

[clang] Windows toolset support?
by Beman Dawes 06 Nov '12

06 Nov '12

Cygwin has been shipping clang for six months or so. Has anyone gotten the cygwin/clang distribution (or any other clang distribution) to build boost? What toolset did you use? What does your user-config.jam file look like? Do you run bjam/b2 from the Windows command line or the bash command line? Thanks, --Beman

7 16

[locale] [filesystem] Windows local 8 bit encoding
by Thiel, Bjoern 06 Nov '12

06 Nov '12

Hi, developing platform independent code I really like the convenience functions conv::to_utf, conv::from_utf, and conv::utf_to_utf from locale. Why not add something like conv::local8bit_to_utf and conv::local8bit_from_utf following the rational from filesystem (path encoding conversions): template < typename CharType > std::basic_string< CharType > local8bit_to_utf ( std::string const & text, method_type how = default_method ) { char const * encoding = impl::local8bit_encoding() ; return to_utf< CharType >( text, encoding, how ) ; } template< typename CharType > std::string local8bit_from_utf ( std::basic_string< CharType > const & text, method_type how = default_method ) { char const * encoding = impl::local8bit_encoding() ; return from_utf< CharType >( text, encoding, how ) ; } with char const * local8bit_encoding() { #ifdef WIN32 UINT codepage = AreFileApisANSI() ? GetACP() : GetOEMCP() ; return windows_codepage_to_encoding( codepage ) ; #else return "UTF-8" ; #endif } and with (better using a map) char const * windows_codepage_to_encoding( int const codepage ) { switch (codepage) { case 874: return "windows-874" ; case 932: return "Shift_JIS" ; // but should be "Windows-31J" ; case 936: return "GB2312" ; case 949: return "KS_C_5601-1987" ; case 950: return "Big5" ; case 1250: return "windows-1250" ; case 1251: return "windows-1251" ; case 1252: return "windows-1252" ; case 1253: return "windows-1253" ; case 1254: return "windows-1254" ; case 1255: return "windows-1255" ; case 1256: return "windows-1256" ; case 1257: return "windows-1257" ; case 1258: return "windows-1258" ; case 20127: return "US-ASCII" ; case 20866: return "KOI8-R" ; case 20932: return "EUC-JP" ; case 21866: return "KOI8-U" ; case 28591: return "ISO-8859-1" ; case 28592: return "ISO-8859-2" ; case 28593: return "ISO-8859-3" ; case 28594: return "ISO-8859-4" ; case 28595: return "ISO-8859-5" ; case 28596: return "ISO-8859-6" ; case 28597: return "ISO-8859-7" ; case 28598: return "ISO-8859-8" ; case 28599: return "ISO-8859-9" ; case 28603: return "ISO-8859-13" ; case 28605: return "ISO-8859-15" ; case 50220: return "ISO-2022-JP" ; case 50225: return "ISO-2022-KR" ; case 51949: return "EUC-KR" ; case 54936: return "GB18030" ; case 65001: return "UTF-8" ; default: { std::ostringstream message ; message << "Unknown codepage " << codepage ; throw std::invalid_argument( message.str() ) ; } } } Best regards Bjoern.

5 10

[variant] awkward recursion
by Dave Abrahams 03 Nov '12

03 Nov '12

I've been playing around with variant a bit and decided to try to build a data structure for storing json. I came up with several different approaches but none are super-satisfying. I'd like some feedback. (If you need a refresher on what's in json, the front page of http://json.org tells all). In the abstract, json looks like: struct null {}; typedef std::map<std::string, value> object; typedef std::vector<value> array; typedef variant< null, std::string, double, object, array, bool > value; Naturally, this code isn't legal C++, so I set about making it be. The first thing I tried was to use recursive_wrapper<>, as the documentation implies it is the most flexible way to do this sort of thing. Unfortunately, there's no clean way to reformulate this type in a way that allows recursive_wrapper work, because the type that needs to be wrapped in recursive_wrapper includes "value" in its name, and I can't forward-declare it. The only way to forward-declare a type X, as far as I know, is: struct X; // or class X; So to try to get recursive_wrapper to work, I tried a couple of formulations that started with that, but it turns out that when you do this, you end up not needing recursive_wrapper at all struct value; typedef std::map<std::string, value> object; typedef std::vector<value> array; typedef variant< null, std::string, double, object, array, bool > value_base; struct value : value_base { value() {}; template <class T> value(T const& x) : base(x) {} // no move; I'm in C++03-land value& operator=(value const& x) { base::operator=(x); return *this; } } }; I don't know if I've missed some things that should be in that "value" class. I know that a recursive variant, in principle, requires a pointer indirection somewhere, so I was wondering if, had I wrapped object and array in recursive_wrapper as below, I would have been adding an unnecessary inefficiency. typedef variant< null, std::string, double, reference_wrapper<object>, reference_wrapper<array>, bool > value_base; I also wondered whether that would give me different results from typedef std::map<std::string, value> object; typedef std::vector<value> array; typedef variant< null, std::string, double, std::map<std::string, reference_wrapper<value> >, std::vector<reference_wrapper<value> >, bool > value_base; and which one was better. Does anyone know? I think that should be in the docs. Using recursive_variant_ works out quite nicely, except that it doesn't allow me to separately declare "object" and "array" and re-use them in the definition of "value": typedef boost::make_recursive_variant< null , std::string , double , std::map<std::string, boost::recursive_variant_> , std::vector<boost::recursive_variant_> , bool >::type value; I also wonder if I'm getting an unnecessary inefficiency in that case. Lastly, what flexibility am I sacrificing by using this approach? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

9 28

[Variant] Documentation Questions/Notes
by Dave Abrahams 02 Nov '12

02 Nov '12

- What does this mean? Full value semantics, including adherence to standard overload resolution rules for conversion operations. Seems to me that it's impossible *not* to adhere to any standard rules. Is the part after the comma vacuous? - The "temporary heap backup" technique seems to have a hole: 1. Copy-construct the content of the left-hand side to the heap; call the pointer to this data backup. 2. Destroy the content of the left-hand side. 3. Copy-construct the content of the right-hand side in the (now-empty) storage of the left-hand side. 4. In the event of failure, copy backup to the left-hand side storage. 5. In the event of success, deallocate the data pointed to by backup. What happens in the event of a failure in step 4? - I note the section on motivation doesn't mention the new capabilities of C++11 unions. Now some of the constructs are possible... *if* you do all the bookeeping yourself. - I note that the implementation has at least some support for move semantics and yet the docs require all elements to be "bounded types", which in turn are required to be CopyConstructible. Is that accurate, or outdated? - "completeness at the point of template instantiation" is a rather odd thing to put in a concept. I suggest that that should be just part of the requirements on the variant template rather than on BoundedType. - Do the semantics for are_strict_equals at http://www.boost.org/doc/libs/1_51_0/doc/html/variant/tutorial.html differ from those of the built-in equality operator? - it might be worth making the point that recursive variants offer the ability to define complex linked data structures *as value types* in a type- and memory-safe manner. I.e. no explicit handling of pointers; copy construction and assignment "just work," etc. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

3 5

[optional] Doc Nit
by Dave Abrahams 01 Nov '12

01 Nov '12

> A typical approach is to consider the existence of a > valid return value as a postcondition, so that if the > function cannot compute the value to return, it has > either undefined behavior (and can use assert in a > debug build) or uses a runtime check and throws an > exception if the postcondition is violated. This is a > reasonable choice for example, for function (A), This is possibly technically correct, but confusing. Undefined behavior results from precondition violations, not postcondition violations. I'd suggest: One approach is to make a non-negative argument a precondition, so when violated the function has undefined behavior (and can use assert in a debug build). Alternatively, one can use a runtime check and specify that an exception is thrown if the postcondition cannot be satisfied. These are a reasonable choice for example, for function (A), I'm not sure the first sentence is quite right for your needs, but I'm out of time to improve it further. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

2 1

C++ Now 2013 Call for Submissions
by Hartmut Kaiser 31 Oct '12

31 Oct '12

---------------------------------------------------------------------------- C++ NOW CONFERENCE 2013 - Aspen CO, USA, May 13-17, 2013, www.cppnow.org ---------------------------------------------------------------------------- CALL FOR SUBMISSIONS -------------------- We invite you to submit session proposals to the 2nd annual C++ Now Conference (Aspen CO, USA, May 13-17, 2013). Building upon the resounding success of C++ Now 2012 and five years of BoostCon, C++ Now 2013 will present leading speakers from the whole C++ community. The C++ Now Conference is dedicated to discussion and education about C++, an open and free language and standard. Our Conference will focus on discussion and education about open source software usage and developments in the C++ developer and user community. To reflect the breadth of the C++ and Boost communities, the conference includes sessions aimed at three constituencies: C++ and Boost end-users, hard-core Boost library and tool developers, and researchers pushing the boundaries of computation. The program fosters interaction and engagement within and across those groups, with an emphasis on hands-on, participatory sessions. As a multi-paradigm language, C++ is a melting pot where the most compelling ideas from other programming communities are blended in powerful ways. Historically, some of the most popular sessions at C++ Now have highlighted these concepts, from DSLs to functional programming to transactional memory and more. Bring your C#, Python, Ruby or Haskell influences to bear in an environment that will broaden their exposure. At C++ Now 2013 we would like to focus on parallel and distributed computing with C++. However, by no means this is intended to restrict the topics of proposals we hope to see. Any other topic related to C++ as outlined below is perfectly fine for submission. IMPORTANT DATES --------------- New proposal submissions due: December 15th, 2013. Proposals decisions sent (tentative program available): January 30th, 2013. Fully scheduled program available: February 24th, 2013. BEST PRESENTATION AWARDS ------------------------ We know how much effort it takes to prepare talks for our conference. For this reason we will award the best presentations in the following categories: Best Presentation, Best Short Presentation, Best Tutorial, and Best Workshop. The awards will be given based on the audience's voting. Each award will include the author's name listed on the cover of the C++ Now website for that year and a plaque containing all the C++ Now conference information. SESSION TOPICS -------------- Topics of interest include, but are not restricted to, the following: * Parallelism in the new C++11 standard * Parallel, distributed and GPGPU topics relating to C++ * C++11 and how it changes life for users and library writers * General tutorial sessions on C++11, the C++11 Standards library, and one or more Boost libraries * In-depth sessions on using specific Boost libraries * Case studies on using Boost * Experts panels * Advanced sessions on implementation techniques used within Boost libraries * Development workshops to extend or enhance existing Boost libraries * Workshops on design process * Infrastructure workshops such as Build tools, Website, Testing * Concepts and Generic Programming * Hardware and infrastructure presentations focused on how libraries can make better use of the technology * Software development tools and their application to C++ and or Boost * Other topics likely to be of great interest to C++ users and developers Interactive and collaborative sessions are encouraged, as this is the style of learning and participation that has proven most successful at such events. Sessions can be tutorial based, with an emphasis on interaction and participant involvement, or workshop based, whether hands-on programming or paper-based, discussion-driven collaborative work. SESSION FORMATS --------------- Presentations Presentations focus on a practitioner's ideas and experience with anything relevant to C++11, Boost and users. Panels Panels feature three or four people presenting their ideas and experiences relating to C++11 and Boost's relevant, controversial, emerging, or unresolved issues. Panels may be conducted in several ways, such as comparative, analytic, or historic. Tutorials Tutorials are sessions at which instructors teach conference participants specific skills relevant to C++11 and Boost. Workshops Workshops provide an active arena for advancements in Boost-relevant topics. Workshops provide the opportunity for experienced practitioners to develop new ideas about a topic of common interest and experience. Author's Corner Presentations These were introduced at BoostCon 2008, and were a great success. They are short (30 minute) sessions, focusing on tips on usage and design. In addition, we're looking to uncover the hidden design gems in Boost libraries. Tool Vendors Presentations We actively encourage tool vendors and ISP's to submit proposals for a special Tool Vendors Session Track aimed at products related to Boost and C++ (compilers, libraries, tools, etc.). Other formats may also be of interest. Don't hold back a proposal just because it doesn't fit into a pigeonhole. SUBMITTING A PROPOSAL --------------------- Standard Sessions are 90 minutes. You may submit a proposal for fractions Or multiples of 90-minutes. Fractional proposals will be grouped into 90 Minute sessions covering related topics. Longer sessions, such as tutorials and classes, will be assigned three hour (i.e. half day), or six hour (i.e. full day) time slots. Please include: * The working title. * Type of session: presentation, panel, tutorial, workshop, authors corner, vendor track, other. * A paragraph or two describing the topic covered, suitable for the conference web site. * Proposed length: 10-20 minute short talks, 45 minutes, 90 minutes, half day, full day. * Alternate lengths, if you are willing to make adjustments: 10-20 minute short-talks, 45 minutes, 90 minutes, half-day, full day. * Audience: users, developers, both. * Level: basic, intermediate, advanced. * A biography, suitable for the conference web site. * Your contact information (will not be made public). SUBMISSION DETAILS ------------------ All submissions should be made through the EasyChair conference management system: http://www.easychair.org/conferences/?conf=cppnow2013. If you have not already registered at EasyChair, you will need to do so in order to submit your proposal. All submissions will go through a peer review process. Authors are invited (but are not required) to submit PDF versions of full papers of up to 10 pages in ACM conference proceedings format (see http://www.acm.org/sigs/publications/proceedings-templates) The full papers are not required unless you want them published in the proceedings. All accepted proposals will be made available in the Association for Computing Machinery (ACM) Digital Library (approval pending). Best papers, after further reviews, will be considered to be book chapters or journal articles in a renowned journal. The session materials go on the C++ Now website and will be available to attendees. For general information on the C++ Now 2013 paper submission or the scope of technical papers solicited; please refer to the conference website at www.cppnow.org. For any other questions about the submission process or paper format, please contact the Program Committee at cppnow2013(a)easychair.com. If you have any technical problems with EasyChair, please contact EasyChair for help. Note: Presenters must agree to grant a non-exclusive perpetual license to publish submitted materials, either electronically or in print, in any media related to C++ Now. Hartmut Kaiser, email: hartmut.kaiser(a)gmail.com (Program Committee Chair) Dave Abrahams, email: dave(a)boostpro.com (Conference Chair) On behalf of the conference organizers

1 0

[chrono][ratio][boost_1_52_0_beta1] warning in user code
by Jeff Flinn 31 Oct '12

31 Oct '12

I've just downloaded boost_1_52_0_beta1 and get the warning below in my user code on VC11(I'm using thread which evidently brings in the above libs). I didn't see mention of this in trac. I'm moving forward from 1.47 and from VC8 so I'm not sure if this is an indication of some project setting[s] of mine, or if it should be corrected in the lib? Thanks, Jeff 6>D:\boost_1_52_0_beta1\boost/ratio/detail/overflow_helpers.hpp(136): warning C4293: '<<' : shift count negative or too big, undefined behavior 6> D:\boost_1_52_0_beta1\boost/ratio/detail/overflow_helpers.hpp(282) : see reference to class template instantiation 'boost::ratio_detail::br_mul<X,Y>' being compiled 6> with 6> [ 6> X=0x01, 6> Y=0x01 6> ] 6> D:\boost_1_52_0_beta1\boost/ratio/ratio.hpp(155) : see reference to class template instantiation 'boost::ratio_detail::ratio_divide<R1,R2>' being compiled 6> with 6> [ 6> R1=boost::ratio<0x01,0x0989680>, 6> R2=boost::ratio<0x01,0x03e8> 6> ] 6> D:\boost_1_52_0_beta1\boost/chrono/duration.hpp(305) : see reference to class template instantiation 'boost::ratio_divide<R1,R2>' being compiled 6> with 6> [ 6> R1=boost::ratio<0x01,0x0989680>, 6> R2=boost::ratio<0x01,0x03e8> 6> ] 6> D:\boost_1_52_0_beta1\boost/chrono/duration.hpp(784) : see reference to class template instantiation 'boost::chrono::detail::duration_cast<FromDuration,ToDuration>' being compiled 6> with 6> [ 6> FromDuration=boost::chrono::duration<int_least64_t,boost::ratio<0x01,0x0989680>>, 6> ToDuration=boost::chrono::milliseconds 6> ] 6> D:\boost_1_52_0_beta1\boost/chrono/ceil.hpp(27) : see reference to function template instantiation 'boost::chrono::duration<Rep,Period> boost::chrono::duration_cast<To,int_least64_t,boost::ratio<N,D>>(const boost::chrono::duration<Rep,boost::ratio<N,D>> &)' being compiled 6> with 6> [ 6> Rep=int_least64_t, 6> Period=boost::milli, 6> To=boost::chrono::milliseconds, 6> N=0x01, 6> D=0x0989680 6> ] 6> D:\boost_1_52_0_beta1\boost/thread/win32/basic_timed_mutex.hpp(199) : see reference to function template instantiation 'To boost::chrono::ceil<boost::chrono::milliseconds,int_least64_t,boost::ratio<N,D>>(const boost::chrono::duration<Rep,Period> &)' being compiled 6> with 6> [ 6> To=boost::chrono::milliseconds, 6> N=0x01, 6> D=0x0989680, 6> Rep=int_least64_t, 6> Period=boost::ratio<0x01,0x0989680> 6> ]

4 8

[Move] Documentation Notes/Questions
by Dave Abrahams 31 Oct '12

31 Oct '12

1. In the docs, "comes in handful" => "comes in handy" 2. IMO, it's almost irresponsible to advertise move_iterator without saying that it's really *only* safe to use when you know implementation details of the algorithm or function to which you're passing it. In particular, it must not attempt to copy from any given position in the sequence more than once. 3. Why doesn't test_move_inserter use std::copy? 4. This sentence doesn't make any sense to me; it needs clarification. I would make a suggestion, but, well, I don't understand what you're trying to say The last one has the same behaviour as std::uninitialized_copy but since several standand library implementations don't play very well with move_iterators, this version is a portable version for those willing to use move iterators. 5. The section on constructor forwarding seems to imply that constructors are the only thing that will be forwarded, when of course that's not the case. 6. These sentences don't make sense to me together. They have no obvious connection to one another. To which limitations are you referring? Fortunately, most constructors take arguments by value, by const-reference or by rvalue reference. If these limitations are accepted, the forwarding emulation of a N-argument case requires just N overloads. This library makes this emulation easy with the help of BOOST_FWD_REF and boost::forward As far as I can tell from the implementation, BOOST_FWD_REF just generates a const& in emulation mode, which isn't much of an emulation at all. 7. "David Abrahams suggested the use of class rv class": too much class :-) -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

4 7

problem adding new toolset
by Pavel Heimlich, a.k.a. hajma 30 Oct '12

30 Oct '12

Hi, I'm trying to add support for building Boost on Solaris 11 with Solaris Studio and the Apache stdcxx4 library. While building it manually works well, I have problems with running the regression testsuite, it fails when trying to build process_jam_log. I'm quite lost in the Boost build system so I don't even know how to start debugging this. TIA for any hints hajma my patch: http://pastebin.com/BbuDv5PB build log: http://pastebin.com/h6wBL6ub

2 3

[serialization] how to retreive true_type from an archive ?
by nico 30 Oct '12

30 Oct '12

Hello. Context: ------- I use the boost serialization library to save and load objects of a system. I defined practices around this lib, and so I always serialize from a base class (every class serializable inherits from ISerializable). As a consequence, the true_type (i.e. the most derived type) is different from the this_type (i.e. ISerializable) and the true_type is stored in the archives. My question: ----------- How to retreive this true_type (as the string written in the archive), only from the archive object? I developp just a little bit: ---------------------------- Let's have this class tre: ISerializable <|-- B <|-- D If I do : B* b = new D(); b->SaveToFile(path); // <= this will do the serialization ar & this (this being a ISerializable*) I obtain an archive where it is written the true_type "D" (whatever the type of the archive : txt, bin or xml). With the b object and this code : const boost::serialization::extended_type_info & true_type = * boost::serialization::type_info_implementation<ISerializable>::type ::get_const_instance().get_derived_extended_type_info(*b); I have what I want in true_type.get_key(), i.e : "D". I can verify that "D" is written in every archive storing b. My question again : how, only with an archive object (construct from the archive file without error), car I retrieve this key? Tanks for any help. Nicolas.

2 3

[declval] non-ascii characters in declval.hpp
by Michel Morin 30 Oct '12

30 Oct '12

Hi Vicente, `utility/declval.hpp` contains a non-ascii character. I tried to fix this and make some improvements. Attached a patch that * removes a non-ascii character, * updates references to the C++11 standard, * fixes obvious oversights (e.g. `// common_type.hpp` --> `// declval.hpp`), * cleans up and reformats the comments (to the style you used in `add_rvalue_reference.hpp`), * renames the include guard macro (`BOOST_TYPE_TRAITS_EXT_...` --> `BOOST_UTILITY_`). May I commit it? Regards, Michel

2 2

[algorithm] non-ascii characters in boyer_moore.hpp
by Michel Morin 30 Oct '12

30 Oct '12

Hi Marshall, `boost/algorithm/searching/boyer_moore.hpp` contains a non-ascii character ("–", en dash) at line 37: 36: Explanations: boostinspect:noascii (test tool complains) 37: http://en.wikipedia.org/wiki/Boyer–Moore_string_search_algorithm Would it be better to URL-encode the dash as "%E2%80%93" rather than relying on `boostinspect:noascii`? Regards, Michel

1 0

Re: [boost] [variant] awkward recursion
by Balazs Arva 29 Oct '12

29 Oct '12

At this moment I'm developing a json library with similar approach. With variant I think the only way this: typedef boost::make_recursive_variant < int, unsigned int, long, unsigned long, float, double, bool, const char*, std::string, boost::recursive_wrapper<std::map<std::string, boost::recursive_variant_>>, std::vector<boost::recursive_variant_>, std::nullptr_t >::type value; typedef std::vector<value> array; typedef std::map<std::string, value> object; I did not find any better solution. However there is still one problem: I do not want to write down every numeric POD in tmpl parameter list. It is a major problem because value a=(unsigned int)5; could not compile. Do you have any advice? I would like do something like this: typedef boost::make_recursive_variant < any_pod_numeric_type, bool, const char*, std::string, boost::recursive_wrapper<std::map<std::string, boost::recursive_variant_>>, std::vector<boost::recursive_variant_>, std::nullptr_t >::type value; Balazs Arva

1 0

Boost.Process 0.5: Minor update
by Boris Schaeling 28 Oct '12

28 Oct '12

I've uploaded a new version of Boost.Process 0.5 to <http://www.highscore.de/boost/process0.5/>: - search_path() added which was called find_executable_in_path() in previous versions (Windows implementation changed quite a lot) - shell_path() added which returns the absolute path to a shell executable - set_args() added which is an initializer to pass command line arguments as a collection (with automatic escaping) - Minor bug fixes There is one more update planned to somewhat mitigate remaining cross-platform differences. Please keep the feedback coming (here on the mailing list or by email)! Boris

1 0

Interesting article on stack-based TMP
by Julien Nitard 28 Oct '12

28 Oct '12

Hi All, That article came out of reddit C++ section: http://pubby8.wordpress.com/2012/10/15/stack-based-template-metaprogramming… It looks like TMP made easy (finally !). I am not that sure it is though and was wondering if anybody had any comments on it. Regards, Julien

9 20

[Boost-build] Turn on _GLIBCXX_DEBUG with <runtime-debugging>on (was: Trivial issues have been neglected.)
by Matthew Chambers 27 Oct '12

27 Oct '12

I'm forwarding this from the boost-build list to get a broader perspective from boost users and probably also some Boost.Build users that don't monitor that list. How many agree with Steven that for <variant>debug: "The libraries that are built need to be ABI compatible with code that isn't compiled using Boost.Build." How many would sacrifice ABI compatibility in order for <runtime-debugging>on to actually do something for GCC? Thanks, -Matt > (2012/10/17 0:09), Matthew Chambers wrote: >> On 10/15/2012 11:29 PM, Steven Watanabe wrote: >>> AMDG >>> >>> On 10/15/2012 07:54 PM, Kohei Takahashi wrote: >>>> Hi all, >>>> >>>> Can anyone handle following two issues? >>>> >>>> <runtime-debugging>on does nothing for libstdc++... >>>> https://svn.boost.org/trac/boost/ticket/4589 >>>> >>> >>> This is /not/ a trivial issue. It may be easy to do, but: > > I understood about this is not trivial issue and I changed the subject. > > >>> a) _GLIBCXX_DEBUG was broken last time I tried it a few years >>> ago. It won't work with all versions of gcc. >> >> I've used it with 4.1.2 and it helped a lot to track down some >> mysterious failures. > I don't know about old releases but recents seem to work well for me. > Indeed, expects to work well and should work with all versions of gcc > if define it by default. > >>> b) Anything the changes the ABI of the compiled libraries needs >>> careful consideration and must be documented. The libraries that >>> are built need to be ABI compatible with code that isn't >>> compiled using Boost.Build. >> >> Is it really that important that debug builds be ABI compatible >> between disparate builds? I think it's reasonable to EXPECT trouble >> when linking a debug build to precompiled libraries. That is >> certainly the case on Windows. > > <define> is not propagated feature, that means to trigger unexpected > link failure or ABI breaking. I think that using <runtime-debugging> > make safely rather than <define>. > I think it is better that provides propagated feature (as > <runtime-debugging> or another) for such purpose at least. > > >>> c) <runtime-debugging>on is part of <variant>debug, but I don't >>> think _GLIBCXX_DEBUG is a standard part of debug builds with >>> gcc. >> >> What is a "standard" debug build with gcc? Most people would >> probably say -g and -O0 but that doesn't provide any real debugging >> support. >> >> I agree it's not trivial, but having a no-op runtime-debugging >> feature is cringe-worthy. It's as good as admitting that GCC (or >> rather, libstdc++) doesn't provide any "official" runtime debugging >> support which is unfair. >> >> In the spirit of upcoming elections, count this as a vote for >> turning on _GLIBCXX_DEBUG. :)

5 4

Relationship of Boost libraries to TR1 and C++11
by Dave Abrahams 27 Oct '12

27 Oct '12

I don't suppose anyone has written up the specific differences between Boost libraries like regex, bind and shared_ptr and their TR1 and C++11 counterparts? It would be great if the maintainers of libraries that were accepted could add a FAQ about that. -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

1 0

BoostCon old videos
by Fernando Pelliccioni 27 Oct '12

27 Oct '12

Does anyone know where I can get the videos of previous years BoostCon? In particular I am looking for the following: "Cross-platform development with Qt and Boost" http://blip.tv/boostcon/joao-p-r-abecasis-cross-platform-development-with-q… Thanks and regards, Fernando Pelliccioni.

5 5

Fwd: Re: [system] symbol visibility and GCC vs. Clang
by Mathias Gaunard 26 Oct '12

26 Oct '12

-------- Original Message -------- Subject: Re: [system] symbol visibility and GCC vs. Clang Date: Tue, 23 Oct 2012 10:40:42 -0700 From: James Walker <jamesw(a)frameforge3d.com> Reply-To: boost-users(a)lists.boost.org To: boost-users(a)lists.boost.org CC: Mathias Gaunard <mathias.gaunard(a)ens-lyon.org> Newsgroups: gmane.comp.lib.boost.user References: <5085BABE.9030609(a)frameforge3d.com> <50868205.6070508(a)ens-lyon.org> On 10/23/2012 4:39 AM, Mathias Gaunard wrote: > On 22/10/12 23:29, James Walker wrote: >> When trying to link a bunch of libraries on OS X, I got this linker >> warning: >> >> ld: warning: direct access in >> boost::system::system_error::~system_error() to global weak symbol >> vtable for boost::system::system_error means the weak symbol cannot be >> overridden at runtime. This was likely caused by different translation >> units being compiled with different visibility settings. >> >> As far as I can tell, everything is compiled using the flags >> -fvisibility=hidden -fvisibility-inlines-hidden. >> >> I'm wondering whether the problem is that some of the libraries were >> built using gcc and some were built using Clang. In >> boost/system/system_error.hpp, the declaration of >> boost::system::system_error is decorated with BOOST_SYMBOL_VISIBLE. In >> boost/config/compiler/gcc.hpp, BOOST_SYMBOL_VISIBLE is defined to be >> __attribute__((visibility("default"))), whereas >> boost/config/compiler/clang.hpp does not define BOOST_SYMBOL_VISIBLE. > > This looks like a significant bug, POSIX-style symbol visibility doesn't > work with Clang. > Please file a ticket. OK, thanks. <https://svn.boost.org/trac/boost/ticket/7559> -- James W. Walker, Innoventive Software LLC <http://www.frameforge3d.com/>

2 1