External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-08-06 17:03:49 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: glib-adoption: split into sections

Browse Source 
Although all the mentioned functions deal with
allocation, replacing the pure allocation
functions is easier than converting code to
use GArrays.

Split them out to encourage usage of GLib
allocation APIs even at the cost of them
being combined with VIR_*ELEMENT APIs.

Signed-off-by: Ján Tomko <jtomko@redhat.com>
Reviewed-by: Andrea Bolognani <abologna@redhat.com>
This commit is contained in:
Ján Tomko 2020-09-24 13:50:49 +02:00
parent 080ab92587
commit 900e54ed2e
1 changed files with 16 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
docs/glib-adoption.rst
View File

@ -14,14 +14,21 @@ the GLib APIs straight away where possible.
The following is a list of libvirt APIs that should no longer be The following is a list of libvirt APIs that should no longer be
used in new code, and their suggested GLib replacements: used in new code, and their suggested GLib replacements:
``VIR_ALLOC``, ``VIR_REALLOC``, ``VIR_RESIZE_N``, ``VIR_EXPAND_N``, ``VIR_SHRINK_N``, ``VIR_FREE``, ``VIR_APPEND_ELEMENT``, ``VIR_INSERT_ELEMENT``, ``VIR_DELETE_ELEMENT`` Memory allocation
``VIR_ALLOC``, ``VIR_REALLOC``, ``VIR_RESIZE_N``,
``VIR_EXPAND_N``, ``VIR_SHRINK_N``, ``VIR_FREE``
Prefer the GLib APIs ``g_new0``/``g_renew``/ ``g_free`` in most Prefer the GLib APIs ``g_new0``/``g_renew``/ ``g_free`` in most
cases. There should rarely be a need to use cases. There should rarely be a need to use
``g_malloc``/``g_realloc``. Instead of using plain C arrays, it ``g_malloc``/``g_realloc``. **NEVER MIX** use of the classic
is preferrable to use one of the GLib types, ``GArray``, libvirt memory allocation APIs and GLib APIs within a single
``GPtrArray`` or ``GByteArray``. These all use a struct to method. Keep the style consistent, converting existing code to
track the array memory and size together and efficiently GLib style in a separate, prior commit.
resize. **NEVER MIX** use of the classic libvirt memory
allocation APIs and GLib APIs within a single method. Keep the Array operations
style consistent, converting existing code to GLib style in a ``VIR_APPEND_ELEMENT``, ``VIR_INSERT_ELEMENT``, ``VIR_DELETE_ELEMENT``
separate, prior commit.
Instead of using plain C arrays, it is preferrable to use one of
the GLib types, ``GArray``, ``GPtrArray`` or ``GByteArray``.
These all use a struct to track the array memory and size
together and efficiently resize.