X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/340c9657933b7046dfd4c4ae347815a1c0155340..a3427ca7c9f8f2563bb982044e1082cc8f3cdd1e:/include/gras/datadesc.h diff --git a/include/gras/datadesc.h b/include/gras/datadesc.h index e259f446eb..dac62222a1 100644 --- a/include/gras/datadesc.h +++ b/include/gras/datadesc.h @@ -16,38 +16,42 @@ 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 \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: * - 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"); gras_datadesc_type_t str = gras_datadesc_by_name("string");\endverbatim + * */ /* @{ */ @@ -59,7 +63,9 @@ gras_datadesc_type_t gras_datadesc_by_name(const char *name); /* @} */ -/** @name 2. Automatic parsing +/** @defgroup GRAS_dd_auto Automatic parsing of data descriptions + * @ingroup GRAS_dd + * \htmlonly \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 @@ -98,26 +104,104 @@ gras_datadesc_type_t gras_datadesc_by_name(const char *name); * 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 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 gras_datadesc_set_const("BLOCK_SIZE",BLOCK_SIZE); 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 * - * \warning The mecanism for multidimensional arrays is known to be fragile and cumbersome. If you want to use it, + * 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 + * 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 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 afterward. * - 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 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. + * (and somehow complex) one described in the \ref GRAS_dd_cb_full. * - * \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_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_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. But + * then you cannot include this right away in all files because the extra + * symbols would be defined in dupplicate. + * + * You thus have to decide in which 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: + * +\verbatim #define GRAS_DEFINE_TYPE_EXTERN +#include "my_header.h" + +int server(int argc, char *argv[]) { + ... +}\endverbatim + + * */ /** @{ */ @@ -126,8 +210,23 @@ gras_datadesc_type_t gras_datadesc_by_name(const char *name); * @hideinitializer */ #define GRAS_DEFINE_TYPE(name,def) \ - static const char * _gras_this_type_symbol_does_not_exist__##name=#def; 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 + + + /** @brief Retrieve a datadesc which was previously parsed * @hideinitializer */ @@ -142,13 +241,18 @@ gras_datadesc_type_t gras_datadesc_by_name(const char *name); * @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); /* @} */ 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. @@ -277,11 +381,13 @@ int gras_datadesc_get_id(gras_datadesc_type_t ddt); /* @} */ -/** @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 \endhtmlonly * * Here is an example:\verbatim struct s_array { @@ -342,10 +448,16 @@ void gras_datadesc_cb_push_ulint_mult(gras_datadesc_type_t typedesc, gras_cbps_t /* @} */ -/** @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 \endhtmlonly + * */ /* @{ */