- Boost-users - lists.boost.org

[interprocess 1.42] Copy multiple variables into shared memory
by Michael Behnke 13 Oct '14

13 Oct '14

Hello, I'm trying to write multiple variables one by one into a mapped_region, but somehow I fail. Here is the Code I worked on so far: boost::interprocess::shared_memory_object shm_obj(boost::interprocess::open_or_create, "Test", boost::interprocess::read_write); shm_obj.truncate(1000); boost::interprocess::mapped_region region(shm_obj, boost::interprocess::read_write, 0, 0); uint32_t size = 33; uint32_t type = 666; std::string data("I'm a Test!"); uint32_t* start_ptr_int = &(static_cast<uint32_t*> (region.get_address())[0]); std::memcpy(start_ptr_int, &size, sizeof (uint32_t)); start_ptr_int = &(static_cast<uint32_t*> (region.get_address())[4]); std::memcpy(start_ptr_int, &type, sizeof (uint32_t)); char* start_ptr_char = &(static_cast<char*> (region.get_address())[8]); std::memcpy(start_ptr_char, data.c_str(), data.length()); uint32_t sizeOfData; std::memcpy(&sizeOfData, &(static_cast<uint32_t*> (region.get_address())[0]), sizeof (uint32_t)); uint32_t typeOfData; std::memcpy(&typeOfData, &(static_cast<uint32_t*> (region.get_address())[4]), 4); char* revData = new char[sizeOfData]; std::memcpy(revData, &(static_cast<char*> (region.get_address())[sizeof (uint32_t) * 2]), sizeOfData); First I write an uint32_t into the region at index 0. Afterwards, I'm writing another uint32_t at position 4 (assuming the first uint32_t took the bytes 0 - 3). Last I write a string into the region, at index 8. Reading the first uint32_t again from shared memory works fine, as does reading the string (the last variable). But if I try to read the second variable (uint32_t) the data is not what I expected. I know that the problem is memcpy, somehow my syntax does not work. Unfortunately I could not find a matching example, cause mostly memset is used to explain the functionality of boost::mapped_region. I have to write lots of data into shared memory (structured like size1|type1|data1|...|sizeN|typeN|dataN) but still can't figure out how to do this the right way. Any suggestions are greatly appreciated. Kind regards Michael Behnke -- Bachelorand ________________________________________________________ ADITION technologies AG Schwarzwaldstraße 78b 79117 Freiburg http://www.adition.com T +49 / (0)761 / 88147 - 30 F +49 / (0)761 / 88147 - 77 SUPPORT +49 / (0)1805 - ADITION (Festnetzpreis 14 ct/min; Mobilfunkpreise maximal 42 ct/min) Eingetragen beim Amtsgericht Düsseldorf unter HRB 54076 Vorstände: Andreas Kleiser, Jörg Klekamp, Marcus Schlüter Aufsichtsratsvorsitzender: Joachim Schneidmadl UStIDNr.: DE 218 858 434

1 0

Boost Locale – accessing ICU functions directly
by Caroline Beltran 10 Oct '14

10 Oct '14

I recently began using Boost Locale traversing and boundary analysis of Unicode strings. I’ve used some of the features available for case conversion, i.e.: to_upper(), which appears to wrap ICU’s toUpper() function. I didn’t find Boost Locale wrappers for other ICU functions such as u_isalpha() or u_isalnum(). How can I these ICU functions? Thank you!

1 0

Are shared memory files distributable?
by Rajalakshmi Iyer 10 Oct '14

10 Oct '14

Hello, Is it possible to create a shared memory file using Boost Interprocess (with STL containers) and distribute it to several machines for reading and modifying independently? Thanks Raj -- @BlisMedia <http://twitter.com/BlisMedia> www.blismedia.com <http://blismedia.com> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of BlisMedia Ltd, a company registered in England and Wales with registered number 06455773. Its registered office is 3rd Floor, 101 New Cavendish St, London, W1W 6XH, United Kingdom. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error.

2 1

[make_shared] How to use boost::make_shared with more than 9 arguments
by dariomt＠gmail.com 10 Oct '14

10 Oct '14

I could patch my local copy with several more overloads (I need up to 12 parameters) but, is there a better way? I cannot change the constructor of the class to group parameters (as recommended in StackOverflow). Of course this is for C++03 Regards

2 1

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