<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Even,<br><br>I submitted the patch as <a href="http://trac.osgeo.org/gdal/ticket/5990" target="_blank">http://trac.osgeo.org/gdal/ticket/5990</a><br><br>Feel free to ask for improvements if needed.<br><br>Simon<br><br><div>> From: even.rouault@spatialys.com<br>> To: gdal-dev@lists.osgeo.org<br>> Subject: Re: [gdal-dev] OGRGeometry copy constructor<br>> Date: Fri, 5 Jun 2015 17:46:20 +0200<br>> CC: simonhege@hotmail.com<br>> <br>> Simon,<br>> <br>> > Looking at the code of GDAL 2.0 (but also 1.x), I noticed that the<br>> > OGRGeometry class (and the derived classes) do not respects the Rule of 3<br>> > : there is a destructor and no copy constructor or assignment operator.<br>> <br>> Indeed, the Rule of 3 is not currently really implemented in the C++ API.<br>> <br>> > It<br>> > seems to me that this may lead to memory leaks on OGRSpatialReference (for<br>> > example when using std::vector<OGRPoint> and not std::vector<OGRPoint*>).<br>> > This is not an issue when using the C API because the clone() method is<br>> > used. Am I well understanding the API ?<br>> > <br>> > Various solutions exists:<br>> > 1) defines private copy constructors and assignment operators (eg. libkml<br>> > does this with a macro on each class: LIBKML_DISALLOW_EVIL_CONSTRUCTORS)<br>> > 2) implements these methods, and manage poSRS the same way that clone() <br>> > does. 3) do nothing (and document it somewhere)<br>> > <br>> > If needed I may open an issue and/or send a patch.<br>> <br>> Option 2 looks good to me if you want to prepare a patch for it. Test cases in <br>> autotest/cpp/test_ogr.cpp would be appreciated.<br>> <br>> Even<br>> <br>> -- <br>> Spatialys - Geospatial professional services<br>> http://www.spatialys.com<br></div> </div></body>
</html>