Re: [Tsp-devel] Question sur la redefinition des types

[Stephane GALLES]

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
>