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

[DUFRENNE, Yves]

D'accord avec Stef G.
Si tu utilise TSP, tu dois attaquer uniquement le niveau tsp_consummer.h, et
si possible en types natifs C.
Y++

> -----Original Message-----
> From: Stephane GALLES - SYNTEGRA FR 
> [mailto:address@hidden
> Sent: Tuesday, April 29, 2003 8:17 AM
> To: tsp-devel
> Subject: Re: [Tsp-devel] Question sur la redefinition des types
> 
> 
> 
> 
> 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
>

important_notice.txt
Description: Text document