mtpchat2-dev
[Top][All Lists]
Advanced

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

Re: [mtpchat2-dev] Proposition


From: VANHULLEBUS Yvan
Subject: Re: [mtpchat2-dev] Proposition
Date: Sun, 21 Apr 2002 18:34:25 +0200
User-agent: Mutt/1.2.5i

Salut.

On Sun, Apr 21, 2002 at 05:56:45PM +0200, Vianney Lecroart wrote:
> 834 Utilisation du langage C++
> 
> A part vanhu, tout le monde est d'accord pour le C++ sans utiliser tout et
> n'importe quoi du langage juste pour faire beau. L'interet des templates est
> justifie car ils sont tres utiles pour faire des containers et gerer des
> parametre de type variable (int, bool, etc...)
> Vanhu, donne nous des arguments justifiant l'interet du C par rapport au C++

Au départ, mon argument est simple: je suis codeur C, Mtp1 est en C,
et le C est à priori "suffisant" pour faire Mtp2. Mon point de vue est
donc plutot "quel est l'intéret du C++ par rapport au C"....

Jusque la, au pire, je toucherai peu/pas au code (au moins dans un
premier temps) si le C++ est choisi.

Maintenant, pour ce que j'ai vu du C++, il y a moyen de faire plus
"propre" (c'est un peu subjectif quand meme) que le C, mais il y a
aussi très facilement moyen de faire un ignoble mélange C/C++ qui est
parfaitement illisible et source inimaginable de bugs.


Donc, si vous êtes tous partants pour du "vrai C++", codé proprement,
sans utiliser de "grosses feintes en C", je coderai surement peu (tout
simplement car je ne suis pas aussi bon/motivé en C++ qu'en C) mais je
suivrai le développement.

Par contre, si c'est pour faire du "C en C++", c'est sans moi, d'un
point de vue développement comme d'un point de vue hébergement du
serveur.


> 835 Portabilite POSIX (windows/linux)
> 
> "Certaines fonctionnalites a preciser" c est a dire? Ne pas melanger l'IDE
> et l'OS. On utilise uniquement des fonctions ANSI et POSIX et si ce n'est
> pas dispo sur l'OS voullu, on fait un #define et on met du code specifique
> pour faire l'equivalent de la fonction.

Sauf que tout le monde n'a pas forcément un environnement de
développement pour chaque OS "cible", et ne peut donc pas forcément
tout valider sur chaque OS....

Mais se restreindre aux fonctions ANSI et POSIX me parait être une
bonne base pour limiter au maximum les problèmes de portabilité...
 

> 845 Compatibilite telnet
> 
> Il faut *au moins *qu'on puisse se connecter avec un telnet linux *ET* avec
> un telnet de windows de base.

Sauf que la plupart des telnets de base windows ont des tares
variables (problemes d'echo, de retour chariot, etc...).

Pour les problemes connus, ca marche sur Mtp1, sauf que c'est pas
toujours super pratique. Mais si on découvre un gros problème avec
l'un de ces clients qui nécessiterait de supprimer une fonctionnalité
importante et/ou intéressante, je suis contre.

Notez que ca vaut aussi pour le client telnet de base sous Linux, mais
je sais pas pourquoi, j'ai moins d'inquiétudes à ce sujet....

Je propose donc "maintenir la possibilité de se connecter avec un
client telnet de base qui est à peu près bien implémenté", ou
quelquechose dans le genre...

> 851 Convention d'ecriture
> 
> Etant donne que tout le monde a son avis la dessus et que *personne* ne
> serra d'accord avec une convention d'un autre, je propose qu'on utilise une
> convention toute faite, comme ca on vote sur la convention et on se prend
> pas la tete:
> gnu, java, NeL

Tu as des URLs pour les 3 conventions ?

Puisque c'est un projet GPL, hébergé par la FSF, ca me paraitrait une
bonne idée d'utiliser le style GNU (je précise que je le connais pas
plus que les autres !!).


A +

VANHU.



reply via email to

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