Re: [Boost-bugs] [Boost C++ Libraries] #8362: Move ctor or assignment for boost::geometry::model::ring?

Subject: Re: [Boost-bugs] [Boost C++ Libraries] #8362: Move ctor or assignment for boost::geometry::model::ring?
From: Boost C++ Libraries (noreply_at_[hidden])
Date: 2013-04-15 08:24:27

#8362: Move ctor or assignment for boost::geometry::model::ring?
------------------------------------------------------+---------------------
  Reporter:  Volker Schöch <vschoech@…>               |       Owner:  mloskot              
      Type:  Support Requests                         |      Status:  new                  
 Milestone:  To Be Determined                         |   Component:  geometry             
   Version:  Boost 1.52.0                             |    Severity:  Cosmetic             
Resolution:                                           |    Keywords:  convert, move, assign
------------------------------------------------------+---------------------

Comment (by Volker Schöch <vschoech@…>):

 Replying to [comment:3 mloskot]:
 > The requested move semantic is one issue, but unless I'm missing
 something, is the ring model supposed to be constructible directly from
 compatible container of compatible points?
 > The extension constructor in ring takes iterators only, not container.

 Replying to [comment:4 barendgehrels]:
 > OK for me to add a constructor with a container with its point types. It
 was not there because vector/deque do not have it neither.

 Although to me this seems to be a desirable extension, I am not saying
 that this is the only way to solve the issue. Leaving constructors alone,
 you could alternatively overload the convert algorithm to support
 conversion from vector-of-points to (Multi-)Polygon:
 {{{
 boost::geometry::convert( std::move(vecpt), *this );
 }}}
 My suggestion to call convert by way of constructing a ring_type first was
 merely based on my observation that convert already supports conversion
 from Ring to Polygon.

 Replying to [comment:4 barendgehrels]:
 > Does this solve the whole issue?

 There are two more niceties I would like to suggest to solve the whole
 issue:

 1. In boost 1.52.0, convert supports Ring to Polygon conversion, but does
 not support ''(any Geometry that supports conversion to Polygon)'' to
 Multi-Polygon conversion. Is this by design, or is this considered a
 missing feature?

 2. While we are at it, is it intentional that I have to guard the
 conversion with "!vecpt.empty()"? I don't see a problem with creating a
 Ring from an empty vector-of-points and convert that to a Polygon that
 consist of empty vectors.

 Replying to [comment:4 barendgehrels]:
 > In the reported problem, std::move seems not necessary in the call to
 convert...

 Can you explain why you think std::move is unnecessary there? It may in
 fact be useless if there is any link in the chain of calls that does not
 support move semantics, but from my perspective I should still put it
 there to enable move semantics where it is supported. There seems to be
 consensus that [http://stackoverflow.com/questions/15387271/can-compiler-

 generate-stdmove-for-a-last-use-of-lvalue-automatically the compiler must
 not automatically turn a copy into a move]. Thus I think I have to be
 explicit about my intent to use move semantics.

-- 
Ticket URL: <https://svn.boost.org/trac/boost/ticket/8362#comment:5>
Boost C++ Libraries <http://www.boost.org/>
Boost provides free peer-reviewed portable C++ source libraries.