[gdal-dev] Refactoring: class members clean-up

[Mateusz Loskot]

On 17 October 2015 at 12:54, Even Rouault <even.rouault at spatialys.com> wrote:
> Le samedi 17 octobre 2015 00:25:45, Kurt Schwehr a écrit :
>> I personally like foo_, but m_ is fine.  I worry about unexpected side
>> effects of changing member naming with private members.  I don't think
>> there will be any if everything builds, but I still worry.
>
> There can be subtle effects indeed, so care should be taken.
>
> Consider the following example (just for the fun) :
>
> [...]


I'm not going to argue if it si common or a bit convoluted case
with limtied scope, it is a good example.

To avoid introducing new bugs, I suggest to use refactoring tools offered by
any modern IDE. VS2015 handles your case flawlessly. I'd expect the same
from Qt Creator or Clion and others.

Potential of such problems is a good reason to use namespaces,
include common C98/C++ headers via C++ equivalents , #include <c*>,
i.e. <cstring>,
and import C stuff via std namespace. Then, such bugs are caught by compiler.

<strings.h> is part of POSIX, means it delivers C definitions,
so there is no std namespace there, but majority of GDAL is C++.

I'm not sure if such clean up is also on Kurt's list, but again, I can help.

Best regards,
-- 
Mateusz  Loskot, http://mateusz.loskot.net