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

[DUFRENNE, Yves]

En synthese, voici ma proposition :

1) Garder l'API consumer en types natifs C (int & double) car on ne dépends
pas précisément du nombre de bits de ces types.
Cela nous laisse indépendants. Certes on prends des risques de portabilité,
mais déjà j'aimerais bien savoir quels sont les variables typés int ou autre
chose dont nous dépendons du codage.

2) Rajouter dans tsp_abs_types.h   un "#ifndef __G_LIB_H__ ... #endif" pour
éviter la redéfinition.
Cela permettra à Stef Gar... (et non pas Sef Gal... ni Stef Can...)
d'utiliser tsp_time en interne si il le veut.

3) Le code en tsp_int me déplait sans que je sache dire pourquoi. On verra
plus tard si le besoin apparaît.

Y++


> -----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
>

important_notice.txt
Description: Text document