[GRASS-dev] [GRASS-SVN] r60054

[Huidae Cho]

I think that it's better to hide implementation details such as the
Map_info structure, then we don't have to worry about user code making
unexpected changes in the Map_info structures. As long as we keep track of
open maps, close/delete them when needed and implement the accessor
functions, the user doesn't need to access Map_info, I think. Are there any
good reasons why we have to expose the Map_info structure to module
developers?

Huidae


On Thu, May 8, 2014 at 12:01 PM, Glynn Clements <glynn at gclements.plus.com>wrote:

>
> Huidae Cho wrote:
>
> > Why don't we keep an array of Map_info only internally (private to
> > libvect), just like R__.fileinfo, and use an integer map descriptor at
> high
> > level? Then we can implement accessor functions, only through which high
> > level routines can read/write map properties.
>
> It doesn't necessarily have to be an integer (although that would
> avoid the issue of code bypassing the accessor functions and
> dereferencing the pointer locally).
>
> The fact that an integer is used for raster maps is largely a
> historical accident. Prior to 7.0, the "descriptor" was the actual
> file descriptor of the cell/fcell file (hence the common use of the
> name "fd" for the variable holding the descriptor). As file
> descriptors are small, non-negative integers, this could be (and was)
> used as the index into a table which held other information about the
> map.
>
> In 7.0, the "descriptor" is only the index into the table
> (R__.fileinfo[fd]). The actual file descriptor for the cell/fcell file
> is stored in R__.fileinfo[fd].data_fd. This avoids wasting a slot for
> each open file which isn't a raster map's cell/fcell file.
>
> > > > which in turn sounds like something for GRASS 8.
> > >
> > > FWIW, the first 6.0 beta was tagged on 2005-01-12, i.e. over 9 years
> > > ago. Unless there's a reason to believe that 7.0->8.0 will happen
> > > somewhat quicker than 6.0->7.0, 8.0 is too long to wait.
> >
> > I think it all depends on how we want to change the vector lib. IMHO,
> only
> > adding an array of open Map_infos would not be very invasive, but
> > synchronizing with librast (e.g., using a map descriptor and hiding
> > Map_info) would take a lot more work and need to wait until 8.0.
>
> Provided that modules (or higher-level libraries) don't try to do
> anything unexpected with the Map_info structures, we could just keep a
> table of pointers.
>
> Problems only arise if code does something like passing in a pointer
> to one structure when opening a map, copying it, then passing in a
> pointer to the copy when closing it. With the existing API, this would
> probably work.
>
> I find it hard to envisage code actually doing that, but it's not
> something which could easily be checked statically (i.e. by analysing
> the code). We'd have to implement the internal table-of-pointers, add
> code to check that any Map_info pointers passed to other functions
> were already in the table, then run tests (or rely upon the users
> reporting any warnings).
>
> --
> Glynn Clements <glynn at gclements.plus.com>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/grass-dev/attachments/20140509/26ae64b5/attachment-0001.html>