Cast dans un #define : questions - C - Programmation
Marsh Posté le 21-12-2005 à 20:04:29
Face à ce déluge de réponses, j'en déduis que la CTLib de Sybase, c'est de la merde.
Je veux dire : maintenant je sais que c'est pas que leur doc, qui à elle seule vaut le détour
Bon, plus qu'à mettre plein de if() pour tester la version du bousin, old-school style
Marsh Posté le 22-12-2005 à 23:16:21
Elmoricq a écrit : J'ai cherché, et j'ai trouvé pourquoi : toutes les macros Sybase sont définies avec un cast.
|
Ajouter dans un include (AMA, il y est déjà...)
#define CT_INT int |
ou
typedef int CT_INT; |
Ca, ça compile ?
Code :
|
Il y a un CS_INT !
Marsh Posté le 22-12-2005 à 23:33:04
Je n'ai pas compris ce que tu voulais dire, mais CS_INT est bien défini en fait (avec un typedef int dans mon cas, mais ça change selon les plateformes)
Ce qui gène ce sont les parenthèses dans le #define, qui font qu'on ne peut pas utiliser cette macro avec #if/#elif
Marsh Posté le 23-12-2005 à 12:03:20
Elmoricq a écrit : Je n'ai pas compris ce que tu voulais dire, mais CS_INT est bien défini en fait (avec un typedef int dans mon cas, mais ça change selon les plateformes) |
Exact, car au moment où les macros sont évaluées, une typedef ne l'est pas. Par contre, ça ne devrait pas géner si CS_INT est défini par une macro au lieu d'un typedef.
De toutes façon, ce cast est absurde. Dans une macro, une constante numérique (sans qualificateur) est de type int.
etc.
Tant que la constante numérique ne dépasse pas 32767 (valeur minimale de INT_MAX garantie par le norme), ca reste portable.
Marsh Posté le 23-12-2005 à 12:07:09
Emmanuel Delahaye a écrit : Exact, car au moment où les macros sont évaluées, une typedef ne l'est pas. Par contre, ça ne devrait pas géner si CS_INT est défini par une macro au lieu d'un typedef. |
Ah oui très juste, je n'avais même pas envisagé cette question sous cet angle.
Emmanuel Delahaye a écrit : De toutes façon, ce cast est absurde. Dans une macro, une constante numérique (sans qualificateur) est de type int. |
Ca confirme ce que je pensais, donc.
Bon j'ai contourné, mais je trouve ça dommage de devoir gérer les versions dans le code directement, au lieu de désactiver certaines parties du code en fonction de la version courante.
Marsh Posté le 23-12-2005 à 12:08:56
chrisbk a écrit : ca lui fait la bite |
Tu m'étonnes. Je passe d'une dizaine de fonctions à appeler pour établir la connexion Sybase, à une seule bête fonction.
Bon c'est un paramétrage par défaut mais on peut toujours régler le paramétrage après coup si on a besoin d'un truc exotique.
Comme quoi, c'est largement simplifiable leur bazar.
Je hais cette API.
Et encore pour pouvoir compiler, il faut inclure les bibliothèques suivantes : -lct -lcs -lcomn -ltcl -lintl -ldl -lnsl -lmp
On peut n'en retirer aucune, elles dépendent toutes les unes des autres.
Avec la dblib, on faisait -ldb et ça roulait.
Je demande donc la pendaison des développeurs de Sybase.
Marsh Posté le 21-12-2005 à 17:05:41
Je suis en train de développer une surcouche à la ctlib, l'API Sybase que je trouve particulièrement mal fichue (ils ont remplacé la dblib, qui était pas mal du tout, par cette infâmie, ça c'est de l'évolution).
Bon, bref.
Dans ma surcouche, je me décide de configurer une connexion standard, en ajustant un certain nombre de paramètres. Or suivant les versions, tous les paramètres ne sont pas connus, je pensais donc utiliser le préprocesseur, par exemple :
Seulement voila, avec cet exemple, cc il est pas content (missing operator, qu'il me dit).
J'ai cherché, et j'ai trouvé pourquoi : toutes les macros Sybase sont définies avec un cast.
Et les casts le préprocesseur il ne connait pas, d'où non-compilation.
Exemple :
#define CS_VERSION_125 (CS_INT)12500
Questions :