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

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

14 Oct '13

On Fri, Oct 11, 2013 at 2:49 PM, Robert Ramey <ramey(a)rrsd.com> wrote: > Mathias Gaunard wrote: > > On 11/10/13 15:31, TONGARI J wrote: > > > >> I think Doxygen is fine for "regular" libraries, but I always have a > >> question: how could a library like Spirit be doucumented with it? > > > > Same as any other library. > > You document the data types and the functions. > > what about the type constraints - aka concepts? > and templates? You can document template parameters with doxygen. If you are using the boost concept check library you can also use those classes to document your concepts. I believe gil does that if you would like an example. You can also always add custom fields fairly easily if none of the existing ones meet you needs. Cheers! Andrew Hundt

5 5

[config][release] Release notes for old compilers.
by Daniel James 14 Oct '13

14 Oct '13

Hi, I added a little release notes for config, and also a note about removing support for older compilers in the future. If this concerns you, please give it a quick check and let me know if you want any changes. This release note is not a promise that future changes will or won't be made, and it can be changed if appropriate. Sorry that this is a bit late. We can still change the release notes after the beta (and final) release, so don't worry about that. thanks, Daniel

5 12

Review request: Require a SFINAE capable compiler
by Stephen Kelly 14 Oct '13

14 Oct '13

Hello, Several of the ancient compilers define BOOST_NO_SFINAE. The attached patch removes support for those versions of the compilers which are not capable of SFINAE. This bumps the compiler requirement to remove support for Borland 5.x, Metrowerks prior to 9.0, and SunPro prior to 5.7. Compilers based on EDG 238 are also affected, though it is unknown what those are. Ok to commit? Thanks, Steve.

6 12

[compiler workaround] Are we purging history?
by Daryle Walker 14 Oct '13

14 Oct '13

As I understand it, the people modernizing Boost code by getting rid of old compiler workarounds are doing two things: 1. Remove the workaround macro flags and the code that uses them, leaving the code that doesn't use the workarounds behind. 2. Purging those workaround macros from Boost.Config. If we are doing [2], why? Doing [1] is sufficient for modernization. Doing [2] is just purging history that we spent blood/sweat/tears generating. Authors/maintainers generally have free reign to use as many or as few workarounds as they want. They can't do that if we're deleting that knowledge from Boost.Config. Daryle W.

3 2

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

14 Oct '13

On Thu, Oct 10, 2013 at 4:29 PM, Mathias Gaunard < mathias.gaunard(a)ens-lyon.org> wrote: > > Documentation like this is generated by preprocessing Doxygen XML output > to integrate it into Boostbook and have a good look for C++ references. > It has most of what you can expect from Doxygen + the Boostbook stuff > which gives better cross-referencing than simple Doxygen. > > I personally don't understand how one cannot notice that the blue bits > that become underlined when you hover them and change colors once visited > are hyperlinks (especially since that's also true for any other hyperlink > in Boost docs and most of the World Wide Web). > What do you suggest would be better? 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#heade… - The following words are blue: - namespace, template, bool, struct, capacity, template, typename, allocator, class, fixed_sized, queue, spec_queue, stack - Out of those, the following are links: - fixed_sized, capacity, allocator, queue, spec_queue, stack I believe there is a word to describe the concept of building things such that people expect to interact with them. I think it is called an affordance, so a link should "afford" clicking. https://en.wikipedia.org/wiki/Affordance When it is your first time ever on the site, even if you try to hover over one of the blue words, you may choose one that can't be clicked on, then assume the same applies for the others. IMHO, changing the color of links or making the underlines always visible could be helpful. One possible improvement would be what Mario Mulansky described. In the Table of Contents of libraries the Reference section could contain a list of links to headers, classes, functions, metafunctions, and definitions. Then if you click to the reference link where it currently just lists headers it could also provide the synopsis of the aforementioned items and links to the detailed docs. Right now all of the documentation is an extremely deep hierarchical structure, which if I recall my conventions correctly has been moved away from in modern user experience design. Most websites try to focus on getting you to the information you need in as few clicks as possible. That is why I mentioned cppreference.com in my previous email, if you check out that site nearly everything is 3 levels deep or less. Since boost is so much larger a total of 4 levels with the top one being the list of libraries would make sense. Some link to the libs unit test and/or example folders in each library would also be helpful. These are a couple small, concrete steps that would probably help with browsing but aren't too out there. It doesn't help some of the possibilities for improved text which could also benefit, but it does help many things at a high level. As a side note, I wonder if the boost main page could be better served as a wiki of some sort? Cheers! Andrew Hundt

3 2

[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