<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">Le 09/08/2023 à 22:29, Steve Lime a
écrit :<br>
</div>
<blockquote type="cite"
cite="mid:CAMrKZ98pte_t06jeeDj5CjuJpcvG-HK==WEQxDy9RZhkyA6H2A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">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:
<div>
<ol>
<li>When required with C++ libs like Agg.</li>
<li>For any new development, for example, OGC API and config
file stuff is C++.</li>
<li>Conversion work Even has spearheaded (e.g.
mappostgis.cpp).</li>
</ol>
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?</div>
</div>
</blockquote>
<p>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.<br>
</p>
<p>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.</p>
<p>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).<br>
</p>
<p>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.<br>
</p>
<p>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</p>
<p>Even<br>
</p>
<p>(*) Which would make it possible to rewrite this extract of
FLTGetTimeExpression():<br>
</p>
<p> expressionObj old_filter;<br>
msInitExpression(&old_filter);<br>
msCopyExpression(&old_filter, &lp->filter); /* save
existing filter */<br>
msFreeExpression(&lp->filter);<br>
... do something ...<br>
msCopyExpression(&lp->filter, &old_filter); /*
restore old filter */<br>
msFreeExpression(&old_filter);</p>
<p> as just:<br>
</p>
<p> expressionObj old_filter(std::move(lp->filter)); /* save
existing filter */<br>
lp->filter.clear();<br>
... do something ...<br>
lp->filter = std::move(old_filter);<br>
</p>
<p></p>
<br>
<p>Even</p>
--
<pre class="moz-signature" cols="72"><a class="moz-txt-link-freetext" href="http://www.spatialys.com">http://www.spatialys.com</a>
My software is free, but my time generally not.</pre>
</body>
</html>