Le choix, ça pourrait être de coder avec des retours par valeur et de laisser le compilo gérer, ce qu'il fait plutôt bien quand le code est clair. En tout cas, c'est ce que j'ai tendance à faire à mon niveau.
Mais bon, j'avoue que je surestime souvent les capacités du compilo à faire des trucs intelligents, notamment pour la gestion de la mémoire. Par exemple, quand on a une fonction qui alloue de la mémoire, fait un traitement, et désalloue la mémoire, appeller la fonction n fois dans une boucle for réalloue et désalloue n fois la mémoire, ce qui me semble assez abérrant. Moi ça me file des boutons en C++11 de refiler des pointeurs vers de la mémoire libre en paramètre des fonctions ou de passer des gros objets par références non-constantes, j'ai l'impression que c'est du mélange crado de paradigmes. Étrangement, ce genre de code est beaucoup plus performant dans certains langages de haut niveau qui vectorisent les appels de fonction.
je ne vois pas comment ça peut tomber dans un comportement non défini.
Je me suis peut-être mal exprimé, mais je n'ai jamais eu de problème avec le comportement du code, seulement avec le temps d'exécution (donc je ne parlais pas du tout de comportement non-défini). Mon problème, c'est que le temps d'exécution du code compilé avec un niveau d'optimisation agressif par le compilo n'était pas compréhensible (tout du moins par moi), avec des temps d'éxécution qui variaient substantiellement et visiblement de manière chaotique en fonction de l'ordre et du nombre de tests conditionnels.
[^] # Re: essayer Julia ?
Posté par arnaudus . En réponse au journal Un Python qui rivalise avec du C++. Évalué à 2.
Le choix, ça pourrait être de coder avec des retours par valeur et de laisser le compilo gérer, ce qu'il fait plutôt bien quand le code est clair. En tout cas, c'est ce que j'ai tendance à faire à mon niveau.
Mais bon, j'avoue que je surestime souvent les capacités du compilo à faire des trucs intelligents, notamment pour la gestion de la mémoire. Par exemple, quand on a une fonction qui alloue de la mémoire, fait un traitement, et désalloue la mémoire, appeller la fonction n fois dans une boucle for réalloue et désalloue n fois la mémoire, ce qui me semble assez abérrant. Moi ça me file des boutons en C++11 de refiler des pointeurs vers de la mémoire libre en paramètre des fonctions ou de passer des gros objets par références non-constantes, j'ai l'impression que c'est du mélange crado de paradigmes. Étrangement, ce genre de code est beaucoup plus performant dans certains langages de haut niveau qui vectorisent les appels de fonction.
Je me suis peut-être mal exprimé, mais je n'ai jamais eu de problème avec le comportement du code, seulement avec le temps d'exécution (donc je ne parlais pas du tout de comportement non-défini). Mon problème, c'est que le temps d'exécution du code compilé avec un niveau d'optimisation agressif par le compilo n'était pas compréhensible (tout du moins par moi), avec des temps d'éxécution qui variaient substantiellement et visiblement de manière chaotique en fonction de l'ordre et du nombre de tests conditionnels.