+/** @defgroup GRAS_dd_auto Automatic parsing of data descriptions
+ * @ingroup GRAS_dd
+ * \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Automatic parsing" --> \endhtmlonly
+ *
+ * If you need to declare a new datatype, this is the simplest way to describe it to GRAS. Simply
+ * enclose its type definition into a \ref GRAS_DEFINE_TYPE macro call, and you're set. Here is
+ * an type declaration example: \verbatim GRAS_DEFINE_TYPE(mytype,struct mytype {
+ int myfirstfield;
+ char mysecondfield;
+ });\endverbatim
+ * The type is then both copied verbatim into your source file and stored for further parsing. This allows
+ * you to let GRAS parse the exact version you are actually using in your program.
+ * You can then retrieve the corresponding type description with \ref gras_datadesc_by_symbol.
+ * Don't worry too much for the performances, the type is only parsed once and a binary representation
+ * is stored and used in any subsequent calls.
+ *
+ * If your structure contains any pointer, you have to explain GRAS the size of the pointed array. This
+ * can be 1 in the case of simple references, or more in the case of regular arrays. For that, use the
+ * \ref GRAS_ANNOTE macro within the type declaration you are passing to \ref GRAS_DEFINE_TYPE. This macro
+ * rewrites itself to nothing in the declaration (so they won't pollute the type definition copied verbatim
+ * into your code), and give some information to GRAS about your pointer.
+
+ * GRAS_ANNOTE takes two arguments being the key name and the key value. For now, the only accepted key name
+ * is "size", to specify the length of the pointed array. It can either be:
+ * - the string "1" (without the quote),
+ * - the name of another field of the structure
+ * - a sort of computed expression for multidimensional arrays (see below -- pay attention to the warnings below).
+ *
+ * Here is an example:\verbatim GRAS_DEFINE_TYPE(s_clause,
+ struct s_array {
+ xbt_string_t name;
+ struct s_array *father GRAS_ANNOTE(size,1);
+ int length;
+ int *data GRAS_ANNOTE(size,length);
+ int rows;
+ int cols;
+ int *matrix GRAS_ANNOTE(size,rows*cols);
+ }
+;)\endverbatim
+ * It specifies that the structure s_array contains six fields, that the \a name field is a classical null-terminated
+ * char* string (#xbt_string_t is just an helper type defined exactly to help the parsing macro to specify the semantic of the pointer),
+ * that \a father field is a simple reference, that the size of the array pointed by \a data is the \a length field, and that the
+ * \a matrix field is an arraywhich size is the result of \a rows times \a cols.
+ *
+ * \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
+ *
+ * \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 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 write GRAS_ANNOTE(size,cols*rows); in previous example (inverting rows and cols in annotation),
+ * \a rows will be given a \ref gras_datadesc_cb_push_int_mult. This cannot work since it will try to
+ * pop the value which will be pushed by \a cols <i>afterward</i>.
+ * - if you have more than one matrix in your structure, don't interleave the size. They are pushed/poped in the structure order.
+ * - if some of the sizes are used in more than one matrix, you cannot use this mecanism -- sorry.
+ *
+ * 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.
+ *
+ * \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
+ * definition in all files, but the gras specific symbol defined in only
+ * one file. For example, consider the following gras project sketch.
+ *
+\verbatim #include <gras.h>
+
+GRAS_DEFINE_TYPE(my_type,struct my_type {
+ int a;
+ int b;
+ double c;
+});
+
+int client(int argc, char *argv[]) {
+ ...
+}
+
+int server(int argc, char *argv[]) {
+ ...
+}\endverbatim
+ *
+ * If you want to split this in two files (one for each kind of processes),
+ * you need to put the GRAS_DEFINE_TYPE block in a separate header (so that
+ * each process kind see the associated C type definition). But
+ * then you cannot include this right away in all files because the extra
+ * symbols containing the GRAS definition would be dupplicated.
+ *
+ * You thus have to decide in which C file the symbols will live. In that
+ * file, include the header without restriction:
+ *
+\verbatim #include "my_header.h"
+
+int client(int argc, char *argv[]) {
+ ...
+}\endverbatim
+
+ * And in the other files needing the C definitions without the extra GRAS
+ * symbols, declare the symbol GRAS_DEFINE_TYPE_EXTERN before loading gras.h:
+ *
+\verbatim #define GRAS_DEFINE_TYPE_EXTERN
+#include <gras.h>
+#include "my_header.h"
+
+int server(int argc, char *argv[]) {
+ ...
+}\endverbatim
+
+ *
+ * Sometimes, the situation is even more complicated: There is some shared
+ * messages that you want to see from every file, and some private messages
+ * that you want to be defined only in one C file.
+ * In that case, use the previous trick for common messages, and use
+ * #GRAS_DEFINE_TYPE_LOCAL for the private messages.
+ *
+ * For now, there is no way to have semi-private symbols (for example shared
+ * in all files of a library), sorry. Use functions as interface to your
+ * library instead of publishing directly the messages.
+ *
+ */
+/** @{ */
+
+
+/** @brief Automatically parse C code
+ * @hideinitializer
+ */
+#define GRAS_DEFINE_TYPE(name,def) \
+ const char * _gras_this_type_symbol_does_not_exist__##name=#def; def
+
+#ifndef DOXYGEN_SKIP /* doxygen don't like macro fun too much */
+# ifdef GRAS_DEFINE_TYPE_EXTERN
+# undef GRAS_DEFINE_TYPE
+# define GRAS_DEFINE_TYPE(name,def) def
+# undef GRAS_DEFINE_TYPE_EXTERN
+# endif
+#endif
+
+/** @brief if this symbol is defined, the \a GRAS_DEFINE_TYPE symbols live in another file.
+ * @hideinitializer
+ */
+#define GRAS_DEFINE_TYPE_EXTERN 1
+/* leave the fun of declaring this to the user */
+#undef GRAS_DEFINE_TYPE_EXTERN
+
+/** @brief Define a symbol to be automatically parsed, disregarding #GRAS_DEFINE_TYPE_EXTERN
+ * @hideinitializer
+ *
+ * Call this macro instead of #GRAS_DEFINE_TYPE if you had to define #GRAS_DEFINE_TYPE_EXTERN
+ * to load some external symbols, but if you now want to automatically parse the content of
+ * your private messages.
+ */
+#define GRAS_DEFINE_TYPE_LOCAL(name, def) \
+ const char * _gras_this_type_symbol_does_not_exist__##name=#def; def
+
+/** @brief Retrieve a datadesc which was previously parsed
+ * @hideinitializer
+ */
+#define gras_datadesc_by_symbol(name) \
+ (gras_datadesc_by_name_or_null(#name) ? \
+ gras_datadesc_by_name_or_null(#name) : \
+ gras_datadesc_parse(#name, \
+ _gras_this_type_symbol_does_not_exist__##name) \
+ )
+
+/** @def GRAS_ANNOTE
+ * @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
+ */
+XBT_PUBLIC(void) gras_datadesc_set_const(const char *name, int value);
+
+/* @} */
+
+XBT_PUBLIC(gras_datadesc_type_t)
+ gras_datadesc_parse(const char *name, const char *C_statement);
+
+/** @defgroup GRAS_dd_manual Simple manual data description
+ * @ingroup GRAS_dd
+ *
+ * Here are the functions to use if you want to declare your description manually.
+ * The function names should be self-explanatory in most cases.
+ *
+ * You can add callbacks to the datatypes doing any kind of action you may want. Usually,
+ * pre-send callbacks are used to prepare the type expedition while post-receive callbacks
+ * are used to fix any issue after the receive.
+ *
+ * If your types are dynamic, you'll need to add some extra callback. For example, there is a
+ * specific callback for the string type which is in charge of computing the length of the char
+ * array. This is done with the cbps mechanism, explained in next section.
+ *
+ * If your types may contain pointer cycle, you must specify it to GRAS using the @ref gras_datadesc_cycle_set.