* - char (both signed and unsigned)
* - int (short, regular, long and long long, both signed and unsigned)
* - float and double
- * - string (which is indeed a reference to a dynamically sized array of char, strlen being used to retrive the size)
+ * - string (which is indeed a reference to a dynamically sized array of char, strlen being used to retrieve the size)
*
* Example:\verbatim gras_datadesc_type_t i = gras_datadesc_by_name("int");
gras_datadesc_type_t uc = gras_datadesc_by_name("unsigned char");
*
* \warning Since GRAS_DEFINE_TYPE is a macro, you shouldn't put any comma in your type definition
* (comma separates macro args). For example, change \verbatim int a, b;\endverbatim to \verbatim int a;
- int b;\endverbatim
+int b;\endverbatim
*
- * <h3>Defining multidimentional arrays</h3>
+ * \section gras_dd_define \#define and fixed size array
+ *
+ * If you want to exchange arrays which size is given at compilation time by a
+ * \#defined constant, you need to keep GRAS informed. It would be done the
+ * following way:
+
+\verbatim #define BLOCK_SIZE 32
+GRAS_DEFINE_TYPE(s_toto,
+struct {
+ double data[BLOCK_SIZE];
+} s_toto;)
+
+void register_messages() {
+ gras_datadesc_type_t toto_type;
+
+ gras_datadesc_set_const("BLOCK_SIZE",BLOCK_SIZE);
+ toto_type = gras_datadesc_by_symbol(s_toto);
+}\endverbatim
+ *
+ * The form <tt>gras_datadesc_set_const("BLOCK_SIZE",BLOCK_SIZE);</tt> ensures
+ * that when you change the definition of the constant, GRAS keeps informed of
+ * the right value. Passing the numerical value of the constant as second
+ * argument would be a bad idea to that regard. Of course, the call to
+ * gras_datadesc_set_const() should come before any gras_datadesc_by_symbol()
+ * containing references to it.
+ *
+ * \section GRAS_dd_multidim Defining multidimentional arrays
*
* The mecanism for multidimensional arrays is known to be fragile and cumbersome. If you want to use it,
* you have to understand how it is implemented: the multiplication is performed using the sizes stack. In previous example,
* a \ref gras_datadesc_cb_push_int callback is added to the \a rows field and a \ref gras_datadesc_cb_push_int_mult one is
* added to \a cols. So, when the structure is sent, the \a rows field push its value onto the stack, then the \a cols field
- * retrieve this value from the stack, compute (and push) the multiplication value. The \a matrix field can then retrive this
+ * retrieve this value from the stack, compute (and push) the multiplication value. The \a matrix field can then retrieve this
* value by poping the array. There is several ways for this to go wrong:
* - if the matrix field is placed before the sizes, the right value won't get pushed into the stack soon enough.
* Reorder your structure fields if needed.
* If you cannot express your datadescs with this mechanism, you'll have to use the more advanced
* (and somehow complex) one described in the \ref GRAS_dd_cb_full.
*
- * <h3>Projects spanning over multiple files</h3>
+ * \section GRAS_dd_multifile Projects spanning over multiple files
*
* GRAS_DEFINE_TYPE declares some symbols to work, it needs some special
* care when used in several files. In such case, you want the regular type
* @brief Add an annotation to a type to be automatically parsed
*/
#define GRAS_ANNOTE(key,val)
+
+/** @brief Defines the value of a define to the datatype parsing infrastructure
+ */
+void gras_datadesc_set_const(const char*name, int value);
/* @} */
