-----Original Message-----
From: Stephane GALLES [mailto:address@hidden
Sent: Wednesday, April 30, 2003 12:47 AM
To: tsp-devel
Subject: Re: [Tsp-devel] Question sur la redefinition des types
Hello !
Je suis d'accord avec toi Vivian, on ne devrait pas supposer
qu'un int
fait 32 bits, etc...
Mais si on l'a fait, c'était pour éviter de redéfinir des
type tsp_int*,
autant que possible, et c'est
effectivement risqué, bien que calculé.
Maintenant, imaginons, qu'il faille introduire des tsp_int* dans les
interfaces publiques de TSP.
Il pourrait y avoir deux raisons à cela :
- l'API TSP évolue, et il faut ajouter une fonction qui a besoin de
manipuler des type C qui sont de longueur
différentes sur les architectures actuelles sur lesquelles fonctionne
TSP (exemple, int64...)
- ou on veut porter TSP sur une processeurs qui fait s'effondrer non
suppositions sur les longueurs des int,
ou des doubles (INTEL ou AMD 64 bits ?)
- ou bien les deux derniers cas mélangées.
Prenons le cas des int, il faut définir des tsp_int32, tsp_int64,
tsp_uint32, tsp_uint64 au moins.
Le remplacement peut se faire assez facilement :
- 1) Remplacer les int de l'API TSP par des tsp_int32, les
uint par des
tsp_uint32
- 2) Faire une moulinette qui remplace tous les gint* par des
tsp_int*
partout dans le code
de TSP (pour ce dernier point j'avoue que j'aurai pu, lorsque j'ai
récupéré le code glib,
faire ce remplacement au départ (mais c'est juste pour la
beauté de la
chose, et surtout
pas pour laisser la possibilité d'utiliser des headers privés
! :) )
Au fait, en ce qui concerne autoconf, cela ne résoud pas la
probleme de
devoir faire des typedef.
Simplement autoconf le ferait 'en dur', alors que pour le
TSP actuel la
plateforme
est détectée par par le préprocesseur (voir fichier tsp_abs_types.h).
Mais cela revient au meme.
Sinon, en ce qui concerne l'utilisation de #ifndef
__G_LIB_H__ / #endif
, par exemple
pour utiliser des types glib dans l'API publique TSP, je ne pense pas
que cela soit trés
robuste.
En particulier, cela revient à se lier définitivement à une
version de
la GLIB, car si on se permet
d'overider (!) les headers TSP avec les headers GLIB, cela revient à
dire que l'on sait que le header
TSP GLIB redéfini EXACTEMENT ce que défini le vrai header GLIB (sinon
certains comportements
de TSP vont changer)
Dans ce cas cela signifi que TSP a indirectement besoin de la
GLIB pour
fonctionner, ou tout du moins,
d'une version précise des headers GLIB, et on sera tous
d'accord sur le
fait que ce n'est pas une bonne idée.
Et puis une dépendance, meme légere avec la glib me generait un peu.
TSP ne dépend de rien actuellement, et il vaut mieux que cela reste
comme cela.
Il est vrai par contre que j'aurai mieux fait de remplacer les gint*
internes par des tsp_int* pour éviter la polémique...
Mea culpa...
Stephane. Celui avec un G, deux L, un E et un S.
Vivian Larrieu wrote:
Salut,
On peut déjà ne pas redéfinir ces types si la Glib est déjà
incluses
via des #ifndef __G_LIB_H__ / #endif.
Sinon, peut-être qu'il faut exploiter le fait qu'autoconf
nous permet
de détecter la taille du int, du long, du double, .... sur une
architecture donnée.
Et donc de générer "à la Glib", le fichier des types standards.
Je ne pense pas qu'il faille faire des suppositions sur la
taille du
int. Sun nous a tout bluffé avec son architecture Int 32, Long 64
(LP64), alors qu'on attendais Int 64 et Long 32 (IP64). Donc, Intel
ferra surrement l'inverse et AMD suivra (Int 32, Long 32,
Pointer 64
(P64) ?).
Vivian
At 08:16 29/04/2003 +0200, Stephane GALLES - SYNTEGRA FR wrote:
en réponse à address@hidden
plouf, plouf,
en fait, il n'a jamais été prévu que les headers privés de
TSP soient
utilisés par autre chose que TSP. parcequ'ils sont...
comment dire...
privés.
Effectivement, les types volés à la GLIB entrent en
conflit avec ceux de
la vraie GLIB, mais cela ne devrait pas arriver lors d'une
utilisation standard de TSP
C'est en particulier pour cela que tsp_consumer.h ne
contient pas des
pseudo types GLIB,
mais uniquement des types C natifs parceque c'etait
possible et que
cela évitait les conflits.
Sans compter que les 'TSP internals' pourraient changer si on a
envie, et cela casserait ce que
tu aurais programmé avec... car on est pas sensé assurer la
compatibilité avec autres
choses que les headers publiques de TSP lors des
changements de version
Maintenant, si on voulait définir des types TSP spécifiques on
pourrait faire
des tsp_int32, tsp_uint32, etc... Mais tant qu'il n'y a en pas
besoin, je pense qu'il vaut mieux
éviter. Sinon, rapidement on arrive à des choses amusantes
du style :
"Je veux écrire un programme avec GLIB + TSP, quels sont les types
que j'utilise ? hum ?
les gint* ou bien les tsp_int* ? "
Je pense que tant qu'on peut éviter, il vaut mieux rester sur des
types C natifs portables
qui ne changent pas selon les architectures / compilateurs
par exemple :
- le 'double' est sympas car il ne change pas, généralement
- le 'int' fait toujours 32 bits pour autant que je sache
(à moins de
vouloir faire du DOS 16 bits, des idées pour un portage TSP ?)
Maintant je ne connais pas les comportement des types C natifs sur
des processeurs 64 bits AMD ou INTEL, mais
j'ose esperer qu'il n'ont pas fait un 'int' 64 bits...et
qu'ils ont
utilisé des 'long' pour cela...mais comme ils sont
joueurs généralement... autant se méfier...
Ce probleme des types natifs/ pas natif est un enfer... D'autres
idées des amis de la communauté TSP ?
Stephane, celui avec un G.
address@hidden wrote :
Salut,
J'ai cherche a utiliser les services 'time' de TSP dans GDISP+.
Concretement : 'tsp_time.h' et 'libtsp_services.a'.
Or :
- 'tsp_time.h' demande 'tsp_prjcfg.h' qui
lui-meme demande
'tsp_abs_types.h'. Dans ce dernier fichier, je trouve une
redefinition des types classiques pour une utilisation
plus facile.
Mais :
- Je vois 'STOLEN from GLIB public headers'. Arrrggg.....
Car GTK+ utilise aussi GLIB (via GDK)...
Donc impossible d'inclure a la fois 'tsp_time.h' (ou autre) et
'gtk.h' sinon
'type redefinition' a la compilation.
Ai-je le droit d'utiliser les services TSP ?
Euskadi.
_______________________________________________
Tsp-devel mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/tsp-devel
_______________________________________________
Tsp-devel mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/tsp-deve
l
-------------------------------------------------------------
-----------
_______________________________________________
Tsp-devel mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/tsp-devel
_______________________________________________
Tsp-devel mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/tsp-devel
------------------------------------------------------------------------
---------------------------------------------------------
CE COURRIER ELECTRONIQUE EST A USAGE STRICTEMENT INFORMATIF ET NE SAURAIT
ENGAGER DE QUELQUE MANIERE QUE CE SOIT ASTRIUM SAS, NI SES FILIALES.
SI UNE ERREUR DE TRANSMISSION OU UNE ADRESSE ERRONEE A MAL DIRIGE CE COURRIER,
MERCI D'EN INFORMER L'EXPEDITEUR EN LUI FAISANT UNE REPONSE PAR COURRIER
ELECTRONIQUE DES RECEPTION. SI VOUS N'ETES PAS LE DESTINATAIRE DE CE COURRIER,
VOUS NE DEVEZ PAS L'UTILISER, LE CONSERVER, EN FAIRE ETAT, LE DISTRIBUER, LE
COPIER, L'IMPRIMER OU EN REVELER LE CONTENU A UNE TIERCE PARTIE.
This email is for information only and will not bind Astrium SAS in any
contract or obligation, nor its subsidiaries.
If you have received it in error, please notify the sender by return email. If
you are not the addressee of this email, you must not use, keep, disseminate,
copy, print or otherwise deal with it.
---------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
Tsp-devel mailing list
address@hidden
http://mail.nongnu.org/mailman/listinfo/tsp-devel