[MapServer-dev] MapServer C++ ification

[Even Rouault]

Le 09/08/2023 à 22:29, Steve Lime a écrit :
> Hi all: I've been wondering what it would take to start moving 
> MapServer towards C++. Currently we have a bit of a mixed bag, mostly 
> C with C++ used:
>
>  1. When required with C++ libs like Agg.
>  2. For any new development, for example, OGC API and config file
>     stuff is C++.
>  3. Conversion work Even has spearheaded (e.g. mappostgis.cpp).
>
> A full-on rewrite is probably not in the cards anytime but are there 
> steps that could/should be taken to move in that direction? For 
> example, is there any value in converting .c to .cpp and using the C++ 
> compiler and fixing errors? When doing a conversion are there 
> particular C patterns that would be ripe for reworking in C++? Are 
> there any tools that might help with something like this?

C++ has a somewhat stricter type checking, particularly it doesn't like 
mixing char* and const char* to avoid altering strings that the user 
meant to be immutable.

Being able to use conveniences like std::string is a big win compared to 
the risky C string manipulations, and having to care about explicit 
allocation/deallocation. Using containers like std::vector, set or map 
is also convenient.

That said, it is a quite significant work to change the interfaces of 
functions to use those C++ types, especially as we don't have a very 
tight public C API (to my taste, we export too many things that should 
be kept as implementation details. I assume a number of them are just 
the accidental result of pasting existing definitions).

I'm not even speaking about making MapServer main structures C++ 
classes, which would make a number of things prettier (cf *), but would 
be an even harder challenge, as it would be very difficult to do in an 
incremental way, and that would be tricky to have it still fully 
backward compatible with the current use of the C API. For examples, 
users of the C API couldn't just msMalloc() / msFree() on the C++'ifed 
structures. They would have to use dedicated C allocators & deallocators 
that would do the appropriate new and delete calls, and the C++ classes 
definition should be fully opaque to the C API, which they aren't.

So our freedom of changing is also restricted by all that. The retrofits 
I did were mostly on changing implementation details within functions, 
or changes in the interface of static methods

Even

(*) Which would make it possible to rewrite this extract of 
FLTGetTimeExpression():

     expressionObj old_filter;
     msInitExpression(&old_filter);
     msCopyExpression(&old_filter, &lp->filter); /* save existing filter */
     msFreeExpression(&lp->filter);
     ... do something ...
     msCopyExpression(&lp->filter, &old_filter); /* restore old filter */
     msFreeExpression(&old_filter);

     as just:

     expressionObj old_filter(std::move(lp->filter)); /* save existing 
filter */
     lp->filter.clear();
     ... do something ...
     lp->filter = std::move(old_filter);


Even

-- 

http://www.spatialys.com
My software is free, but my time generally not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20230809/0200dcee/attachment.htm>