cadey
/
nim-wiki
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Updated Nimrod for C programmers (markdown)

This commit is contained in:
Audun Wilhelmsen 2013-12-26 14:03:47 -08:00
parent df51787100
commit 1b7896de82
1 changed files with 5 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
Nimrod-for-C-programmers.md
View File

@ -23,6 +23,10 @@ http://nimrod-lang.org/manual.html
<tr><td>Custom Operators</td><td>No</td><td>Yes</td></tr>
</table>
### Philosophy
The key to understanding Nimrod is that Nimrod was designed to be as fast as C, but to be much safer. Many of the design-decisions are based on making it harder to shoot yourself in the foot. The other important thing to know is that while C uses a separate language to do meta-programming (the preprocessor), Nimrod meta-programming is done with the Nimrod language itself. That means that most Nimrod code can be executed at compile time, and Nimrod's ability to generate Nimrod-code at compile time is much more sophisticated.
### Arrays
In C an array is more or less syntactic sugar for pointers. In Nimrod, arrays are much more strict and safe to use. They are pass-by-value (meaning they're copied at assignment). When passing an array to a proc in Nimrod, the argument is a read-only reference, meaning it can't be assigned to. Take the following example:
@ -58,7 +62,7 @@ In C, you can pass an ``int[3]`` to the foobar function, and the compiler will n
Nimrod arrays can also be indexed from any number. That is, ``z: array[1..4, int]`` is an array of int indexed from 1 to 4. Trying to access ``z[0]`` would throw an index out bounds error.
In C, there's nothing that keeps you from keeping a pointer to a stack-allocated array
In C, there's nothing that keeps you from keeping a pointer to a stack-allocated array
### Structs - Tuples and Objects