Discussion :

[Mizar75]

Bonjour

On me demande de faire des régles de codage pure C++. C'est à dire en supprimant les méthodes du C ayant un remplacant C++.

C'est bête mais je séche.

J'ai identifié
- Pas de structure mais des classe
- pas de malloc/free mais des new/delete
- pas de pointeur de fonctions
- pas de #define (#define PI 3.14 mais static const double pi=3.14)
- réduction de la portée des variable (déclaration au plus prés de l'utilisation)
- utilisaition de la stl

et...

Des idées ???
merci

[stardeath]

pas de pointeur nu -> pointeur intelligent

[Niark13]

Salut,

- Pas de structure mais des classe

Je ne suis pas trop d'accord sur ce point. Se priver de faire un POD tout bête quand il n'y a pas besoin de plus revient à se forcer à faire compliqué quand on peut faire simple. Après tout dépend de son utilisation.

Pour compléter ta liste :
- Pas de tableaux de char mais des std::string
- Pas de tableaux, mais des std::vector/std::array
- Pas de setlocale, mais std::locale
- numeric_limits<int>::max plutôt que la macro INT_MAX

Si tu as droit à C++11 :
- remplacement de rand() par <random>
- remplacement de ton api native de threads par <thread>

[jblecanard]

pas de pointeur nu -> pointeur intelligent

My god, surtout pas ! Les pointeurs intelligents répondent à des besoins précis, il ne faut surtout pas en faire une utilisation systématique.

Je ne suis pas trop d'accord sur ce point. Se priver de faire un POD tout bête quand il n'y a pas besoin de plus revient à se forcer à faire compliqué quand on peut faire simple.

Ca va plus loin que ça, les struct C++ ne sont d'ailleurs pas des struct C, ils sont quasiment identiques aux classes et sont très utilisés.

Une règle importante selon moi: remplacer les cast C par des casts C++.

[cob59]

- pas de pointeur de fonctions

« ... là où d'autres stratégies (polymorphisme, foncteurs, ...) suffisent » ?

[stardeath]

My god, surtout pas ! Les pointeurs intelligents répondent à des besoins précis, il ne faut surtout pas en faire une utilisation systématique.

bah je dirai comme toutes les fonctionnalités du "c" dans ce cas.
utiliser des pointeurs intelligents, c'est une des premiers choses qu'on fait quand on commence à jouer avec les exceptions, le surtout pas est un peu gros.

[jblecanard]

D'accord c'est un peu sec, pardon , mais c'est pour bien mettre en garde l'op ! Je voulais dire "ne surtout pas instaurer comme règle de remplacer les pointeurs nus par des pointeurs intelligents". Ca reste des cas assez rare dans la pratique. Les pointeurs intelligents ont un sens fort sur le cycle de vie de l'objet, il faut être très prudent avec. Je te renvoie vers cet article qui traite du sujet en profondeur.

[stardeath]

pas de problème, je suis d'accord

pas de macro genre min, max, avantageusement remplacé par des template et/ou fonction inline.

[ternel]

D'une manière générale, je dirai:

Mes principes de bases du codeur qui veut pouvoir dormir:

• Une variable de moins est une source d'erreur en moins.
• Un pointeur de moins est une montagne d'erreurs en moins.
• Un copier-coller, ça doit se justifier... Deux, c'est un de trop.

J'y ajoute aussi:

• RAII toujours, rira bien qui finira son programme…
• commente d'abord, programme après, le commentaire en sera toujours plus utile
• le code s'écrit du papier au clavier, jamais dans l'autre sens

[Niark13]

Ca va plus loin que ça, les struct C++ ne sont d'ailleurs pas des struct C, ils sont quasiment identiques aux classes et sont très utilisés.

Ça me semblait tellement évident que j'ai sous-entendu que struct == POD dans le message d'origine. Mea culpa

[koala01]

Salut,

Je mettrais en gros et en tout premier lieu: Penser en terme de services rendus et non en terme de données utilisées

N'oublies pas que l'encapsulation n'est pas le principe de base de la programmation OO, même si ce principe a quelque part été "institutionnalisé" avec ce paradigme

Le principe de base de la programmation OO est la substituabilité (le fait de pouvoir faire passer un pointeur (ou une référence) sur un objet d'un type dérivé pour un pointeur (ou une référence) sur un objet du type de base

Je rajouterais très vite le respect primordial de LSP (et des autres principes SOLID)

[Emmanuel Deloget]

My god, surtout pas ! Les pointeurs intelligents répondent à des besoins précis, il ne faut surtout pas en faire une utilisation systématique.

Il y a toujours std::unique_ptr<> en C++11 (et std::auto_ptr<> en C++98, en faisant très attention à ce qui se passe). Ceux là peuvent remplacer des pointeurs nus, mais encore faut-il apprendre à s'en servir pour éviter leurs pièges restrictifs (avec std::unique_ptr<>, il faut souvent jouer avec la sémantique de mouvement ; avec std::auto_ptr<>, outre le fait que l'achat d'une corde utile pour un éventuel suicide, il faut faire attention à la sémantique de mouvement implicite).

Ca va plus loin que ça, les struct C++ ne sont d'ailleurs pas des struct C, ils sont quasiment identiques aux classes et sont très utilisés.

Je te suis sur ce point - les struct ne doivent pas être écartées du langage - elles sont extrêmement importantes : c'est souvent une struct qu'on utilisera par exemple pour définir un foncteur ou les classes helper cachées dans une implémentation template complexe (parce que la sémantique du tout public sauf ce qui est marqué comme ne l'étant pas permet d'écrire un code un peu plus compact qu'en utilisant une classe).

Ça me semblait tellement évident que j'ai sous-entendu que struct == POD dans le message d'origine. Mea culpa

Les types POD ont nécessairement leur utilité. Par exemple, le header d'un fichier sera exprimé sous la forme d'un POD, une structure avec laquelle on communique avec l'OS idem, etc.

Une règle importante selon moi: remplacer les cast C par des casts C++.

Ca, oui. Par contre il faut bien comprendre les règles permattant de distinguer const_cast<>, dynamic_cast<>, static_cast<> et reinterpret_cast<> - et ne pas se contenter de remplacer tous les casts C par des reinterpret_cast<>.

Un règle importante selon moi : pas de pointeurs void en C++.

[Mizar75]

Salut,
Je ne suis pas trop d'accord sur ce point. Se priver de faire un POD tout bête quand il n'y a pas besoin de plus revient à se forcer à faire compliqué quand on peut faire simple. Après tout dépend de son utilisation.

Effectivement c'est peut être un peut bcp de faire une classe pour un POD. mon idée été l'utilisation de code dans une struct.

D'une manière générale, je dirai:

• commente d'abord, programme après, le commentaire en sera toujours plus utile
• le code s'écrit du papier au clavier, jamais dans l'autre sens

Ça c'est aussi valable pour le C, le Java, le VB, le Php, le ....

Ca, oui. Par contre il faut bien comprendre les règles permattant de distinguer const_cast<>, dynamic_cast<>, static_cast<> et reinterpret_cast<> - et ne pas se contenter de remplacer tous les casts C par des reinterpret_cast<>.

Const_cast: J'ai pas encore compris à quoi cela peu servir

Un règle importante selon moi : pas de pointeurs void en C++.

Je signe

[Niark13]

Const_cast: J'ai pas encore compris à quoi cela peu servir

Si tu utilises des fonctions C qui datent de Mathusalem et qui ont des paramètres déclarés comme char* alors qu'elles ne modifient pas les données. Par exemple, certaines version libiconv.

À part ça, effectivement, l'emploi de const_cast est dur à justifier.

[Flob90]

const_cast sert aussi dans l'écriture d'implémentation de couple de fonction const/non_const pour écrire l'une en fonction de l'autre (factorisation du code).

[jblecanard]

À part ça, effectivement, l'emploi de const_cast est dur à justifier.

Quand tu arrives dans une base de code dans laquelle const été sous utilisé et que tu veux toi utilisons la constness un peu proprement... tu ne peux pas mettre à jour tout le code concerné parce que introduire du const là ou il n'y en avait pas se révèle très fastidieux. Ou alors parce que le code n'appartient pas à ton équipe et que tu ne peux pas le modifier. Et tu ne veux pas non plus ne pas utiliser const en te disant "tant pis fuck ça compilera". Donc quelques const_cast bien choisis peuvent se révéler utiles... du moment qu'on sait ce qu'on fait et qu'on maitrise la situation.

[Luc Hermitte]

My god, surtout pas ! Les pointeurs intelligents répondent à des besoins précis, il ne faut surtout pas en faire une utilisation systématique.

Comme le dit Emmanuel, les pointeurs intelligents ne se limitent pas aux pointeurs à comptage de référence. std::vector est d'une certaine façon un pointeur intelligent -- bien qu'il rendent bien d'autres services.

Si tu préfères, il faut systématiser les capsules RAII. Au développeur ensuite de savoir choisir la bonne capsule pour chaque cas. J'aime beaucoup l'article de Lahman au sujet de l'écriture de code robuste.