Version imprimable
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
pas de pointeur nu -> pointeur intelligent
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.Citation:
- Pas de structure mais des classe
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>
My god, surtout pas ! Les pointeurs intelligents répondent à des besoins précis, il ne faut surtout pas en faire une utilisation systématique.Citation:
Envoyé par stardeath
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.Citation:
Envoyé par Niark13
Une règle importante selon moi: remplacer les cast C par des casts C++.
« ... là où d'autres stratégies (polymorphisme, foncteurs, ...) suffisent » ?Citation:
- pas de pointeur de fonctions
bah je dirai comme toutes les fonctionnalités du "c" dans ce cas.Citation:
Envoyé par jblecanard
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.
D'accord c'est un peu sec, pardon :mrgreen:, 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.
pas de problème, je suis d'accord :ccool:
pas de macro genre min, max, avantageusement remplacé par des template et/ou fonction inline.
D'une manière générale, je dirai:
J'y ajoute aussi:Citation:
Envoyé par ma signature du moment
- 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
Ça me semblait tellement évident que j'ai sous-entendu que struct == POD dans le message d'origine. Mea culpaCitation:
Envoyé par jblecanard
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 :D
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) ;)
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).Citation:
Envoyé par jblecanard
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).Citation:
Envoyé par jblecanard
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.Citation:
Envoyé par Niark13
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<>.Citation:
Envoyé par jblecanard
Un règle importante selon moi : pas de pointeurs void en C++.
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.Citation:
Envoyé par Niark13
Ça c'est aussi valable pour le C, le Java, le VB, le Php, le ....:ccool:Citation:
Envoyé par leternel
Const_cast: J'ai pas encore compris à quoi cela peu servir :cry:Citation:
Envoyé par Emmanuel Deloget
Je signeCitation:
Envoyé par Emmanuel Deloget
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.Citation:
Envoyé par Mizar75
À part ça, effectivement, l'emploi de const_cast est dur à justifier.
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).
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.Citation:
Envoyé par Niark13
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.Citation:
Envoyé par jblecanard
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.