bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Non-opaque hamt type?


From: Bruno Haible
Subject: Re: Non-opaque hamt type?
Date: Sun, 18 Oct 2020 19:58:27 +0200
User-agent: KMail/5.1.3 (Linux/4.4.0-189-generic; KDE/5.18.0; x86_64; ; )

Marc Nieper-Wißkirchen wrote:
> The existing protocol is as follows:
> 
> Hamt_entry *e = hamt_entry (...);
> Hamt_entry *p = e;
> Hamt *new_hamt = hamt_insert (old_hamt, &p);
> if (old_hamt == new_hamt)
>   {
>     /* The element hasn't been insert as an equivalent element has already 
> been in the hamt. p now holds a reference to the entry that already existed 
> in the hamt.
>     element_free (e);
>     ...
>     hamt_free (old_hamt); /* We don't have to free new_hamt because no new 
> hamt was created. */
>   }
> else
>   {
>     /* The element has been inserted. p hasn't changed. */
>     ...
>     hamt_free (old_hamt);  /* This frees all hamts */
>     hamt_free (new_hamt); /* and all elements inserted, including e. */
>   }
> 
> A protocol where no pointer values need to be compared could use p to
> carry the information:
> 
> Hamt_entry *e = hamt_entry ();
> Hamt_entry *p = e;
> Hamt new_hamt = hamt_insert (old_hamt, &p);
> if (p == e)
>   {
>     /* The element has been inserted. */
>     ... /* See above. */
>   }
> else if (p == NULL)
>   {
>     /* The element e already existed in the hamt. */
>    ... /* See above. */
>   }
> else /* p != e && p != NULL */
>   {
>     /* An element equivalent to e already existed in the hamt. p now holds 
> this element. */
>     ... /* See above. */
>   }

I find the latter protocol more robust: it does not depend on details of
the implementation of hamt_insert.

Can you decide on your original question (allow stack-allocated HAMTs)?
I don't feel I can help you decide this.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]