- Boost - lists.preview.boost.org

Re: [boost] decay.hpp problem
by Tim Burgess 20 Nov '13

20 Nov '13

OK, Here's the output from the Log Navigator, showing how includes are being stacked. I've placed it at: https://dl.dropboxusercontent.com/u/29578720/Build%20log.rtf I noted the references to wxAny, which I was using for handling variants, but I've now replaced this with boost::any and I'm not including wxAny in any of my modules, despite the log seeming to implicate this class. Again, the new version of the code builds fine using VS2010, but fails using Xcode. Best wishes. Tim Burgess -----Original Message----- From: Steve Ramsey [mailto:steve@lucena.com] Sent: 18 November 2013 18:59 To: tim(a)raisedbar.net Subject: Re: [boost] decay.hpp - anonymous enum problem On Nov 18, 2013, at 7:37 AM, Tim Burgess <tim(a)raisedbar.net> wrote: > I'm pretty much a newbie when it comes to Xcode, so I've no idea how > to get you that trace - the Issue Navigator gives me no clues as to > what's including/calling decay.hpp. Any clues/links to reading > materials would be most welcome. I find the Log Navigator using the Assistant editor pane to be more flexible than the Issue Navigator when dealing with failed build detritus. So, from the Log Navigator, select your failed build. In the editor pane, you'll find an expandable list of build issues broken down by file. On the far right side of each file-level entry, there is a "show transcript" widget; popup text shows the internal command that was issued for the file and when it was issued. Clicking the widget will show a complete dump of the compiler/linker output for that particular command. It's also possible to right-click on any given issue entry and copy the transcript for either just the current issue or for the entire filtered list of issues. Steve

3 3

VC2013 1.55 beta failures
by Olaf van der Spek 19 Nov '13

19 Nov '13

Hi, Building 1.55 beta keeps failing on VC2013 RC. Trunk fails too IIRC. compile-c-c++ bin.v2\libs\date_time\build\msvc-12.0\debug\link-static\threading-multi\gregorian\greg_month.obj greg_month.cpp C:\VC\boost_1_55_0b1\boost/iterator/detail/facade_iterator_category.hpp(166) : error C2039: 'assert_not_arg' : is not a member of 'boost::mpl' C:\VC\boost_1_55_0b1\boost/mpl/eval_if.hpp(41) : see reference to class template instantiation 'boost::detail::facade_iterator_category_impl<CategoryOrTraversal,ValueParam,Reference>' being compiled with [ CategoryOrTraversal=boost::forward_traversal_tag , ValueParam=std::basic_string<char,std::char_traits<char>,std::allocator<char>> , Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> & ] C:\VC\boost_1_55_0b1\boost/iterator/detail/facade_iterator_category.hpp(193) : see reference to class template instantiation 'boost::mpl::eval_if<boost::detail::is_iterator_category<CategoryOrTraversal>,boost::mpl::identity<boost::forward_traversal_tag>,boost::detail::facade_iterator_category_impl<CategoryOrTra versal,ValueParam,Reference>>' being compiled with [ CategoryOrTraversal=boost::forward_traversal_tag , ValueParam=std::basic_string<char,std::char_traits<char>,std::allocator<char>> , Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> & ] C:\VC\boost_1_55_0b1\boost/iterator/iterator_facade.hpp(104) : see reference to class template instantiation 'boost::detail::facade_iterator_category<CategoryOrTraversal,ValueParam,Reference>' being compiled with [ CategoryOrTraversal=boost::forward_traversal_tag , ValueParam=std::basic_string<char,std::char_traits<char>,std::allocator<char>> , Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> & ] C:\VC\boost_1_55_0b1\boost/iterator/iterator_facade.hpp(620) : see reference to class template instantiation 'boost::detail::iterator_facade_types<Value,CategoryOrTraversal,Reference,Difference>' being compiled with [ Value=std::basic_string<char,std::char_traits<char>,std::allocator<char>> , CategoryOrTraversal=boost::forward_traversal_tag , Reference=const std::basic_string<char,std::char_traits<char>,std::allocator<char>> & , Difference=ptrdiff_t ] C:\VC\boost_1_55_0b1\boost/token_iterator.hpp(40) : see reference to class template instantiation 'boost::iterator_facade<boost::token_iterator<TokenizerFunc,Iterator,Type>,Type,boost::forward_traversal_tag,const Type &,ptrdiff_t>' being compiled with [ TokenizerFunc=char_separator_type , Iterator=std::_String_const_iterator<std::_String_val<std::_Simple_types<char>>> , Type=std::basic_string<char,std::char_traits<char>,std::allocator<char>> ] C:\VC\boost_1_55_0b1\boost/date_time/date_parsing.hpp(132) : see reference to class template instantiation 'boost::token_iterator<TokenizerFunc,Iterator,Type>' being compiled with [ TokenizerFunc=char_separator_type , Iterator=std::_String_const_iterator<std::_String_val<std::_Simple_types<char>>> , Type=std::basic_string<char,std::char_traits<char>,std::allocator<char>> ] C:\VC\boost_1_55_0b1\boost/date_time/gregorian/parsers.hpp(30) : see reference to function template instantiation 'date_type boost::date_time::parse_date<boost::gregorian::date>(const std::string &,int)' being compiled with [

13 52

Interesting variadic template trick
by Louis Dionne 19 Nov '13

19 Nov '13

Hi, As some might know, I'm currently working on a reimplementation of the MPL for C++11. In doing so, I came across a technique that I did not know of and I thought I would share my discovery with the community. If this is already well known, please excuse my ignorance. The goal is to implement fast compile-time conjunction and disjunction. It goes like this: template <typename ...T> void allow_expansion(T&&...); template <typename ...T> struct or_ { static constexpr bool value = !noexcept( allow_expansion((T::value ? throw : 0)...) ); }; That's it! Note that disjunction is easily obtained in a similar way. The benefit of this technique over traditional implementations is that it's several times faster according to my benchmarks. However, you might have noticed that short-circuit evaluation is not respected so the above technique is only suitable when short-circuit evaluation is not required. If you find this interesting, see [1] for a collection of similar techniques. The one I posted above seems to be the fastest with Clang and GCC. Regards, Louis Dionne [1] https://gist.github.com/ldionne/7522393

7 12

[git help] GitHub boostorg library authentication
by Beman Dawes 19 Nov '13

19 Nov '13

To test the modular boost docs I'm writing, I did this: git clone --recursive https://github.com/boostorg/boost.git modular-boost cd modular-boost ./bootstrap.sh ./b2 headers cd libs/system git checkout develop # did a simple edit of one file git commit -a -m "my bug fix" git push origin develop Everything ran as expected until the last step, which resulted in this: Username for 'http://github.com': That's a problem. Authentication needs to happen automatically. What steps did I miss? Thanks, --Beman

6 11

Re: [boost] Improving Documentation
by Andrew Hundt 19 Nov '13

19 Nov '13

On Thu, Oct 10, 2013 at 12:20 AM, Robert Ramey <ramey(a)rrsd.com> wrote: > Jeff Flinn wrote: > > On 10/9/2013 12:41 PM, Robert Ramey wrote: > >> Daryle Walker wrote: > >>>> From: ramey(a)rrsd.com > > I wish this thread had come up 3-4months ago. Unlike you I couldn't > > grok the docs to use multi-array as a back end to a Qt table where I > > needed > > to support run time row/col insertion/deletion. I was under time > > constraints and found it much easier to build my own facilities. I'm > > not sure whether it was due to docs or design. > > Well, I did come to understand it pretty well. But I really have to > say I spent a LOT of time poring over the documentation, experimenting > etc. The oddest thing to me is that now it seems easy to me and I > can't figure out what I spent the time on - we're talking a few days. > I had the same experience (only worse) with units library. Actually > I have this experience with almost every boost library I use. This > brings up the whole question of documentation of boost libraries > and in fact documentation of computer libraries in general. I've spent > a lot of time thinking about this lately. I feel we've been too lax in > accepting libraries after the review whose documentation isn't up > to some minimum standard (not that we have a standard). > > Robert Ramey > +1 Every boost library I've used has been great once I've understood it. However, I have trouble getting some very smart people on my team to use existing boost tools because they find it confusing, and they also have a tough time finding the functionality they need. I believe this is a documentation problem. For example, a number of people I know were surprised when I told them that the /libs folder contains examples and unit tests for every library. The documentation doesn't seem to consistently provide links and explanations of each. I believe I spent months as a user before I found the libs folder. I'll take boost.container.static_vector, as an additional example. I contributed to it so it seems like a decent choice. Here are the two most easily accessible links in Boost.Container for documentation of static_vector: http://www.boost.org/doc/libs/1_54_0/doc/html/container/non_standard_contai… The first link contains the first block of text about static_vector I expect one would run into, and there isn't even a link to the class documentation! http://www.boost.org/doc/libs/1_54_0/doc/html/boost_container_header_refere… This second link is the typical header documentation throughout boost. When I first started using boost it was months before I realized that in these header synopsis I could click on the words of the class to see the full documentation of that class, in this case "static_vector". Much of the time I just felt confused and lost. I think this is indicative of a layout and user interface that needs some improvement. Now, perhaps I should blame myself for this in the static_vector case and fix it, but it is indicative of the general documentation problems. One example of C++ documentation I have found that I've actually been happy with is cppreference.com. If you look at their front page they have many of the major classes, and with one click you are in there reading what you want to know, with examples at the bottom of every page. It is actually entertaining that they mention boost documentation in their FAQ as follows: Why is the material here limited to the standard C and C++? > In short, we chose quality over quantity. Some boost libraries<http://www.boost.org/> could > also be candidates for inclusion though. While their tutorials are very > good, the *reference* documentation is often very inflexible and > inconvenient. So, is there anything we can do about it? I remember a couple of years ago Boost had a "Bug Sprint" with the goal of closing lots of open tickets. Perhaps we should do a "documentation sprint"? Here is an interesting article about writing good documentation that also contains links to other solid articles that I recommend checking out: http://stevelosh.com/blog/2013/09/teach-dont-tell/ Cheers! Andrew Hundt

13 63

[git] [modular boost] Switchover schedule proposal
by Beman Dawes 19 Nov '13

19 Nov '13

The showstoppers other than documentation have been cleared from the conversion issues list. That includes the issues blocking documentation, so doc work is underway again. The 1.55 release is scheduled for November 4, and as of the moment it doesn't look like that will sip much if at all. I'm assuming that we want to reopen svn branches/release for a week or so after 1.55 ships as some developers would like to merge pending changes to branches/before the switchover. That would mean an actual switchover starting about November 11. It seems to me we need approximately a week after svn is made read-only and the final conversion run is done to verify the correctness of the conversion. During that time it seems to me that it would be unwise for developers to make git commits since if a serious problem was discovered we might decide to rerun the conversion process, wiping out the git repos. At that point (roughly November 18, we would go totally live and developers could resume their work, now using git and modular boost. Comments, --Beman

10 33

concept_check() fails for types from unnamed namespace on gcc 4.2.3
by Adam Romanek 19 Nov '13

19 Nov '13

Dear Boosters! I already posted this message to boost-users lists last week but I got no response. So here we are. I have a problem compiling some source code that uses Boost 1.54 and gcc 4.2.3 (it's a toolchain for a MIPS platform but that's irrelevant). Basically there is a problem with checking concepts on types that come from unnamed namespaces. See the attached code example and compiler error message. Note that the same code compiles without any problems on gcc 4.6.3. I've found a question on boost-dev list [1] and a ticket [2] related to this particular issue. Note that the ticket was closed with "worksforme" resolution, which I don't understand - the problem is still out there. Now since Boost's minimal requirements are gcc 3.3 [3] then should I consider it a bug that I should report or is it a known issue? In case the latter is true then what should I do? [1] http://boost.2283326.n4.nabble.com/concept-check-fails-with-types-declared-… [2] https://svn.boost.org/trac/boost/ticket/2037 [3] http://www.boost.org/users/history/version_1_55_0.html WBR, Adam Romanek

3 2

[asio] How to initialize a strand
by Kyle Ketterer 19 Nov '13

19 Nov '13

Hello, I am just curious - how you can you initialize an strand via assignment? I am passing an strand by reference to an object so I have a reference variable declared: boost::asio::io_service::strand & strand_; In the constructor I would like to assign the reference variable an io_service (which has also been passed by reference). I would like to initialize strand_ in a way such as this ( I know it doesn't work) strand_ = boost::asio::io_service::strand(io_service_); Any ideas? Thanks

2 2

New Windows Build of 1.55.0
by Tom Kent 19 Nov '13

19 Nov '13

The previous build of 1.55.0 did not build with the correct zlib version (and thus the correct sub-library of iostreams did not build). I have created a 1.55.0-build2 directory on the sourceforge page with the updated version. I've also added a note to the 1.55.0/README.md file explaining that it is incomplete, but I did not remove the prior build. http://sourceforge.net/projects/boost/files/boost-binaries/1.55.0-build2/ Tom

1 0

decay.hpp - anonymous enum problem
by Tim Burgess 18 Nov '13

18 Nov '13

Hi, I have a project for Windows/Mac that builds fine using VS2010, but generates errors when I build using Xcode 4.6 with the Apple-provided GCC 4.2 compiler (required, as this project also uses wxWidgets). All of my own modules compile cleanly, but I get the following error output: SurfaceReader Group /users/tim/developer/libraries/boost_1_54_0/boost/type_traits/decay.hpp /users/tim/developer/libraries/boost_1_54_0/boost/type_traits/decay.hpp:28: '<anonymous enum>' is/uses anonymous type /users/tim/developer/libraries/boost_1_54_0/boost/type_traits/decay.hpp:28: Trying to instantiate 'template<class T> struct boost::remove_reference' /users/tim/developer/libraries/boost_1_54_0/boost/type_traits/decay.hpp:38: '<anonymous enum>' is/uses anonymous type /users/tim/developer/libraries/boost_1_54_0/boost/type_traits/decay.hpp:38: Trying to instantiate 'template<class T> struct boost::remove_reference' I realise that I haven't provided the command that Xcode is using to build the project - this isn't deliberate, but I can't seem to locate where Xcode provides this on-screen using the VoiceOver accessibility tool (I'm a totally blind developer). I don't include decay.hpp directly in any of my modules, but further research turned up: https://svn.boost.org/trac/boost/ticket/6362 If I can find the anonymous enum within the files included within decay.hpp I can patch it by providing a tag for the enum and I believe that this will rectify the issue. Can anybody point me at the appropriate file, or have I got to plough through the lot? I initially discovered this issue in Boost 1.54.0, but I can also reproduce it using 1.55.0. Many thanks in advance. Best wishes. Tim Burgess

3 4