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

[NOULARD Eric]

        C'est l'histoire d'un type qui rencontre un type et...

        Je pense que Vivian n'était peut-être pas si loin d'une solution
avec Autoconf. Si on admet que l'on utilise pas TSP avec 2 LIBS qui 
s'amusent à redéfinir les types de base, i.e. c'est QT ou GTK.
        Si on a un jour le besoin on définit les tsp_xxx types
qui vont bien et c'est autoconf qui nous fera le

        typedef gogo_type tsp_type

        suivant le nom de la lib passé en paramètre d'autoconf
--with-tsptype=[glib|qt|native].
        si on est pas lié à une lib autoconf nous fait les
        typedef par défaut sur les types de bases adéquats
        suivant l'architecture 
        (32,64, 128 bits (pour TSP sur console de jeux :))

        dans tous les cas les applis. TSP utilisent les types
        tsp_gnagagnga



Le mer 30/04/2003 à 19:26, Stephane GALLES a écrit :
> Bon, je comprend le besoin, et je m'incline humblement.
> - les types natifs C sont conservés dans l'API (ce qui me semble 
> effectivement suffisant pour l'instant)
> - utilisation du #ifndef __G_LIB_H__ ... #endif pour pouvoir utiliser 
> certains headers
> publiques-privés de TSP
> 
> La question restante est : "Quels seront les types à utiliser
> si le besoin se fait sentir un jour d'utiliser des types non natifs C dans les
> headers publiques TSP ?"
> 
> Alors là, je pense que ce jour là il sera assez arbitraire de rester avec 
> des types de la GLIB. 
> 
> En effet, le raisonnement qui consiste à dire : "en utilisant des types GLIB 
> dans les
> headers publiques de TSP, je me facilite la tache lorsque j'utilise TSP dans 
> un contexte GLIB",
> a ses limites.
> 
> par exemple, si je veux utiliser TSP avec les lib QT, dans ce cas je vais 
> mélanger des Q_INT32 avec 
> des gint32...bof...bof...je préfére que les choses soient claires et mélanger 
> des Q_INT32 et des tsp_int32.
> 
> Mais je suis d'accord pour dire que tout cela tient plus de la philosophie ou 
> de la theologie que de la technique...
> 
> 
> Stephane, celui avec deux L, un G, un S, un A, et un accent grave sur le E
> 
> 
> DUFRENNE, Yves wrote:
> 
> >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
> >>    
> >>
> >>------------------------------------------------------------------------
> >>
> >>---------------------------------------------------------
> >>
> >>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
> >>    
> >>
> 
> 
> 
> 
> 
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/tsp-devel
-- 
Eric NOULARD
Syntegra-FR - Toulouse / http://www.syntegra.fr
E-mail: address@hidden
Tél: 05 34 60 49 70