[GRASS-dev] use G_find_raster2() instead of G_find_raster()

[Vaclav Petras]

On Sat, Nov 2, 2013 at 5:35 AM, Martin Landa <landa.martin at gmail.com> wrote:

> Hi,
>
> 2013/11/1 Glynn Clements <glynn at gclements.plus.com>:
> >> But I'm not able to decide on which occasion I want which function.
> >> Someday, I can try to call both functions with different map/mapset
> >> combinations but reading from manual would be more effective.
> >
> > Please use G_find_raster2() always (similarly for the other G_find_*
> > functions). G_find_raster() exists for backward compatibility only.
> > Having it modify the map name in-place has been the source of
> > countless bugs.
>
> it would be probably better to replace G_find_raster() by
> G_find_raster2() in G7. Any objections?
>
Current situation is apparently confusing for many of GRASS
> programmers. Keeping backward compatibility between G6 (where
> G_find_<maptype>2() have been introduced) and G7 is not necessary in
> this case I would say.
>

So, it is very clear. The only problem was the missing documentation. In G6
we introduced new function A2 to replace function A because function A is
bad. This should be explicitly stated in G6 function A documentation. Now
we have the new major version G7 (which is not supposed to be C API
backwards compatible), so we have to finish the change from A to A2 (in
G7). And than we can also rename the A2 function to A (and optionally leave
there also A2).

Is there a (cross-compiler) way we can use GCC depreciated attribute to
trigger compiler warring in these cases?

__attribute__ ((deprecated))
__attribute__((deprecated("use new_function instead"))

Vaclav


> [...]
>
> Martin
>
> --
> Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20131102/61f590f5/attachment.html>