<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 5/7/2016 11:10 AM, Kurt Schwehr
wrote:<br>
</div>
<blockquote
cite="mid:CACmBxyui3pmUV=ADxsr5gqNw+6b5MaMVJsuqKkFSAwAtu2uzNA@mail.gmail.com"
type="cite">This is why starting with zero features and working
our way up with a white list gives examples of correct usage. It
looks like a lot of GDAL development happens by copy-paste-tweak,
so good examples are key. And for every issue, we have solutions
that are valid C/C++03/C++11/C++14... the best solution is not
necessarily in any particular one.
<div>
<div class="gmail_extra">
<div class="gmail_quote"><br>
</div>
</div>
</div>
</blockquote>
Amen.<br>
<blockquote
cite="mid:CACmBxyui3pmUV=ADxsr5gqNw+6b5MaMVJsuqKkFSAwAtu2uzNA@mail.gmail.com"
type="cite">
<div>
<div class="gmail_extra">
<div class="gmail_quote">
<div><br>
</div>
<div>auto poInstance = <span
style="color:rgb(0,0,0);font-size:12.8px;line-height:1.2em;background-color:rgb(249,249,249)">std</span><span
class=""
style="font-size:12.8px;line-height:1.2em;color:rgb(0,128,128)">::</span><span
class=""
style="color:rgb(0,0,0);font-size:12.8px;line-height:1.2em">make_unique<GDALMyBigObj>(arg1,
arg2, arg3);</span></div>
</div>
</div>
</div>
</blockquote>
This example is more powerful than just the elimination of the
opportunities for memory leaks. Kurt has snuck in the use of the
GDALMyBigObj constructor, which makes the initialization of the
object more transparent (and in fact assures that it occurs.) And if
I correctly understand std::make_unique, by making poinstance const,
we can go farther and guarantee that this pointer isn't assigned to
another pointer, so that the object will be destroyed at the end of
current scope. (If the pointer is assigned to another
std::make_unique ptr, the scope of that pointer will control when
the object is destroyed). <br>
<br>
If the use of std::make_unique doesn't make it into the whitelist of
features, we can still achieve a similar goal by using the
GDALMyBigObj directly. Recalling Kurt's concern about growing stack
size, we don't want to declare a GDALMyBigObj in the local scope on
the stack. But we can resolve this contradiction by allocating the
buffer or whatever the space hog is within the constructor for
GDALMyBigObj. If inheritance is deemed to be an encouraged style, we
can even define a GDALBigObj class that encapsulates whatever is the
current best practice for allocating large chunks of space and
GDALMyBigObj just inherits from that. In this case we can use
whatever ugly C++ construct we want to allocate the space since very
few devs will ever have to look at the guts of this base class. As
an added benefit, if in the future there is a better way to allocate
space, we just change the GDALBigObj class and the effect propagates
through the inheritance. (Of course, depending on the use,
inheriting from GDALBigObj might not be conceptually right, in which
case we could just have a GDALBigObj object as a member var of
GDALMyBigObj. )<br>
<br>
<br>
<br>
<br>
</body>
</html>