summaryrefslogtreecommitdiff
path: root/pages/develop/tutorials
diff options
context:
space:
mode:
authorXavi Artigas <xavierartigas@yahoo.es>2018-05-25 10:24:38 -0700
committerapache <apache@e5-web1.enlightenment.org>2018-05-25 10:24:38 -0700
commit3d6083076c3655f179533c41cc95a04036a59300 (patch)
tree6309867347d4497b20e3d8a1fe7e39c4f6baf373 /pages/develop/tutorials
parent67539c96933e81d298e25ecdc4bc60c83a39ed16 (diff)
Wiki page eo-refcount.md changed with summary [Updated to efl_new] by Xavi Artigas
Diffstat (limited to 'pages/develop/tutorials')
-rw-r--r--pages/develop/tutorials/c/eo-refcount.md.txt20
1 files changed, 10 insertions, 10 deletions
diff --git a/pages/develop/tutorials/c/eo-refcount.md.txt b/pages/develop/tutorials/c/eo-refcount.md.txt
index 61818e76b..bd28fde50 100644
--- a/pages/develop/tutorials/c/eo-refcount.md.txt
+++ b/pages/develop/tutorials/c/eo-refcount.md.txt
@@ -6,7 +6,7 @@
6 6
7The previous tutorial ([Introduction to Eo](eo-intro.md)) explained how you should create and destroy Eo objects in order to avoid *memory leaks*. The present tutorial shows graphically the inner workings of the reference counting mechanism. 7The previous tutorial ([Introduction to Eo](eo-intro.md)) explained how you should create and destroy Eo objects in order to avoid *memory leaks*. The present tutorial shows graphically the inner workings of the reference counting mechanism.
8 8
9To do so, some new *instrumentation* techniques are introduced. These techniques allow collecting information about the state of your program, and, although not frequently used in normal applications, they can be useful for debugging purposes. 9To do so, some new *instrumentation* techniques are introduced. These techniques allow collecting information about the state of your program, and, although not frequently used in normal applications, they can be useful for debugging (and tutorial) purposes.
10 10
11## Prerequisites ## 11## Prerequisites ##
12 12
@@ -36,7 +36,7 @@ static void
36_obj_create() 36_obj_create()
37{ 37{
38 // First create a root element 38 // First create a root element
39 _root = efl_add(EFL_MODEL_ITEM_CLASS, NULL, 39 _root = efl_new(EFL_MODEL_ITEM_CLASS,
40 efl_name_set(efl_added, "Root")); 40 efl_name_set(efl_added, "Root"));
41 41
42 // Create the first child element 42 // Create the first child element
@@ -120,7 +120,7 @@ The expected behavior is *undefined*, which usually means your program will abor
120 120
121You can always ask an object for its internal reference count... as long as the object still exists. The problem with the above code is that when a reference count reaches 0, the object is destroyed. If you still hold a pointer to that object (like ``_root`` or ``_child1``) that pointer is *invalid*, and trying to use it as a parameter to any EFL call will result in an *undefined behavior*. 121You can always ask an object for its internal reference count... as long as the object still exists. The problem with the above code is that when a reference count reaches 0, the object is destroyed. If you still hold a pointer to that object (like ``_root`` or ``_child1``) that pointer is *invalid*, and trying to use it as a parameter to any EFL call will result in an *undefined behavior*.
122 122
123In summary, the first call to ``_status_print()`` succeeded because the objects where alive, but the second one, after calling ``_obj_destroy()``, crashed because all the objects had been destroyed, and hence their pointers where invalid. 123**In summary:** the first call to ``_status_print()`` succeeded because the objects where alive, but the second one, after calling ``_obj_destroy()``, crashed because all the objects had been destroyed, and hence their pointers where **invalid**.
124 124
125In your applications, you should not try to use an object after you returned the reference you had to it, so you should not encounter this problem. In some rare cases, though, for debugging or didactic purposes, you might want to examine the state of an object, even after it has been destroyed. 125In your applications, you should not try to use an object after you returned the reference you had to it, so you should not encounter this problem. In some rare cases, though, for debugging or didactic purposes, you might want to examine the state of an object, even after it has been destroyed.
126 126
@@ -142,7 +142,7 @@ Eo *_root_ref, *_child1_ref, *_child2_ref;
142 142
143As you can see, wrefs are also regular ``Eo`` pointers; you can use them anywhere you would use an object pointer. 143As you can see, wrefs are also regular ``Eo`` pointers; you can use them anywhere you would use an object pointer.
144 144
145In fact, you could get rid of the previous plain object pointers (``_root``, ``_child1`` and ``_child2``) and only use the wrefs from now on. This tutorial keeps them separate to highlight that plain object pointers will become invalid, whereas wrefs will become NULL. 145In fact, you could get rid of the previous plain object pointers (``_root``, ``_child1`` and ``_child2``) and only use the wrefs from now on. This tutorial keeps them separate to highlight that plain object pointers will become invalid, whereas wrefs will become ``NULL``.
146 146
147Now, replace the previous usage of the plain object pointers in the ``printf()`` call in ``_status_print()`` with the wrefs: 147Now, replace the previous usage of the plain object pointers in the ``printf()`` call in ``_status_print()`` with the wrefs:
148 148
@@ -155,7 +155,7 @@ Now, replace the previous usage of the plain object pointers in the ``printf()``
155 [...] 155 [...]
156``` 156```
157 157
158Finally, create the wrefs by adding a call to ``efl_wref_add()`` after each call to ``efl_add()`` in the ``_obj_create()`` method. It should look like this: 158Finally, create the wrefs by adding a call to ``efl_wref_add()`` after each object is created in the ``_obj_create()`` method. It should look like this:
159 159
160```c 160```c
161[...] 161[...]
@@ -163,7 +163,7 @@ static void
163_obj_create() 163_obj_create()
164{ 164{
165 // First create a root element 165 // First create a root element
166 _root = efl_add(EFL_MODEL_ITEM_CLASS, NULL, 166 _root = efl_new(EFL_MODEL_ITEM_CLASS,
167 efl_name_set(efl_added, "Root")); 167 efl_name_set(efl_added, "Root"));
168 // Add a weak reference so we can keep track of its state 168 // Add a weak reference so we can keep track of its state
169 efl_wref_add(_root, &_root_ref); 169 efl_wref_add(_root, &_root_ref);
@@ -254,7 +254,7 @@ _parent_name_get(Eo *obj)
254 254
255Remember you will be calling this method in situations where some of the objects might have already been destroyed. Therefore, the first thing this method does is check whether the reference count is 0 with ``efl_ref_count()``. In that case it returns a simple dash "-". 255Remember you will be calling this method in situations where some of the objects might have already been destroyed. Therefore, the first thing this method does is check whether the reference count is 0 with ``efl_ref_count()``. In that case it returns a simple dash "-".
256 256
257Remember also that you can do this, because you are using weak references. Passing an invalid pointer to ``efl_ref_count()`` would result in undefined behavior. 257Remember also that you can do this, because you are using weak references: Passing an invalid pointer to ``efl_ref_count()`` would result in undefined behavior but passing in ``NULL`` is OK.
258 258
259The second thing the method does is check whether the object has a parent or not by calling ``efl_parent_get()``. If it has no parent, it returns "none". 259The second thing the method does is check whether the object has a parent or not by calling ``efl_parent_get()``. If it has no parent, it returns "none".
260 260
@@ -307,7 +307,7 @@ static void
307_obj_create() 307_obj_create()
308{ 308{
309 // First create a root element 309 // First create a root element
310 _root = efl_add(EFL_MODEL_ITEM_CLASS, NULL, 310 _root = efl_new(EFL_MODEL_ITEM_CLASS,
311 efl_name_set(efl_added, "Root")); 311 efl_name_set(efl_added, "Root"));
312 // Add a weak reference so we can keep track of its state 312 // Add a weak reference so we can keep track of its state
313 efl_wref_add(_root, &_root_ref); 313 efl_wref_add(_root, &_root_ref);
@@ -401,7 +401,7 @@ Use it to be notified of the destruction of each object. ``_obj_create()`` shoul
401```c 401```c
402[...] 402[...]
403 // First create a root element 403 // First create a root element
404 _root = efl_add(EFL_MODEL_ITEM_CLASS, NULL, 404 _root = efl_new(EFL_MODEL_ITEM_CLASS,
405 efl_name_set(efl_added, "Root")); 405 efl_name_set(efl_added, "Root"));
406 // Add a weak reference so we can keep track of its state 406 // Add a weak reference so we can keep track of its state
407 efl_wref_add(_root, &_root_ref); 407 efl_wref_add(_root, &_root_ref);
@@ -505,7 +505,7 @@ static void
505_obj_create() 505_obj_create()
506{ 506{
507 // First create a root element 507 // First create a root element
508 _root = efl_add(EFL_MODEL_ITEM_CLASS, NULL, 508 _root = efl_new(EFL_MODEL_ITEM_CLASS,
509 efl_name_set(efl_added, "Root")); 509 efl_name_set(efl_added, "Root"));
510 // Add a weak reference so we can keep track of its state 510 // Add a weak reference so we can keep track of its state
511 efl_wref_add(_root, &_root_ref); 511 efl_wref_add(_root, &_root_ref);