WWW-www.enlightenment.org pushed a commit to branch master.


commit 57b177d0d0ef970f6e1284a723a4f51a1ad92439
Author: Raster <ras...@rasterman.com>
Date:   Thu May 28 04:14:39 2015 -0700

    Wiki page start changed with summary [] by Raster
 pages/docs/c/start.txt | 39 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 39 insertions(+)

diff --git a/pages/docs/c/start.txt b/pages/docs/c/start.txt
index dd4ca95..0a67536 100644
--- a/pages/docs/c/start.txt
+++ b/pages/docs/c/start.txt
@@ -465,11 +465,50 @@ struct mydata
+If we were to fill this structure with the following code:
+<code c>
+struct mydata d;
+d.number1 = 1234567;
+strcpy(d.string1, "Hello world!");
+d.number2 = 1;
+d.floating_point1 = 2.0;
+d.char1 = 1;
+d.floating_point2 = 999.999;
+d.short1 = 30000;
+d.number3 = -1;
+d.floating_array[0] = 1.0;
+d.floating_array[1] = 2.0;
+d.floating_array[2] = 3.0;
 In memory from start to end it looks like:
 {{ memory.svg?nolink |Memory layout }}
+Note that members will add padding to align members to their natural 
alignment. This is necessary for correctness and speed reasons across all 
architectures. Everything is really just a series of bytes in memory. Memory is 
filled with 1000's or even millions of these bits of data, either one after the 
other, or spread out. You can jump from one to the other by just using a 
pointer. Pointers are simply byte numbers from the start of memory (which is 
0). The data lives somewhere in memory, [...]
+Generally you allocate memory with functions such as ''malloc()'', 
''calloc()'', or ''realloc()''. Some libraries you use may do allocations for 
you. Be sure to read the manuals on them as well as these above. You would free 
memory you no longer need with ''free()''. All these functions just take a 
pointer value that .. points at the memory to free, reallocate, or they return 
a pointer to this place in memory where your new memory block has been 
arranged. There are some special functions [...]
+==== Stack and heap ===
+The memory of your process, other than memory used to store the 
code/instructions loaded from disk, is primarily made up of 2 elements. The 
[[stack|http://en.wikipedia.org/wiki/Call_stack]] and the 
+The stack is managed for you mostly by the compiler and runtime. As the 
application runs, every time a function is called, a new blob of memory is 
"pushed" at the "top" of the stack. This memory contains the parameters passed 
to the function, and will contain return values from the function as well as a 
return address to go back (to read instructions from) to when this function 
returns. It is a very simple structure, and yet incredibly useful. Note that 
stack often have limited sizes (so [...]
+The heap is where more permanent memory is stored, and data here remains until 
explicitly freed. Most objects and larger data will life here. Getting memory 
in the heap is more costly in terms of time, but the limit on memory in the 
heap is generally "all available memory on the system", given caveats of 
fragmentation of memory, and possible process allocation limits imposed by the 
 ==== Libraries ====
+A shared library is simple a large bit of code you can "load" when your 
application (or library) is loaded, where the code in it is shared with other 
users on the system. It mostly is provided by another group of developers, and 
thus may change its internals without your application or library needing to be 
re-compiled. If there is a bug in the library it may be fixed later on by an 
update to the library. Everyone who installs the update gets the fix. Same for 
new features. Libraries hav [...]
+If you want to do something privileged, or hide data, it needs to cross a 
process boundary. Normally you're speak some form of IPC to a privileged "root" 
process for example. Of course all of this "we share everything" with libraries 
also means that code in your application could corrupt/mess/destroy data the 
library is maintaining, as well as vice-versa. There is no protection between a 
library, another library and your process. This lack of protection means 
performance is very good and [...]
+The benefit of a shared library is to avoid needing a re-compile to get 
improvements, save writing all the code the library shares with you, and to 
share the memory the code in the shared library would consume. As it is a 
//SHARED// library, the code from that library is loaded only once on the 
system. It may add to the virtual size of the process, but this space is shared 
across every process using that library, so the cost is paid just once.
+Generally a library exposes an API (a set of functions to call). It will 
provide header files you #include in your application (or library). you would 
link to the library and thus, at runtime, the "runtime linker" (ld.so often), 
will glue in the function symbols in your code to the library you link to. This 
is all done at the start of process startup before the main() function is 
called. There is a cost to this, but it is generally worth paying for the 
benefits. your code will then be ab [...]
 ==== API calls ====
 ==== System calls ====


Reply via email to