Discussion :

[germinolegrand]

Poursuivant les dix premiers articles de la série d'Alex Darby que l'on peut retrouver traduite ici : Programme d'étude sur le C++ bas niveau.

Bravo à Kalite qui vient de terminer la traduction du 11^e article :

Programme d'étude sur le C++ bas niveau n°11 : Héritage

Celui-ci porte sur l'héritage, il aborde la façon dont celui-ci se retrouve dans le code assembleur généré, il fait suite au 2^e article qui abordait les types et structures simples.

Le prochain abordera l'héritage multiple, cela promet d'être passionnant !

Et vous,
Connaissez-vous la portée de ce que vous écrivez, la façon dont cela impactera le code assembleur généré ?
Vous intéressez-vous au code généré par votre code C++ ? Pourquoi ?

---

Si vous souhaitez vous lancer dans la traduction ou la rédaction d'un article, n'hésitez pas à me contacter, je pourrai ainsi vous fournir tous les renseignements et les outils nécessaires !

[jblecanard]

Hello

Pas mal, par contre j'émettrais les réserves suivantes:
- Les noms des membres commencent par un _ ce qui est déconseillé car c'est une convention normalement réservée à la STL.
- L'impact de l'ajout d'une table virtuelle n'est pas abordé.
- L'impact de l'héritage multiple n'est pas abordé.

[oodini]

- Les noms des membres commencent par un _ ce qui est déconseillé car c'est une convention normalement réservée à la STL.

Déconseillé par qui ? La norme ?

- L'impact de l'héritage multiple n'est pas abordé.

D'après les propos de germinolegrand, cela sera traité dans l'élément suivant.

[Kalite]

Bonjour,

en effet l'héritage multiple est traité dans l'article suivant. Je suis entrain de le traduire donc encore un peu de patience.

[jblecanard]

Déconseillé par qui ? La norme ?

Oui, par la norme.

en effet l'héritage multiple est traité dans l'article suivant. Je suis entrain de le traduire donc encore un peu de patience.

Cool

[oodini]

Reserved in any scope, including for use as implementation macros:

• identifiers beginning with an underscore and an uppercase letter
• identifiers containing adjacent underscores (or "double underscore")

Reserved in the global namespaces:

• identifiers beginning with an underscore

Les membres commençant par un _ suivis par une minuscule, comme dans le code de l'article, ne semblent donc pas poser de problèmes.

[jblecanard]

C'est exact, mais c'est plus simple et moins source d'erreur de décider par convention de ne simplement pas mettre d'underscore au début du nom des membres tu ne crois pas ? Ce que préconise l'auteur de la réponse du lien, ce que préconisent les google guidelines, ainsi que des spécialistes reconnus comme Herb Sutter (par exemple dans cet article).

[Iradrille]

Connaissez-vous la portée de ce que vous écrivez, la façon dont cela impactera le code assembleur généré ?

J'ai souvent une bonne idée de ce que ça va donner en théorie, mais il reste encore trop de magie derrière le C++ et les optimisations des compilos pour prévoir le code généré exactement.

Vous intéressez-vous au code généré par votre code C++ ? Pourquoi ?

Rarement, dans deux cas seulement :
L'optimisation, une fois qu'on à le meilleur algo, il faut le meilleur code.
Le debug, mais ça reste rare, généralement un débogueur et quelques points d'arrêts suffisent.

[Luc Hermitte]

Sans aller chercher aussi loin, la FAQ est très claire sur les préfixages par des tirets-bas, et c'est le même discours que celui tenu par ailleurs : on n'est pas en Java/C#/whatever, le préfixage par un _telNom est globalement proscris car _Nom et __nom sont réservés aux implémentations de la lib standard et aux spécificités des compilos

Mais de toute façons, si l'auteur utilise un style d'écriture, n'allez pas le modifier dans le cadre d'une traduction. Si le traducteur a des remarques à émettre, il faut rajouter des NdT, et puis basta.

[jblecanard]

Mais de toute façons, si l'auteur utilise un style d'écriture, n'allez pas le modifier dans le cadre d'une traduction. Si le traducteur a des remarques à émettre, il faut rajouter des NdT, et puis basta.

C'est vrai, ma remarque porte bien sur le contenu effectif, pas sur la version traduite en particulier .