Discussion :

[MacPro]

Hello,

Je vous présente brièvement un débat que j'ai avec un collègue, pour espérer avoir raison je me fie à vous dans vos commentaires par la suite
Je m'explique : je travaille actuellement sur un projet embarqué, un oscilloscope sur une base ARM9 (processeur à 200 MHz), 32 Mo de RAM tout ça tout ça. Bref, c'est fait en C++ pour la partie "user", le noyau étant un truc fait maison basé sur eCos et en C.

Dans mon projet, je m'efforce toujours de me remettre en question et d'utiliser les capacités du C++ pour le design et l'architecture. Je trouve que mes collègues considèrent trop que le C++ est du C avec des classes (cf. ), ils ne font que du C-style cast alors que le C++ en a introduit d'autres (http://cpp.developpez.com/faq/cpp/in...s#DIVERS_casts), il y a encore plein d'exemples comme ça ! Un jour, je regarde un peu leur code et je vois que ils ont des macros pour trouver le minimum ou le maximum de deux paramètres. Moi, je change ça en utilisant des templates (cf. http://cpp.developpez.com/faq/cpp/in...#TEMPLATES_def). Et c'est là qu'un collègue vient me dire que les templates en embarqué c'est pas bien et il n'est pas foutu de me justifier pourquoi, je lui dis que non, ça change rien, le compilateur va réécrire les fonctions templates avec les types précisés et basta, un peu comme si je l'avais fait moi-même. Sauf que voilà, il maintient que c'est pas bien. Etant donné que j'ai bien moins d'expérience que lui, je me dis que éventuellement il peut avoir une part de raison. Moi je tente de lui dire que si c'était pas bien ... on ne serait pas cassé le c*l à faire une STL par exemple, que les performances sont identiques, et que dans mon cas, ma fonction template qui de plus est inlinée (pour trouver un min ou un max) est pas mois performante que sa vieille macro !

Je m'en remets donc à vous pour statuer sur ses allégations : en quoi les templates ne sont pas bons ?

[MatRem]

Cette version de max :

Code :

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

#define max(a, b) ((a) > (b) ? (a) : (b))

par rapport à celle ci :

Code :

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

1
2
3
4
5
inline template<typename T>
T const & max(T const & a, T const &b)
{
   return  a > b ? a : b
}

ne me semble d'aucun intérêt, elle va même avoir deux problèmes :
- elle pourri le code avec un max qui va etre remplacé partout;
- dans le cas d'expressions complexes (pour a et b), elle va évaluer a et b deux fois, et aussi du coup écrire un code plus gros.

[nikko34]

Pour moi, le seul argument valable pour interdire les templates est de travailler sur une plateforme qui possède un vieux compilateur C++ qui n'est pas au norme.

Et même dans ce cas on peut toujours utiliser "ce qui marche".

L'embarqué, ça englobe beaucoup de choses. Tu peux faire de l'embarqué sur une plateforme avec des compilateurs modernes, comme tu peux faire de l'embarqué pour un ensemble disparate de plateformes où tu utilises ce qui va marcher pour tous.

L'utilisation de la librairie standard en c++ est parfois interdite, et généralement le problème se pose au niveau de l'utilisation des containers qui allouent de la mémoire dynamiquement. Mais on peut très bien utiliser le reste de la SL sans utiliser les containers à allocation dynamique. ( bien sûr avec certaines plateformes, allouer de la mémoire dynamiquement ne pose pas beaucoup de problème.)

[Joel F]

on peut aussi jouer ave les régles et fournir des allcoateur special embarqué (ca se fait très bien).

Les tempaltes quant à eux n'on tqu'un seul impact, l'augmentation probable de la taille de l'executable.

Ceci étant j'ai compilé des trucs genre boost.proto sur des cibles embarqués, ca ne m'a jaamsi posé de pb.

[MatRem]

Les tempaltes quant à eux n'on tqu'un seul impact, l'augmentation probable de la taille de l'executable.

Mais pas par rapport au même code écrit "en define" .

[jblecanard]

De manière plus pragmatique, s'il n'a pas d'arguments à t'opposer, c'est qu'il a tort

[jabbounet]

si la STL est supportée par ta/tes cible/s je ne vois pas de souci majeur, sauf dans le cas de code critique nécessitant une certification particulière.

Dans ce cas il te faut une version de STL/compilateur qui ai passé la dite certification (do178b, SIL4, ...).

Après, si tu n'es pas dans ce cadre là, c'est un choix qui se fait au niveau du projet, a toi de savoir les convaincre

[jabbounet]

pour t'aider ou pas , quelques liens utiles

Utilisation de C++ dans l'avionique (lockheed martin)
http://www2.research.att.com/~bs/JSF-AV-rules.pdf

Quelques débats déjà ouvert sur le sujet c++ en embarqué.
http://www.developpez.net/forums/d88...s-performance/
http://www.developpez.net/forums/d95...mbarque-c-cpp/

D'autres liens
http://www.artima.com/shop/effective...ed_environment

[MacPro]

Cette version de max :

Code :

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

#define max(a, b) ((a) > (b) ? (a) : (b))

par rapport à celle ci :

Code :

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

1
2
3
4
5
inline template<typename T>
T const & max(T const & a, T const &b)
{
   return  a > b ? a : b
}

ne me semble d'aucun intérêt, elle va même avoir deux problèmes :
- elle pourri le code avec un max qui va etre remplacé partout;
- dans le cas d'expressions complexes (pour a et b), elle va évaluer a et b deux fois, et aussi du coup écrire un code plus gros.

J'ai oublié de préciser qu'on n'a pas de choses complexes à comparer, que des nombres et jamais d'objets.
Lorsque tu dis que max va être remplacé de partout ... c'est la même chose pour la macro non ?
Je ne comprends pas pourquoi tu dis que a et b vont être évalué deux fois dans le cas d'expressions complexes ?

[jblecanard]

Salut

c'est simple avec le define, si tu tapes :

Code :

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

max(1+2, 4);

C'est ceci qui sera compilé :

Code :

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

((1+2) > (4) ? (1+2) : (4))

Et donc "1+2" sera évalué deux fois.

[MacPro]

Effectivement, j'avais mal lu la réponse de MatRem , j'ai cru qu'il était partisan de la macro alors que non d'où mon second post.

Si je comprends bien, ... le template n'est pas plus mauvais ?!
J'ai fais un test et je trouve un truc bizarre, j'ai bien inliné la fonction template sauf que dans le code assembleur y'a un appel à cette même foncion (instruction call du x86), où est l'embrouille ?

Mon but est de montrer à mon collègue que si la fonction template n'a pas forcément plus d'instructions que la sienne et que en nombre de cycles elle n'est pas pire, que donc la lisibilité est meilleure et que au final il a tort

[jabbounet]

Défaut majeur des macros:
Coller des expression complexe en paramètre d'une macro est à éviter en général.
Cela peut entrainer certains effets de bord si elle sont mal utilisés/écrites.
Il est donc primordial de pouvoir les identifier facilement dans le code.

Exemple:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
#include <stdio.h>
#define max(a,b) ((a) > (b) ? (a) : (b))
int main() {
  int i = 3;
  int j = 4;
 
   /* utilisation normale */
  int k = max(i,j);
  printf(" max(%d,%d) = %d\n",i,j,k);
 
  /* utilisation étrange */
  k = max(i++,--j);
  printf(" max(%d,%d) = %d\n",i,j,k);
 
  return 0;
}

donne à l'exécution:

max(3,4) = 4
max(4,2) = 2

les macros on toutefois leur utilité dans certains cas surtout avec l'opérateur de concaténation ##
par exemple:
http://gcc.gnu.org/onlinedocs/cpp/Co...#Concatenation

le tout est de savoir adapter l'outil à son besoin.

[koala01]

Salut,

Dans le cadre de max, les template auront pas mal d'avantages:

Celui d'assurer un minimum de cohérence entre les différents types : La macro n'effectue aucune vérification de type: elle se contente de remplacer X et Y par les valeurs qui lui sont passées, et "tant pis si X et Y ne sont pas compatibles"

De son coté, la version template s'assurera au minimum que les types sont identiques, ce qui devrait déjà limiter quelque peu les risques que résultats aberrants

Mais il ne faut pas oublier un aspect qui peut s'avérer réellement intéressant si tu compare, pourquoi pas, des additions de constantes connues à la compilation.

Ainsi, le fameux code (que j'adapte un peu à ce que l'on pourrait facilement rencontrer pour te montrer toute l'aberration des macros dans ce cas )

Code :

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

1
2
3
4
5
6
 
#define deux 2
#define trois 3
#define quatre 4
#define cinq 5
max( quatre + quatre, trois - deux)

sera remplacé au final par

Code :

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

return 4 + 4 < 3-2 ? 4 + 4 : 3 - 2;

En terme d'utilisation de la mémoire, nous avons donc 8 valeurs numériques utilisées

La même fonction dans sa version template aura pour résultat de calculer directement la valeur à renvoyer et sera, au niveau binaire, codée sous la forme de

Code :

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

return 8;// Hé oui: 4 + 4 = 8 :D

Ce que disait joel est tout à fait juste: tu auras régulièrement une empreinte mémoire plus importante avec les template, mais, dans des cas particuliers comme celui-ci, tu te retrouves, non seulement, avec une empreinte mémoire largement inférieure, mais aussi avec une vitesse d'exécution bien supérieure parce que la valeur renvoyée est calculée directement à la compilation.

Evidemment, cela se fait au détriment... d'un temps de compilation un peu plus important

[gl]

J'ai fais un test et je trouve un truc bizarre, j'ai bien inliné la fonction template sauf que dans le code assembleur y'a un appel à cette même foncion (instruction call du x86), où est l'embrouille ?

Il n'y a pas d'embrouille. Inliner une fonction indique ton intention mais n'est pas une contrainte. Le compilateur est libre d'inliner ou non la fonction au final.

Il existe sur certains compilateurs des options permettant de forcer l'inlining mais en général ce n'est pas une bonne idée de les utiliser.

[MacPro]

Celui d'assurer un minimum de cohérence entre les différents types : La macro n'effectue aucune vérification de type: elle se contente de remplacer X et Y par les valeurs qui lui sont passées, et "tant pis si X et Y ne sont pas compatibles"

Oui, c'est une des raisons pour laquelle j'avais utilisé ça car ils avaient la sale manie de comparer des choux et des carottes castées en pomme

De son coté, la version template s'assurera au minimum que les types sont identiques, ce qui devrait déjà limiter quelque peu les risques que résultats aberrants

j'ai fait le test :
int A = 1;
double B = 2;
int c = Max<int>(A, B);

bizarrement, le compilateur (GCC 4.4) ne m'a pas dit :"attention gamin, tu compares un int et un double, a-t-il casté tout seul le double ?? Il faudrait que je teste en utilisant des variables dont la valeur n'est pas connue à la compilation.

Code :

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

return 4 + 4 < 3-2 ? 4 + 4 : 3 - 2;

En terme d'utilisation de la mémoire, nous avons donc 8 valeurs numériques utilisées

La même fonction dans sa version template aura pour résultat de calculer directement la valeur à renvoyer et sera, au niveau binaire, codée sous la forme de

Code :

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

return 8;// Hé oui: 4 + 4 = 8 :D

Tu m'en dis une bonne, je savais que le préprocesseur va remplacer les définitions parce qu'elles valent, je pensais qu'ensuite le compilateur allait simplifier tout ça même si ce n'est pas issu d'un template.
Y'a-t-il une raison particulière pour que le compilateur fasse un return 8 dans le cas d'un template et pas avec les macros ?

Ce que disait joel est tout à fait juste: tu auras régulièrement une empreinte mémoire plus importante avec les template, mais, dans des cas particuliers comme celui-ci, tu te retrouves, non seulement, avec une empreinte mémoire largement inférieure, mais aussi avec une vitesse d'exécution bien supérieure parce que la valeur renvoyée est calculée directement à la compilation.

D'où le template metaprogramming non ?

[MacPro]

Il n'y a pas d'embrouille. Inliner une fonction indique ton intention mais n'est pas une contrainte. Le compilateur est libre d'inliner ou non la fonction au final.

Il existe sur certains compilateurs des options permettant de forcer l'inlining mais en général ce n'est pas une bonne idée de les utiliser.

ah merci, je savais pas ça, il serait bon de le mentionner dans la FAQ !

[koala01]

j'ai fait le test :
int A = 1;
double B = 2;
int c = Max<int>(A, B);

bizarrement, le compilateur (GCC 4.4) ne m'a pas dit :"attention gamin, tu compares un int et un double, a-t-il casté tout seul le double ?? Il faudrait que je teste en utilisant des variables dont la valeur n'est pas connue à la compilation.

N'oublie pas que le compilateur est capable, sous réserve de rester dans les limites communes aux deux types envisagés, de convertir à peu près n'importe quel type primitif dans un autre.

Le code que tu présente force le transtypage des variables que tu donnes en int, et tu n'aura sans doute aucun avertissement tant que ce transtypage est susceptible de s'effectuer normalement.

Par contre, si, au lieu d'essayer de forcer l'utilisation du int, tu avais écrit un code proche de

Code :

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

cout<<Max( A, b );

(où A est un int et B est un double), tu aurais obtenu une erreur t'indiquant qu'il n'existe aucune fonction Max acceptant un int & et un double &.

Tu m'en dis une bonne, je savais que le préprocesseur va remplacer les définitions parce qu'elles valent, je pensais qu'ensuite le compilateur allait simplifier tout ça même si ce n'est pas issu d'un template.
Y'a-t-il une raison particulière pour que le compilateur fasse un return 8 dans le cas d'un template et pas avec les macros ?

Je t'avouerai ne pas savoir avec certitude ce que pourrait faire le compilateur s'il se retrouve à devoir (par exemple) additionner deux valeurs constantes connues à la compilation, après application de la macro .

S'il n'est donc pas impossible que le compilateur fasse effectivement l'addition avec la macro, il est par contre certain qu'il la fera avec la version template

D'où le template metaprogramming non ?

Entre autres, oui...

Mais l'exemple que j'ai donné est très clairement particulier, hein

Le gros avantage des template restant, quoi qu'il arrive, toujours d'assurer un concordance des types utilisés, chose qui est impossible à assurer à l'aide de macro

[JolyLoic]

S'il y a des constantes, macro comme template, tout devrait être résolu à la compilation avec un bon compilo.

Là où un abus de template peut faire du mal en embarqué, c'est pour des classes, si par exemple on implémente bêtement, vector<A*> et vector<B*> vont générer deux fois des fonctions qui au final font les mêmes choses, ce qui peut être gênant.

Mais bien entendu, il y a des techniques pour éviter ça (spécialiser vector<T*> pour qu'il dérive d'une implémentation vector<void*>, ne faisant qu'un cast du résultat, cast qui sera inliné). Simplement, si on ne fait pas attention, ça peut surprendre.

[MacPro]

Merci de vos réponses, je lui ai montré tout ça avec un "kicèkarèson ?"