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

[stef . vnrq]

B'Soir

Je voulais juste utiliser les services TIME de TSP pour eviter
de re-faire une é-nième fois le travail.
Mais si c'est privé, OK, je fais autrement.

Yves m'a suggere de faire une API publique pour les services.
Comments ?

Euskadi (Stephane G. egalement).



29/04/03 10:03:22, Vivian Larrieu <address@hidden> 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-devel
>
>_______________________________________________
>Tsp-devel mailing list
>address@hidden
>http://mail.nongnu.org/mailman/listinfo/tsp-devel
>