<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, May 7, 2016 at 2:00 PM, David Strip <span dir="ltr"><<a href="mailto:gdal@stripfamily.net" target="_blank">gdal@stripfamily.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>On 5/7/2016 11:10 AM, Kurt Schwehr
wrote:<br></div></span></div></blockquote><div> </div></div></div><div class="gmail_extra"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span style="font-size:12.8px">This is cart before the horse but... as fast as I can so expect typos. Now just think of a ~1K long function or method with tons of instances and lots of places to bailout successfully or as failures. </span><span style="font-size:12.8px"> </span> </blockquote></div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class=""><div>
</div>
<blockquote 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></span>
Amen.<span class=""><br>
<blockquote 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 style="font-size:12.8px;line-height:1.2em;color:rgb(0,128,128)">::</span><span 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></span></div></blockquote><div><br></div><div>I think that some of you may be talking about features of a language that you really aren't comfortable with. The notion of disallowing language features because someone thinks they aren't useful or are confusing isn't the way to go, IMO. C++, more than most other languages, goes through pains before features are introduced. Nobody has to use all the features, but all are useful to a subset of users and their proper use either makes the code more clear, more efficient or less prone to bugs. (Yes, auto_ptr was awful, but nobody uses auto_ptr anymore). Regardless of the language or language feature, code can be clear or unclear and it's not the fault of the feature for the lack of clarity. It may be that the reader hasn't seen the use before or it may be that the writer didn't use feature in the best way possible, but to make lists because Fred or Sam don't like this or that isn't productive.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">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).</div></blockquote><div><br></div><div>As someone else said, GDAL code looks like C code, not like well-structured C++. That's OK. But the notion of shoe-horning this or that feature into the codebase seems fraught. If you're going to say that C++ 11 is OK, then fine, use C++ 11 where appropriate in ways that make the code more readable, more efficient or smaller. The reason to disallow a feature shouldn't be about the whims of a developer or two, it should be because compilers you are targeting don't support them or because you have ABI issues. Reviewing code as it's submitted for clarity and efficiency is a much better way to ensure quality code than is coming up with a semi-arbitrary list of acceptable language features. Yes, sometimes even "goto" is a good thing.</div><div><br></div><div>I also don't agree that more features mean more bugs. More features means a language that takes more care to learn, but it doesn't mean more bugs. If you're uncomfortable with move constructors, don't use them. But they are useful at certain times for optimization. The provided example is just confusing and useless code, not an indictment of move constructors. There are plenty of newer language features that make code LESS susceptible to bugs, when used properly.<br></div><div><br></div><div>P.S. - The above would just normally be written:</div><div><br></div><div>std::unique_ptr<GDALMyBigObj> obj(new GDALMyBigObj(arg1, arg2, arg3));</div><div><br></div><div>although without context, it's unclear that this is good bad or neither. If I saw this code without a comment, I'd be tempted to change it to:</div><div><br></div><div>GDALMyBigObj obj(arg1, arg2, arg3);<br></div><div><br></div><div>because, hey, why not put it on the stack? The important bit here is that someone needs to add a comment that it was put on the heap for a reason -- to keep the stack small.</div><div><br></div><div>P.P.S - I used to think lambdas were confusing, useless things. Having now seen and written enough code containing lambdas, I'm happy to admit that I was wrong.</div><div><br></div></div>-- <br><div class="gmail_signature">Andrew Bell<br><a href="mailto:andrew.bell.ia@gmail.com" target="_blank">andrew.bell.ia@gmail.com</a></div>
</div></div>