Discussion :

[kaitlyn]

Ben les calculs sur un nombre de 32bits n'en seront pas moins performants. Si tu n'as pas besoin d'un nombre de 64bits, int reste l’idéal.

[WhiteCrow]

Dans la norme C99, certains retiennent en priorité, les types mis en avant comme size_t, que la librairie standard utilise partout (1 exemple malloc), le retour int de main.
Et d'autres, les VLAs (qui sont dépréciés depuis C11), les instructions non standard comme _restrict et qui sont des conseils et attendent la nouvelle norme C23 pour savoir comment rendre lisible 1 code C.

Les VLA ne sont pas dépréciés (comme l'a pu être gets avant d'être obsolète et retirée), mais optionnels. Si la macro _ _STDC_NO_VLA_ _ est définie et vaut 1 alors l'implémentation ne propose pas les VLA. Même s'ils peuvent ne pas être proposés par une implémentation, elle doit néanmoins les reconnaître syntaxiquement, ce qui semble aller de soi ne serait-ce que pour émettre un message d'erreur indiquant que l'utilisateur les utilise mais que le compilo ne l'implémente pas.

restrict est un mot clé depuis C99, c'est un qualificateur de type dont le but même est de pouvoir avoir une optimisation plus aggressive.

Les types comme size_t ne sont pas utilisés partout dans la libc, mais partout où ils font sens. size_t par exemple sera préférentiellement utilisé là où la notion de taille, d'alignement ou de nombre d'éléments apparaît comme dans malloc mais aussi dans strlen ou fwrite (où d'ailleurs restrict apparaît aussi pour assurer au compilo que les deux pointeurs passés pointent bien sur deux objets différents).

Après tu as raison, j'ai été traumatisé par Visual C++ 2008-2010-2013 qui n'est pas compatible C99 : je définis toujours en premier mes variables, j'essaye de ne pas utiliser le nouveau commentaire, et mes booléens sont des unsigned char (et peut-être d'autres choses)


Et pour le type "idéal", le type int ne fait que 32 bits même en 64 bits : donc j'ai 1 doute sur cette affirmation

Ouais, moi aussi j'aime bien les années 80, mais surtout pour la musique

[WhiteCrow]

et si tu mets des size_t à la place de tes int cela fait quoi ?

Bah tu n'as pas essayé ???
C'est pourtant fait pour ça un site comme celui de godbolt, apprendre aussi par l'expérimentation … apprendre c'est toujours une bonne chose. Si tu essayes tu verras qu'effectivement le code produit change et ce d'une manière à laquelle tu ne dois pas t'attendre quand je lis la fin de ton message.

Il optimise que dalle ton compilateur ... or 1 somme ne peut être jamais négative (et je ne dis rien sur commencer ta boucle à 0 ne sert à rien sauf perdre 1 tour de boucle)

Donc tu n'as absolument rien compris à l'exemple, mais j'ai sans doute dû mal m'exprimer.
Tu as un code source très naïf pour calculer une somme avec un accumulateur et une boucle. Le truc de base c'est qu'un programmeur (ou développeur ou analyste ou …) un peu expérimenté et connaissant un peu ses math va remplacer cette affreuse boucle en O(n) par une belle formule explicite en O(1).
Le lien sur godbolt montre que le compilo le fait tout seul. Rien que ça, ça troue le cul. Bon après quand tu regarde un peu les coulisses, il y a du boulot avec des reconnaissances de patterns (inimaginable il n'y a que 10 ans dans le domaines pour des raisons de perf), rien de magique …
Donc le compilo il passe tout seul de la boucle à la formule explicite, mais il ne choisit pas la même expression que le dèv humain de base (comme moi et c'est ce qui me troue encore plus), il en choisit une dont le comportement est exactement conforme à la boucle de départ. Si la boucle plante (à cause d'un overflow) alors la formule aussi, si la boucle ne plante pas alors la formule non plus ⇒ c'est une production de code conforme. Ce qui n'est pas le cas de ce que fait en général un dèv humain.
Ce n'est qu'un exemple qui montre que désormais, et cela sera de plus en plus vrai dans l'avenir, un compilateur sera toujours plus intelligent qu'un humain. Que cet humain ne doit pas essayer d'optimiser le code (dont la production finale lui échappe complètement) mais d'aider le compilo là où il a des encore des soucis de compréhension.
Voilà l'essence de la recommandation 15 du WG14 pour C23.

Et pour ton "overflow" ne peut intervenir qu'à INT_MAX (à cause du +1) ... or ta somme cela fait déjà depuis longtemps qu'elle déborde (à N=20724 si je ne me trompe pas)

Alors que la formule n(n-1)/2+n avec des types non signés ne donnent pas de valeurs correctes pour 0 (à cause du -1)

De toute manière, c'est le genre de calcul à faire en macro

#define SUM(N) ((N * (N + 1)) / 2).
Et comme tu kiffes l'assembleur

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
        mov     rax, qword ptr [rsp]
        lea     rsi, [rax + 1]
        imul    rsi, rax
        shr     rsi
        mov     qword ptr [rsp], rsi

Ce n'est pas «mon» overflow
L'overflow est au niveau de la multiplication … pas de l'addition. J'aurais sans doute dû préciser, cela me semblait évident.
Et à nouveau, ce n'est pas l'assembleur que je kiffe, mais la manière dont le compilo est smart, tellement plus qu'un humain sur ce genre de chose.

Edit:
En te relisant je me dis que je peux encore ajouter une brique …
Une fonction static inline sera bien plus efficace qu'une macro, surtout si tu indiques au compilo que c'est une fonction pure ou constante. Il calculera lui même la valeur du résultat de l'appel à la compilation et pas au run time …
Et en plus tu as la vérification des types et pas d'effets de bord genre ceux d'un SUM(n++) …

[foetus]

Donc tu n'as absolument rien compris à l'exemple, mais j'ai sans doute dû mal m'exprimer.

Sisi j'ai bien compris mon propos c'est : je suis là pour coder et non pas pour chaque ligne, savoir comment va compiler tel ou tel compilateur (... et si je peux le savoir )
Comme l'a dit @Sve@r, en embarqué (ou C++ Builder avant le XE7 ), ce sont des compilateurs qui sont propriétaires qui n'ont que faire des normes C (du moins il respecte en partie C89)

Et j'ai testé et l'assembleur change en fonction du type, de la première valeur (0 ou 1), si tu mets l'incrémentation dans la boucle (boucle vide) ... et je n'ai pas testé la récursion ni le return dans la boucle (même si c'est débile)
Et on parle d'1 "banale" somme avec 1 formule mathématique comme solution et c'est déjà

Comme je l'ai dit commence à apprendre à programmer : 1 fonction ou 1 macro, prendre le bon type (1 signed a 2 fois moins de valeurs positives qu'1 unsigned et pour 1 somme cela permet de repousser les débordements), éviter les tours de boucle qui ne servent à rien, ...
Et comme le dit @Sve@r, lorsqu'on est 1 bon programmeur, on simplifie par 1 fonction mathématique ... + rapide, - de code, 0 dépendance compilateur.

un peu ses math va remplacer cette affreuse boucle en O(n) par une belle formule explicite en O(1).

Tu m'as pris pour 1 imbécile, mais il y a 2 types de codeurs : ceux qui créent les briques logicielles, et ceux qui les utilisent.
Et désolé, mais que le compilateur puisse faire cela, cela est notable, mais j'en ai rien à braire : c'est le travail du programmeur de s'assurer que son code va fonctionner correctement sur tous les compilateurs utilisés.
Mais aujourd'hui, on veut former les développeurs le + rapidement possible : donc on reste en surface en utilisant des langages haut niveau et des bibliothèques.
Effectivement, le développeur va se consacrer quasi que sur des problèmes métiers et il y a sûrement 1 corrélation avec les délais de développement.
Mais ne te trompes pas : le langage C n'est pas devenu obsolète. Il ne permet pas de faire du développement Web et donc avec les demandes employeurs, il devient 1 niche.

Ce n'est pas «mon» overflow
L'overflow est au niveau de la multiplication … pas de l'addition. J'aurais sans doute dû préciser, cela me semblait évident.

Là encore ce n'est pas au compilateur d'anticiper les débordements mais au programmeur de choisir le bon type et la bonne plage (32 bits unsigned int ou unsigned long, 64 bits unsigned long long, size_t en automatique) ... voire carrément utiliser SIMD ou les "big numbers"
Et en fonction du choix, le code peut être radicalement différent

Et de plus, si N=20724 on déborde 32 bits. Donc que ce soit 1 multiplication avec N+1 ou N-1, cela ne va pas changer grand chose

Et à nouveau, ce n'est pas l'assembleur que je kiffe, mais la manière dont le compilo est smart, tellement plus qu'un humain sur ce genre de chose.

Aussi intelligent qu'il soit, il lui manque le contexte d'exécution (précédente réponse)

Une fonction static inline sera bien plus efficace qu'une macro, surtout si tu indiques au compilo que c'est une fonction pure ou constante. Il calculera lui même la valeur du résultat de l'appel à la compilation et pas au run time …

C'est vraiment cela qui serait intéressant : les constexpr du C++. Mais comme inline cela reste 1 conseil, et on n'est jamais sûr que le compilateur va le faire ou pas.
1 macro c'est moche, c'est potentiellement dangereux, mais tu sais que n'importe quel compilateur va faire le remplacement ... et tu macroifer des pans de code sans que ce soit 1 fonction/ procédure/ méthode.

[WhiteCrow]

Sisi j'ai bien compris mon propos c'est : je suis là pour coder et non pas pour chaque ligne, savoir comment va compiler tel ou tel compilateur (... et si je peux le savoir )
Comme l'a dit @Sve@r, en embarqué (ou C++ Builder avant le XE7 ), ce sont des compilateurs qui sont propriétaires qui n'ont que faire des normes C (du moins il respecte en partie C89)

Et j'ai testé et l'assembleur change en fonction du type, de la première valeur (0 ou 1), si tu mets l'incrémentation dans la boucle (boucle vide) ... et je n'ai pas testé la récursion ni le return dans la boucle (même si c'est débile)
Et on parle d'1 "banale" somme avec 1 formule mathématique comme solution et c'est déjà

Comme je l'ai dit commence à apprendre à programmer : 1 fonction ou 1 macro, prendre le bon type (1 signed a 2 fois moins de valeurs positives qu'1 unsigned et pour 1 somme cela permet de repousser les débordements), éviter les tours de boucle qui ne servent à rien, ...
Et comme le dit @Sve@r, lorsqu'on est 1 bon programmeur, on simplifie par 1 fonction mathématique ... + rapide, - de code, 0 dépendance compilateur.

Donc non … ça te passe au-dessus de la tête apparemment.
Un bon programmeur ne va plus «simplifier par une fonction mathématique +rapide -code» parce que justement les compilos deviennent plus intelligents que le vrai faux bon mauvais programmeur …
Tu n'as absolument pas compris que si tu es un mauvais programmeur (selon tes critères) tu obtiens un meilleur code que lorsque tu essayes de bidouiller ?
C'était déjà vrai depuis quelques temps, même avec les compilo de niche (ce qui n'a rien à voir ici avec un PO sur mac qui apprend le C), mais cela est de plus en plus vrai …

As-tu au moins fait l'effort de tester sur le site de Godbolt ? (un conférencier dont je recommande vivement les vidéos).

Tu m'as pris pour 1 imbécile, mais il y a 2 types de codeurs : ceux qui créent les briques logicielles, et ceux qui les utilisent.
Et désolé, mais que le compilateur puisse faire cela, cela est notable, mais j'en ai rien à braire : c'est le travail du programmeur de s'assurer que son code va fonctionner correctement sur tous les compilateurs utilisés.
Mais aujourd'hui, on veut former les développeurs le + rapidement possible : donc on reste en surface en utilisant des langages haut niveau et des bibliothèques.
Effectivement, le développeur va se consacrer quasi que sur des problèmes métiers et il y a sûrement 1 corrélation avec les délais de développement.
Mais ne te trompes pas : le langage C n'est pas devenu obsolète. Il ne permet pas de faire du développement Web et donc avec les demandes employeurs, il devient 1 niche.

Humm … ça sent le pedantic lol
Ah ben oui … si tu es quelque part où on utilise un compilateur C74 pour un Z80 tu ne vas pas vraiment pouvoir bénéficier des avancées faites ces 47 dernières années
Et bien sûr qu'une époque est révolue … Il me semble que c'est Kevlin Henney ou Robert "uncle Bob" Martin qui expliquait fort justement que la première vague d'informaticiens, ceux qui ont réellement fait avancer les choses, est morte dans les années 90, cette vague constituée de tout (matheux, comptables, rh, …) sauf d'informaticiens tels qu'on les connaît aujourd'hui.
Il a fait une projection et il y a un doublement du nombre de <programmeur/dev/analyste/…> tous les 5 ans. Cela signifie que la moitié du parc de <…> est constituée de personnes ayant moins de 5 ans d'expérience … et on ne prend pas le turn over en compte.
Oui ça fait réfléchir.
Ah tient … tu connais emcc ? ok je joke à moitié quoique

Là encore ce n'est pas au compilateur d'anticiper les débordements mais au programmeur de choisir le bon type et la bonne plage (32 bits unsigned int ou unsigned long, 64 bits unsigned long long, size_t en automatique) ... voire carrément utiliser SIMD ou les "big numbers"
Et en fonction du choix, le code peut être radicalement différent



Aussi intelligent qu'il soit, il lui manque le contexte d'exécution (précédente réponse)

Bon je vais réessayer …
Lorsque le compilateur produit un code, il doit être conforme au source, peu importe que le source soit correct ou non.
Dans l'exemple que j'ai donné, le source devrait produire un résultat correct jusqu'à 92679 pour des int 32 bits.
Un compilateur, quelles que soient les décisions prises, doit produire un code qui produira un résultat correct jusqu'à 92679.
Peu importe que le code «traduise littéralement la boucle» ou qu'il soit super smart et produise une formule close … le code produit doit être correct.

La solution proposée par un <...> classique sera un remplacement de la boucle par le fameux n(n+1)/2, et cette solution sera fausse … c'est ce que tu appelles un bon <...>.
La solution proposée par clang (en l'occurrence) elle est correcte, correcte. Elle ne plantera pas à 65537 … tout comme la boucle ne plante pas à cette valeur …

C'est vraiment cela qui serait intéressant : les constexpr du C++. Mais comme inline cela reste 1 conseil, et on n'est jamais sûr que le compilateur va le faire ou pas.
1 macro c'est moche, c'est potentiellement dangereux, mais tu sais que n'importe quel compilateur va faire le remplacement ... et tu macroifer des pans de code sans que ce soit 1 fonction/ procédure/ méthode.

À nouveau je ne parle pas de simples fonctions inline, mais de fonctions static inline … et je ne parle pas de constexpr de C++ car c'est un autre langage. Donc oui … les static inline seront toujours (sauf indication contraires données par le <...> lors de la compilation) inlinées, il y a d'autres inconvénients comme la duplication de code qui peut aussi être surmontée par une analyse de programme entier. Ooops … enfin avec des compilos modernes, s'entend.
Utiliser les macros comme tu le préconises n'est plus un bon conseil pour un débutant sur plateforme moderne, bien au contraire … à moins d'utiliser les mécanismes de généricité il n'y a plus d'utilité à faire des fonctions macros.

Edit: j'ai du me planter d'un facteur 2 dans mes chiffres, désolé.

[Sve@r]

Tu n'as absolument pas compris que si tu es un mauvais programmeur (selon tes critères) tu obtiens un meilleur code que lorsque tu essayes de bidouiller ?

Est-ce que cela va gêner le compilateur que de coder la somme ainsi unsigned long somme(unsigned short n) {...} plutôt que int somme(int n) {...} ?
Si c'est le cas moi ça m'embête parce que l'étape suivante ce sera les compilateurs qui coderont à ma place et ensuite qui se rendront compte que je ne sers plus à rien.
Et si ce n'est pas le cas, alors je prefère la première écriture qui, sans nuire au résultat, informe un autre lecteur que la somme sera potentiellement assez élevée mais qu'elle restera positive et que le nombre qu'on lui passe, lui, ne doit pas être trop élevé et lui aussi être positif. Déjà rien que pour ça, ça vaut le coup.
Par ailleurs la seconde écriture peut, si la somme dépasse 2^16, tomber dans le négatif, autrement dit, produire un résultat faux. Donc c'est aussi pour ça que je préfère la première écriture. Je me souviens d'un de mes profs en école qui avait parlé de je ne sais plus quelle fusée qui s'était écrasée parce que les programmeurs du calculateur de vol avaient oublié que si le cosinus d'un angle positif est toujours positif, un sinus lui peut quand-même être négatif.

[WhiteCrow]

Est-ce que cela va gêner le compilateur que de coder la somme ansi unsigned long somme(unsigned short n) {...} plutôt que int somme(int n) {...} ?
Si c'est le cas moi ça m'embête.
Et si ce n'est pas le cas, alors je prefère la première écriture qui, sans nuire au résultat, informe un autre lecteur que la somme sera potentiellement assez élevée mais qu'elle restera positive et que le nombre qu'on lui passe, lui, ne doit pas être trop élevé et lui aussi être positif. Et rien que pour ça, ça vaut le coup.

Après le compilo ne fait que ce que tu lui demandes.
Avant il était plus un traducteur littéral … maintenant il devient plus un interprète genre What You Get Is What You Meant.
Le choix du type est ton choix, le compilo s'arrange pour produire le meilleur code selon tes critères en respectant ton choix.
Mais bon, avec le lien sur le site godbolt tu peux voir ce que ça donne en fonction des architectures, des compilos et options → https://godbolt.org/


Edit:

[...]
Par ailleurs la seconde écriture peut, si la somme dépasse 2^16, tomber dans le négatif, autrement dit, produire un résultat faux. Donc c'est aussi pour ça que je préfère la première écriture. Je me souviens d'un de mes profs en école qui avait parlé de je ne sais plus quelle fusée qui s'était écrasée parce que les programmeurs du calculateur de vol avaient oublié que si le cosinus d'un angle positif est toujours positif, un sinus lui peut quand-même être négatif.

Ah ben ça, le compilo ne va pas non plus faire un What You Get Is What You Wanted But Incorrectly Expressed
Je pense que l'idéal pour bien exprimer l'intention serait de soit utiliser les typdefs de stdint, ou les faire soi-même si on utilise un compilateur un peu ancien sur une plateforme ancienne ou un compilo non conforme …
Un uint64_t int_sum(uint32_t n) me semble clair dans l'intention par exemple.

[foetus]

Après le compilo ne fait que ce que tu lui demandes.

Je comprends que tu te pâmes sur ton compilateur

Je viens de vérifier avec 1 test unitaire Est-ce désormais 1 gros mot ? 1 truc que le compilateur fait ? délégué au "SUPRA TEST CHEF OFFICIER" ?
Entre 1 boucle et les 2 formules, la limite est 92682 avec des nombres non signés et 65536 avec des nombres signés.
Je me suis trompé avec mon N=20724 mais bon les tests des limites c'est la base et j'ai vu le truc.

Et en vérifiant sur Google , le dépassement de multiplication en C est 1 UB avec des nombres signés, mais pas avec des nombres non signés.
Les règles de conversion entre signed et unsigned, mais également entre les différents types sont très complexes.
Donc, dire que le compilo fait ce que tu lui demandes non, il y a des règles et des pièges.

Et l'autre truc, même le compilateur ne détecte pas les dépassements de multiplication : il faut tester ou prendre des types + larges (je parlais de SIMD et de "big numbers")
Par contre, comme les opérations se font sur des int, des opérations entre char et short peuvent résulter à des surprises : le compilateur fait vraiment ce que tu veux

[WhiteCrow]

Je comprends que tu te pâmes sur ton compilateur

Ah … susceptible … tu sais je n'ai rien contre toi, en particulier, mais bon quand tu écris des choses fausses que je repère, je les corrige …
Mais bon … passons sur ça et concentrons-nous sur ce que tu as toujours du mal à comprendre plutôt.
Ce n'est pas «mon» compilateur, c'est un compilateur parmi la liste proposée, avec un code et des options de compilations, mais encore faudrait-il que tu prennes le temps de suivre les liens que je donne.

Je viens de vérifier avec 1 test unitaire Est-ce désormais 1 gros mot ? 1 truc que le compilateur fait ? délégué au "SUPRA TEST CHEF OFFICIER" ?
Entre 1 boucle et les 2 formules, la limite est 92682 avec des nombres non signés et 65536 avec des nombres signés.
Je me suis trompé avec mon N=20724 mais bon les tests des limites c'est la base et j'ai vu le truc.

Et en vérifiant sur Google , le dépassement de multiplication en C est 1 UB avec des nombres signés, mais pas avec des nombres non signés.
Les règles de conversion entre signed et unsigned, mais également entre les différents types sont très complexes.
Donc, dire que le compilo fait ce que tu lui demandes non, il y a des règles et des pièges.

Et l'autre truc, même le compilateur ne détecte pas les dépassements de multiplication : il faut tester ou prendre des types + larges (je parlais de SIMD et de "big numbers")
Par contre, comme les opérations se font sur des int, des opérations entre char et short peuvent résulter à des surprises : le compilateur fait vraiment ce que tu veux

Maintenant je vais essayer une dernière fois de t'expliquer ce qui est intéressant dans ce que j'ai montré, en des termes simples :

le dèv propose un algo naïf pas forcément performant
le compilo reconnait l'algo et sait qu'il y a une implémentation plus efficace ⇒ il l'utilise à la place «de la bonne manière»

«de la bonne manière» = avec le même comportement … fonctionne pareil, plante pareil, etc …
ce n'est plus de l'optimisation de code, mais de l'optimisation d'algo … dit ainsi il va peut-être y avoir une étincelle ?


Maintenant il y a clairement des limites … que tu aurait pu découvrir si tu avais testé un minimum en suivant le lien … mais il ne faut pas demander l'impossible hein.
Par exemple, le compilo réagit différemment avec les entiers non signés, il réagit aussi différemment suivant leur taille … et c'est intéressant de comprendre pourquoi il retombe sur la boucle avec des unint64_t
Mais bon avant de comprendre ça, il faut déjà comprendre en quoi c'est étonnant que le compilo transforme un algo en O(n) en algo en O(1), une implémentation différente, de «la bonne manière».

Tu peux pérorer sur beaucoup de choses, mais bon … essaye au moins de suivre ce que je raconte et réagis sur cela, pas à côté …

[Sve@r]

Ah ben ça, le compilo ne va pas non plus faire un What You Get Is What You Wanted But Incorrectly Expressed

Ben oui mais tu dis que le compilo est assez intelligent pour détecter l'overflow d'une boucle sur la somme et pour ça, va rajouter exprès un "+n" à l'expression mathématique pour ainsi reproduire l'overflow qu'il a détecté (enfin c'est ce qui me semble car il y a eu beaucoup de posts). Donc désolé mais un compilo qui va détecter l'erreur et optimiser en reproduisant l'erreur exprès je trouve ça con. Autant alors rester sur le bon vieux compilo de base qui se contentait de retranscrire simplement ce que je lui disais plutôt qu'un truc qui va faire "héhé ce con ne sait pas que ça dépend ça dépasse alors laissons le se dém.". C'est autant ça de gagné pour tous ceux occupés à créer ces compilos en croyant faire avancer l'informatique. Sans déconner, moi qui pensais que l'ordinateur allait nous aider, non, maintenant on a des ordis qui voient l'erreur mais qui ne disent rien exprès. Plus les ordis de Chine qui, eux, comptent combien de fois tu traverses hors des clous et qui te mettent autant de points négatifs, il se présente joliment le monde de demain du capitaine Sky...

Sinon je suis allé voir godbolt. C'est effectivement un site super bien fait mais que je ne peux pas apprécier car mes connaissances en assembleur sont néant. Mais je comprends que pour un pointu de l'optimisation il puisse être précieux.

le compilo reconnait l'algo et sait qu'il y a une implémentation plus efficace ⇒ il l'utilise à la place «de la bonne manière»

«de la bonne manière» = avec le même comportement … fonctionne pareil, plante pareil, etc …
ce n'est plus de l'optimisation de code, mais de l'optimisation d'algo

Oui mais voilà quoi. Le compilo qui voit l'erreur mais qui ne la récupère pas, autant qu'il ne s'en occupe pas quoi, c'est autant de travail inutile en moins. Et qu'il me laisse faire mon algo à ma sauce, j'ai quand-même l'espoir que mon cerveau avec ses milliards de neurones fera mieux les choses qu'un code à 64 bits qui, même s'il sait remplacer la somme des n premiers entiers par la formule d'Euclide (super l'effort, il en sait autant qu'un élève de 6° sur un petit sujet de maths !!!) ne fera probablement pas beaucoup mieux. Saura-t-il calculer la somme d'une suite arithmétique de raison "r"? D'une suite géométrique? Des n premiers carrés? Non alors autant qu'il ne fasse rien et laisse faire ceux qui savent compter.

Un uint64_t int_sum(uint32_t n) me semble clair dans l'intention par exemple.

Ah là effectivement j'approuve. Je suis en effet assez fan de la centalisation. Le jour où par exemple uint64_t évolue, suffit de recompiler et tout le code s'y adapte. C'est en effet ce que tu aurais dû dire dès le départ plutôt que me reprocher mes conseils à propos du unsigned short pour stocker les trimestres de ce pauvre Bruno qui doit être totalement largué depuis.

[WhiteCrow]

Ben oui mais tu dis que le compilo est assez intelligent pour détecter l'overflow d'une boucle sur la somme et pour ça, va rajouter exprès un "+n" à l'expression mathématique pour ainsi reproduire l'overflow qu'il a détecté (enfin c'est ce qui me semble car il y a eu beaucoup de posts). [...]

ok, je commence à comprendre le malentendu.
Je ne dis pas que le compilo repère l'overflow. Je dis que le compilo fait de l'optimisation d'algo ce qui est vachement mieux !

Ce qui est étonnant c'est que le compilo repère l'algo et en choisisse un autre plus performant.
Ce qui est surprenant c'est que l'algo utilisé pour remplacer la boucle se comporte exactement de la même manière.
Ce qui est rigolo c'est que les dèv font souvent ça et que pour ce cas de figure ils le font mal en général (à cause d'un overflow qui est pris en compte par le remplacement du compilo).

Donc désolé mais un compilo qui va détecter l'erreur et optimiser en reproduisant l'erreur exprès je trouve ça con.

Bah c'est ce qu'on demande à un compilo, produire un code qui fait ce que tu lui demandes. Là où c'est fort c'est qu'il le fait en restant correct et en optimisant l'algo …

[...]
Ah là effectivement j'approuve. Je suis en effet assez fan de la centalisation. Le jour où par exemple uint64_t évolue, suffit de recompiler et tout le code s'y adapte. C'est en effet ce que tu aurais dû dire dès le départ plutôt que me reprocher mes conseils à propos du unsigned short pour stocker les trimestres de ce pauvre Bruno qui doit être totalmeent largué depuis.

bah quelquepart un uint64_t devrait toujours être un entier non signé codé sur 64 bits et ne devrait pas trop changer. Mais bon, un unsigned short, c'est ce que j'appelle de la fausse bonne optimisation.

Ah Bruno … si tu nous lis, je suis désolé hein ^_^

[Sve@r]

Ce qui est étonnant c'est que le compilo repère l'algo et en choisisse un autre plus performant.

Comme dans Terminator1, où un type tape à la porte de l'appart en gueulant pour sais plus quoi (le loyer?) et où on voit Schwarzy (le robot) choisir la réponse la plus appropriée parmi une liste de réponses et chosir "va te faire...". Ensuite ça continuera comme dans T2 T3 puis T4 où les compilos prendront nos places.

Ce qui est surprenant c'est que l'algo utilisé pour remplacer la boucle se comporte exactement de la même manière.

Oui, surprenant que finalement toute cette optimisation produise le même résultat en cas d'erreur que pas d'optimisation du tout. Autant s'éviter l'optimisation quoi.

Ce qui est rigolo c'est que les dèv font souvent ça et que pour ce cas de figure ils le font mal en général (à cause d'un overflow qui est pris en compte par le remplacement du compilo).

Manque de foi dans l'intelligence du dev, tout comme manque de foi dans les jeunes conducteurs (assurances 3 fois plus chères).
Moi je préfère le système allemand (chez-eux un jeune conducteur est assuré pareil et s'il se plante là il mange). Donc pareil, je préfère présumer que le dev saura faire sa boucle et s'il se plante, je le tue.

Mais bon, un unsigned short, c'est ce que j'appelle de la fausse bonne optimisation.

Ah voilà où on n'est pas d'accord. Sans même parler d'optimisation, le unsigned short c'est un type de base, enseigné dans les tutos et les livres, le K&R en parle, il a son utilité. Et si cette utilité est intéressante, autant s'en servir. Pour en revenir au code initial, un trimestre (ou un salaire) s'inclut parfaitement dans ce cadre d'un exo de débutant. Cela a amené à montrer le "%hu" du printf() et potentiellement ouvert d'autres pistes à explorer pour Bruno.
Ensuite là où l'optimisation (terme à prendre dans le sens "petit plus gratuit") entre en jeu, c'est dans les calculs avec ce fameux bit de signe qui sera/ne sera pas étendu selon le type signed/unsigned de la variable. Si ça ne coûte rien, et que ça peut aider, alors pourquoi s'en priver (PS quand j'ai écrit mon post je ne connaissais pas les uint_64t et ses copains mais même si je les avais connus, je ne pense pas que j'en aurais parlé car eux ils ne s'inscrivent pas dans les types de base du C, ni le size_t que lui je connaissais et dont je n'ai pas non plus parlé).

[WhiteCrow]

Ah voilà où on n'est pas d'accord. Sans même parler d'optimisation, le unsigned short c'est un type de base, enseigné dans les tutos et les livres, le K&R en parle, il a son utilité. Et si cette utilité est intéressante, autant s'en servir. Pour en revenir au code initial, un trimestre (ou un salaire) s'inclut parfaitement dans ce cadre d'un exo de débutant.
[...]

Le problème avec short (et long et long long en unsigned ou signed) c'est qu'on ne sait pas grand chose sur eux. Un unsigned short c'est un type entier non signé dont le sizeof est au moins égal à celui d'un char et qui peut au minimum encoder jusqu'à 2¹⁶-1=65535. Mais si ça se trouve c'est un unsigned int de 64 bits ou 32 bits ou autre chose suivant la plateforme. C'est d'ailleurs le cas pour long qui change allègrement de taille suivant les plateformes … et je ne parle même pas du non sens des wchar_t …
Alors oui, les salaires, les trimestres dans un exo débutant pourquoi pas. Bien que int reste tout de même l'entier de prédilection par défaut surtout pour les débutant, c';est vachement plus simple.
Et c'est un peu ce que je cherchais à dire tout au début ^_^ d'autres langages plus simples pour l'apprentissage n'ont qu'un type pour les nombres voire deux … par 32 zillions comme C (ok j'exagère).

[foetus]

d'autres langages plus simples pour l'apprentissage n'ont qu'un type pour les nombres voire deux … par 32 zillions comme C (ok j'exagère).

On peut retourner l'exemple : en Python tu as les tableaux, les listes, les set, les tuples et les dictionnaires. En C que des tableaux.

[WhiteCrow]

On peut retourner l'exemple : en Python tu as les tableaux, les listes, les set, les tuples et les dictionnaires. En C que des tableaux.

Ouaips
Tout un tas de trucs que le débutant peut utiliser et expérimenter sans avoir besoin de traverser le désert du «pointeur» et l'enfer du «comment ça un pointeur c'est pas un tableau ?».
Tout un tas de structures de données qui ne sont pas à implémenter from scratch (scratch étant le bruit de cheveux arrachés par poignées lors du debugage ).
Après je ne dis pas que c'est important de savoir comment faire une liste chainée avec des pointeurs en C … ce que je dis c'est que pour un grand débutant, surtout s'il veut faire de l'algo comme le PO, il est plus simple de découvrir les piles, les files les deques et autres sda an ayant déjà sous la main des listes par exemple …
Et puis surtout : Python dispose d'un REPL ou de notebook type jupyter qui permettent une facilité d'exploration déconcertante.

[Sve@r]

Tout un tas de trucs que le débutant peut utiliser et expérimenter sans avoir besoin de traverser le désert du «pointeur» et l'enfer du «comment ça un pointeur c'est pas un tableau ?».
Après je ne dis pas que c'est important de savoir comment faire une liste chainée avec des pointeurs en C … ce que je dis c'est que pour un grand débutant, surtout s'il veut faire de l'algo comme le PO, il est plus simple de découvrir les piles, les files les deques et autres sda an ayant déjà sous la main des listes par exemple …

Ah oui mais non. Il indique vouloir faire du C donc on l'aide à faire du C. Ok tu as vu dans un autre forum qu'il veut faire de l'algo, je veux bien, mais on n'a pas à en tenir compte ici. Ok on peut éventuellement lui conseiller de regarder Python parce que effectivement çà se marie bien avec l'algo mais c'est tout (et encore ce serait plutôt dans l'autre fofo qu'il faudrait le lui dire) mais on ne va pas lui dire "nan le C c'est pas pour toi" ou d'autres trucs de ce genre.
Et donc oui s'il continue il devra traverser un jour l'enfer du pointeur. Et toi ton rôle sera de l'aider à le traverser et pas lui dire "tu devrais regarder Python, il y a plein de trucs sympas pour les algos".

Et plus tard, peut-être qu'il arrivera en disant "j'ai un souci j'aimerais faire tel truc est-ce que vous avez un langage à me conseiller" et c'est seulement là que tu pourras lui dire "oui tu devrais regarder Python, je pense que ça serait un bon langage pour ça". C'est ce qui est arrivé pour moi (sur un autre forum).

[Kannagi]

Pour l'optimisation de "unsigned short" , int ou d'un long , de nos jours sur les calculs relativement simple (en gros hors division sur le x86) , il n'y a pas de différence.

Effectivement je peux comprendre que cela puisse être "étonnant" , dans des vieux proc (comme le M68000) , les opérations 32 bits prenait le double des opérations 16 bits ,parce que l'ALU était en 16 bits (donc en 32 bits , il prenait deux fois plus de temps).

Mais de nos jours on ne s'amuse pas vraiment à faire une ALU de 8/16/32/64 bits, on fait une ALU de 64 bits, et si y'a un 8,16,32 bits ben on l’exécute sur l'unité de calcul 64 bits.
Il y'a des fois d'autre contrainte lié aux microprocesseur (que je détaillerai pas ici vu que c'est pas le sujet ) qui oblige des fois a avoir toute les opérations de même longueur (comme certain ARM) ,donc tout les calculs , addition , mul,div prenne 4 cycles de latence.

Bref l'optimisation en C , et souvent pas la chose la plus évidente si on ne prend pas en compte l’architecture cible.
Surtout que les plus grosse optimisation sur les proc moderne se trouve bien plus sur le cache que sur les instructions.

[WhiteCrow]

Ah oui mais non. Il indique vouloir faire du C donc on l'aide à faire du C. Ok tu as vu dans un autre forum qu'il veut faire de l'algo, je veux bien, mais on n'a pas à en tenir compte ici. Ok on peut éventuellement lui conseiller de regarder Python parce que effectivement çà se marie bien avec l'algo mais c'est tout (et encore ce serait plutôt dans l'autre fofo qu'il faudrait le lui dire) mais on ne va pas lui dire "nan le C c'est pas pour toi" ou d'autres trucs de ce genre.[...]

Oui et c'est bien pour cela que dès ma première intervention je précise bien :

Re-Bonjour Bruno,
Je ne sais pas qui te traite de fou mais je me permets d'intervenir car sur un autre site, celui d'OCR le QG de M. Nébra, tu précises aussi bientôt suivre une formation en algo.
Cette précision est importante, car à moins d'avoir comme prérequis une connaissance minimale de C pour suivre cette formation, il est fort à parier que si un langage particulier est pris pour implémenter des algorithmes alors ce sera certainement ou python ou javascript ou quelque chose de ce acabit.

Bruno a peut-être mal pris les remarques qui lui ont été faites sur OCR (personne à ma connaissance l'ayant traité de fou là-bas) qui majoritairement lui conseillaient de ne pas essayer d'apprendre le C s'il devait suivre une formation d'algo en octobre prochain.
Je suis intervenu ici pour éviter d'avoir à faire à un problème XY, ou du moins un problème si apparentant car apparemment le PO pense que C sera pour lui «une base solide» car il le lit … que rajouter si ce n'est qu'il utilise le support de M. Nébra (no comment) et qu'il est ce qu'on appelle euphémiquement «un grand débutant».

La discussion a largement digressé ensuite …

[foetus]

Pour l'optimisation de "unsigned short" , int ou d'un long , de nos jours sur les calculs relativement simple (en gros hors division sur le x86) , il n'y a pas de différence.

Qu'est-ce tu en sais ?

Image que le PO fasse 1 structure, avec différents taux ou autres variables, il peut gagner quelques octets en choisissant adéquatement les types dans sa 1 structure (pour les passages de paramètres, les allocations, ...)
Il faut faire attention à l'alignement mais c'est 1 truc à vérifier avec son IDE.

Et donc, comme je l'ai dit avant (c'est dans la norme si je ne dis pas de bêtises ), les opérations sur des char et short, ce font avec des int (<- et des fois il y a des surprises )

[Kannagi]

Qu'est-ce tu en sais ?

Parce que j'étudie la micro-architecture des processeurs depuis des années (et bien sur les processeurs de Intel et AMD ), et que j'en conçois un donc toute les contraintes matériel je les connais assez bien
(Et j'ai explique plus bas pourquoi d’ailleurs).

Image que le PO fasse 1 structure, avec différents taux ou autres variables, il peut gagner quelques octets en choisissant adéquatement les types dans sa 1 structure (pour les passages de paramètres, les allocations, ...)
Il faut faire attention à l'alignement mais c'est 1 truc à vérifier avec son IDE.

C'est ce que font certain programmeur , il aligne leur structure par rapport à une ligne de cache ou un de ces multiples (64 octets ).
Si c'est sur la pile ,le compilateur est assez intelligent pour optimiser le cache.

Sinon le compilateur nativement va aligner les données , a ma connaissance il faut y 'aller en asm pour avoir des données non aligné (et encore ici que le x86 permet de gérer des données non aligné , je ne pense pas avoir vu ça sur ARM).