#ifndef GRAS_DATADESC_H
#define GRAS_DATADESC_H
-#include "xbt/misc.h" /* BEGIN_DECL */
+#include "xbt/misc.h" /* SG_BEGIN_DECL */
#include "xbt/dynar.h" /* void_f_pvoid_t */
-BEGIN_DECL()
+SG_BEGIN_DECL()
/** @addtogroup GRAS_dd Data description
- * @brief Describing data to be exchanged (Communication facility)
- *
- * @section Overview
+ * @brief Describing data to be exchanged
*
* Since GRAS takes care of potential representation conversion when the platform is heterogeneous,
* any data which transits on the network must be described beforehand.
*
* There is several possible interfaces for this, ranging from the really completely automatic parsing to
- * completely manual. Let's study each of them from the simplest to the more advanced.
+ * completely manual. Let's study each of them from the simplest to the more advanced:
*
- * \warning At least, I would like to present those sections in the right order, but doxygen prevents me
- * from doing so. There is a weird bug I fail to circumvent here. The right order is naturally:
- * -# basic operations
- * -# Automatic parsing
- * -# Simple manual definitions
- * -# Callback Persistant State: Simple push/pop mechanism
- * -# Callback Persistant State: Full featured mechanism
- */
-/* @{*/
-
-/** @name 1. basic operations
+ * - Section \ref GRAS_dd_basic presents how to retrieve and use an already described type.
+ * - Section \ref GRAS_dd_auto shows how to get GRAS parsing your type description automagically. This
+ * is unfortunately not always possible (only works for some structures), but if it is for your data,
+ * this is definitly the way to go.
+ * - Section \ref GRAS_dd_manual presents how to build a description manually. This is useful when you want
+ * to describe an array or a pointer of pre-defined structures.
+ * - You sometimes need to exchange informations between descriptions at send or receive time. This is
+ * for example useful when your structure contains an array which size is given by another field of the
+ * structure.
+ * - Section \ref GRAS_dd_cb_simple provides a simple interface to do so, allowing to share integers stored on a stack.
+ * - Section \ref GRAS_dd_cb_full provides a full featured interface to do so, but it may reveal somehow difficult to use.
+ **/
+
+/** @defgroup GRAS_dd_basic Basic operations on data descriptions
+ * @ingroup GRAS_dd
+ * \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Basics" --> \endhtmlonly
*
* If you only want to send pre-existing types, simply retrieve the pre-defined description with
* the \ref gras_datadesc_by_name function. Existing types entail:
* Example:\verbatim gras_datadesc_type_t i = gras_datadesc_by_name("int");
gras_datadesc_type_t uc = gras_datadesc_by_name("unsigned char");
gras_datadesc_type_t str = gras_datadesc_by_name("string");\endverbatim
+ *
*/
/* @{ */
/* @} */
-/** @name 2. Automatic parsing
+/** @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
* 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)
- * or the name of another field of the structure.
+ * 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 {
+ struct s_array *father GRAS_ANNOTE(size,1);
int length;
int *data GRAS_ANNOTE(size,length);
- struct s_array *father GRAS_ANNOTE(size,1);
+ int rows;
+ int cols;
+ int *matrix GRAS_ANNOTE(size,rows*cols);
}
;)\endverbatim
- * It specifies that the structure s_array contains two fields, and that the size of the array pointed
- * by \a data is the \a length field, and that the \a father field is a simple reference.
+ * It specifies that the structure s_array contains five fields, that the \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 array
+ * which size is the result of \a rows times \a cols.
*
+ * \warning 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 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
+ * 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 below.
- *
- * \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;
+ *
+ * \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
*/
/** @{ */
gras_datadesc_type_t
gras_datadesc_parse(const char *name, const char *C_statement);
-/** @name 3. Simple manual definitions
+/** @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.
/** \brief Add a pre-send callback to the given field resulting in its value to be pushed */
void gras_datadesc_cb_field_push (gras_datadesc_type_t type,
const char *field_name);
+/** \brief Add a pre-send callback to the given field resulting in its value multiplied to any previously pushed value and then pushed back */
+void gras_datadesc_cb_field_push_multiplier (gras_datadesc_type_t type,
+ const char *field_name);
/******************************
* Get stuff within datadescs *
/* @} */
-/** @name 4. Callback Persistant State: Simple push/pop mechanism
+/** @defgroup GRAS_dd_cb_simple Data description with Callback Persistant State: Simple push/pop mechanism
+ * @ingroup GRAS_dd
*
* Sometimes, one of the callbacks need to leave information for the next ones. If this is a simple integer (such as
* an array size), you can use the functions described here. If not, you'll have to play with the complete cbps interface.
+ *
+ * \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Simple push/pop Callback State" -->\endhtmlonly
*
* Here is an example:\verbatim
struct s_array {
gras_datadesc_struct_close(my_type);
\endverbatim
+ *
+ * The *_mult versions are intended for multi-dimensional arrays: They multiply their value to the previously pushed one
+ * (by another field callback) and push the result of the multiplication back. An example of use follows. Please note
+ * that the first field needs a regular push callback, not a multiplier one. Think of it as a stacked calculator (man dc(1)).\verbatim
+struct s_matrix {
+ int row;
+ int col;
+ int *data;
+}
+[...]
+my_type=gras_datadesc_struct("s_matrix");
+gras_datadesc_struct_append(my_type,"row", gras_datadesc_by_name("int"));
+gras_datadesc_cb_field_send (my_type, "length", gras_datadesc_cb_push_int);
+gras_datadesc_struct_append(my_type,"col", gras_datadesc_by_name("int"));
+gras_datadesc_cb_field_send (my_type, "length", gras_datadesc_cb_push_int_mult);
+
+gras_datadesc_struct_append(my_type,"data",
+ gras_datadesc_array_dyn ("s_matrix::data",gras_datadesc_by_name("int"), gras_datadesc_cb_pop));
+gras_datadesc_struct_close(my_type);
+\endverbatim
+
*/
/* @{ */
gras_cbps_i_pop(gras_cbps_t ps);
int gras_datadesc_cb_pop(gras_datadesc_type_t typedesc, gras_cbps_t vars, void *data);
+
void gras_datadesc_cb_push_int(gras_datadesc_type_t typedesc, gras_cbps_t vars, void *data);
void gras_datadesc_cb_push_uint(gras_datadesc_type_t typedesc, gras_cbps_t vars, void *data);
void gras_datadesc_cb_push_lint(gras_datadesc_type_t typedesc, gras_cbps_t vars, void *data);
void gras_datadesc_cb_push_ulint(gras_datadesc_type_t typedesc, gras_cbps_t vars, void *data);
+void gras_datadesc_cb_push_int_mult(gras_datadesc_type_t typedesc, gras_cbps_t vars, void *data);
+void gras_datadesc_cb_push_uint_mult(gras_datadesc_type_t typedesc, gras_cbps_t vars, void *data);
+void gras_datadesc_cb_push_lint_mult(gras_datadesc_type_t typedesc, gras_cbps_t vars, void *data);
+void gras_datadesc_cb_push_ulint_mult(gras_datadesc_type_t typedesc, gras_cbps_t vars, void *data);
+
/* @} */
-/** @name 5. Callback Persistant State: Full featured mechanism
+/** @defgroup GRAS_dd_cb_full Data description with Callback Persistant State: Full featured interface
+ * @ingroup GRAS_dd
*
- * Sometimes, one of the callbacks need to leave information for the next ones. If the simple push/pop mechanism
- * introduced in previous section isn't enough, you can always use this full featured one.
+ * Sometimes, one of the callbacks need to leave information for the next
+ * ones. If the simple push/pop mechanism introduced in previous section
+ * isn't enough, you can always use this full featured one. The bad point is
+ * that it is quite badly documented...
+ *
+ * \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Full featured Callback State" -->\endhtmlonly
+ *
*/
/* @{ */
unsigned long howmany);
-END_DECL()
+SG_END_DECL()
#endif /* GRAS_DATADESC_H */