>  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

Reply via email to