November 2014 - Boost - lists.boost.org

[fit] please respond
by Andrzej Krzemienski 19 Nov '14

19 Nov '14

Hi, Encouraged by Boost Library Incubator initiative I wanted to make a review of FIT library, but I found I had some questions to Paul - the author. I send my questions also here, in case you are not subscribed for the comments in Boost Library Incubator. Please see my comment here: http://rrsd.com/blincubator.com/bi_library/fit-3/?gform_post_id=1100 Regards, &rzej

1 0

Variant and visitation (was: [optional] Safe optional)
by Nevin Liber 19 Nov '14

19 Nov '14

On 18 November 2014 15:02, Matt Calabrese <rivorus(a)gmail.com> wrote: > > > > For a while I assumed exactly that, but he actually specifically voiced > > > that he does not like visitation on variant and thinks of it as a hack. > > > It's sad :/ > > > > > > > FWIW: I think he is (a) correct, but (b) we have nothing better to > replace > > it, so we still need it. > > > > We should really start a thread about this. I'm very curious to see an > actual objective rationale both for why visitation over a closed set of > types known at compile time is in any way a "hack," It's the inversion of control that people just don't like. > along with a realistic > alternative. As I already said, I don't know of one, and having it is better than not having it. The discussion in Urbana on n4218 <http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4218.pdf> (variant), which didn't propose visitation, basically amounted to we don't like visitation but we need it unless something better comes along. > It really is a fundamental operation of a discriminated union. > As someone who uses variants pretty much as the "default" for run-time > polymorphism in day-to-day coding, I have never seen an actual explanation > for what someone might consider bad about variant visitation, neither from > Bjarne nor anyone else. > While I don't want to speak for Bjarne, I believe he would rather have some form of Pattern Matching <http://www.stroustrup.com/OpenPatternMatching.pdf> and possibly variant as a language feature. That being said, no one has proposed it. -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404

5 8

Re: [boost] [optional] Safe optional
by Felix Uhl 18 Nov '14

18 Nov '14

Matt Calabrese wrote: > I know that there are others (Eric?) who prefer to think of optional as a > container of size 0 or 1, so it could also make sense to provide an > accessor to a range. One interesting effect of this is that now > range-based-for sort of becomes a "visit if." There are probably other... > interesting uses of standard algorithms. I don’t know why, but I really like that idea; int f(optional<int> input){ int ret = 0; for(int opt : input){ ret = opt; } return ret; } It somehow seems like a really interesting Syntax, but to be honest, it doesn’t really offer any benefits, does it? You neither have any improvements on performance, nor any on code clarity. --- Felix Uhl Von: Matt Calabrese Gesendet: ‎Montag‎, ‎17‎. ‎November‎ ‎2014 ‎17‎:‎41 An: boost(a)lists.boost.org On Nov 17, 2014 1:25 AM, "Andrzej Krzemienski" <akrzemi1(a)gmail.com> wrote: > No, no exceptions. > The solution is based on the observation that there is a limited number of > things you can do with optional<T> > > optional<int> oi = ...; > > 1: > if (oi) doSomething(*oi); > else doSomethingElse(); // or nothing > > 2: > if (oi) doSomething(*oi); > else doSomething(-1); // use default value > > 3: > if (!oi) oi = (int)getIntByOtherMeans(); > doSomething(*oi); // now it is safe > > Now we simply provide a dedicated interface for each of these three usages: > > 1: > oi.use(&doSomething, &doSomethingElse); // or use lambdas > > 2: > doSomething(oi.value_or(-1)); > > 3: > doSomething(oi.value_or_eval(getIntByOtherMeans)); While I agree that we should be encouraging high order functions/visitation here, my personal experience is simply that many people do not like it. When given the choice to pass a lamda or to use an "if" or a range-based-for over high order function alternatives, programmers will generally opt for not using a lambda. The fact that Bjarne thinks visitation is somehow "bad" doesn't help. I agree that it's safer and I'd be in favor of it, but be aware that not everyone will like it. That said, I'd be in favor of this. If going with this approach, though, I'd say make optional a model of a variant and/or discriminated union concept that it and variant share, along with "expected" if it were to make it into boost (I.E. allow for apply_visitor of T and none, provide a "which"). I'd still like to see the other functions you mention as well for convenience. I know that there are others (Eric?) who prefer to think of optional as a container of size 0 or 1, so it could also make sense to provide an accessor to a range. One interesting effect of this is that now range-based-for sort of becomes a "visit if." There are probably other... interesting uses of standard algorithms. > I would rather not go that way. boost::optional is not unsafe. It is simply > something else than what some people think. Its conceptual model is more > like any value of T, plus one additional value. In this model implicit > conversions make perfect sense and are n fact desirable. I'm not sure I agree. These two templates aren't exactly complimentary in terms of the functionality that they provide, they really would just provide exactly the same functionality with the same internals. All that is different is the interface. Because of that, I say either it replaces optional or it doesn't exit as a part of boost. If people are convinced that this interface is less error prone, then it should be THE interface for optional. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

2 1

[config] [VC++ 14.0 aka 2015] Removing BOOST_MSVC_ENABLE_2014_JUN_CTP macro requirement.
by Beman Dawes 18 Nov '14

18 Nov '14

As of the moment, the BOOST_MSVC_ENABLE_2014_JUN_CTP macro must be defined to eliminate a bunch of macros that should not apply to the Visual Studio 2015 Preview: BOOST_NO_CXX11_ALIGNAS [no value] BOOST_NO_CXX11_CHAR16_T [no value] BOOST_NO_CXX11_CHAR32_T [no value] BOOST_NO_CXX11_INLINE_NAMESPACES [no value] BOOST_NO_CXX11_NOEXCEPT [no value] BOOST_NO_CXX11_REF_QUALIFIERS [no value] BOOST_NO_CXX11_UNICODE_LITERALS [no value] BOOST_NO_CXX11_USER_DEFINED_LITERALS [no value] In other words, the only CXX11 macros that should be defined are: BOOST_NO_CXX11_ADDRESSOF [no value] BOOST_NO_CXX11_CONSTEXPR [no value] Unless someone objects strongly in the next few hours, I'm going to remove the need for the BOOST_MSVC_ENABLE_2014_JUN_CTP macro; it is just causing confusion at this point. --Beman

6 11

noexcept(true) for ~noncopyable?
by Olaf van der Spek 18 Nov '14

18 Nov '14

Shouldn't ~noncopyable be noexcept? I'm seeing this error: class Cconnection : public Cclient, boost::noncopyable connection.h:5:7: error: looser throw specifier for ‘virtual Cconnection::~Cconnection()’ In file included from connection.h:3:0, from connection.cpp:2: client.h:10:10: error: overriding ‘virtual Cclient::~Cclient() noexcept (true)’ https://svn.boost.org/trac/boost/ticket/10698 -- Olaf

2 3

[BGL] [push_relabel_max_flow]
by Pablo Madoery 18 Nov '14

18 Nov '14

Hello, I am having trouble using the push_relabel_max_flow algorithm when i put std::numeric_limits<double>::max() as capacity attribute in some edges. is there a maximum value that I can use as capacities. which ?. This is the example I am using : #include <iostream> #include <boost/graph/adjacency_list.hpp> #include <boost/graph/push_relabel_max_flow.hpp> #include <boost/graph/graphviz.hpp> using namespace std; using namespace boost; struct vertexInfo { }; struct edgeInfo { double capacity; double residualCapacity; double flow; adjacency_list_traits<vecS, vecS, bidirectionalS>::edge_descriptor rev; edgeInfo() { residualCapacity = 1000; } }; typedef adjacency_list<vecS, vecS, bidirectionalS, vertexInfo, edgeInfo> Graph; typedef Graph::edge_descriptor edge_d; const char* names[] = { "SV", "L1", "L2", "L3", "L4", "ET"}; template<typename Vertex> void create_edge(Graph& g, Vertex v0, Vertex v1, double capacity) { //the algorithm requires that for each edge u-v in the graph, the edge v-u also exists Graph::edge_descriptor ep0 = (add_edge(v0, v1, g)).first; Graph::edge_descriptor ep1 = (add_edge(v1, v0, g)).first; g[ep0].capacity = capacity; g[ep0].rev = ep1; g[ep1].capacity = 0; // the capacity of v-u needs to be 0 g[ep1].rev = ep0; } int main() { Graph graph; Graph::vertex_descriptor SV = add_vertex(graph); Graph::vertex_descriptor L1 = add_vertex(graph); Graph::vertex_descriptor L2 = add_vertex(graph); Graph::vertex_descriptor L3 = add_vertex(graph); Graph::vertex_descriptor L4 = add_vertex(graph); Graph::vertex_descriptor ET = add_vertex(graph); create_edge(graph, SV, L1, std::numeric_limits<double>::max()); create_edge(graph, SV, L2, std::numeric_limits<double>::max()); create_edge(graph, SV, L3, std::numeric_limits<double>::max()); create_edge(graph, SV, L4, std::numeric_limits<double>::max()); create_edge(graph, L3, ET, 1000); create_edge(graph, L4, L3, 1000); create_edge(graph, L2, L3, 1000); create_edge(graph, L1, L2, 1000); // arcos de vuelta create_edge(graph, L3, L4, 1000); create_edge(graph, L3, L2, 1000); create_edge(graph, L2, L1, 1000); std::cout << "Max flow: " << push_relabel_max_flow(graph, SV, ET, get(&edgeInfo::capacity, graph), get(&edgeInfo::residualCapacity, graph), get(&edgeInfo::rev, graph), get(boost::vertex_index, graph)) << std::endl; graph_traits<Graph>::vertex_iterator vi, vi_end; graph_traits<Graph>::out_edge_iterator ei, ei_end; cout.precision(20); for (tie(vi, vi_end) = vertices(graph); vi!= vi_end; ++vi) { for (tie(ei, ei_end) = out_edges(*vi, graph); ei != ei_end; ++ei) { graph[*ei].flow = graph[*ei].capacity - graph[*ei].residualCapacity; if (graph[*ei].capacity > 0) { std::cout << names[*vi] << " " << names[target(*ei, graph)] << " " << (graph[*ei].capacity - graph[*ei].residualCapacity) << "/" << graph[*ei].capacity << std::endl; } } } cout<<"end"<<endl; return 0; } ----------------------------------------------------------------------------------------------------------------------------- And this is the exception: /home/madoery/boost_1_55_0/boost/graph/push_relabel_max_flow.hpp:706: typename boost::property_traits<CapacityEdgeMap>::value_type boost::push_relabel_max_flow(Graph&, typename boost::graph_traits<Graph>::vertex_descriptor, typename boost::graph_traits<Graph>::vertex_descriptor, CapacityEdgeMap, ResidualCapacityEdgeMap, ReverseEdgeMap, VertexIndexMap) [with Graph = boost::adjacency_list<boost::vecS, boost::vecS, boost::bidirectionalS, vertexInfo, edgeInfo>, CapacityEdgeMap = boost::adj_list_edge_property_map<boost::bidirectional_tag, double, double&, long unsigned int, edgeInfo, double edgeInfo::*>, ResidualCapacityEdgeMap = boost::adj_list_edge_property_map<boost::bidirectional_tag, double, double&, long unsigned int, edgeInfo, double edgeInfo::*>, ReverseEdgeMap = boost::adj_list_edge_property_map<boost::bidirectional_tag, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int>&, long unsigned int, edgeInfo, boost::detail::edge_desc_impl<boost::bidirectional_tag, long unsigned int> edgeInfo::*>, VertexIndexMap = boost::vec_adj_list_vertex_id_map<vertexInfo, long unsigned int>, typename boost::property_traits<CapacityEdgeMap>::value_type = double, typename boost::graph_traits<Graph>::vertex_descriptor = long unsigned int]: Assertion `algo.is_flow()' failed. Thank You

1 0

gdb pretty printers
by Paul Fee 18 Nov '14

18 Nov '14

Hi all, On Linux, when using GDB to debug C++ programs that use Boost, it's difficult to get human readable values from variables. e.g. == Source == boost::optional<std::string> s("hello world"); == GDB == (gdb) print s $1 = {<boost::optional_detail::optional_base<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >> = {<boost::optional_detail::optional_tag> = {<No data fields>}, m_initialized = true, m_storage = {dummy_ = {data = "(0`\000\000\000\000", aligner_ = {<No data fields>}}}}, <No data fields>} ======== A set of python pretty printers that understand the internals of some Boost objects can be found here: https://github.com/ruediger/Boost-Pretty-Printer The resulting output is more useful: == GDB == (gdb) print s $2 = boost::optional<std::basic_string<char, std::char_traits<char>, std::allocator<char> > > is initialized = {value = "Hello world"} ========= Some distros, e.g. Fedora, CentOS have STL pretty printers working out of the box. It would be great to also have Boost pretty printers widely available via Linux distros. Since the pretty printers are tightly coupled to the objects they're printing, it would be ideal if they were included with Boost. That way both the class definitions and python printers should stay in sync. Can someone provide guidance on how to get code in the above github repo into Boost? Thanks, Paul

1 0

Boost config macros for 'override' and 'final'?
by Nat Goodspeed 18 Nov '14

18 Nov '14

I don't find in Boost 1.57 any Boost macros to mediate use of the 'override' or 'final' C++11 specifiers. Would that be a reasonable addition?

6 7

RFC/patch: compile boost on Android for platform development
by Wagner, David 17 Nov '14

17 Nov '14

Hi, We are evaluating the pros and cons of using Boost for platform development on Android. We have successfully built and run Asio's "chat" server and client examples on an Android device running Lollipop. The C++ support seems to have been greatly improved since KitKat. Even though it is still early to say that all of Boost runs ok, all the Asio unit tests passed with "*** No errors detected" except the multicast test. I've attached a patch that adds Android makefiles to relevant libraries for compiling Boost.Asio. It's a first draft and it doesn't use the git submodules. The development of this patch has been made on top of the 1.56.0 tag. Platform development on android is different than native development ("NDK", used for JNI libraries). There seem to have been several efforts made for Boost support on NDK but we haven't found any for platform development (which is aimed at device support, e.g., HAL development, native tools). Is there an interest for maintaining a set of Android makefiles on vanilla Boost ? I understand someone would need to run the regression tests on Android; is there any other such requirement ? Kind Regards, -- David Wagner Intel Corp. --------------------------------------------------------------------- Intel Corporation SAS (French simplified joint stock company) Registered headquarters: "Les Montalets"- 2, rue de Paris, 92196 Meudon Cedex, France Registration Number: 302 456 199 R.C.S. NANTERRE Capital: 4,572,000 Euros This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.

2 2

Re: [boost] Is there interest in a library for string-convertible enums?
by Jeffrey Bush 17 Nov '14

17 Nov '14

> > Jeffrey Bush wrote: > > > I have also offered a class for doing this as well, although it didn't > draw > > the interest that this one did. > > Here was my attempt at it with a test/example class: > > https://gist.github.com/coderforlife/6d8bac451d49dd1a0c81 > > > > > Looks good to me, and seems to be quite close to what I aim at. > > But the definition seems very user unfriendly. Is it correct that > > you always have to declare enums in the public namespace? > > --- > > Felix > Sorry for the delayed response. It does support being in a public namespace, even as a sub-class. However the definition does get uglier in sub-classes. The major problem I ran into was that the class could not be defined in a header file without getting multiple-definition or as a sub-class without running into problems. Mainly because of the constant arrays in the classes couldn't be defined in-line and in headers. Some C++11 features may help get around this. I do think that when these issues are ignored the declarations are pretty nice: BOOST_FLAGS_WITH_VALUES(MyFlags, std::uint8_t, A, 1, B, 2, AB, 3, C, 4); BOOST_FLAGS(MyDefaultFlags, AX, BX, CX, DX, EX, FX, GX, HX); namespace MyNS { BOOST_FLAGS(MyFlags, M, N, O, P, Q); } That makes 3 different enumerations, first with custom values and a custom base (uint8_t), the second with default values (powers of two) and selects the smallest base type, and the third is the same but in a non-public-namespace. All of these don't work in header files without getting multiple definitions. To avoid that problem you can do something like: // In H file: BOOST_FLAGS_DECL(MyFlags, M, N, O, P, Q); // In CPP file: BOOST_FLAGS_DEFN(MyFlags, M, N, O, P, Q); The same technique can be used to make sub-classes (as in the example file). If I remember correctly if the ability to go from string -> value and get list of values at runtime then the ugliness of the separate DECL/DEFN would be avoided. Jeff

1 0