[mapserver-dev] MOTION: adopt RFC 128: Make C99 and C++11 build requirements

[Even Rouault]

> The question I have is how to get it done. Even, was this something you
> were going to take on? Something we would want to divide and conquer? Can
> it be done incrementally? Is this something we could use 2019 budget $'s
> for (we have $2,500 available)?

Steve,

As mentionned in the RFC, the main intent of it is mostly to make it possible 
to adopt new coding style(s). I don't have a grand plan to refactor the whole 
code base. Sorry... (or maybe luckily. Every change has the potential to break 
things, so we'd better check that the code paths modified are reasonably 
tested by msautotest)

I'd say that with C99 now available, devs should really stop stuffing all 
variable declarations at the top of functions, and use them just in the scope 
where they are needed. This is something that can be easily done 
incrementally.
Porting existing code to C++ is a much more difficult task. But I'd say that 
if someone want to use some facilities the language offer (thinking to data 
structures like vectors, hash sets/maps, etc... Or automatic memory 
management) to create new code, they should seriously consider it.

Changing the internal interfaces of MapServer would be significant work, but 
implementation details can certainly benefit from some C++isms. Like using 
std::string for temporary string manipulations.

If we had to do it now, all the layer vtable mechanism is something that 
should be implemented with C++ virtual methods. But the benefit / (cost*risk) 
of refactoring the exiting code is far less obvious.

I can tell you a bit with my experience with PROJ. In PROJ 6, we "converted" 
all .c files into .cpp, meaning renaming them from .c to .cpp, adding extern 
"C" { } where needed, and fixing warning/errors. All new functionnality, which 
was not interacting or very little with the historic C code base was coded in 
C++. Bridging the existing historic C code and C++ is the challenging part. 
For example, if you want to add a C++ object as a member of what was 
previously a pure C structure, you need to make sure that all code paths that 
allocate/destroy it use the new/delete C++ operators and not malloc/free C 
functions.
Example just from today:
- adding here a C++ object in a structure:
https://github.com/rouault/PROJ/commit/
78298d1335838ad45499fb2d7f2deb5d0a6c5589#diff-8d43d921d30ce0c05f84f46da4a3203eR19
- implies to change the allocator from pj_calloc() to new:
https://github.com/rouault/PROJ/commit/
78298d1335838ad45499fb2d7f2deb5d0a6c5589#diff-8d43d921d30ce0c05f84f46da4a3203eR98
- and make sure the structure is freed with delete:
https://github.com/rouault/PROJ/commit/
78298d1335838ad45499fb2d7f2deb5d0a6c5589#diff-8d43d921d30ce0c05f84f46da4a3203eR91

So this is done by very little steps, when it is needed.

As far as I'm concerned, I don't have remaining bandwidth for 2019.

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com