Efficient C Tips #1 - Choisir la bonne taille d'entiers

Tout le monde se secoue !

J'ai commencé (il y a une heure) la rédaction d'un article au doux nom de « Efficient C Tips #1 - Choisir la bonne taille d'entiers » et j'ai dans l'objectif de proposer en validation un texte aux petits oignons. Je fais donc appel à votre bonté sans limite pour dénicher le moindre pépin, que ce soit à propos du fond ou de la forme. Vous pourrez consulter la bêta à votre guise à l'adresse suivante :

Merci !

C'es tapé/traduit au kilomètre (donc sans relecture), donc probablement pas mal de fautes de français sont présentes…

Je n’ai pas encore regardé la traduction, mais je peux déjà dire que je trouve que les contenus sont très très courts. Il serait à mon avis plus judicieux de les regrouper. Peut-être en un seul article, peut-être en une série de 3-4 articles. Mais clairement pas 13 articles aussi riquiqui.

Par ailleurs, cet article ne semble pas apparaître dans ta liste.

Salut,

Orthographe :

Remarques générales :

Pour le fond lui-même, je n'ai pas grand chose à dire, ce n'est pas mon domaine, mais ça me semble suffisamment clair. Après, la traduction me paraît parfois bancale, peut-être trop mot à mot ? Mais globalement c'est bien. Sur le contenu en lui-même, j'y verrais plus comme un billet, peut-être à cause du ton employé par l'auteur, mais à voir ce qu'en pensent les autres.

Une autre possibilité serait d'en faire un contenu unique (moyen-tuto ? moyen-article si c'est possible ?) mis à jour à chaque nouvelle traduction.

Sinon tribune libre vu le format court.

Salut.

peu de personnes savent que le C99 a apporté de nouvelles conventions de nommage pour des types de données particuliers […]. Ce qui n'est pas si connu est le fait qu'il existe aussi […].

La version originale utilise "quite a few people", qui signifie « un certain nombre de personnes » plutôt que « peu de personnes ».

Concernant le sujet traité, je trouve le conseil daté. L'écrasante majorité des variables d'un programme C seront stockées dans des registres après le passage de l'optimiseur, et le compilateur est libre de choisir la taille de registre indépendamment du type original dans le code C. C'est aussi valable pour la taille en pile des spill/reload.

Le conseil était peut être entièrement valable en 2008, mais aujourd'hui, à moins de travailler avec des pointeurs (et encore, même là l'optimiseur peut bidouiller), les compilateurs font un bien meilleur job à ce niveau.

Salut,

L'article est intéressant, mais un peu court comme le souligne Dominus. Ne serait-il pas possible de le regrouper avec les autres traitants également des entiers ?

S'il est compatible, vous trouverez en plus des types uint8_t et compagnie au moins deux autres sections : "minimum width" et "fastest minimum width".

La présence des types uintXX_t est facultative, seuls les types int_leastXX_t et int_fastXX_t sont obligatoires. Un compilateur peut donc parfaitement être compatible avec la norme C99 et ne pas proposer les types uintXX_t.

La version originale utilise "quite a few people", qui signifie « un certain nombre de personnes » plutôt que « peu de personnes ».

Permet moi d'en douter.

Concernant le sujet traité, je trouve le conseil daté. L'écrasante majorité des variables d'un programme C seront stockées dans des registres après le passage de l'optimiseur, et le compilateur est libre de choisir la taille de registre indépendamment du type original dans le code C. C'est aussi valable pour la taille en pile des spill/reload.

Le conseil était peut être entièrement valable en 2008, mais aujourd'hui, à moins de travailler avec des pointeurs (et encore, même là l'optimiseur peut bidouiller), les compilateurs font un bien meilleur job à ce niveau.

Faisant de l'embarqué sur des micro 8 bits peu puissant et 32 bits plus costaud, j'ai perso trouvé son article hyper pertinent (et bien que du métier, je n'avais aucune idée de ces types fast/least et rien que pour la curiosité j'étais content de trouver ce document).

La version originale utilise "quite a few people", qui signifie « un certain nombre de personnes » plutôt que « peu de personnes ».

Permet moi d'en douter.

Je me dois de confirmer. Quite a few, ça veut dire « un bon paquet ».

Je n’ai pas lu l’intégralité de la traduction, mais je vais te faire la même remarque qu’à Saroupille : tu t’éloignes trop du texte original. Par exemple, quand le texte original dit :

In my experience in writing programs for both embedded systems and computers,

… tu traduis cela par :

D'après mon expériences en tant que programmeur et développeur sur système embarqué

… passant ainsi totalement à la trappe le fait qu’il parle à la fois de systèmes embarqués et d’ordinateurs plus classiques.

Autre exemple.

The answer to the first question is a bit long winded and consists of:

[…]

The answer to the second question is short: No!

Et ta traduction.

La réponse à la première question est assez longue mais peut se résumer à :

[…]

La réponse à la deuxième question est simple : Non.

1. Long winded signifie « interminable, trop long », et non « assez long ».
2. Il n’y a aucune idée de résumé dans sa phrase.
3. En traduisant short par « simple », non seulement tu changes le sens, ce qui est mââââââl en soi, mais en plus, tu perds l’effet de miroir entre long winded et short.

Un peu plus loin :

such a trite answer will quickly get you into trouble

… qui devient :

les choses ne sont pas si évidente

… est clairement abusé.

Bon, je m’arrête là, tu as compris l’idée. J’ai bien conscience que c’est traduit « au kilomètre », mais il ne suffira pas d’une relecture orthotypo pour corriger ce qui ne va pas.

Je me dois de confirmer. Quite a few, ça veut dire « un bon paquet ».

Autant pour moi, j'étais persuadé de déjà l'avoir rencontré/entendu dans le sens traduit.

Pour le reste, j'ai pas eu le sentiment d'être si éloigné lors de l'écriture (afin d'éviter aussi de faire du mot à mot, pas forcément agréable)

passant ainsi totalement à la trappe le fait qu’il parle à la fois de systèmes embarqués et d’ordinateurs plus classiques.

Yep, mea culpa, je me souviens d'avoir écris cette phrase en deux fois, ayant été dérangé pendant l'écriture

The answer to the first question is a bit long winded and consists of:

Le mec dit que c'est long et finalement met ca en quelques points. Si c'est pas un résumé ca…

Après je clame clairement pas être parfait point de vue traduction. J'ai apparement voulu faire trop vite (impatience quand tu nous tiens) et le résultat en pâti, c'est dommage. Il faudra que je sois plus patient/vigilant si je continue. C'est un métier (pas le mien) et j'ai voulu faire la tentative. À voir si c'est pertinent, tant au niveau de la forme que du fond qui semble discutable. Toujours est-il que ce n'est pas perdu, ca finira surement sur mon blog après relecture (et toujours mention de l'original pour éviter que mes imperfections nuisent de trop à l'original).

Es-tu obligé de traduire fidèlement ? Ne peux-tu pas "t'inspirer de" ? Tout en mettant le lien vers l'original. Ça te permettrait de l'écrire avec ton propre style.

Oui, la question générale reste intéressante et on peut encore trouver des applications à ces types. Mais ils viennent quand même d'une norme ayant plus de 15 ans, et les problématiques auxquelles ils répondaient ont évolué.

et les problématiques auxquelles ils répondaient ont évolué.

Justement, pas dans l'embarqué. Il arrive encore de travailler sur des systèmes vraiment limité où ce genre de conseils peut avoir son sens (en tout cas je trouve)

J'ai apparement voulu faire trop vite (impatience quand tu nous tiens) et le résultat en pâti, c'est dommage. Il faudra que je sois plus patient/vigilant si je continue.

Oui. Les gens se rendent rarement compte que, même avec de l’entraînement, une heure pour traduire une page A4 n’est pas une durée aberrante.

Techniquement, une traduction se doit d'être la plus fidèle possible à l'original.

près je clame clairement pas être parfait point de vue traduction. J'ai apparement voulu faire trop vite (impatience quand tu nous tiens) et le résultat en pâti, c'est dommage. Il faudra que je sois plus patient/vigilant si je continue.

Tracasse, c'est pour ça qu'il y a la relecture. N'essaye pas d'avoir la traduction parfaite d'un coup, je connais des juriste-linguistes et je ne les ai jamais vu réussir des traductions du premier coup. Ce qui compte c'est avoir un premier jet, c'est bien plus facile de corriger par la suite. L'idée, c'est d'abord de récupérer le gros du texte avant de s'assurer d'en préserver l'esprit. C'est en repassant plusieurs fois sur le texte qu'on modifie petite touche par petite touche.

Tiens j'en profite de t'avoir toi et Dominus sous la main. Comment se passe la propriété intellectuel d'une traduction ? Entre autres, puis-je avoir une licence différente de l'original ?

Si mes souvenirs sont bons, il s'agit d'une œuvre dérivée, il te faut donc l'accord de l'auteur pour la réaliser et la publier. Après, tu disposes également de droits sur ta traduction et tu es donc libre de moduler ceux-ci.

Comme dit Taurre, une traduction est une œuvre dérivée sur laquelle tu as les droits d’auteur, dans la limite des autorisations concédées par l’auteur de la version originale.

Ça veut dire que, par exemple, tu ne peux pas de ton propre chef autoriser les gens à traduire ta propre traduction, parce que cela reviendrait à les autoriser à traduire la VO, ce que tu n’es pas habilité à faire.

Et du coup si la VO est en tout droit réservé, je dois faire de même ?

Non, tu peux mettre la traduction en CC BY-SA-NC-ND ou sous une licence équivalente.