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 <[email protected]>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 <[email protected]> >
_______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
