> Is this the correct understanding - that string values are never free()'ed?
If they are not allocated by IUP they must not be freed by IUP. Yes, they are never freed. That's why you can also store any pointer in a custom attribute to be retrieved later inside a callback, for instance. > Am I correct to assume that these copies are allocated from the heap? If they are allocated from the heap whose responsibility is it to free these values when the associated Ihandle has been deallocated/destroyed? They are allocated/released always using malloc and free. Any memory IUP allocates it is IUP's responsibility to release it when the control is destroyed. > but did we just leak memory for "bar1"? No. IUP knows when FOO was set with a duplicated memory allocation. If that attribute is set again, that old memory is properly release before any type of new assignment. > These same questions (seem) to apply to the IupConfig() family of functions. Do they follow an identical memory ownership model as regular Ihandle attributes? Yes, IupConfig internally use regular IupSet* functions with a twist to combine group and variable names. > Effectively who must manage the memory associated with value attributes: IUP or the user code that sets them (and possibly replaces one value with another). Depends which function you use. Best, Scuri Em sex., 17 de abr. de 2020 às 13:29, Glenn Schmottlach < gschmottl...@hotmail.com> escreveu: > I am having trouble getting my head around the memory ownership model for > IUP's implementation of > > IupSetAttribute() > > And the "string" related value functions like: > > IupSetStrAttribute() > IupSetStrf() ... > > As I understand the documentation, IupSetAttribute() only stores > references to strings but does NOT assume ownership of that memory. This > means constant strings can be stored there, even local (stack-based) > strings as long as they go out of scope AFTER the Ihandle associated with > the attribute has been de-allocate/destroyed. This seems to imply that IUP > makes absolutely no effort to ever "free" strings associated with an > attribute when the Ihandle goes out of scope or is destroyed. Is this the > correct understanding - that string values are never free()'ed? > > I am trying to understand how IupSetStrAttribute(), IupSetStrf() are > different. The documentation states that these functions make a copy of the > provided attribute value. Am I correct to assume that these copies are > allocated from the heap? If they are allocated from the heap whose > responsibility is it to free these values when the associated Ihandle has > been deallocated/destroyed? If IUP frees these strings, how does it > differentiate between heap allocated string values and constant ones that > don't exist in the heap? Assuming I set all my attributes using > IupSetStrAttribute() and friends is it the expectation the user is > explicitly responsible for freeing the attribute values (e.g the library > does not do it)? Is there a way to tell whether an attribute value resides > on the heap or elsewhere? > > I can envision this scenario: > > /* Constant string - not allocated on the heap and no need to ever free. */ > IupSetAttribute(hnd, "FOO", "bar"); > > /* Constant string "bar" is replaced by heap memory allocated for > formatted "bar1" string */ > IupSetStrf(hnd, "FOO", "bar%d", 1); > > /* Heap memory allocated for formatted "bar2" string - but did we just > leak memory for "bar1"? */ > IupSetStrf(hnd, "FOO", "bar%d", 2); > > > These same questions (seem) to apply to the IupConfig() family of > functions. Do they follow an identical memory ownership model as regular > Ihandle attributes? > > Effectively who must manage the memory associated with value attributes: > IUP or the user code that sets them (and possibly replaces one value with > another). > > Thanks for any insights that can be offered . . . > > > _______________________________________________ > Iup-users mailing list > Iup-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/iup-users >
_______________________________________________ Iup-users mailing list Iup-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/iup-users