Re: [certi-devel] Proposition

[Valéry Raulet]

Benoît Bréholée wrote:

> Valéry Raulet <address@hidden> writes:
>
>  
>
> > Le patch #1469 est une proposition pour simplifier les échanges
> > entre la libRTI et le RTIA.
> >    
>
> Oui sur le principe...
>
>  
>
> > Il évite les codages/décodages suivant le type de message. Les
> > messages sont générés au fur et à mesure via les appels des méthodes
> > qui conviennent.
> >    
>
> Je n'ai pas tout regardé, si le contenu des messages réseau change,
> j'aurai besoin de faire des tests/comparaisons avant d'appliquer.
>  
OK !

>  
>
> > je me demandais si le fichier config.h ne devais pas être installé
> > en même temps que les entêtes. Les entêtes peuvent être dépendant de
> > ce fichier (même si ce n'est pas le cas actuellement).
> >    
>
> Les entetes ne doivent pas dépendre de ce fichier. Je modifie
> doc/coding.txt pour placer les include correctement : tout ce qui est
> lié à l'interface dans le .hh, et les include uniquement utilisés à
> l'implémentation dans le .cc. En pratique tout avoir dans le .hh peut
> convenir. Il faudrait aussi théoriquement placer les using dans le .cc
> pour ne pas l'imposer à l'utilisateur de l'interface, mais là aussi
> c'est vraiment pour le principe, en général ça ne pose pas de
> problème.
>
> Pour le config.h, tu peux regarder la doc d'Autoheader : le principe
> est d'y mettre ce qui serait placé en ligne de commande par Autoconf si
> on n'utilisait pas ce fichier. Ces informations sont donc utilisées
> pendant la compilation, mais perdues après, le but étant de tenir compte 
> d'infos systèmes pour la compilation sans que ça modifie les interfaces.
> (l'exemple obsolète mais classique: est-ce que le système supporte memcpy()
> du style System V ou bien bcopy() du style BSD ? -> l'implémentation en
> tiens compte et ça ne doit pas être vu par l'utilisateur).
>  
D'accord.

>  
>
> > Sinon, pour gérer les sockets, est-ce que l'on ne pourrait pas se
> > reposer sur un framework C++ comme Common C++
> > (http://voxilla.org/projects/projape.html) ?
> >    
>
> Pour l'instant on voit nettement plus d'inconvénients que d'avantages
> - le fonctionnement actuel convient, et est bien configuré (ce qui n'est
>  pas négligeable: j'ai passé du temps sur des bugs liés à tes mofifications
>  (pas ton code en général, mais par exemple des bugs des nouvelles 
>  fonctions utilisées comme les fstreams du CC de Sun -- les parties de
>  bas niveau orientées C pourraient être plus élégantes, mais le fait que
>  ce soit stable dans l'état actuel est un véritable avantage.)
> - ça ajoute une vraie dépendance (je ne suis déja pas très satisfait
>  de la semi-dépendance libXML, lib trop complexe pour ce que j'utilise)
>
> Est-ce que tu proposais ça pour la clarté / un portage, ou bien pour un
> besoin sur le fond (des ajouts à faire dans cette partie) ?
Pour un peu de tout ! Le projet Common C++ est une bibliothèque C++ 
portable qui offre des fonctionnalités pour les sockets assez 
intéressantes (streamSocket et autres).  On pourra peut être faire un 
essai (comme pour le patch #1469) et si ça ne convient pas (trop de pbs 
sur Solaris ou autres), on annule la modif.

Je sais, que ça crée une dépendance vis à vis d'une bibliothèque mais on 
ne peut pas (on ne doit pas !) continuellement (ré)inventer la roue ! De 
plus, cette bibliothèque me semble bien conçue, est un projet officiel 
de GNU et supporte Solaris et Windows. Ce ne peut être qu'un gage de 
réussite ;-).

> Benoit.
>
>  
      Valéry.

Par contre les patchs #1480 et #1474 peuvent être appliqués 
indépendamment du #1469 si tu préfères attendre pour ce dernier.

--
Valéry Raulet
Ecole Nationale d'Ingénieurs de Brest
Laboratoire d'Ingénierie Informatique
Parvis Blaise Pascal
Technopole Brest-Iroise                  Tél : (033) 298 05 66 75
29200 Brest - France                     Fax : (033) 298 05 66 29