- Boost - lists.boost.org

[typeof] trunk build broken
by Agustín K-ballo Bergé 12 Oct '13

12 Oct '13

Boost.TypeOf is broken as of revision #85920 due to an invalid preprocessing directive. Patch attached. Regards, -- Agustín K-ballo Bergé.- http://talesofcpp.fusionfenix.com

3 3

Re: [boost] Improving Documentation
by Andrew Hundt 12 Oct '13

12 Oct '13

On Friday, October 11, 2013, Mathias Gaunard wrote: > On 11/10/13 00:07, Andrew Hundt wrote: > > I believe part of the problem is that everything is blue. For instance, on >> the boost.lockfree page: >> >> http://www.boost.org/doc/libs/**1_54_0/doc/html/lockfree/** >> reference.html#header.boost.**lockfree.policies_hpp<http://www.boost.org/doc/libs/1_54_0/doc/html/lockfree/reference.html#heade…> >> >> >> - The following words are blue: >> - namespace, template, bool, struct, capacity, template, typename, >> allocator, class, fixed_sized, queue, spec_queue, stack >> > > It's clearly not the same shade of blue though. The links (capacity, > allocator, fixed, queue, spec_queue, stack) are closer to a greenish blue. > Do they appear difficult to distinguish to you? > > Maybe the color palette could be changed. It isn't just me. I believe two others in this email chain mentioned it took them a while to figure out too, and I have had to explain it to other users who are not on this list. The shades certainly don't "pop" and it could just be more syntax highlighting. There isn't anything distinguishing it a a link when you just look at the page and imagine not already being familiar with this documentation layout. Doxygen and other documentation tools don't really have anything like it. > > Some link to the libs unit test and/or example folders in each library >> would also be helpful. >> > > I agree for examples, but I don't think unit tests should appear in the > documentation. > > They can be obscure test cases that users don't need to worry about. > Yeah, it would be great if everything had micro examples at the bottom of each page but often the only thing that exists is a unit test. While it isn't a great situation it would be better than nothing. Cheers! Andrew Hundt

2 1

[type_traits] Variadic function pointer with __fastcall calling convention
by Edward Diener 12 Oct '13

12 Oct '13

In type_traits/detail/is_function_ptr_tester.hpp there are pointer to function signatures being tested which have the __fastcall calling convention and variadic functions. While MSVC accepts this code clang in Windows, which defines _MSC_VER and _MSC_EXTENSIONS, currently gives an error. The justification for giving an error is that __fastcall is a callee stack cleanup calling convention, so it cannot be used for variadic functions. There is a bug report regarding this in the Bugzilla for llvm at http://llvm.org/bugs/show_bug.cgi?id=12535. Comments have been made to me in e-mail and the clang developer's mailing list that it is a type_traits error to allow this, even for MSVC-emulation code. Of course we can temporarily fix this for clang on Windows, possibly with a BOOST_WORKAROUND solution for clang and see if/how clang eventually addresses the bug report. But I would like some sort of resolution so that clang on Windows can compile type_traits in the current Boost trunk.

3 11

[1.55.0] Beta 1 Available
by Marshall Clow 12 Oct '13

12 Oct '13

Boost release 1.55.0 beta 1 is now available from SourceForge See http://sourceforge.net/projects/boost/files/boost/1.55.0.beta.1/ This release contains 1 new library: * Predef: This library defines a set of compiler, architecture, operating system, library, and other version numbers from the information it can gather of C, C++, Objective C, and Objective C++ predefined macros or those defined in generally available headers, from Rene Rivera. For details of what's in the release, see http://www.boost.org/users/history/version_1_55_0.html. Note that the links to files on this web page are for the final release - use the SourceForge link above to get the beta files. Please download the beta, give it a try, and report any problems you encounter. Thanks, -- The Boost Release Team

6 11

results pages not updating
by Michael Mathews 11 Oct '13

11 Oct '13

Neither the trunk nor release results have updated since Wednesday michael

1 0

[1.55][Math] Permission to apply bug fix?
by John Maddock 11 Oct '13

11 Oct '13

Is 1.55 release branch open for bug fixes again? If so I'd like to apply the patch for: https://svn.boost.org/trac/boost/ticket/9183 in https://svn.boost.org/trac/boost/changeset/86205 Many thanks, John.

2 1

Looking for thoughts on a new smart pointer: shared_ptr_nonnull
by Luke Bradford 11 Oct '13

11 Oct '13

Hi, I'm new to this list, so apologies for any oversights or faux pas. I've been finding a lot of use for a type of smart pointer I call shared_ptr_nonnull, which is a variation on shared_ptr which is never allowed to be empty. Specifically: (1) It doesn't have reset() with no arguments, doesn't have a default constructor, and doesn't have implicit conversion to bool (which would always be true.) (2) It throws an exception whenever there's an attempt to make it empty, i.e. in constructors, reset, assignment, and swap. For convenience, it's implicitly convertible to shared_ptr, and I have all of shared_ptr's templated operators implemented with possible combinations of shared_ptr and shared_ptr_nonnull. Usually it can be used just by changing the type of a shared_ptr. We have a lot of shared_ptrs, especially member variables, which are claimed to be "always valid" and this class enforces that, at compile time (1) and runtime (2). Has there been any discussion of something like this? Does anybody have any thoughts, suggestions, criticisms? Who's in charge of the smart pointer library these days? Thanks, Luke

20 113

Review wizards response and Boost reviews
by Edward Diener 11 Oct '13

11 Oct '13

I tried to contact the review wizards via their e-mail addresses to update some information on the Boost Formal Review Schedule page at http://www.boost.org/community/review_schedule.html but have heard nothing in response. I appreciate that they have a hard job to do for which most people would not want the responsibility. But it does seem to me, either by plan or because there appear to be no people willing to act as review managers, that the Boost formal review process has completely bogged down for some time now. Since I am interested in getting my own library reviewed I would like to volunteer to act as a Review Manager for other libraries. I have no particular library in mind but I am pretty knowledgeable and interested in some of the ideas of libraries on the review schedule. I have been a Review Manager for a past library and think I did a pretty good job. At the same time I am looking for a review manager for my Variadic Macro Data library. Unfortunately the link to it on the web page above is wrong. It is now on GitHub at https://github.com/eldiener/variadic_macro_data. Edward Diener

2 4

libs/context/src/asm/make_i386_sysv_elf_gas.S:37: Error: junk at end of line
by Frédéric Bron 11 Oct '13

11 Oct '13

Hello, When building with i686-w64-mingw32 cross compiler, this is what I get: libs/context/src/asm/make_i386_sysv_elf_gas.S: Assembler messages: libs/context/src/asm/make_i386_sysv_elf_gas.S:37: Warning: .type pseudo-op used outside of .def/.endef ignored. libs/context/src/asm/make_i386_sysv_elf_gas.S:37: Error: junk at end of line, first unrecognized character is `m' libs/context/src/asm/make_i386_sysv_elf_gas.S:77: Warning: .size pseudo-op used outside of .def/.endef ignored. libs/context/src/asm/make_i386_sysv_elf_gas.S:77: Error: junk at end of line, first unrecognized character is `m' libs/context/src/asm/make_i386_sysv_elf_gas.S:80: Error: junk at end of line, first unrecognized character is `-' ...failed gcc.compile.asm bin.v2/libs/context/build/gcc-mingw-4.8.1/debug/address-model-32/link-static/target-os-windows/threadapi-win32/threading-multi/asm/make_i386_> What does that mean? Frédéric

2 4

[type_traits] VC++ and vararg function/mmeber functions and varargs
by Edward Diener 10 Oct '13

10 Oct '13

After going back and for with Mr. Lavavej from Microsoft about how VC++ treats functions/member functions which have varargs parameters and calling conventions, I learned that VC++ always treats all these function types as if the calling convention is __cdecl, no matter what the end-user specifies. Therefore attempting to match function and member function types taking varargs, with VC++ and compatibles, by having to specify __cdecl, __fastcall, and __stdcall calling conventions for every function/member function declaration with varargs, is a waste since these are not potential new types being tested by templates but just the same type redeclared. These occur in type_traits/detail files is_mem_fun_pointer_tester.hpp and is_mem_fun_pointer_tester.hpp when BOOST_TT_TEST_MS_FUNC_SIGS ( essentially _MSC_EXTENSIONS) is defined. I would like to remove these redundant declarations from these files. I have made sure that my tests for VC++ pass. I will test Intel C++, if it also emulates VC++ in this way. Can I make the change on trunk to these files once I ascertain that Intel C++ tests with type_traits also pass with this change ? Are there any other VC++ emulation compilers that need to be tested ?

4 11