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

[pointee] partially specialize for pointer types?
by Jeffrey Lee Hellrung, Jr. 14 Oct '12

14 Oct '12

Right now, boost::pointee<T*> is evaluated to T via evaluation of boost::detail::is_incrementable<T*>. Unfortunately, this causes a hard error when T is incomplete. See [1] for motivation on why this might be undesirable. It seems there's no loss in partially specializing boost::pointee for pointer types to allow it to be used for incomplete types. Ditto for boost::indirect_reference. Are there issues with this that I might be missing? As both pointee and indirect_reference seem to fall under the purview of Boost.Iterator, I would take responsibility of making this change and adding appropriate unit tests for the incomplete type case. - Jeff [1] https://svn.boost.org/trac/boost/ticket/5965

1 0

Terminology check.
by Larisse Voufo 14 Oct '12

14 Oct '12

Hello -- What would happen to be the C++ word for: name lookup + overload resolution? I would have thought it was "name resolution", but the standard seems to be suggesting otherwise. Thanks, -- Larisse.

2 1

[iterator] [documentation] need help generating
by Jeffrey Lee Hellrung, Jr. 13 Oct '12

13 Oct '12

I'm a n00b regarding Boost's documentation generation. I've gone through https://svn.boost.org/trac/boost/wiki/BoostDocs/GettingStarted to set up my system (Windows 7, MSVC9, try to do everything from the Windows command line). I then navigate to trunk\libs\iterator\doc and run b2 (the b2 I have from the 1.51.0 release; would that matter?). I get -------- don't know how to make <p..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi-object(xinclude-scanner)@987>iterator.xml ...found 37 targets... ...updating 5 targets... ...can't find 1 target... ...can't make 2 targets... common.mkdir ..\..\..\bin.v2\libs\iterator\doc common.mkdir ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0 common.mkdir ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug common.mkdir ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi quickbook.quickbook-to-boostbook ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi\iterator.xml Generating Output File: ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi\iterator.xml quickbook\iterator.qbk:24: warning: Quickbook version undefined. Version 1.1 is assumed quickbook\concepts.qbk:159: warning: line breaks generate invalid boostbook (will only note first occurrence). quickbook\facade.qbk:491: warning: in column:6, unexpected character: ` [...lots more warnings of this nature...] quickbook\facade.qbk:612: warning: in column:52, unexpected character: ` quickbook\utilities.qbk:77: warning: in column:14, unexpected character: ` quickbook\utilities.qbk:77: warning: in column:44, unexpected character: ` quickbook\utilities.qbk:79: warning: in column:12, unexpected character: ` quickbook\utilities.qbk:79: warning: in column:15, unexpected character: ` quickbook\utilities.qbk:109: warning: in column:14, unexpected character: ` quickbook\utilities.qbk:109: warning: in column:46, unexpected character: ` ...skipped <p..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi>iterator.docbook for lack of <p..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi-object(xinclude-scanner)@987>iterator.xml... ...skipped <phtml>standalone_HTML.manifest for lack of <p..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading-multi>iterator.docbook... ...skipped 2 targets... ...updated 6 targets... -------- Then I run it again: -------- ...found 37 targets... ...updating 2 targets... xslt-xsltproc.windows ..\..\..\bin.v2\libs\iterator\doc\msvc-9.0\debug\threading -multi\iterator.docbook xslt-xsltproc-dir.windows html\standalone_HTML.manifest Error: no ID for constraint linkend: indirecct. ...updated 2 targets... -------- This seems to throw everything into trunk\libs\iterator\doc\html. However, these generated html documents don't seem to be the same as those in the Boost releases. For example, the table of contents is deeper in the generated index.html than the 1.51.0 release one (which looks be identical to trunk/libs/iterator/doc/index.html), and it lacks documentation for function_input_iterator. It seems like I'm doing something wrong, and I'm not really sure what to make of the various errors and warnings I'm getting. Would anyone be kind of enough to help me out here? Oh, my user-config.jam file, located in "C:/Users/Jeffrey/", looks like -------- using xsltproc : C:/Users/Jeffrey/boost-tools/libxslt-1.1.26.win32/bin/xsltproc.exe ; using boostbook : C:/Users/Jeffrey/boost-tools/xml/docbook-xsl-1.77.1 : C:/Users/Jeffrey/boost-tools/xml/docbook-xml-4.2 ; using quickbook : %BOOST_ROOT%/dist/bin/quickbook ; -------- BOOST_ROOT refers to my Boost 1.51.0 installation, and C:/Users/Jeffrey/boost-tools/bin is part of my path. Let me know if other information is needed. TIA, - Jeff

2 3

[addressof] Intel C++ 13 Warning (Cannot be suppressed)
by Joshua Boyce 13 Oct '12

13 Oct '12

addressof.hpp causes a warning under Intel C++ 13 when using the highest warning level, which cannot be suppressed using the regular #pragma directives. This causes problems when compiling user code with warnings as errors, as the header causes an error which cannot be disabled. The root of the issue seems to be that ICC thinks that an rvalue is being passed to a function which takes a non-const ref, however in this case I think it's a false positive (ICC apparently isn't smart enough to notice and analyze the implicit conversion operator). My simple workaround is to turn the temporary into an lvalue and pass that instead. After making this change I tested under MSVC 12, GCC 4.7, ICC 13, and Clang 3.1 (all under Windows) and recorded no changes in number of failed compiles or tests. Is this an acceptable change that could be merged into trunk? Thanks.

1 1

[contract] toward N3351 concepts
by Lorenzo Caminiti 13 Oct '12

13 Oct '12

Hello all, I'm reading N3351: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3351.pdf It's a bottom-up approach to define concepts starting from what's needed by STL algorithms. So far so good--I like it probably more than C++0x concept proposals--N331 is simpler :) However, N3351 STL design is not fully compatible with the current STL specifications--maybe N3351 is better, more mathematically sound? In N3351, concepts are boolean constants: ``We can define concepts as simple (constant) Boolean expressions. This is useful when building constraints predicated on non-syntactic and non-semantics properties of types.`` So I can implement concepts in C++11 as boolean meta-functions using expression SFINAE to check the requirements and enable_if to disable generic algorithms when the instantiated types don't model the concepts (i.e., the concept's boolean meta-function is false). For example, that's the case for the bool{a== b} and bool{a!=b} expressions of the EqualityComparable concept below. However, N3351 says that axioms should not be checked by the compiler... ``Axioms express the semantics of a concept’s required syntax; they are assumed to be true and must not be checked by the compiler beyond conformance to the C++ syntax. Any additional checking is beyond the scope of the compiler’s translation requirements. The compiler must not generate code that evaluates axioms as preconditions, either. This could lead to program errors if the evaluated assertions have side effects. For example, asserting that distance(first, last) > 1 when the type of those iterators is istream_iterator will consume the first element of the range, causing the assertion to pass, but the algorithm to have undefined behavior.'' So what am I supposed to do with axioms? Do nothing? Axioms are just "comments" that document the semantic? For example: `` concept EqualityComparable<typename T> = requires (T a, T b, T c) { bool { a == b }; bool { a != b }; axiom { a == b <=> eq(a, b); } // true equality axiom { a == a; // reflexive a == b => b == a; // symmetric a == b && b == c => a == c; // transitive } axiom { a != b <=> !(a == b); } // complement }; So, EqualityComparable<T> is true if T 1. has == and != with result types that can be converted to bool 2. == compares for true equality 3. == is reflexive, symmetric, and transitive 4. != is the complement of == However, the compiler can only check the first of these conditions. The rest must be verified through other means (i.e. manually). '' Thanks, --Lorenzo

16 82

Re: [boost] Boost CRC maintainer (Daryle Walker) missing in action?
by Olaf van der Spek 13 Oct '12

13 Oct '12

On Sat, Mar 10, 2012 at 2:06 PM, Olaf van der Spek <ml(a)vdspek.org> wrote: > On Mon, Nov 28, 2011 at 1:11 AM, Daryle Walker <darylew(a)gmail.com> wrote: >> I can look at it once I've finished my new setup. >> >> I had to reset my computer after a partial crash years ago. I never >> got around to recreating my programming setup. My computer had been >> at its maximum Operating System level back then, which is now 3 >> versions behind. For the past few months, I've had my sister's old >> laptop, with Windows Vista, and am trying to add a programming setup >> to it now. > > Hi Daryle, > > Any updates on these two? > > https://svn.boost.org/trac/boost/ticket/3030 > https://svn.boost.org/trac/boost/ticket/5970 Mr Walker? Have you gone missing in action again? :( -- Olaf

1 0

[1.52] compile errors with xcode / apple llvm 4.1
by Jochen Wilhelmy 13 Oct '12

13 Oct '12

Hi! Had anybody success in compiling an own project that uses boost with xcode 4.5.1 / apple llvm 4.1? I get this error: In file included from /Users/jwilhelmy/Coding/Install/include/boost/type_traits.hpp:35: In file included from /Users/jwilhelmy/Coding/Install/include/boost/type_traits/has_operator.hpp:42: In file included from /Users/jwilhelmy/Coding/Install/include/boost/type_traits/has_post_decrement.hpp:34: .../boost/type_traits/detail/has_postfix_operator.hpp:143:109: error: expected expression BOOST_STATIC_CONSTANT(bool, value = (sizeof(check(((make<Lhs>() BOOST_TT_TRAIT_OP),make<has_operator>())))==sizeof(::boost::type_traits::yes_type))); ^ .../boost/config/suffix.hpp:392:72: note: expanded from macro 'BOOST_STATIC_CONSTANT' # define BOOST_STATIC_CONSTANT(type, assignment) static const type assignment ^ -Jochen

1 0

build err Boost 1.51.0 for PPC64 - is this a real error?
by david.hagood＠gmail.com 12 Oct '12

12 Oct '12

I have a reproducible error attempting to build Boost 1.51.0 for a PPC64 system: libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S:225: Error: syntax error; found `@', expected `,' libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S:225: Error: junk at end of line: `@plt' libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S:249: Error: syntax error; found `@', expected `,' libs/context/src/asm/fcontext_ppc64_sysv_elf_gas.S:249: Error: junk at end of line: `@plt' I've seen one other person report this online, but I've seen no follow-ups. 1) Is this a known issue in 1.51.0? 2) Is there a patch? 3) Should I try the 1.52.0 Beta instead? I'd rather not spend all the time building it to find there is an issue. I have 1.51.0 for PPC32, i686, X86_64, and ARM - it's just the PPC64 that fails.

2 2

Augmented trees
by Phil Endecott 12 Oct '12

12 Oct '12

Dear Experts, I find myself in need of an augmented tree. My problem is something like [but not exactly] this: - Say I have a line of text, i.e. a sequence of characters, in a variable-width font; each character stores its width in pixels. - I need to efficiently insert and remove characters. - I need to efficiently find the range of characters that spans a given range of pixels. It seems to me that an augmented tree lets me do all of those operations in log(N) time - and no other data structure offers the same performance. I'm aware of two augmented trees that have been proposed here. Francisco Jose Tapia has proposed "Countertree", but this only stores the count of elements not the sum of a property of the elements (i.e. the widths in my example). Vadim Stadnik has proposed stl_ext_adv, which is a doubly-augmented B+ tree. Has anyone looked at Vadim's code since it was proposed last year? I have a couple of concerns about Vadim's proposal: 1. It uses B+ trees, and in the discussion it was suggested that these are inferior to red-black trees in some way. 2. In order to get the property to be accumulated (i.e. the widths in my case) it requires that arithmetic can be done on the stored type itself; this is fine for e.g. a sequence of ints, but if the stored type is a struct it is necessary to add various "unnatural" operator overloads. I think I would prefer it to have some sort of user-supplied accessor to get the property to be accumulated. Is there any other work that I've overlooked? Is there a "friendly" red-black tree implementation somewhere that could be augmented relatively easily? Regards, Phil.

8 9

[1.52.0] Beta1 release available
by Daniel James 11 Oct '12

11 Oct '12

Boost release 1.52.0 beta 1 is now available from SourceForge See https://sourceforge.net/projects/boost/files/boost/1.52.0.beta.1/ This release contains numerous enhancements and bug fixes for existing libraries. For details of what's in the release, see http://www.boost.org/users/history/version_1_52_0.html. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

4 8