[Bug 24618] [0.11] add TpStringPool, a refcounted pool of strings

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=24618

--- Comment #7 from Simon McVittie <simon.mcvittie at collabora.co.uk> 2010-04-20 08:53:13 PDT ---
Diffing the right branch this time (sorry about that):

The handle-leak-debug machinery in handle-repo-dynamic.c seems to be unused
now? You'll probably need to delete it, otherwise the build will fail if you
--enable-handle-leak-debug. (Please do that and see whether everything still
compiles.)

I don't like the replacement of "handle" with "reference"... we already have a
thing called a reference, and this isn't it. Of your suggestions, I think "key"
is my favourite, although we'd have to rename the key_id argument of the qdata
functions (easy, call it "quark" or something).

Perhaps rename like this?

guint32 reference => guint32 key
TpStringPoolReferencePriv => TpStringPoolEntry
reference_to_priv => key_to_entry (or entries)
string_to_reference => string_to_key

> +#ifdef ENABLE_REFERENCE_LEAK_DEBUG

I think that's a poor name for this functionality: I'd automatically assume
that was tracking GObject ref leaks. (--enable-string-pool-leak-debug might be
better.) Also, you haven't changed configure.ac to remove
--enable-handle-leak-debug and replace it with this?

The practical effect of this debug mode is to consider it to be a problem if a
string pool is destroyed with strings allocated to it. Whether that's the case
or not depends on usage - if we're going to consider that to be an error, then
we should probably have a tp_string_pool_release_all() method that can be used
just before destroying the string pool if you don't care if it still has
contents, or something?

(Or, we could just drop this functionality...)

I think it'd make the code clearer if we called strings "s" rather than "id",
probably - the string pool doesn't care what the string means, so the string
isn't guaranteed to be any sort of identifier.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.