This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
------- Forwarded Message Date: Mon, 12 Jul 2004 09:50:34 -0600 From: Russ Rew <address@hidden> To: der Mouse <address@hidden> cc: ed Subject: Re: 20040703: Some NetCDF C interface doc issues (cont.) >To: address@hidden >From: der Mouse <address@hidden> >Subject: Some NetCDF C interface doc issues >Organization: ? >Keywords: 200407030332.i633WhaW006446 Hi der Mouse, > * All the nc_put_var1_* functions take pointers to the data to store. > This makes no sense to me; why not simply pass the datum directly > rather than forcing the caller to allocate a variable to store it? Ed responded to many of your suggestions on the documentation, and you wrote back: > > Or am I reading your question wrong? Do you really want to do > > something like this? > > > nc_put_var1_int(ncid, varid, index, 99); > > Exactly. (Mutatis mutandis, that is. See below.) > > > If so, you're right, that won't work. However it seems like few > > programs would be writing a data constant with nc_put_var1_int. > > Oh, the last arg doesn't have to be a constant, and in the case at hand > it wasn't. I wanted to do > > nc_put_var1_float(dsid,v_load,&locv[0],int1/(float)int2); > > but instead I had to allocate a variable, otherwise unused, to hold the > quotient. Thing is, I can't see anything that using a pointer allows > you to do that you can't do at least as well without the pointer, which > leaves me rather baffled about why you designed it that way. Either > I'm missing something or you did something gratuitously bizarre, and > either way, I'm puzzled. Now that I'm back from vacation, I wanted to offer an explanation/excuse for the interface you are referring to here, since I was one of the four developers who agreed to it. This was done to make the interface simple and consistent, since all the other C functions for putting or getting data take pointers to the data. It was a trade-off between making the interface consistent enough to be easy to remember and making each function call as simple as possible. With the current interface, writing a single array value with the nc_put_vara_* functions is very similar to writing a single value with the nc_put_var1_* functions, and similar to writing or reading array slices with other functions. I agree with you that this seems awkward (or maybe even "gratuitously bizarre") if you use the nc_put_var1_* functions a lot, but giving a name to something you put in an argument list is also helpful to later maintainers, as in: { double rh_value = int1/(float)int2; status = nc_put_var1_double(ncid, rh_id, rh_index, &rh_value); } and the current interface encourages this, although that's not its primary intention. But again, I agree that this is a pretty weak argument for an arguably bad interface, which it's now too late to change ... --Russ ------- End of Forwarded Message