tsp-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE : [Tsp-devel] TSP_STATUS, TRUE, FALSE etc...


From: eric.noulard
Subject: RE : [Tsp-devel] TSP_STATUS, TRUE, FALSE etc...
Date: Fri, 14 Apr 2006 12:49:34 +0100

>-------- Message d'origine--------
>De: address@hidden de la part de dufy
>Date: ven. 14/04/2006 13:35
>À: Transport Sample Protocol development list
>Objet : Re: [Tsp-devel] TSP_STATUS, TRUE, FALSE etc...
 
>Pour moi on a 2 choix : Tout en TSP_STATUS,  ou alors TOUT en philo C like
>(0=OK, <0 erreur, ....) mais pas forcément adapté à du C++ ou autre truc qui
>gère les exceptions. En tout cas il ne faut pas melanger les 2..

Disons que justement la philo C-like a ses limites vu que
souvent OK = 0 et NOK <0 
mais aussi actuellement
TRUE = 1 et FALSE = 0
et puis quand pas OK il faut pouvoir tester par rapport à ENOxxxx en C-like
donc nous on fera par rapport à TSP_STATUS_xxx

donc on serait un peu comme C-like sauf qu'il ne faut PAS
supposer TSP_STATUS_OK == 0 (même si c'est le cas aujourd'hui).

>
>Donc Eric, à ta question "keskevouzendite", je répondrait de manière concise
>:"du bien !"

Y++

Le 14/04/06, address@hidden <address@hidden> a écrit :
>
> Cher amis TSPiens,
>
> J'aimerais rationaliser un peu les codes de retours
> des diffférentes API TSP (intérieur du CORE et également API publique).
>
> Certaines fonctions renvoient TRUE/FALSE
> d'autres 0 et  != 0
> d'autres des TSP_STATUS_xxx
> d'autres encore TSP_CONSUMER_STATUS_xxx
>
> J'aimerais unifier tout ça en ne renvoyant uniquement
> des TSP_STATUS_xxx afin de pouvoir vérifer la valeur
> de retour du genre
>
> if (TSP_STATUS_OK!=TSP_consumer_request_open) {
>
> ]
>
> Ces status étant définis par un enum dans tsp_rpc.x
> (et plus tard [ bientôt :))] dans tsp.idl) on peut
> dispoer des valeurs "symboliques" partout (ruby, perl, python, C, java
> ...)
> de façon consistente.
>
> Les seules fonctions qui ne renverraient pas de "TSP_STATUS_xxx"
> seraien celles renvoyant des pointeurs.
> Auquel cas pour ces dernière on poeut tester NULL ou !=NULL
>
> Qu'en dîtes-vous?
>
> ---
> Eric Noulard - Software Architect
> BT Consulting & Systems Integration
> tel: (+33) (0)534 604970
> mob: (+33) (0)607 948100
> web: www.bt.com/consulting
>
>
>
> _______________________________________________
> Tsp-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/tsp-devel
>

<<winmail.dat>>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]