Discussion :

[mister3957]

Les arguments sont intéressants, merci, c'est instructif et ça a tout son sens dans les exemples cités qui sont plutôt haut niveau.

Mais j'ai très rarement travaillé en C++ sur des applis haut niveau. A chaque fois il y avait un gros besoin en minimalisant le poids des livrables pour les cibles embarquées (mobiles / Raspberry / équipements industriels), économisant la mémoire (jusqu'aux échanges entre processeur / cache / et mémoire) et garantissant les performances ainsi que la conso réseau (surtout quand on est en 3G / 4G).

Quand c'est plus haut niveau (comme par exemple un moteur 2D / 3D), l'interface, l'ergonomie et les fonctionnalités utilisatrices sont déléguées à des technos plus haut niveau comme C#, Java ou via des modules Node, NDK ou tout simplement exploités par sockets.

A ce niveau d'exigence, on doit tout savoir sur chaque instruction commandée au dispositif.

En effet, les principales techniques d'optimisation reposent sur comment on utilise les choses. Par exemple on privilégiera un tableau de structures à une structure de tableaux, ou l'inverse, selon le cas d'usage qui lui est plus haut niveau. La cohésion est alors un peu pétée mais il y a des techniques pour contraindre l'utilisateur à l'utiliser de telle ou telle manière même s'il doit garder sa part de vigilance en fonction de comment sont faites les choses pour les exploiter au mieux, parfois même il devra adapter son organisation.

Pour l'alignement mémoire, c'est pareil. Est-ce que je dois faire

Code :

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

1
2
3
4
5
6
7
8
9
 
class A
{
public:
   ....
private:
   auto titi A;
   auto tata B;
}

ou

Code :

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

1
2
3
4
5
6
7
8
9
 
class A
{
public:
   ....
private:
   auto tata B;
   auto titi A;
}

Mais c'est super bandant ce genre d'évolution, peut-être qu'un jour le C++ pourra permettre de faire des choses haut niveau avec un seul de rentabilité équivalent à du Java ou du C# mais avec ses performances en plus.

C'est pourquoi le concept du "vol de mémoire" est pour moi la plus grande avancée du C++ ces dernière années. Pour le reste, c'est sûrement que ça me fait peur de ne pas avoir la pleine maîtrise de ce qui se passe à niveau matériel mais sur d'autres projets où c'est moins important, ça risque d'être vraiment pas mal ce mot clé "auto".

A bientôt et merci pour cet échange

[renoo]

À partir du moment où tu parles de naviguer dans le code, on ne parle plus de la lisibilité passive, mais d'une lisibilité active. Avec mon IDE, que j'utilise auto ou pas, aller à la définition d'un type, c'est 1 touche à appuyer. Je pense que c'est plus efficace que toute stratégie qui serait basée sur une homonymie espérée entre nom de type et nom de fichier... Je ne suis donc pas très convaincu par cet argument...

Tu perds quand même une information à la relecture du code avec auto, c'est le type de la variable, là il faut deviner au moment de l'appel de la fonction. Tu peux parfois connaitre le type et ce que tu peux faire avec, dans ton cas pour faire pareil tu utilises une homonymie type/variable ?

[JolyLoic]

La plupart du temps, j'essaye de trouver un nom qui définisse le rôle de la variable (password, plutôt que passwordString ou str). Mais il y a des cas où je n'y arrive pas (essayez de trouver un nom descriptif pour un itérateur!). Sans ce cas là, il y a homonymie non pas variable/type, mais plus variable/concept auquel répond le type.

Pour reprendre le cas de l'itérateur, je le nommerais plutôt it ou iterator que vector_of_string_iterator ou encore je nommerais une variable fileList même si son type est std::vector<std::string>.

D'ailleurs, à ce sujet, il y a eu des suggestions pour étendre les concepts à la déclaration de variables, histoire d'avoir un intermédiaire entre le type, trop précis, et auto, perçu par certains comme trop imprécis. On pourrait alors écrire Iterator it = v.begin();, le type de it serait déduit comme avec auto, mais ensuite, on vérifierait si ce type répond au concept Iterator, et si ce n'est pas le cas, on lèverait une erreur. Je ne sais pas trop si j'utiliserais une telle écriture si elle devenait disponible, ou si je resterais avec auto. Il faudrait que je l'expérimente dans la vraie vie.

[jblecanard]

Globalement, on y gagne à la relecture. Si le nom de la variable a du sens, on se pert difficilement. En tout cas dans mon expérience, utilise auto en vaut vraiment la peine. Et je fais aussi des softs dans lesquels on règle les perfs au nano poil de cul, ça n'y change rien, c'est quand même utile.

[Bousk]

...

Pour l'alignement mémoire, c'est pareil. Est-ce que je dois faire

Code :

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

1
2
3
4
5
6
7
8
9
 
class A
{
public:
   ....
private:
   auto titi A;
   auto tata B;
}

ou

Code :

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

1
2
3
4
5
6
7
8
9
 
class A
{
public:
   ....
private:
   auto tata B;
   auto titi A;
}

...

Mais auto n'est pas utilisable dans ce cas. Il n'a strictement rien à voir avec quelconque problème de performance, conso, poids du livrable, quelque soit le niveau ni rien. Ce n'est qu'un sucre syntaxique.