Hi Martin and others,
I saw r58135. If one function is preferred, manual should state and explain it. I also noticed that there is no find…2 function for 3D rasters. If you understand this topic, please share you knowledge in the manual.
Thanks,
Vaclav
https://trac.osgeo.org/grass/changeset/58135
http://grass.osgeo.org/programming7/find__rast_8c.html
Hi Vaclav,
to my knowledge, it's already explained in the manual.
"""
Note: If the user specifies a fully qualified raster map which exists,
then G_find_raster() modifies name by removing the "@<i>mapset</i>".
""""
Martin
2013/11/1 Vaclav Petras <wenzeslaus@gmail.com>:
Hi Martin and others,
I saw r58135. If one function is preferred, manual should state and explain
it. I also noticed that there is no find...2 function for 3D rasters. If you
understand this topic, please share you knowledge in the manual.Thanks,
Vaclavhttps://trac.osgeo.org/grass/changeset/58135
http://grass.osgeo.org/programming7/find__rast_8c.html
http://grass.osgeo.org/programming7/find__vect_8c.html
http://grass.osgeo.org/programming7/find__rast3d_8c.html
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Fri, Nov 1, 2013 at 10:32 AM, Martin Landa <landa.martin@gmail.com>wrote:
Hi Vaclav,
to my knowledge, it's already explained in the manual.
"""
Note: If the user specifies a fully qualified raster map which exists,
then G_find_raster() modifies name by removing the "@<i>mapset</i>".""""
Yes, and also
"""
The same as G_find_vector() but doesn't remove the "@<i>mapset</i>"
qualification from name, if present.
"""
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.
Martin
2013/11/1 Vaclav Petras <wenzeslaus@gmail.com>:
> Hi Martin and others,
>
> I saw r58135. If one function is preferred, manual should state and
explain
> it. I also noticed that there is no find...2 function for 3D rasters. If
you
> understand this topic, please share you knowledge in the manual.
>
> Thanks,
> Vaclav
>
> https://trac.osgeo.org/grass/changeset/58135
>
> http://grass.osgeo.org/programming7/find__rast_8c.html
> http://grass.osgeo.org/programming7/find__vect_8c.html
> http://grass.osgeo.org/programming7/find__rast3d_8c.html
>--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
Vaclav Petras wrote:
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.
Note that the first argument to G_find_raster() is "char *", rather
than "const char *", so if you have a "const" string you must use
G_find_raster2().
Even if the string isn't explicitly declared "const", the fact that it
may be modified means that if you need to retain the original value,
you have to explicitly copy it.
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2013/11/1 Glynn Clements <glynn@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.
[...]
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Sat, Nov 2, 2013 at 5:35 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2013/11/1 Glynn Clements <glynn@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
Martin Landa wrote:
>> 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?
Not from me. For code which specifically needs an unqualified name,
use G_unqualified_name() or G_name_is_fully_qualified().
--
Glynn Clements <glynn@gclements.plus.com>
Vaclav Petras wrote:
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"))
That's fine. gis.h defines the __attribute__ macro (as a no-op) if gcc
isn't being used.
--
Glynn Clements <glynn@gclements.plus.com>
Hi,
2013/11/4 Glynn Clements <glynn@gclements.plus.com>:
Martin Landa wrote:
>> 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?Not from me. For code which specifically needs an unqualified name,
use G_unqualified_name() or G_name_is_fully_qualified().
perfect, is there any volunteer for this job? Unfortunately I will not
find time for that not earlier than in some weeks. And we should also
check other V2() functions.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa
On Mon, Nov 4, 2013 at 5:28 AM, Martin Landa <landa.martin@gmail.com> wrote:
Hi,
2013/11/4 Glynn Clements <glynn@gclements.plus.com>:
>
> Martin Landa wrote:
>
>> >> 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?
>
> Not from me. For code which specifically needs an unqualified name,
> use G_unqualified_name() or G_name_is_fully_qualified().perfect, is there any volunteer for this job? Unfortunately I will not
find time for that not earlier than in some weeks. And we should also
check other V2() functions.Same here, maybe, in the meantime, I will add the depreciated attribute
there, that should be quick and it would be good to test it anyway.
Martin
--
Martin Landa <landa.martin gmail.com> * http://geo.fsv.cvut.cz/~landa