|
On 5/7/2016 11:10 AM, Kurt Schwehr
wrote:
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.Amen. 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). 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. ) |
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
