Re: [certi-devel] Proposition

[Benoît Bréholée]

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.

> 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).

> 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) ?

Benoit.