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

New Stepanov lecture videos released by A9
by Mat Marcus 02 Nov '12

02 Nov '12

http://www.youtube.com/user/A9Videos/videos?flow=grid&view=1

1 0

[string_algo] Documentation Complaint
by Dave Abrahams 02 Nov '12

02 Nov '12

Wow, I found this documentation hard to use! I wanted to translate various 1-character substrings into new strings, e.g. translate the TAB character ('\t') to its textual escaped representation "\\t", and I went looking for an algorithm to do it. After 5 minutes of searching, I *think* the algorithm isn't there, but I'm still not sure. I nearly went blind (well, not really, but it felt that way) looking at http://www.boost.org/doc/libs/1_51_0/doc/html/string_algo/reference.html#he… because there's no vertical whitespace. More importantly, there's *no description of what any of these algorithms actually do*! ... calming down ... Heh, very terse descriptions are in the "Quick Reference": http://www.boost.org/doc/libs/1_51_0/doc/html/string_algo/quickref.html These might be good enough for me, but I always figure I'm going to get complete detail from the non-quick reference, and this one is just a dump of all the declarations, so I had to go around in a big circle and begin writing this documentation complaint before I found it. Can this situation be improved? -- Dave Abrahams BoostPro Computing Software Development Training http://www.boostpro.com Clang/LLVM/EDG Compilers C++ Boost

2 2

[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

Re: [boost] make_shared_array and allocate_shared_array
by Glen Fernandes 01 Nov '12

01 Nov '12

On Thu Nov 1 2012 at 1:48 PM, Olaf van der Spek <ml(a)vdspek.org> wrote: > Does Glen's make_shared_array have variants for both initialized and uninitialized allocations (for builtin types)? Hi Olaf, I just updated the code to only have initialization for non POD types: https://github.com/glenfe/glenfern/commit/05ea1f429bddfe7f07e4bb392db248492… Glen

1 0

Review: Code Review: allocate_shared_array and make_shared_array
by Glen Fernandes 01 Nov '12

01 Nov '12

A big thank you to Peter Dimov who has been kind enough to review my code. The open question we both have is whether these functions should continue to return shared_ptr<T> or be changed to return shared_array<T> after some modification to shared_array (both to support construction from (or conversion to) a shared_ptr and to have things like a no-throw constructor). Updated code: https://github.com/glenfe/glenfern/tree/master/boost Original blog post: http://glenfernandes.wordpress.com/ Some context from our discussion: Peter Dimov wrote: > Providing two separate sets of functions doesn't appeal to me much. > make_shared_array should return whatever we decide they should return. You > are right about shared_array's default constructor though, and maybe we can > use this opportunity to fix it (and add move support), and perhaps provide a > way for people to get a shared_ptr from a shared_array, if they have to work > with other people who only use that in their APIs. :-) > > Let's see what the Boost list will say. > > Glen Fernandes wrote: > > 1. I keep the functions returning shared_ptr but rename them to > > allocate_shared_sequence and make_shared_sequence. I think they are still > > useful for people who would want to avoid shared_array in their APIs for > > various reasons (e.g. its default constructor can throw). > >

1 0