Ubuntu-fr

Destroyers

[C++] Quelques petites questions [RESOLU]

Salut à tous, ça fait bien longtemps que j'ai pas posé de question, mais là je trouve pas toutes mes réponses sur google

1)
J'ai eu une discussion avec un ami, et nos avis divergent.
Lequel de ces 2 codes est le mieux ?

bool foo(int a)
{
bool sain;
if(a < 3)
	{
		sain = false;
	}
	else
	{
		sain = true;
	}
        //reste du code
	return sain;
}

bool foo(int a)
{
if(a < 3)
	{
		return false;
	}
	else
	{
		return true;
	}
//reste du code
}

2)
Quel est le plus intéressant entre "if...else" et "?"      ?

3)
utiliser des méthodes/variables constantes a-t-il des conséquences sur l'optimisation ?
même question pour les méthodes virtuelles (pour savoir si je peux toutes les déclarer virtuelles même si je n'en ai pas l'utilité)

4)
au sujet de l'alignement de la mémoire:
http://linux.leunen.com/?p=371

Pour optimiser le programme, ne faudrait-il pas déclarer tout les entiers en long int ? et tout les décimaux en double ? (ils prennent 8 octets)

5)
je lis sur developpez que les templates ne sont pas superbement optimisées, pour diverses raisons. Est-il plus optimisé de faire des surcharge de ces fonctions pour tout les types que l'on a besoin ?

6)
Je recherche une bibliothèque audio de moyen/ haut niveau (pas openAL) gratuit à la distribution (pas FmodEx) tout en ayant une grande marge de manœuvre (pas irrklang)
Une idée ? :-)
j'avais songé a la SFML mais je suis pas certain de ses performances.

c'est à dire que je voudrais pouvoir reculer, avancer, mettre en pause, extraire une partie du son, ne jouer que certaines fréquences, mettre des effets, gérer les basses et les aigus ... Enfin bref je suis assez exigeant, et je ne trouve donc pas mon bonheur !

7)
j'ai pas tout bien compris aux #define
quel est l'équivalent des codes suivant si on les transformait en fonctions normales ?

#define SHA2_SHFR(x, n)    (x >> n)



#define SHA256_F2(x) (SHA2_ROTR(x,  6) ^ SHA2_ROTR(x, 11) ^ SHA2_ROTR(x, 25))



#define SHA2_UNPACK32(x, str)                 \
{                                             \
    *((str) + 3) = (unsigned char) ((x)      );       \
    *((str) + 2) = (unsigned char) ((x) >>  8);       \
    *((str) + 1) = (unsigned char) ((x) >> 16);       \
    *((str) + 0) = (unsigned char) ((x) >> 24);       \
}



#define SHA2_PACK32(str, x)                   \
{                                             \
    *(x) =   ((unsigned long) *((str) + 3)      )    \
           | ((unsigned long) *((str) + 2) <<  8)    \
           | ((unsigned long) *((str) + 1) << 16)    \
           | ((unsigned long) *((str) + 0) << 24);   \
}

8)
Les fonction inlines ont elles vraiment un intérêt quelconque ? En effet, à quoi sert de remplacer le corps de ces fonctions dans la fonction appelante ?

9)
à quoi servent (expliquez moi comme si j'étais un gosse) les fonctions memcpy, memset et sprintf (je rappelle au cas ou que je n'ai jamais fait de C)
Expliquez moi leur fonctionnement, et comment les remplacer en un code plus "normal", car j'ai cru comprendre que c'était pas très conventionnel en C++.

10)
mieux vaut utiliser:
&& ou and ?
|| ou or ?

Merci beaucoup, car ces questions sans réponses pour moi s'accumulent

Dernière modification par Destroyers (Le 30/12/2014, à 22:04)

Braun

Re : [C++] Quelques petites questions [RESOLU]

Bonsoir,
Des égouts et des couleuvres on ne discute pas disait Devos.
2) Par goût personnel je préfère toujours la concision, donc ? plutôt que if else.
7) #define n'a rien à voir avec le compilateur C ou C++, c'est une commande du préprocesseur (traitement de texte) qui remplace tout bêtement un alias par une expression. Sur certains systèmes de développement on peut extraire le texte modifié avant qu'il ne soit transmis au compilateur.

grim7reaper

Re : [C++] Quelques petites questions [RESOLU]

Salut,

1) J'ai eu une discussion avec un ami, et nos avis divergent.
Lequel de ces 2 codes est le mieux ?

Les 2 codes ne sont pas équivalents :

• le premier va donner une valeur à la variable sain, puis exécuter «  reste du code ».

• le deuxième n’exécutera jamais «  reste du code », il va renvoyer true ou false.

Difficile donc de comparer, les deux codes sont très différents.

2) Quel est le plus intéressant entre "if...else" et "?"      ?

Pas de réponse universelle.
Ça dépends de ce que tu veux faire dans le if/else.

3) utiliser des méthodes/variables constantes a-t-il des conséquences sur l'optimisation ?

Sur l’optimisation, oui probablement (étant donné que le compilateur est sûr que tu ne pourras pas changer les valeurs il peut sûrement simplifier pas mal de choses).
Sur la sûreté de ton programme, c’est certain. Tu ne pourras pas modifier par erreur des choses censées être constantes.
Donc oui, quand tu peux déclarer des méthodes constantes il faut le faire.

même question pour les méthodes virtuelles (pour savoir si je peux toutes les déclarer virtuelles même si je n'en ai pas l'utilité)

Oui, ça a des conséquences. Une méthode virtuelle est plus lente qu’une méthode non virtuelle, et ça te fait des objets plus gros aussi.
Tout ça à cause de la vtable nécessaire pour faire fonctionner les méthodes virtuelles en C++.
Donc il ne faut mettre en virtuel que ce qui est nécessaire, pas tout mettre par défaut (comme le fait Java). D’ailleurs toutes les méthodes n’ont pas vocations a être surchargées, donc il n’y a aucune raisons de tout déclarer en virtuel.

4) au sujet de l'alignement de la mémoire:
http://linux.leunen.com/?p=371

Pour optimiser le programme, ne faudrait-il pas déclarer tout les entiers en long int ? et tout les décimaux en double ? (ils prennent 8 octets)

Non.
Les contraintes d’alignement dépendent de l’architecture du CPU. Donc même si tu utilises des types pour aligner aux petits oignons pour ta config’, ça sera sûrement pas parfait pour une autre archi’ et du coup le compilo devra faire du padding.
Donc sauf cas particuliers, ne te soucis pas de ça, utilise les types dont tu as besoin et laisse le compilateur faire son boulot.

Par contre, oui, je te recommande d’utiliser les double au lieu des float sauf contraintes au niveau de la mémoire. La précisions des float est vraiment limite et on peut avoir des problème assez rapidement. De plus, il me semble que les FPU bossent au minimum en double précision donc utiliser un double ne sera pas plus lent.

5) je lis sur developpez que les templates ne sont pas superbement optimisées, pour diverses raisons. Est-il plus optimisé de faire des surcharge de ces fonctions pour tout les types que l'on a besoin ?

C’est à dire ?
Un exemple de citation ?

Par le passé oui, les templates c’était vraiment pas la joie.
Maintenant, c’est bien supporté par tous les compilateurs majeurs (gcc, clang, icc, celui de Microsoft aussi je pense) donc pas de raisons de se priver je pense. Surtout que les templates c’est extrêmement puissant (les templates sont un langage Turing-complet, c’est un peu un second langage dans le langage ^^) donc ça serait dommage de s’en priver. Par contre c’est pas toujours très lisible ^^"
Ce qui est vrai c’est que ça rallonge les temps de compilations, ça c’est sûr. Et les messages d’erreurs sont parfois abscons, mais clang est plutôt bon là-dessus et gcc a fait beaucoup de progrès à ce niveau là aussi.

6) Je recherche une bibliothèque audio de moyen/ haut niveau (pas openAL) gratuit à la distribution (pas FmodEx) tout en ayant une grande marge de manœuvre (pas irrklang)
Une idée ? :-)
j'avais songé a la SFML mais je suis pas certain de ses performances.

c'est à dire que je voudrais pouvoir reculer, avancer, mettre en pause, extraire une partie du son, ne jouer que certaines fréquences, mettre des effets, gérer les basses et les aigus ... Enfin bref je suis assez exigeant, et je ne trouve donc pas mon bonheur !

Pas trop d’idée, mais je ne pense pas que les perf’ soit vraiment critique dans ce que tu veux faire.
Donc essayer la SFML peut-être (qui a de plutôt bonnes perf’ pour ce que j’en sais).

7) j'ai pas tout bien compris aux #define

Quelle partie tu ne comprends pas ?

quel est l'équivalent des codes suivant si on les transformait en fonctions normales ?

gcc -E ou clang -E peuvent t’aider.
À moins que j’ai mal compris la question.

8)
Les fonction inlines ont elles vraiment un intérêt quelconque ?

Oui, utilisées à bon escient elles augmentent les performances et/ou réduisent la taille du code.
Utilisées abusivement, elles peuvent rendre le code plus lent et/ou plus gros.

En effet, à quoi sert de remplacer le corps de ces fonctions dans la fonction appelante ?

• ça permet d’éviter un appel de fonction (qui n’est pas gratuit) ;

• ça augmente la localité du code (donc on tire encore plus profit du cache du CPU) ;

• le compilateurs peut faire plus d’optimisations (propagation de constantes, élimination de code mort, …).

Mais ça n’est pas toujours vrai, ça dépend de pas mal de choses et donc la décision d’inliner ou non revient toujours au compilateur (sauf options spécifiques du compilateur). Le mot-clef inline du C++ (et du C) n’est qu’une demande au compilateur : Il le fera ou pas, selon si c’est valable ou pas.
De même, il pourra inliner des fonctions sans que tu lui demandes s’il trouve que ça vaut la peine.

Tu peux jeter un œil à cette page, en particulier cette question.

9)à quoi servent (expliquez moi comme si j'étais un gosse) les fonctions memcpy, memset et sprintf (je rappelle au cas ou que je n'ai jamais fait de C)

memcpy copie un bloc de mémoire de taille N.
memset initialise un bloc de mémoire de taille N.
sprintf c’est du formatage de chaîne de caractères.

Expliquez moi leur fonctionnement, et comment les remplacer en un code plus "normal", car j'ai cru comprendre que c'était pas très conventionnel en C++.

Pour te donner une réponse exacte, il faudrait voir des cas d’utilisations que tu as.
Sans plus d’info, je vais faire une réponse générale (qui peut être inadaptée ou pas optimale dans certains cas) :
memcpy => std::copy, ou constructeur de copie.
memset => std::fill, ou constructeur.
sprintf => std::ostringstream peut-être.

10)
mieux vaut utiliser:
&& ou and ?
|| ou or ?

and et or n’existent pas en C++, donc la question est vite réglée.

Dernière modification par grim7reaper (Le 28/11/2013, à 04:14)

---

Blog

pingouinux

Re : [C++] Quelques petites questions [RESOLU]

Bonjour,
Pour info, cette séquence

bool sain;
if(a < 3)
	{
		sain = false;
	}
	else
	{
		sain = true;
	}

peut-être remplacée par

bool sain;
sain = (a>=3);

et celle-ci

if(a < 3)
	{
		return false;
	}
	else
	{
		return true;
	}

par

return (a>=3);

Luc Hermitte

Re : [C++] Quelques petites questions [RESOLU]

1) const bool sain = a >=3;

2) Etrangement, l'opérateur ternaire permet de meilleures optimisations. Les compilos ne cherchent pas à reconnaitre les cas d'équivalence.
Sinon, L'opérateur ternaire permet de définir des variables constantes, ce qui est un plus (toujours faire en sorte que nos variables soient déclarées et construites à une valeur pertinente (i.e. elles ne doivent pas pouvoir exister dans un état intermédiaire qu'il soit neutre, ou pire indéterminé), de préférence définitive. D'où ma réponse au 1) qui diverge de celle de pingouinux.

Le if ne permet pas non plus d'écrire des fonctions constexpr en C++11 (car la seule chose autorisée dans ces fonctions est de renvoyer une expression). Il devrait y avoir un patch en C++14 ou 17  pour autoriser for, if et d'autres choses il me semble.

3) En termes d'optimisation, rajouter const à une variable qui sera évaluée dynamiquement apporte normalement que dalle, malgré ce qu'en disent les légendes urbaines -- ce n'est pas parce qu'un truc est vu const à un endroit qu'il ne peut pas changer depuis un autre contexte.
Ca reste préférable comme cela a été dit.

En revanche, les constexpr du C++11 offrent de vraies optimisations.

Concernant les fonctions virtuelles: il est idiot de déclarer virtuelle une fonction qui ne correspond pas à un point de variation. Cela impacte les perfs pour un besoin inexistant. Si point de variation dynamique il doit y avoir, alors les fonctions virtuelles sont un des mécanismes les plus efficace à notre disposition.

5) Où ? Quand ?
Hors cas de bloating, les templates améliorent généralement les performances.

9) std::copy pourrait reconnaitre qu'il y a un POD et tutti-quanti pour se voir remplacer automagiquement par un memcpy, mais je ne crois pas qu'il y ait d'implémentation de la SL qui prenne la peine de vérifier cela, ce qui est bien dommage car memcpy et memset déchirent en termes de perfs.

10) Si si. and, bitand et cie existent -> §2.6/2, §2.12/2, ...
Bref, dans tous les cas je dirais de préférer &&, &, et cie.

Destroyers

Re : [C++] Quelques petites questions [RESOLU]

Destroyers a écrit :

    1) J'ai eu une discussion avec un ami, et nos avis divergent.
    Lequel de ces 2 codes est le mieux ?

Les 2 codes ne sont pas équivalents :

    le premier va donner une valeur à la variable sain, puis exécuter «  reste du code ».

    le deuxième n’exécutera jamais «  reste du code », il va renvoyer true ou false.

Difficile donc de comparer, les deux codes sont très différents.

Alors admettons qu'il n'y ai pas de "reste du code", y-a-t-il une convention ? mieux vaut retourner avec ou sans variable ?

Destroyers a écrit :

    5) je lis sur developpez que les templates ne sont pas superbement optimisées, pour diverses raisons. Est-il plus optimisé de faire des surcharge de ces fonctions pour tout les types que l'on a besoin ?

C’est à dire ?
Un exemple de citation ?

Je me suis trompé, ce n'est pas sur développez ===> http://casteyde.christian.free.fr/cpp/c … x4636.html

12.4.3. Problèmes soulevés par l'instanciation des template

Les template doivent impérativement être définis lors de leur instanciation pour que le compilateur puisse générer le code de l'instance. Cela signifie que les fichiers d'en-tête doivent contenir non seulement la déclaration, mais également la définition complète des template. Cela a plusieurs inconvénients. Le premier est bien entendu que l'on ne peut pas considérer les template comme les fonctions et les classes normales du langage, pour lesquels il est possible de séparer la déclaration de la définition dans des fichiers séparés. Le deuxième inconvénient est que les instances des template sont compilées plusieurs fois, ce qui diminue d'autant plus les performances des compilateurs. Enfin, ce qui est le plus grave, c'est que les instances des template sont en multiples exemplaires dans les fichiers objets générés par le compilateur, et accroissent donc la taille des fichiers exécutables à l'issue de l'édition de liens. Cela n'est pas gênant pour les petits programmes, mais peut devenir rédhibitoire pour les programmes assez gros.

10)
    mieux vaut utiliser:
    && ou and ?
    || ou or ?

and et or n’existent pas en C++, donc la question est vite réglée.

Pourtant ça compile.

Je réfléchis aux questions 7 et 9, les autres ayant été répondu et comprises

Luc Hermitte

Re : [C++] Quelques petites questions [RESOLU]

1- Ici, passer par une variable intermédiaire pour stocker le booléen ne changera rien. Dans le cas d'objets plus complexes, les mots clés sont copy elision, RVO, et RNVO (ou NRVO, je me plante tout le temps).
Sinon, passer par un if pour stocker le résultat d'une expression booléenne (i.e. if (expr) v = true; else v=false;) est totalement ridicule. Sincèrement. expr est déjà un booléen.

5- C'est bien ça. Il ne parle pas d'optimisation. Mais il sous-entend des conséquences dont le mot clé pour google est "template code bloat". C'est une question d'équilibre. Dans tous les cas, ça ne sera jamais pire que du copier-coller.

(10- Déjà répondu. C'est dans la norme, mais en général on évite -- de vieux soucis avec certains compilos, IIRC)

grim7reaper

Re : [C++] Quelques petites questions [RESOLU]

9) std::copy pourrait reconnaitre qu'il y a un POD et tutti-quanti pour se voir remplacer automagiquement par un memcpy, mais je ne crois pas qu'il y ait d'implémentation de la SL qui prenne la peine de vérifier cela, ce qui est bien dommage car memcpy et memset déchirent en termes de perfs.

Avec les apports du C++11, ils semblent que c’est maintenant le cas
Celle de clang (libc++) semble le faire :

template <class _Tp, class _Up>
inline _LIBCPP_INLINE_VISIBILITY
typename enable_if
<
    is_same<typename remove_const<_Tp>::type, _Up>::value &&
    is_trivially_copy_assignable<_Up>::value,
    _Up*
>::type
__copy(_Tp* __first, _Tp* __last, _Up* __result)
{
    const size_t __n = static_cast<size_t>(__last - __first);
    _VSTD::memmove(__result, __first, __n * sizeof(_Up));
    return __result + __n;
}

Celle de GCC (libstdc++) aussi si j’en crois les commentaires :

/**
   *  @brief Copies the range [first,last) into result.
   *  @ingroup mutating_algorithms
   *  @param  __first  An input iterator.
   *  @param  __last   An input iterator.
   *  @param  __result An output iterator.
   *  @return   result + (first - last)
   *
   *  This inline function will boil down to a call to @c memmove whenever
   *  possible.  Failing that, if random access iterators are passed, then the
   *  loop count will be known (and therefore a candidate for compiler
   *  optimizations such as unrolling).  Result may not be contained within
   *  [first,last); the copy_backward function should be used instead.
   *
   *  Note that the end of the output range is permitted to be contained
   *  within [first,last).
  */

10) Si si. and, bitand et cie existent -> §2.6/2, §2.12/2, ...
Bref, dans tous les cas je dirais de préférer &&, &, et cie.

Au temps pour moi.

Je me suis trompé, ce n'est pas sur développez ===> http://casteyde.christian.free.fr/cpp/c … x4636.html

12.4.3. Problèmes soulevés par l'instanciation des template

Les template doivent impérativement être définis lors de leur instanciation pour que le compilateur puisse générer le code de l'instance. Cela signifie que les fichiers d'en-tête doivent contenir non seulement la déclaration, mais également la définition complète des template. Cela a plusieurs inconvénients. Le premier est bien entendu que l'on ne peut pas considérer les template comme les fonctions et les classes normales du langage, pour lesquels il est possible de séparer la déclaration de la définition dans des fichiers séparés. Le deuxième inconvénient est que les instances des template sont compilées plusieurs fois, ce qui diminue d'autant plus les performances des compilateurs. Enfin, ce qui est le plus grave, c'est que les instances des template sont en multiples exemplaires dans les fichiers objets générés par le compilateur, et accroissent donc la taille des fichiers exécutables à l'issue de l'édition de liens. Cela n'est pas gênant pour les petits programmes, mais peut devenir rédhibitoire pour les programmes assez gros.

La partie mise en gras est partiellement fausse.
On peux faire une séparation artificielle en deux fichiers. Mais dans l’absolu il a raison.

Dernière modification par grim7reaper (Le 29/11/2013, à 03:53)

---

Blog

Destroyers

Re : [C++] Quelques petites questions [RESOLU]

Bon.

en gros ce que j'ai pas très bien compris est quelle est l'utilité de déclarer ceci en #define ?

#define SHA2_SHFR(x, n)    (x >> n)

que fait ce code ? comment l'appeler ? comment en faire une fonction ? (inline éventuellement, et pourquoi, si c'est le cas)
http://cpp.developpez.com/faq/cpp/?page … LINE_macro

mêmes questions pour :

#define SHA2_ROTR(x, n)   ((x >> n) | (x << ((sizeof(x) << 3) - n)))

#define SHA256_F4(x) (SHA2_ROTR(x, 17) ^ SHA2_ROTR(x, 19) ^ SHA2_SHFR(x, 10))

#define SHA2_CH(x, y, z)  ((x & y) ^ (~x & z))

#define SHA2_PACK32(str, x)                          \
{                                                    \
    *(x) =   ((unsigned long) *((str) + 3)      )    \
           | ((unsigned long) *((str) + 2) <<  8)    \
           | ((unsigned long) *((str) + 1) << 16)    \
           | ((unsigned long) *((str) + 0) << 24);   \
}

Merci

#EDIT
pourquoi mettre le mot "inline" si le compilateur le fait tout seul dès que possible ?

Dernière modification par Destroyers (Le 01/12/2013, à 15:11)

Braun

Re : [C++] Quelques petites questions [RESOLU]

en gros ce que j'ai pas très bien compris est quelle est l'utilité de déclarer ceci en #define ?

Franchement, moi non plus, (x >> n) me semble beaucoup plus lisible.

que fait ce code ?

Ben justement ce n'est pas du code mais deux alias pour une même phrase.
Ceci dit je plussoie la critique de ton lien.

grim7reaper

Re : [C++] Quelques petites questions [RESOLU]

Bon.

en gros ce que j'ai pas très bien compris est quelle est l'utilité de déclarer ceci en #define ?

Bon déjà de base, faut dire que en C++ les macro n’ont plus vraiment lieu d’être.
Autant en C ça reste utile pour faire de l’inline (inline est apparu en C99 en C, pas avant) ou pour avoir une sorte de templace du pauvre, autant en C++ les cas justifiés sont bien plus rares.

#define SHA2_SHFR(x, n)    (x >> n)

Ici, aucun intérêt.
C’est juste une instruction (décalage de n bits vers la droite) et elle est simple à comprendre.
Ça mérite vraiment pas une macro. Autant écrire le code directement.

comment l'appeler ?

Ça s’appelle comme une fonction. Par contre ça ne se comporte pas toujours comme une fonction…

comment en faire une fonction ? (inline éventuellement, et pourquoi, si c'est le cas)

Grosso modo, en ajoutant une déclaration de fonction et une instruction return. Après ça dépend des macros bien sûr.

#define SHA2_ROTR(x, n)   ((x >> n) | (x << ((sizeof(x) << 3) - n)))

Rotation (décalage circulaire) à droite de n bits.

#define SHA256_F4(x) (SHA2_ROTR(x, 17) ^ SHA2_ROTR(x, 19) ^ SHA2_SHFR(x, 10))

#define SHA2_CH(x, y, z)  ((x & y) ^ (~x & z))

Des manipulations bit à bit en rapport avec l’algo SHA. Faudrait regarder l’algo pour savoir exactement le rôle.

#define SHA2_PACK32(str, x)                          \
{                                                    \
    *(x) =   ((unsigned long) *((str) + 3)      )    \
           | ((unsigned long) *((str) + 2) <<  8)    \
           | ((unsigned long) *((str) + 1) << 16)    \
           | ((unsigned long) *((str) + 0) << 24);   \
}

Ça prend 4 octets et ça les mets dans un entier de 32 bits.

pourquoi mettre le mot "inline" si le compilateur le fait tout seul dès que possible ?

Pour demander au compilateur de mettre cette fonction inline. Mais ça reste une demande, rien de plus.

---

Blog