- Boost-users - lists.preview.boost.org

Re: [Boost-users] Flyweight: wrapping shared_ptr
by Joaquin M Lopez Munoz 10 Oct '14

10 Oct '14

> De: Boost-users [mailto:boost-users-bounces@lists.boost.org] > En nombre de Akim Demaille > Enviado el: martes, 07 de octubre de 2014 18:27 > Para: Boost Users List > Asunto: Re: [Boost-users] Flyweight: wrapping shared_ptr > > Le 7 oct. 2014 à 18:18, Joaquín Mª López Muñoz <joaquin(a)tid.es> a écrit : > > > An alternative would be to use some sort of cloning smart pointer to > > spare the reference count, but it's not clear to me this would be > > faster than > > shared_ptr: > > > > * element exists: shared_ptr creation is slower than clone_ptr > > creation > > * element does not exist: shared_ptr creation and copy is probably > > faster than clone_ptr creation and cloning. > > Yes, indeed. A slightly smarter approach involves a cloning class that accepts a const Base& and does only clone on copy, thus avoiding dynamic memory allocation when the element already exists. This can be nicely wrapped up as follows: template<typename Base> class poly_holder { public: poly_holder(const Base& x):p(&x),dlt(false){} poly_holder(const poly_holder& x):p(x.p->clone()),dlt(true){} poly_holder& operator=(const poly_holder& x) { Base* q=x.p->clone(); if(dlt)delete p; p=q; dlt=true; return *this; } ~poly_holder(){if(dlt)delete p;} operator const Base&()const {return *p;} private: const Base* p; bool dlt; }; template<typename Base> class poly_flyweight:public boost::flyweight<poly_holder<Base>> { public: using super=boost::flyweight<poly_holder<Base>>; using super::super; const Base& operator*() const{return base();} const Base* operator->()const{return &base();} private: const Base& base()const{return this->get();} }; template<typename Base> std::size_t hash_value(const poly_flyweight<Base>& x) { return boost::hash<const Base*>()(&*x); } template<typename Base> bool operator==( const poly_flyweight<Base>& l,const poly_flyweight<Base>& r) { return static_cast<boost::flyweight<poly_holder<Base>>>(l)== static_cast<boost::flyweight<poly_holder<Base>>>(r); } template<typename Base> bool operator!=( const poly_flyweight<Base>& l,const poly_flyweight<Base>& r) { return !(l==r); } I've rewritten your test case to take advantage of this poly_flyweight thing, cleaning up some unnecessary hash and operator== overloads along the way and without resorting to the intermediate Exp_ type; see: http://coliru.stacked-crooked.com/a/76e87531b65d44f9 > Is there anyway Flyweight could have supported the operator-> natively? > It seems that with some SFINAE under the hood, it would work, don't you think? Yep, that would be possible, the only reason I didn't do it is to not clutter the interface. Also, some std classes such as (C++17) std::optional implement operator* differently, without the extra dereference required by smart pointer semantics. Joaquín M López Muñoz Telefónica

3 20

Boost.Geometry, probable bug in point_on_surface
by Petr Doubrava 10 Oct '14

10 Oct '14

#include <boost/geometry.hpp> #include <boost/geometry/geometries/point_xy.hpp> #include <boost/geometry/geometries/polygon.hpp> void test_point_on_surface() { typedef boost::geometry::model::point<double, 2, boost::geometry::cs::cartesian> Point; boost::geometry::model::polygon<Point> poly; boost::geometry::read_wkt("POLYGON((1074699.93 703064.65, 1074702.10 703054.62, 1074704.53 703061.40, 1074703.90 703064.58, 1074699.93 703064.65))",poly); boost::geometry::correct(poly); Point point; boost::geometry::point_on_surface(poly,point); //computed point isn't on the surface of polygon //[0] 1074839.1013086310 double //[1] 703154.77900308778 double bool res = boost::geometry::within(point,poly); // res is false }

2 2

[property_tree] Failure with Boost 1.56
by beet 10 Oct '14

10 Oct '14

Dear all, with the release of Boost 1.56, on Ubuntu 14.04 (g++ 4.8.2, 64 bit), code like the following suddenly fails to compile: pt::xml_writer_settings<char> settings('\t', 1); pt::write_xml(someFileName, ptr_out, std::locale(), settings); "pt" is obviously an alias for boost::property_tree. The error message I'm getting is /opt/boost156/include/boost/property_tree/detail/xml_parser_writer_settings.hpp:38:35: error: 'char' is not a class, struct, or union type typedef typename Str::value_type Ch; I can see the following possibly relevant change in property_tree: In Boost 1.55, from xml_parser.hpp: ----------------------------------- template<typename Ptree> void write_xml( const std::string & , const Ptree & , const std::locale & = std::locale() , const xml_writer_settings<typename Ptree::key_type::value_type >& = xml_writer_settings<typename Ptree::key_type::value_type >() ); In Boost 1.56, same header: --------------------------- template<typename Ptree> void write_xml( const std::string & , const Ptree & , const std::locale & = std::locale() , const xml_writer_settings<typename Ptree::key_type > & = xml_writer_settings<typename Ptree::key_type >() ); So xml_writer_settings is now given a Ptree::key_type instead of a Ptree::key_type::value_type which I assume is the reason for the above error. Is there a portable way to specify the type of indention character in write_xml ? Best Regards, Beet

2 1

[Boost.Polygon] Bug in polygon_set_data, or are my expectations wrong?
by Patrick J. LoPresti 09 Oct '14

09 Oct '14

I have just submitted a bug report: https://svn.boost.org/trac/boost/ticket/10642 ...but I am wondering if the bug is in my understanding rather than in Boost.Polygon. The test case is very simple, so I am appending it to this message. My question is, should I expect polygon_set_data<int> to scramble such a simple figure? It almost looks like some (but not all) of the coordinates are being snapped to multiples of 2. Or something. Note that doubling all of the coordinates avoids the bug. Assuming it is a bug (?) Thanks! - Pat #include <boost/polygon/polygon.hpp> #include <iostream> #include <cstdlib> namespace bp = boost::polygon; using namespace bp::operators; typedef bp::polygon_set_data<int> PolygonSet; typedef bp::polygon_data<PolygonSet::coordinate_type> Polygon; typedef bp::polygon_traits<Polygon>::point_type Point; int main(int argc, char *argv[]) { // Small figure with a little hole. Area should be 32. const Point points[] = { Point(0,0), Point(6,0), Point(6,4), Point(4,6), Point(0,6), Point(0,0), Point(4,4), Point(5,4) }; Polygon poly1(&points[0], &points[sizeof(points)/sizeof(points[0])]); PolygonSet ps1; ps1 += poly1; std::cout << "poly1 area == " << area(poly1) << "\n"; // Boost.Polygon says the area of ps1 is 30. That is because its internal // representation is wrong, as you can confirm by manually // examining the result of ps1.get() or ps1.get_trapezoids(). std::cout << "ps1 area == " << area(ps1) << "\n"; // Doubling the coordinates avoids the bug. Polygon poly2(poly1); scale_up(poly2, 2); PolygonSet ps2; ps2 += poly2; std::cout << "poly2 area == " << area(poly2) << "\n"; std::cout << "ps2 area == " << area(ps2) << "\n"; assert(area(poly2) == area(ps2)); assert(area(poly1) == area(ps1)); }

1 0

[polygon] Incorrect output from get_trapezoids(..., HORIZONTAL)
by Patrick J. LoPresti 08 Oct '14

08 Oct '14

I apologize for sending this to the mailing list, but when I tried to file a bug report via Trac, it said "Trac thinks your submission might be Spam. To prove otherwise please provide a response to the following"... And then there was no "following". Please let me know if there is a better forum to report this sort of issue. I am using Boost 1.56. The following program uses boost::polygon to slice up a figure (with a "hole" cut out of it) into horizontal trapezoids. The output I get is: Output: polygon (4 3) (4 0) (0 0) (0 3) (4 3) ...which is clearly wrong. I am pretty sure my code is correct, because if I replace bg::HORIZONTAL with bg::VERTICAL, I get the correct output of a bunch of vertical trapezoids. For my application, I really want horizontal traps. I suppose I can just swap x and y on input and output... But this seemed worth reporting. Thanks. - Pat #include <boost/polygon/polygon.hpp> #include <iostream> namespace bp = boost::polygon; typedef bp::polygon_set_data<int> PolygonSet; typedef bp::polygon_data<PolygonSet::coordinate_type> Polygon; typedef bp::polygon_traits<Polygon>::point_type Point; std::ostream & operator<<(std::ostream &os, const Point &pt) { return os << "(" << bp::x(pt) << " " << bp::y(pt) << ")"; } std::ostream & operator<<(std::ostream &os, const Polygon &poly) { os << "polygon "; for (Polygon::iterator_type p = poly.begin() ; p != poly.end() ; ++p) os << " " << *p; return os; } std::ostream & operator<<(std::ostream &os, const PolygonSet &ps) { std::vector<Polygon> temp; ps.get(temp); os << "polygonset "; for (std::vector<Polygon>::const_iterator p = temp.begin() ; p != temp.end() ; ++p) os << " " << *p; return os; } int main(int argc, char *argv[]) { const Point points[] = { Point(2,0), Point(4,0), Point(4,3), Point(0,3), Point(0,0), Point(2,0), Point(2,1), Point(1,1), Point(1,2), Point(3,2), Point(3,1), Point(2,1) }; Polygon poly; bp::set_points(poly, &points[0], &points[sizeof(points)/sizeof(points[0])]); std::cout << "Input: " << poly << "\n"; PolygonSet ps; ps.insert(poly); std::cout << "ps = " << ps << "\n"; std::vector<Polygon> traps; // Note: bp::VERTICAL works fine bp::get_trapezoids(traps, ps, bp::HORIZONTAL); std::cout << "Output:\n"; for (std::vector<Polygon>::const_iterator p = traps.begin() ; p != traps.end() ; ++p) std::cout << *p << "\n"; }

2 2

program_options: Make PO not eat argc
by Florian Lindner 08 Oct '14

08 Oct '14

Hello, I have a couple of libraries (MPI, petsc) that also consume my applications argc and argv, which is parsed with boost::program_options before. po seems to eat up argv, i.e. removes all items that it handles. Can I disable that behavior somehow so that po does not touch argc/argv. Or do I need to recreate it, e.g. using collect_unrecognized? Thanks, Florian

2 2

program_options: How to best model two/three pos args
by Florian Lindner 08 Oct '14

08 Oct '14

Hello, my application has positional arguments like that: Run tests : ./app test ConfigurationName PathToSrc Run server : ./app server ParticipantName ConfigurationName Print XML reference: ./app xml Linewidth It has three (if first in [test, server]) or two (if first in [xml]) positional arguments. How to model and test this best using boost? I could add three options and declare them as positional arguments, named like "first", "second", "third". I could also use just one positional argument like: po::positional_options_description pos_dec; pos_dec.add("positionals", 3); and test the resulting vector. What do you think? Thanks, Florian

2 1

MSM to diagram
by Robert Bielik 08 Oct '14

08 Oct '14

Hi all, I want to use MSM in an application, however, for design documentation purposes I'd like to be able to express the state machine in a diagram. And preferably going the route from C++ code -> graphical diagram (i.e. not from UML -> C++ code). Has anyone looked at that, or know of resources on how to accomplish this ? TIA /Robert

1 0

[general] Advice from Bjarne Stroustrup
by legalize+jeeves＠mail.xmission.com 06 Oct '14

06 Oct '14

[Please do not mail me a copy of your followup] At the end of each chapter in "The C++ Programming Language", 4th edition, Bjarne Stroustrup has a list of advice. I found the advice very helpful and decided that the advice should be online somewhere. Initially I put this together as a PPT presentation, but oh my lord, it was too long. Instead, I made a page in my user space on the cppreference.com wiki: <http://en.cppreference.com/w/User:Legalize/Advice_from_Bjarne_Stroustrup> This let me link to other pages on the wiki describing specific language features where possible. Hopefully you will find it useful. -- "The Direct3D Graphics Pipeline" free book <http://tinyurl.com/d3d-pipeline> The Computer Graphics Museum <http://computergraphicsmuseum.org> The Terminals Wiki <http://terminals.classiccmp.org> Legalize Adulthood! (my blog) <http://legalizeadulthood.wordpress.com>

2 1

NT² eand Boost.SIMD release 3.1
by Joel FALCOU 06 Oct '14

06 Oct '14

NT2 is a Matlab inspired, high-level API for scientific computation in C++. Boost.SIMD is a candidate library for inclusion in Boost dealing with the portable encpsulation of SIMD instructions sets. This following releases updates NT2 and Boost.SIMD libraries to version 3.1 This new release of NT2 and Boost.SIMD focused on fixing performance issues and add some new support for architecture and parallel algorithms. The main new features include: - Linear Algebra functions can now use GPGPU through the MAGMA library whenever possible. - Reduction and Scan operations now works with more shared memory back-end - Altivec support is now complete for the VMX ISA We wish to thanks Ian Masliah for his work on MAGMA, Antoine Tran Tan for the shared memory support and Pierre Esterie participation to the Altivec ISA completion. Special thanks to Tim Blenchmann and khegeman for their help and patch submisisons throughout this development. The release Changelog is here : https://github.com/MetaScale/nt2/releases/tag/3.1.0 The files can be download from : http://nt2.metascale.org/downloads/ The Documentation (in progress) is here : http://nt2.metascale.org/doc/html/index.html **Next release announcment** This release is the last C++03 compliant version of both NT2 and Boost.SIMD. The next release - 4.0 - will be C++11 only. The new minimal version of supported compilers will be : - g++ 4.6 - Microsoft Visual Studio 12 (2013) - clang 3.4 - icc 12.1 The main reason for this change is to be able to properly fix the compile-time issue that one may experience. It'll also allow us to use some C++11 feature to simplify or streamline some of the user interface. * The NT2 Team

1 0