[gnome-devel-docs] programming-guidelines: Clarify memory management coding style



commit 5fca5a4e6f2b17e79fb2e5aec518d61268123972
Author: Philip Withnall <philip withnall collabora co uk>
Date:   Thu Feb 12 14:40:37 2015 +0000

    programming-guidelines: Clarify memory management coding style
    
    Fix an ingrammatical sentence in c-coding-style, add a cross-reference
    to the memory-management page, and clarify (in a <comment>) on that page
    why we don’t mention GSlice anywhere.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=744355

 programming-guidelines/C/c-coding-style.page    |    7 +++++--
 programming-guidelines/C/memory-management.page |    9 +++++++++
 2 files changed, 14 insertions(+), 2 deletions(-)
---
diff --git a/programming-guidelines/C/c-coding-style.page b/programming-guidelines/C/c-coding-style.page
index e5b25e0..5438186 100644
--- a/programming-guidelines/C/c-coding-style.page
+++ b/programming-guidelines/C/c-coding-style.page
@@ -896,8 +896,7 @@ typedef struct _GtkFooableInterface     GtkFooableInterface;</code>
     <title>Memory Allocation</title>
 
     <p>
-      When dynamically allocating data on the heap either use
-      <code>g_new()</code>.
+      When dynamically allocating data on the heap use <code>g_new()</code>.
     </p>
 
     <p>
@@ -905,6 +904,10 @@ typedef struct _GtkFooableInterface     GtkFooableInterface;</code>
       zero-ed, either explicitly for each member, or by using
       <code>g_new0()</code>.
     </p>
+
+    <p>
+      See <link xref="memory-management"/> for more details.
+    </p>
   </section>
 
   <section id="macros">
diff --git a/programming-guidelines/C/memory-management.page b/programming-guidelines/C/memory-management.page
index 3f53d89..45303bd 100644
--- a/programming-guidelines/C/memory-management.page
+++ b/programming-guidelines/C/memory-management.page
@@ -21,6 +21,15 @@
 
   <comment>
     <p>
+      Note: GSlice is deliberately not mentioned on this page because we don’t
+      want to encourage its use. GLib developers are moving towards deprecating
+      it due to its performance slipping significantly behind the libc
+      allocator’s on Linux in recent years.
+    </p>
+  </comment>
+
+  <comment>
+    <p>
       FIXME:
     </p>
     <list>


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