Discussion :

[Invité]

Dans de telles conditions, même s'il est intéressant de se souvenir des problèmes rencontrés et des solutions apportées au cours du cycle de vie de la première version, il ne s'agit, ni plus ni moins, de relancer un projet complet, et, de ce fait, je trouverais particulièrement dommage de repartir avec du code ancien plutôt que de réellement partir d'une feuille blanche, et de choisir dés le départ de coder de manière "moderne".

Ce choix "feuille blanche" vs "refonte" n'est pas du tout anodin. Je sors juste d'un projet qui a pris beaucoup de retard parce qu'on est partis sur une idée de "feuille blanche", sans bien se rendre compte de ce que cela impliquait...

A mon avis, la difficulté est la suivante...

Une application vieillissante est souvent bâtie autour d'une architecture ancienne, selon des principes qui sont de plus en plus difficiles à respecter, en imposant des limites qu'on voudrait dépasser. De ce point de vue, une réécriture complète s'impose.

Mais, et on l'oublie presque toujours, ladite application comporte souvent un très grand nombre de petits modules, qui marchent très bien (c'est pour cela qu'on n'en parle pas), et qui ont parfois été très durs à mettre au point. S'il faut les refaire, sans régression, cela risque de prendre beaucoup de temps. Dans ce contexte, on préfèrerait refondre, en conservant ces modules.


En général, la réécriture totale gagne, parce qu'on pense la réécriture en termes de fonctionnalité manquantes, et pas de fonctionnalités présentes (cela participe du même raisonnement que le développement de ses propres classes String et Vector), et le début du projet (tant qu'on reste dans les grands principes) donne raison à ce choix.

C'est après, quand les utilisateurs commencent à râler parce que les exports, les sauvegardes, la compatibilité, les petits machins qui gagnaient un temps précieux, manquent, qu'on regrette parfois ce choix... On s'aperçoit alors que la mise au point prend un temps bien plus grand que prévu. Et c'est là qu'on entre dans le dialogue de sourd : "c'est plus lent/moins pratique qu'avant", "oui mais les limites sur le nombre de lignes/colonnes/fichiers de l'application précédente ont disparu", "oui mais j'aimais mieux avant..."


Personnellement, je pense qu'à l'avenir, je privilégierai toujours la refonte profonde du code existant. C'est beaucoup plus exigeant (même sur un code qu'on a écrit soi même), mais je pense que c'est également plus efficace.

Et c'est là qu'une vraie méthodologie de redéveloppement fait cruellement défaut.

Francois

[Klaim]

J'ai été dans une boite par le passé ou une pseudo-STL était spécifiquement écrite. Vu le niveau des développeurs C++ de la boite, qui était tout a fait excellent (j'y ai beaucoup appris), je me demandais pourquoi s'être pris la tête à refaire une STL incomplète et légèrement différente?

J'ai donc fini par demander et j'eu ma réponse :: nous travaillions avec des téléphones portables, des PDA et autres hardware embarqué et il n'était pas toujours possible d'avoir 1) une STL 2) dont le comportement soit strictement le même partout 3) portable sur toutes les plateformes en question -- limitations de certains compilateurs.
Du coup cela m'a semblé tout a fait justifié. Je ne sais pas si ça serait encore justifié aujourd'hui mais lorsque ce code avait été mis en place (moins de dix ans avant) c'était une bonne idée pour éviter tout un tas de problèmes.

Ces mêmes developpeurs m'encourageaient a utiliser STL/BOOST et même Lokki dans mes autres projets (persos) parcequ'ils en voyaient tout a fait le bénéfice.

Je pense que les cas où avoir sa propre STL est justifié reste rare mais existe toujours, parcequ'il existe toujours des cas où on a des contraintes fortes ou des contraintes historiques.

[Médinoc]

En effet, l'embarqué tend à avoir des problèmes avec les standards.

[Mac LAK]

En effet, l'embarqué tend à avoir des problèmes avec les standards.

Et c'est un euphémisme...

[reptils]

Rectification : on connait la différence. C'est plutôt que l'on se contrefiche de la "pureté" du programme, on veut qu'il soit efficace.
Typiquement, la STL et les flux sont bien trop lents pour le code critique, donc on les fait allègrement sauter au profit des fonctions C correspondantes. De quoi faire bondir un puriste C++, mais quand tu gagnes 10% de perfs en plus en écrivant un mix C-C++ par rapport à la version C++ "pure" et que ça te permet d'éviter d'acheter du matériel plus cher, tu oublies la "pureté" et tu fais au plus efficace.....

Je suis à 100% d'accord avec ça !
Je croyais être le seul au monde à penser comme ça. sachant que certaine fois tu peux gagner bien plus que 10% de perf!

[Joel F]

Je suis à 100% d'accord avec ça !
Je croyais être le seul au monde à penser comme ça. sachant que certaine fois tu peux gagner bien plus que 10% de perf!

ca doit etre la fete du slip par chez vous c'est dingue. Pourquoi ne faites vous pas juste du C à ce moment ???

[reptils]

Quand tu arrives dans un environnement qui a un passif c'est pas évident de faire changer les choses. De plus de mon coté les perfs c'est toujours critique. Enfin il y a des gardes chapelle avec positions politiques

[Joel F]

Quand tu arrives dans un environnement qui a un passif c'est pas évident de faire changer les choses. De plus de mon coté les perfs c'est toujours critique. Enfin il y a des gardes chapelle avec positions politiques

Ok d'accord mais, pourquoi pas faire QUE du C à ce moment ?

[Invité]

Ok d'accord mais, pourquoi pas faire QUE du C à ce moment ?

Parce que le C++ offre tout un tas de fonctionnalités pratiques. Je ne suis problablement pas le seul programmeur C à être tombé de ma chaise en découvrant le C++ (en fait, c'avait été l'objective C, le bouquin de Cox). Chacun reconnait les apports du C++. La question est de savoir s'il faut, pour en bénéficier, "renier" le C...

Sauf contrainte externe, je ne vois pas très bien l'intérêt de se priver du C++ (y compris la STL : ne pas avoir a récrire un set, quand on n'y est pas obligé, ne pas avoir à réfléchir sur sort() ou sur merge(), voire savoir qu'on peut bâtir un tas sans avoir à exhumer le vieux bouquin qu'on a lu il y a longtemps, c'est un vrai luxe).

Une fois de plus, la considération qui prime, c'est l'efficacité, en terme de rapidité du code, d'utilisation de compétences (pas mal de vieux programmeurs C++ viennent du C), ou de lisibilité du code (si toute l'équipe lit la "mixture", il est idiot d'essayer de lui imposer un style, à des fins de beauté formelle).

Dans pas mal de gros projets, l'application utilise un mélange de langages (parfois un macrolangage un peu fonctionnel, du C dans les librairies de base, des scripts ici et là...), et ça ne gêne personne. La proximité syntaxique du C et du C++ permettent ce mélange à un niveau plus bas (celui du code source), pourquoi s'en priver?

Francois

[Joel F]

Dans pas mal de gros projets, l'application utilise un mélange de langages (parfois un macrolangage un peu fonctionnel, du C dans les librairies de base, des scripts ici et là...), et ça ne gêne personne. La proximité syntaxique du C et du C++ permettent ce mélange à un niveau plus bas (celui du code source), pourquoi s'en priver?

On est d'accord là.

[white_tentacle]

Ok d'accord mais, pourquoi pas faire QUE du C à ce moment ?

Parce que n'importe qui qui défend le fait que le C est plus performant que le C++ se plante totalement (sauf s'il parle du temps de compilation, là )

Quelque soit un programme C, il existe un programme C++ au moins aussi performant : au pire, le même programme, puisqu'un programme C est un programme C++ valide (je sais, c'est à nuancer avec C99). Et régulièrement, il est possible de faire des optimisations supplémentaires en faisant résoudre certaines choses à la compilation.

[Mac LAK]

ca doit etre la fete du slip par chez vous c'est dingue. Pourquoi ne faites vous pas juste du C à ce moment ???

Parce qu'il y a AUSSI du code non-critique à côté, et qu'il est plus simple à écrire en C++... C'est pourtant évident, il me semble.
Il y a même du code tellement peu critique (mais tellement souvent modifié...) qu'il tourne dans un interpréteur Python ou LUA embarqué. Tout est question de contexte.

Quelque soit un programme C, il existe un programme C++ au moins aussi performant : au pire, le même programme, puisqu'un programme C est un programme C++ valide (je sais, c'est à nuancer avec C99). Et régulièrement, il est possible de faire des optimisations supplémentaires en faisant résoudre certaines choses à la compilation.

C'est effectivement à nuancer : on ne fait en général pas vraiment du C, dans ce cas là, mais plutôt du code qui est dans l'intersection des deux langages. Mais c'est en utilisant des structures plus proches du C que du C++, car étant plus bas niveau (et, hélas, nettement moins sécurisées, toute médaille a son revers), elles sont plus performantes.

Au final, le code est effectivement compilé en C++ et non pas en C, mais le code ressemble plus à du C qu'à du C++.

[Joel F]

Au final, le code est effectivement compilé en C++ et non pas en C, mais le code ressemble plus à du C qu'à du C++.

en fait, c'est relativement intéressant ce point. A croire qu'il faudrait presque 3 denominations (C, C compilé C++ et C++).

Bon point sur LUA et python aussi, ca m'avais echappé.

[Médinoc]

J'en utilise déjà trois. Par contre, autorises-t-on l'emploi de cout (mais pas de std::string, hein) et diverses choses incompatibles avec le C90 (comme les variables déclarées en milieu de bloc) dans le "C compilé C++" ? Car c'est un cas assez courant...

[Invité]

J'en utilise déjà trois. Par contre, autorises-t-on l'emploi de cout (mais pas de std::string, hein) et diverses choses incompatibles avec le C90 (comme les variables déclarées en milieu de bloc) dans le "C compilé C++" ? Car c'est un cas assez courant...

J'ai l'impression qu'on y met pas mal de choses :

- cout, et les sorties de base des iostream
- new([]) et delete([]) à la place de malloc et free
- les commentaires sous les deux formes (enfin bon, ca c'est standard, je crois)
-les parties les plus évidentes de la stl, string à mon avis, et même vector, et les algos de base (min, max, etc...)

En fait, le C++ est alors vécu comme une extension de la librairie C.

Francois

[Médinoc]

-les parties les plus évidentes de la stl, string à mon avis, et même vector, et les algos de base (min, max, etc...)

Pour moi, ce dernier point, c'est déjà du "vrai" C++.

[Mac LAK]

J'en utilise déjà trois. Par contre, autorises-t-on l'emploi de cout (mais pas de std::string, hein) et diverses choses incompatibles avec le C90 (comme les variables déclarées en milieu de bloc) dans le "C compilé C++" ? Car c'est un cas assez courant...

Personnellement, j'ai bien plus que 3 cas...

• C ou C++ : Évident, on est "stricts" sur chacun des deux. Seuls cas où j'applique une quelconque norme de langage, sinon, dans les autres, c'est "tronc commun" de rigueur (comprendre "norme d'il y a 10 ans au bas mot").
  
  
• "C++ without classes" : C++ correct, mais en code procédural et, donc, sans classes au niveau utilisateur.
  
  Pas de restrictions pour utiliser des flux, des containers ou quoi que ce soit d'autre. Utilisé principalement pour les parties "routines" des librairies.
  
  
• "C with classes" : Des classes, éventuellement de la STL, mais des E/S "C" exclusivement (notamment, aucun flux).
  
  Utilisé principalement pour pallier les STL pourries de certaines plate-formes.
  
  
• "C inter C++" : je ne mets alors RIEN qui soit spécifique à un langage (= qui clashe dans l'autre). Donc, il n'y a pas de flux, les malloc sont castés, les commentaires sont "C" et pas "C++", aucun entête C++ "pur" n'est inclus, etc. La plus stricte intersection des deux langages, le tronc commun pur et dur.
  
  Le but d'un code comme ça est d'être hyper performant, portable et auto-testé (pour éviter les régressions idiotes), mais surtout le but est de ne plus jamais avoir à le retoucher. Parce que bon, la maintenance d'un code pareil qui définit des trucs en compilation conditionnelle pour une demi-douzaine de CPU et compilateurs, ça va bien 30 secondes, mais zéro c'est encore mieux. C'est du "write-only" : ce n'est pas fait pour être beau, c'est fait pour être efficace.
  
  Il fait ce qu'on lui demande (l'optimum), et ceci quel que soit le compilateur utilisé, du vieux compilo C pré-ANSI au tout dernier G++/VS-C++, et s'il le fait correctement, on revoit le code au prochain changement de matériel, c'est à dire dans dix ans... Et on le jettera alors pour en réécrire un pour le nouveau matos !
  
  
• "Crucify Him" : Un mélange infect (et surtout non cohérent) des autres modes...

[Médinoc]

Je programme pas mal en C∩C++, mais je tends à l'étendre un peu par l'usage de macros (notamment pour mes casts: mes macros deviennent des casts C++ quand je compile dans ce langage).

[Invité]

Pour moi, ce dernier point, c'est déjà du "vrai" C++.

vector et string probablement, ce sont des classes. Les algos STL, vu que la plupart supportent des pointeurs en lieu et place des itérateurs, pour un non initié, ca ressemble furieusement à une bibliothèque utilitaire C, non?

Si tu n'as pas vu la directive using que j'ai cachée quelque part, dans un code C, je ne crois pas que tu tiques si tu vois

sort(ptr, ptr+nb);

ou même

find(tab, tab+nb, val);

Francois

[nikko34]

Je me trompe peut être, mais j'ai l'impression que pour vous le soucis principal est la portabilité.

J'avoue que j'ai des soucis bien différents, dans le sens où on peut se permettre d'utiliser des ordinateurs avec des compilateurs qui respectent le standard, en programmant nous en respectant le standard et surtout sans bibliothèques maisons énormes mais juste le strict nécessaire. On ne va pas se trimballer 40 standards différents pour le plaisir. Enfin on peut se permettre d'en avoir qu'un quoi.

Le jour où on change carrément de marque/ou une grosse évolution du matériel embarqué, on prendra quelque chose respectant aussi le standard (on aura au mieux un gcc plus récent, au pire le même qu'actuellement). (enfin on sait jamais c'est sûr).

Et pour nos applis industrielles ne fonctionnant pas sur matériel embarqué, C++/boost et c'est la fête.