From 7b9483641e0c268985f05eb926f6b580f826e09b Mon Sep 17 00:00:00 2001 From: Attila Kovacs Date: Sat, 28 Sep 2024 10:33:54 +0200 Subject: [PATCH] README spelling and site update --- README.md | 20 ++++++++++---------- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index b10961d..2d363fa 100644 --- a/README.md +++ b/README.md @@ -72,7 +72,7 @@ prior to invoking `make`. The following build variables can be configured: - `CC`: The C compiler to use (default: `gcc`). - - `CPPFLAGS`: C pre-processor flags, such as externally defined compiler constants. + - `CPPFLAGS`: C preprocessor flags, such as externally defined compiler constants. - `CFLAGS`: Flags to pass onto the C compiler (default: `-Os -Wall -std=c99`). Note, `-Iinclude` will be added automatically. @@ -119,17 +119,17 @@ associated data type, a dimensionality, a shape (for multidimensional arrays). ### Basic data types The __xchange__ library supports most basic (primitive) data types used across programming languages. The table below -shows the (`XType`) types recognised by the library and their C equivalents etc.: +shows the (`XType`) types recognized by the library and their C equivalents etc.: | __xchange__ type | C type | Comment / example | |------------------|--------------------------|----------------------------------------------------------| | `X_BOOLEAN` | `boolean`* | '`true`' or '`false`' | | `X_BYTE` | `char` or `int8_t` | '`-128`' to '`127`' | - | `X_BYTE_HEX` | `char` or `[u]int8_t` | '`0x0`' to '`0xff`' (hexadeximal representation) | + | `X_BYTE_HEX` | `char` or `[u]int8_t` | '`0x0`' to '`0xff`' (hexadecimal representation) | | `X_SHORT` | `short` or `int16_t` | '`-32768`' to '`32767`' | - | `X_SHORT_HEX` | `short` or `[u]int16_t` | '`0x0`' to '`0xffff`' (hexadeximal representation) | + | `X_SHORT_HEX` | `short` or `[u]int16_t` | '`0x0`' to '`0xffff`' (hexadecimal representation) | | `X_INT` | `int32_t` | '`-2,147,483,648`' to '`2,147,483,647`' | - | `X_INT_HEX` | `[u]int32_t` | '`0x0`' to '`0xffffffff`' (hexadeximal representation) | + | `X_INT_HEX` | `[u]int32_t` | '`0x0`' to '`0xffffffff`' (hexadecimal representation) | | `X_LONG` | `long long` or `int64_t` | '`-9,223,372,036,854,775,808`' to '`9,223,372,036,854,775,807`' | | `X_LONG_HEX` | `[u]int64_t` | '`0x0`' to '`0xffffffffffffffff`' (hex. representation) | | `X_FLOAT` | `float` | `1`, `1.0`, `-1.234567e-33` | @@ -149,7 +149,7 @@ value is to be represented in hexadecimal format rather than the default decimal Strings can be either fixed-length or else a 0-terminated sequence of ASCII characters. At its basic level the library does not impose any restriction of what ASCII characters may be used. However, we recommend that users stick to the -JSON convention, and represent special characters in escaped form. E.g. carriagle return (`0xd`) as `\` followed by +JSON convention, and represent special characters in escaped form. E.g. carriage return (`0xd`) as `\` followed by `n`, tabs as `\` followed by `t`, etc. As a result a single backslash should also be escaped as two consecutive `\` characters. You might use `xjsonEscapeString()` or `xjsonUnescapeString()` to perform the conversion to/from standard JSON representation. @@ -180,7 +180,7 @@ You can create scalar fields easily, e.g.: Under the hood, scalar values are a special case of arrays containing a single element. Scalars have dimension zero i.e., a shape defined by an empty integer array, e.g. `int shape[0]` in a corresponding `XField` element. -In this way scalars are distinsguished from true arrays containing just a single elements, which have dimensionality +In this way scalars are distinguished from true arrays containing just a single elements, which have dimensionality <=1 and shapes e.g., `int shape[1] = {1}` or `int shape[2] = {1, 1}`. The difference, while subtle, becomes more obvious when serializing the array, e.g. to JSON. A scalar floating point value of 1.04, for example, will appear as `1.04` in JSON, whereas the 1D and 2D single-element arrays will be serialized as `{ 1.04 }` or `{{ 1.04 }}`, @@ -247,8 +247,8 @@ and then eventually destroyed after use as: ### Aggregate IDs Since the `XStructure` data type can represent hierarchies of arbitrary depth, and named at every level of the -hieratchy, we can uniquely identify any particular field, at any level, with an aggregate ID, which concatenates the -field names eatch every level, top-down, with a separator. The convention of __xchange__ is to use colon (':') as the +hierarchy, we can uniquely identify any particular field, at any level, with an aggregate ID, which concatenates the +field names each every level, top-down, with a separator. The convention of __xchange__ is to use colon (':') as the separator. Consider an example structure (in JSON notation): ``` @@ -353,7 +353,7 @@ may call `xReverseFieldOrder()` at the end, so the fields will appear in the sam #### Iterating over elements You can easily iterate over the elements also. This is one application where you may want to know the internal layout -of `XStructure`, namely that it contains a simple linked-list of `XField` fields. One way to iterate over a strucures +of `XStructure`, namely that it contains a simple linked-list of `XField` fields. One way to iterate over a structures elements is with a `for` loop, e.g.: ```c