[MapServer-dev] MapServer C++ ification

[Lime, Steve D (MNIT)]

Thanks for the detailed response as always. From your comments it sounds like just having access to std::string would be worth it. So convert things .cpp and do targeted, high-value refactoring mostly around string manipulation to start. At the same time we could visit the public C API - I honestly don't know how much that is used by folks but I definitely agree that's much more expansive than it needs to be.

From: MapServer-dev <mapserver-dev-bounces at lists.osgeo.org> On Behalf Of Even Rouault
Sent: Wednesday, August 9, 2023 4:50 PM
To: Steve Lime <sdlime at gmail.com>; MapServer Dev Mailing List <mapserver-dev at lists.osgeo.org>
Subject: Re: [MapServer-dev] MapServer C++ ification

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<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/20230811/d6bd33d8/attachment.htm>