diff options
author | Xavi Artigas <xavierartigas@yahoo.es> | 2018-05-25 10:24:38 -0700 |
---|---|---|
committer | apache <apache@e5-web1.enlightenment.org> | 2018-05-25 10:24:38 -0700 |
commit | 3d6083076c3655f179533c41cc95a04036a59300 (patch) | |
tree | 6309867347d4497b20e3d8a1fe7e39c4f6baf373 /pages | |
parent | 67539c96933e81d298e25ecdc4bc60c83a39ed16 (diff) |
Wiki page eo-refcount.md changed with summary [Updated to efl_new] by Xavi Artigas
Diffstat (limited to 'pages')
-rw-r--r-- | pages/develop/tutorials/c/eo-refcount.md.txt | 20 |
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 | ||
7 | The 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. | 7 | The 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 | ||
9 | To 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. | 9 | To 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 | ||
121 | You 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*. | 121 | You 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 | ||
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. | 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 | ||
125 | In 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. | 125 | In 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 | ||
143 | As you can see, wrefs are also regular ``Eo`` pointers; you can use them anywhere you would use an object pointer. | 143 | As you can see, wrefs are also regular ``Eo`` pointers; you can use them anywhere you would use an object pointer. |
144 | 144 | ||
145 | In 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. | 145 | In 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 | ||
147 | Now, replace the previous usage of the plain object pointers in the ``printf()`` call in ``_status_print()`` with the wrefs: | 147 | Now, 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 | ||
158 | Finally, 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: | 158 | Finally, 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 | ||
255 | Remember 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 "-". | 255 | Remember 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 | ||
257 | Remember 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. | 257 | Remember 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 | ||
259 | The 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". | 259 | The 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); |