 |
 |
On Sep 23, 1:00pm, Dick Hendrickson wrote: > Subject: Re: A rare behaivor of pointers > At 11:57 AM 9/23/98 -0400, Peter Shenkin wrote: > >On Sep 23, 5:46pm, Thorsten Ohl wrote: > >> Subject: Re: A rare behaivor of pointers > >... > >> The area where the undifined status hurts (me) most is the need to use > >> pointers as poor man's allocatable components in user defined types. > >> F95 helps a lot and F2K will (hopefully) be even better. > > > >Sorry, but why does it hurt you there especially? I mean, when > >you allocate a user-defined type, you have to initialize all the > >components explicitly (F90) or implicitly (F95). Why is this problem > >worse here than elsewhere? > > > > I think the problem is with derived type variables that include pointers > and have a module that does the work on them. The varying length > character string module is an example. Variables are declared in user > routines > and then the module tries to do something with them. But, the module > routines don't know whether or not they can release the storage > "associated" with the pointer because they can't tell if it has been > initialized or not. A user thinks he's initializing a string variable > when he does something like > v_l_s_thing = "starting_value" > but the defined assignment routine can't tell whether or not this is the > first use of the internal pointer. So storage leaks. > > One solution is to have initializer routines that the user must call, but > people forget and there isn't a good way for the module to detect that. > Yes, forgetting is a case of people using the module incorrectly, but > it happens. This is exactly the same mistake as a user forgetting to initialize some other kind of variable. This happens, too. There are other ways of doing things that avoid this; for instance, require the user to call a module routine to obtain the variable in the first place; the module routine returns a pointer to internal, hidden storage which has just been properly initialized. Of course, you could say, "What if the user forgets to call this function before trying to use the variable." There's no way to safeguard against every kind of dumb error, and we all make our share of them on a regular basis. I mean, even if pointers are NULL() by default when created, failure to pass the user-defined variable to the initialization routine is likely to cause havoc anyway, due to the uninitialized status of the other elements of the user-defined type. Again, I just don't see why failure of the pointer to be initialized by default is worse than the failure of anything else to be initialized by default, and I don't hear everybody pissing and moaning that you can't do that -- so why this? Finally, you can able to specify default intializations of all user-defined-type elements in F95, so this problem, if is or was one, went away three years ago. :-) -P. -- *** "Freedom's just another word for nothing left to lose." (B. Yeltsin)*** *Peter Shenkin; Chemistry, Columbia U.; [log in to unmask] (212)854-5143* *MacroModel WWW page: http://www.columbia.edu/cu/chemistry/mmod/mmod.html * %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%