- Boost - lists.boost.org

[Context] Compile Broken for MSVC under x64 (r77477 Trunk)
by Joshua Boyce 23 Mar '12

23 Mar '12

r77477 has broken compilation of Boost.Context on trunk for me when using MSVC and targeting x64 (it spits out a "platform not supported" error). I believe this is because MSVC does not define any of the preprocessor directives that are being checked now (instead of _WIN64). I believe the fix for this is to check _M_AMD64 and/or _M_X64. http://msdn.microsoft.com/en-us/library/b0084kay(v=vs.110).aspx _M_X64: Defined for x64 processors. _M_AMD64: Defined for x64 processors. This patch fixes the issue for me: http://dl.dropbox.com/u/74751/cpp/boost/patches/context-msvc-x64-fix-201203… Thanks.

1 0

[algorithm] aesthetic question about cxx11
by lcaminiti 22 Mar '12

22 Mar '12

Hello all, I have an aesthetic question. Boost.Algorithm puts C++11 algorithms like all_of into a directory boost/algorithm/cxx11. Would the directory name boost/algorithm/cpp11 be preferred? I think for file names .cpp and .hpp are Boost choice over .cxx and .hxx. But for directory names instead cxx11 is Boost choice over cpp11? Similarly, shall macros that refer to C++11 be named BOOST_..._CPP11_... or BOOST_..._CXX11_...? In general, shall Boost refer to C++11 as cpp11/CPP11 or cxx11/CXX11? Given that .cpp/.hpp is Boost choice for file names over .cxx/.hxx, I'd think cpp11/CPP11 would be Boost choice over cxx11/CXX11... P.S. I have a similar situation in Boost.Contract where I want to put macros to parse C++11 keywords (override, final, etc) in a separated directory and I want to name that directory cxx11 or cpp11 consistently with other Boost libraries (so users don't have to remember different conventions). Thanks. --Lorenzo -- View this message in context: http://boost.2283326.n4.nabble.com/boost-algorithm-aesthetic-question-about… Sent from the Boost - Dev mailing list archive at Nabble.com.

10 21

[config] local types as template params
by Lorenzo Caminiti 22 Mar '12

22 Mar '12

Hello all, Is it possible to add a macro BOOST_CONFIG_LOCAL_TYPES_AS_TEMPLATE_PARAMS to Boost.Config to indicate if local types can be passed as template parameters? 1) Boost.Closure (formerly, Boost.Local) implements some optimizations when local types can be passed as template parameters. 2) C++11 always allows to pass local types as template parameters. 3) Local types cannot be passed as template parameters on C++03 instead but some C++03 compilers MSVC 8 (and older?) allow it anyway. // If it is possible to pass local types (classes, etc) as template parameters. // This is not possible in pure C++03 but it is possible in some C++03 // extensions (MSVC 8.0) and with C++11 (GCC >= 4.5.x -std=c++0x). #if (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 4)) && \ defined(__GXX_EXPERIMENTAL_CXX0X__) // From GCC 4.5.x when -std=c++0x specified. # define BOOST_LOCAL_TYPES_AS_TEMPLATE_PARAMS #elif defined(_MSC_VER) // For (all?) MSVC (tested on MVSC 8.0). # define BOOST_LOCAL_TYPES_AS_TEMPLATE_PARAMS #endif All, can you please try to compile the following example on different compilers/versions and let me know the outcome? If this example compiles successfully then the specific compiler supports local types as template parameters: #include <algorithm> #include <iostream> int main() { struct s { void operator()(int x) { std::cout << x << std::endl; } } l; int nums[] = {1, 2, 3}; std::for_each(nums, nums + 3, l); return 0; } For example, this compiles on GCC >= 4.5.x w/ C++0x extensions enabled and on MSVC 8.0- does it compile on all MSVC versions? Thanks. --Lorenzo

8 12

[config] missing BOOST_HAS_STDINT_H for PGI
by Oliver Kowalke 22 Mar '12

22 Mar '12

ticket: 6724 boost/config/compilers/pgi.h does not define BOOST_HAS_STDINT_H -> boost/cstdint.hpp does not include stdint.h Oliver

2 1

Re: [boost] [git] Mercurial?
by Jason Harris 22 Mar '12

22 Mar '12

> >>>>> Dave Abrahams <dave <at> boostpro.com> writes: > > > More attention from the community, more support, more tools work with it, > > more money behind it, more people will be familiar with it in the long run, > > etc., etc. > > Example: compare the number of commercial tools for working with Git, compared > to those available for working with Mercurial. On OS X along I can use: > SourceTree, Tower, GitHub, GitBox, GitDiary, QuickHub, Octopus, and that's > only the commercial tools! > > By contrast, if I search for "mercurial" in the AppStore, I can only use > SourceTree (which works with both). > Well, I am the author of MacHg a very fully featured multithreaded osx client for mercurial. There was murky and a few other clients around for OSX. But for now the scene seems to have settled into MacHg and SourceTree. I would also point out that I think the kiln team will soon have a nice port of TortiseHg to OSX. A partial listing of general tools is here: http://mercurial.selenic.com/wiki/OtherTools (Note I have not put MacHg on the AppStore since it is a bit of a pain trying to sand box the thing. I think Neil (the author of SourceTree) complained about the fact that he could not include compiled python file etc, in the app store version. Also a good GUI should have some command line drivers. Eg from the command line you should be able to enter "machg somerepo" and have it open in MacHg or something similar. (This has been on my to-do list for quite some time.) And such tools contravene the AppStore guidelines. Eg BBedit had to remove such tools from their application in order to get it onto the AppStore. Eg see http://www.barebones.com/store/macappstore.html and the section about the limitations of the AppStore version.)) I would think most developers would not be strictly limited to the AppStore version and a simple google of "OSX mercurial" will turn up MacHg... As to the whole discussion of Mercurial vs Git. I really have to say that both products are quite similar now in what they can do. However, the learning curve for me for git is just not good. Eg just for some simple comparisons do a: [salt:~] ⌘ hg help pull | wc 40 264 1753 [salt:~] ⌘ git help pull | wc 638 3624 29834 These are basically the same commands. Yet, the size of the help entry for pull for mercurial is 6% of the size of the git help entry. That says a lot about the understandability of one system to the other. (cf the size difference for other commands like pull, log, status, etc.) Git has **soo** many bells and whistles. Every so often as a real DVCS ninja git has something that mercurial doesn't have in my experience. Eg there is a feature in git when you are doing a total conversion of a repository you can run a filter over all of the files as you go. (eg imagine you want to convert all of say windows newlines to unix newlines in every version stored in history, or some other repetitive thing like this.) Up until a little while ago Mercurial didn't have that feature. So on the extreme cases there are definitely bits to git where git has more options. However these extra command switches in git are definitely a very sharp double edged sword in that for the average user the number of git options is just insanely huge. Thus I think the mercurial philosophy of trying to keep things clean, organized, and coherent is much better for at least 90% of users if not more like 98% of users. I am sure that each of you and each of your colleagues are gurus in a number of things, but do you want to require that they are gurus in DVCS systems? Even in Mercurial a lot of the users I encounter are sometimes woefully clued in to what is going on, and Mercurial is more streamlined, and cleanly organized than git (in my humble personal experience.) And it isn't all a bed of roses in Mercurial either. Eg there are things one should really watch out for, for example in using sub-repositories (these parallel sub-modules in git) one should use a thin super-repo layer. We got bitten by this at our work and it has caused problems. See eg http://mercurial.selenic.com/wiki/Subrepository#Recommendations Other points to consider: Those people who think you can't edit history in Mercurial or have many "branches" within a repo, their information is years out of date... I edit history and rebase, etc all of the time. It is part of my standard work flows. The arguments about popularity might have some weight but I think Mercurial and Git are definitely both large enough and will stick around. Besides converting one repo to the other in case one disappears is not that difficult. There are tools which interoperate between both formats (se hg-git.) Also, being a GUI writer I would say the number of differences once you are using a GUI is even smaller in day to day usage once you know what is going on. One, difference is with git you have to be careful to name *everything* or you get "detached heads". In mercurial you don't have to worry about this at all. You can happily update to any revision and start working right there without having to remember to name it / think up a name for it. (However, there are certain advantages to naming everything since then you can track revisions across all sorts of history edits, where-as in Mercurial you have to do some of this tracking manually...) (As a GUI writer I have thought about making the changes to MacHg to be able to release MacGit, but ever time I start playing with git it just... I don't know... I can go into details but the details would likely not be relevant here...) In any case, I use boost in my projects and think it's fantastic! Whether you all end up choosing git or hg a DVCS IMHO is much better than a centralized VCS. (However, I haven't used svn extensively since the company I worked for has skipped directly from cvs to mercurial & git.) Also whether you choose hg or git you might want to have an official mirror in the other system... So users can just use the system they want to. Best of luck, Jason

1 0

[accumulator] Problem with 'droppable_accumulator.hpp' (rev. 77432)
by sguazt 21 Mar '12

21 Mar '12

Hello, I have a problem when compiling with the current trunk version (rev. 77432) of Boost.Accumulator: In file included from projects/boost-trunk/boost/accumulators/framework/accumulator_set.hpp:28:0, from projects/boost-trunk/boost/accumulators/accumulators.hpp:12, ... projects/boost-trunk/boost/accumulators/framework/accumulators/droppable_accumulator.hpp: In copy constructor 'boost::accumulators::droppable_accumulator<Accumulator>::droppable_accumulator(const boost::accumulators::droppable_accumulator<Accumulator>&)': projects/boost-trunk/boost/accumulators/framework/accumulators/droppable_accumulator.hpp:173:54: error: expected type-specifier projects/boost-trunk/boost/accumulators/framework/accumulators/droppable_accumulator.hpp:173:54: error: expected '>' projects/boost-trunk/boost/accumulators/framework/accumulators/droppable_accumulator.hpp:173:54: error: expected '(' projects/boost-trunk/boost/accumulators/framework/accumulators/droppable_accumulator.hpp:173:82: error: expected ')' before 'const' My system is: OS: Fedora 14 x86_64 Compiler: GCC 4.6.1 Compiler's Flags: --ansi -pedantic -Wall -Wextra I think you need to change line 173: : droppable_accumulator::base(*static_cast<droppable_accumulator::base const *>(&that)) with the following (note the addition of "typename") : droppable_accumulator::base(*static_cast<typename droppable_accumulator::base const *>(&that)) After this addition all seems to work. Could you fix it, please? Thank you very much. Best, -- Marco

2 2

Please advise: Boost with LLVM Clang and 0x11 dialect ?
by John M. Dlugosz 21 Mar '12

21 Mar '12

Can someone please advise on how to get Boost headers to work when compiling using Clang (as found on Apple OSX/iOS development) when the 0x11 dialect is enabled? We're stuck at Boost 1.47 because 1.48 doesn't even work with the current settings (C++03 dialect). The Mac developers don't want to fiddle with 1.49 without knowing what the deal is. Is there someone who has used Boost on the Apple with Clang who can relate some tales of how it works and offer suggestions? I've had no luck on the Boost.Users mailing list, or a previous post here on Boost.Devel. Is there anyplace else I might ask? At this point, any scrap of wisdom would be appreciated. —John

2 1

Graph properties and GraphML
by Arthur Castonguay 21 Mar '12

21 Mar '12

I'm using 1.49.0 and am attempting to read a GraphML file that has graph attributes on it (example file below). My test program is below too. I've run into two issues. 1. The GraphML reader didn't quite handle them. There was some facilities put in place but it was never glued together. I added some code (patch below) and now it appears that that will do what I want... I'm getting "property not found" exception now. Great... onto item 2. 2. I cannot seem to wire the graph property into the dynamic properties. I've used the same syntax used for node and edge properties: props.property("gattr", get(&GraphProperty::gattr, g)); I've search examples and cannot find an instance of this to see if graph properties are handled differently. It's possible I've just written bad code for #2. I'm still working through the adjacency_list code to see if I can grok what's going on. Figured maybe someone more familiar with this could find the issue quickly. Once functionaly, I'll report a bug regarding item #1 but I want to ensure the writing of the GraphML works as well before doing that (the code appears to write graph attributes.. can't test yet due to item #2). For those that don't want to bother, this is the compile error I'm getting: boost/graph/adjacency_list.hpp: In function ‘typename boost::property_map<boost::adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>, T Bundle::*>::type boost::get(T Bundle::*, boost::adjacency_list<OutEdgeListS, VertexListS, DirectedS, VertexProperty, EdgeProperty, GraphProperty, EdgeListS>&) [with OutEdgeListS = boost::vecS, VertexListS = boost::vecS, DirectedS = boost::bidirectionalS, VertexProperty = NodeProperty, EdgeProperty = EdgeProperty, GraphProperty = GraphProperty, EdgeListS = boost::listS, T = std::string, Bundle = GraphProperty]’: ex.cpp:37: instantiated from here boost/boost/graph/adjacency_list.hpp:561: error: no matching function for call to ‘boost::bundle_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, NodeProperty, EdgeProperty, GraphProperty, boost::listS>, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>, EdgeProperty, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::bundle_property_map(boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, NodeProperty, EdgeProperty, GraphProperty, boost::listS>*, std::string GraphProperty::*&)’ boost/boost/graph/properties.hpp:397: note: candidates are: boost::bundle_property_map<Graph, Descriptor, Bundle, T>::bundle_property_map(Graph*, T Bundle::*) [with Graph = boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, NodeProperty, EdgeProperty, GraphProperty, boost::listS>, Descriptor = boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>, Bundle = EdgeProperty, T = std::basic_string<char, std::char_traits<char>, std::allocator<char> >] boost/boost/graph/properties.hpp:396: note: boost::bundle_property_map<Graph, Descriptor, Bundle, T>::bundle_property_map() [with Graph = boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, NodeProperty, EdgeProperty, GraphProperty, boost::listS>, Descriptor = boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>, Bundle = EdgeProperty, T = std::basic_string<char, std::char_traits<char>, std::allocator<char> >] boost/boost/graph/properties.hpp:390: note: boost::bundle_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, NodeProperty, EdgeProperty, GraphProperty, boost::listS>, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>, EdgeProperty, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >::bundle_property_map(const boost::bundle_property_map<boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, NodeProperty, EdgeProperty, GraphProperty, boost::listS>, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>, EdgeProperty, std::basic_string<char, std::char_traits<char>, std::allocator<char> > >&) Here's my compiler version: $ cc --version i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Any ideas? Is item #2 a bug or dumbass programmer (aka me)? Regards, Arthur --- 8< Start ex.graphml 8< --- <?xml version="1.0" encoding="UTF-8"?> <graphml xmlns="http://graphml.graphdrawing.org/xmlns" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://graphml.graphdrawing.org/xmlns http://graphml.graphdrawing.org/xmlns/1.0/graphml.xsd"> <key id="key0" for="graph" attr.name="gattr" attr.type="string"/> <key id="key1" for="node" attr.name="nattr" attr.type="string"/> <key id="key2" for="edge" attr.name="eattr" attr.type="string"/> <graph id="G" edgedefault="directed"> <data key="key0">graphval</data> <node id="n0"> <data key="key1">nodeval0</data> </node> <node id="n1"> <data key="key1">nodeval1</data> </node> <edge source="n0" target="n1"> <data key="key2">edgeval</data> </edge> </graph> </graphml> --- 8< End ex.graphml 8< --- --- 8< Start ex.cpp 8< --- #include <iostream> #include <string> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/graphml.hpp> #include <boost/property_map/dynamic_property_map.hpp> struct GraphProperty { std::string gattr; }; struct NodeProperty { std::string nattr; }; struct EdgeProperty { std::string eattr; }; typedef boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, NodeProperty, EdgeProperty, GraphProperty> Graph; using namespace std; using namespace boost; int main() { Graph g; dynamic_properties props; props.property("nattr", get(&NodeProperty::nattr, g)); props.property("eattr", get(&EdgeProperty::eattr, g)); props.property("gattr", get(&GraphProperty::gattr, g)); // Fails to compile try { read_graphml(cin, g, props); write_graphml(cout, g, props); } catch (parse_error e) { cerr << e.what() << endl; } catch (bad_parallel_edge e) { cerr << e.what() << endl; } catch (directed_graph_error e) { cerr << e.what() << endl; } catch (property_not_found e) { cerr << e.what() << endl; } catch (...) { cerr << "Caught unhandled excption" << endl; } return EXIT_SUCCESS; } --- 8< Start ex.cpp 8< --- Patch to enable graph properties on GraphML files. Using 1.49.0. Index: libs/graph/src/graphml.cpp =================================================================== --- libs/graph/src/graphml.cpp (revision 1) +++ libs/graph/src/graphml.cpp (working copy) @@ -74,6 +74,15 @@ std::vector<const ptree*> graphs; get_graphs(gml, graphs); BOOST_FOREACH(const ptree* gr, graphs) { + // Search for graph attributes + BOOST_FOREACH(const ptree::value_type& attr, *gr) { + if (attr.first != "data") continue; + std::string key = attr.second.get<std::string>(path("<xmlattr>/key")); + std::string value = attr.second.get_value(""); + handle_graph_property(key, value); + } + } + BOOST_FOREACH(const ptree* gr, graphs) { // Search for nodes BOOST_FOREACH(const ptree::value_type& node, *gr) { if (node.first != "node") continue; @@ -183,6 +192,11 @@ } } + void handle_graph_property(const std::string& key_id, const std::string& value) + { + m_g.set_graph_property(m_key_name[key_id], value, m_key_type[key_id]); + } + void handle_node_property(const std::string& key_id, const std::string& descriptor, const std::string& value) { m_g.set_vertex_property(m_key_name[key_id], m_vertex[descriptor], value, m_key_type[key_id]);

1 0

[lambda] Can't get simple lambda working...
by Robert Dailey 21 Mar '12

21 Mar '12

Here is a basic function I have: bool MimeDocument::GetExistingAttachment( std::string const& filename, std::vector<MessageAttachment> const& attachments, MessageAttachment& attachment ) { using namespace boost::lambda; using boost::lambda::_1; std::vector<MessageAttachment>::const_iterator it = std::find_if( attachments.begin(), attachments.end(), bind( &MessageAttachment::name, _1 ) == filename ); if( it != attachments.end() ) { attachment = *it; return true; } return false; } MessageAttachment::name() has 2 overloads, one that takes 1 parameter and the other that takes no parameter. I'm attempting to call the version that accepts no parameters and returns a "char const*". I want to then compare this value to the local variable "filename". This should happen for each object in the vector (_1). I get various types of compiler errors on MSVC9. They all have to do with C2780: 1>c:\code\work\cmake-mds\server\gmmserver\domino\server\interface\dimime.cpp(287) : error C2780: 'const boost::lambda::lambda_functor<boost::lambda::lambda_functor_base<boost::lambda::action<10,boost::lambda::function_action<10,T>>,detail::bind_tuple_mapper<const Arg1,const Arg2,const Arg3,const Arg4,const Arg5,const Arg6,const Arg7,const Arg8,const Arg9,const Arg10>::type>> boost::lambda::bind(const Arg1 &,const Arg2 &,const Arg3 &,const Arg4 &,const Arg5 &,const Arg6 &,const Arg7 &,const Arg8 &,const Arg9 &,const Arg10 &)' : expects 10 arguments - 2 provided 1> c:\code\work\cmake-mds\build-vc9\third_party\boost\1.48.0\include\boost\lambda\detail\bind_functions.hpp(1743) : see declaration of 'boost::lambda::bind' Anyone have any idea what I'm doing wrong? --------- Robert Dailey

6 10

Re: [boost] [git] Mercurial?
by Steve Ramsey 21 Mar '12

21 Mar '12

On Mar 20, 2012, at 8:40 PM, Edward Diener <eldiener(a)tropicsoft.com> wrote: > I have never heard a single technical argument, in all the endless > mentions of Git among the people riding that bandwagon, why Git is > better than SVN, or even why any DVCS is better than a centralized SCCS. > I consider this whole move to Git and/or DVCS among "hip" programmers > little more than a move to conform with what others are doing and feel > "cool". > > I am perfectly willing to read well-chosen technical arguments but not > from people already sold on one side or the other. But I really despair > of anyone being able to present such arguments in the atmosphere created > by Git fanatics and DVCS fanatics. The only thing I have gotten from all > this is "I've tried it, I like it, and therefore its superior". > > Feel free, anyone, to point me to a purely technical discussion, > article, whatnot, explaining the practical reasons why using a DVCS, or > Git, is more productive and more pleasurable than using a centralized > SCCS like Subversion. For what it’s worth, here is a series of articles that sold me on DVCS (and Mercurial in particular, though that’s neither here nor there) after spending quite some time wondering whether to bother: <http://hginit.com/> It’s a typically breezy Joel Spolsky piece, but it does cover use cases nicely. Steve

2 1