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

a marqué ce sujet comme résolu.
Auteur du sujet

Tout le monde se secoue ! :D

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…

Édité par Eskimon

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+1 -0

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.

#JeSuisGrimur #OnVautMieuxQueÇa

+1 -0

Salut,

Orthographe :

Efficient C Tips #1

Pourquoi ne pas traduire aussi le début du titre en un truc comme "Astuces pour coder en C plus efficacement" par exemple ?

je compte profite de mon temps libre

profiter

D'après mon expériences

expérience

du temps en embarqués on travail

embarqué & travaille

Il s'avère aussi que travail

travailler

est plus rapide et sûre

plus sûr

un tas de problème.

problèmes

développeurs embarqué

embarqués OU dans l'embarqué

un tas de type définit

types & définis

Si vous écrivez pour une plateforme particulière, vous devez être en mesure de déterminer si c'est un |microcontrôleur/microprocesseur 8, 16, 32 ou 64 bits et pourriez alors faire votre choix sur ce seul critère.

devriez et pourrez

ces types sont censé levé

censés lever

la norme C99 rends

rend

un uint8_t vous garanti

garantit

Si votre compilateur ne supporte pas le C99, alors attendez qu'il le soit ou changer de fabricant !

qu'il le fasse ou changez de fabricant !

des améliorations possible

possibles

Autre articles de cette série :

Autres


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.

Édité par Rek

+0 -0

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.

Mon Github | Pony : Un langage à acteurs sûr et performant

+0 -0

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.

The typedef name intN_t designates a signed integer type with width N , no padding bits, and a two’s complement representation.

[…]

These types are optional.

ISO/IEC 9899:T3, doc. N1256, § 7.18.1.1, al. 1 à 3, p. 256.

Édité par Taurre

+0 -0
Auteur du sujet

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).

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+0 -0

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. :)

#JeSuisGrimur #OnVautMieuxQueÇa

+0 -0
Auteur du sujet

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).

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+0 -0

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).

Eskimon

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é.

Mon Github | Pony : Un langage à acteurs sûr et performant

+0 -0
Auteur du sujet

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)

ZdS, le best du Zeste ! | Tuto Arduino, blog, etc

+0 -0

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. :)

#JeSuisGrimur #OnVautMieuxQueÇa

+0 -0

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.

Looping

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. ;)

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.

Édité par Taurre

+0 -0

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. :)

#JeSuisGrimur #OnVautMieuxQueÇa

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte