C et C++ mythe et realité

**yan** · 04/09/2007, 16h45

Code c++ :

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

1
2
 
if ( fonctiona()  || fonctionb()   &&  fonctionc())

pour moi, l'ordre des appels (s'ils sont nécessaire bien sur) est fonctiona(),fonctionb() puis fonctionC().
Et non fonctionb(), fonctionC() puis fonctiona() comme tu le propose.
Les deux appèls sont valables en algèbre booléenne (ainsi que fonctionC(), fonctionb() puis fonctiona()), mais si le C/C++ va bien de gauche à droite j'ai raison

.

**koala01** · 04/09/2007, 16h47

En fait, je me suis peut être mal exprimé...

Tu peux tourner les choses dans le sens que tu veux (en algebre Booléenne):
a+bc <==> bc+a

Comme la norme précise que la première expression est testée en premier, tu aura plutôt

fonctiona() appelée en premier
si fonctiona() donne vrai ==> fonctionb() et fonctionc() ne sont pas appelées
si fonctiona() donne faux ==>fonctionb() est appelée et fonction c ne sera appelée que si fonctionb() donne vrai

et bien sur, tu rentre dans le bloc "vrai" dans l'un des deux cas:

fonctiona() donne vrai (les deux autres non testées)
fonctiona() donne faux (fonctionb() et fonctionc() testées et donnent vrai)

Bref, tu as deux chances sur trois que fonctionc() ne soit jamais appelée et une chance sur trois pour que ni fonctionb() ni fonctionc() ne soient appelées...

Si tu comptais sur les effets de bord d'une de ces deux fonctions, t'es mal barre

**yan** · 04/09/2007, 16h47

Envoyé par screetch

je pense qu'il manque toujours l'info importante!!

supposons que functiona, functionb et functionc aient des effets de bords, alors

Code :

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

1
2
 
if(functiona() || functionb() && functionc())

D'abord functionb() est appelé, si elle renvoie false alors functiona(9 est appelé. Quel que soit le resultat, functionc() n'est pas appelé et son effet de bord non executé!

ca s'appelle la "lazy evaluation", ca doit pas etre le terme technique mais en tous cas ca parle mieux comme ca : a partir du moment ou tu peux deduire le resultat tu ne lances pas l'evaluation de la suite.

je connaissait pas le terme.C'est trés pratique pour programmer des condition sur des appels de fonction sont forme "algébrique" plustôt que d'utiliser des if.
Si C et C++ ne va pas de gauche a droite, j'ai tous faux

**Matthieu Brucher** · 04/09/2007, 16h53

Envoyé par Mongaulois

Code c++ :

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

1
2
 
if ( fonctiona()  || fonctionb()   &&  fonctionc())

pour moi, l'ordre des appels (s'ils sont nécessaire bien sur) est fonctiona(),fonctionb() puis fonctionC().
Et non fonctionb(), fonctionC() puis fonctiona() comme tu le propose.
Les deux appèls sont valables en algèbre booléenne (ainsi que fonctionC(), fonctionb() puis fonctiona()), mais si le C/C++ va bien de gauche à droite j'ai raison

.

L'ordre d'appel des fonctions n'est pas donné, selon les optimisations, il peut être quelconque.

**koala01** · 04/09/2007, 16h55

Me suis trompé dans mes proportions:

deux chances sur huit d'entrer dans le bloc "vrai" (2^3==8)
six chances sur huit d'entrer dans le bloc "faux"
quatre chances sur huit que fonctionb() soit appelée
deux chances sur huit que fonctionc() soit appelée
quatre chances sur huit que ni fonctionb() ni fonctionc() ne soit appelée
Autrement dit, trois chances sur quatre que les effets de bords de toutes les fonctions ne soient pas appliqués

**yan** · 04/09/2007, 16h56

Envoyé par Miles

L'ordre d'appel des fonctions n'est pas donné, selon les optimisations, il peut être quelconque.

ah...ok

Tu es sur?

Pourtant je n'ai jamais eu de problème....
Je vais plus le faire alors....

**Matthieu Brucher** · 04/09/2007, 16h58

Certain, malheureusement. C'est pour ça aussi que les fonctions avec effet de bord sont à proscrire, surtout dans les expressions logiques

**koala01** · 04/09/2007, 16h59

Envoyé par Mongaulois

ah...ok

Tu es sur?

Pourtant je n'ai jamais eu de problème....
Je vais plus le faire alors....

Jean-Marc vient de confirmer que c'est garanti par la norme

**yan** · 04/09/2007, 17h00

Envoyé par koala01

Jean-Marc vient de confirmer que c'est garanti par la norme

que c'est de gauche a droite?

**koala01** · 04/09/2007, 17h01

Envoyé par Miles

Certain, malheureusement. C'est pour ça aussi que les fonctions avec effet de bord sont à proscrire, surtout dans les expressions logiques

Est-ce moi qui ai mal compris ce qu'écrit Jean-Marc, ou toi

ca commence à m'inquiéter, tout cela

**Jean-Marc.Bourguet** · 04/09/2007, 17h05

Je confirme encore. Dans l'exemple ci-dessus: fonctiona est appelee puis fonctionb puis fonctionc si necessaire a chaque fois.

Ce n'est pas de l'evaluation paresseuse (qui designe autre chose qui n'est pas disponible en C ni en C++ sans se palucher soi-meme une implementation ou en trouver une deja faite), mais de l'evaluation court-circuit (short-circuit, je ne l'ai jamais entendu qu'en anglais)

(A reflechir, on peut peut-etre considerer cela comme un cas tres particulier d'evaluation paresseuse.)

**Matthieu Brucher** · 04/09/2007, 17h08

D'accord, c'est testé de la gauche vers la droite, mais le compilateur peut à la limite évaluer la deuxième fonction en avance, non ?

**yan** · 04/09/2007, 17h09

http://www.codepedia.com/1/ShortCircuitEval

ca va je pense que je peut continuer.

**Matthieu Brucher** · 04/09/2007, 17h12

Pour une fois qu'on est sûr que c'est bien dans l'ordre

Merci pour le lien

**koala01** · 04/09/2007, 17h13

Envoyé par Miles

D'accord, c'est testé de la gauche vers la droite, mais le compilateur peut à la limite évaluer la deuxième fonction en avance, non ?

Ca, ca dépend sans doute, entre autre, du processeur: ceux qui peuvent effectuer un traitement prédictif ou non, et, de toutes manières, d'une fonction à effet de bord vs fonction constante... Toujours à moins que la norme ne dise autre chose

**yan** · 04/09/2007, 17h28

Envoyé par koala01

Ca, ca dépend sans doute, entre autre, du processeur: ceux qui peuvent effectuer un traitement prédictif ou non, et, de toutes manières, d'une fonction à effet de bord vs fonction constante... Toujours à moins que la norme ne dise autre chose

Mais euh.....

**yan** · 04/09/2007, 17h31

Une autre question,

va_list, Va_start, va_arg et va_end (pour les fonction a variable multiple) c'est du C ou C++ ???
http://www.cplusplus.com/reference/clibrary/cstdarg/

Si c'est du C comment doit on faire en C++ ??

**Matthieu Brucher** · 04/09/2007, 17h33

C'est du C, en C++, vaut mieux éviter et prendre un conteneur à la place

**Jean-Marc.Bourguet** · 04/09/2007, 17h42

Envoyé par Miles

D'accord, c'est testé de la gauche vers la droite, mais le compilateur peut à la limite évaluer la deuxième fonction en avance, non ?

Non. Les fonctions dont on n'a pas besoin ne doivent pas etre evaluees.

(Mais il y a toujours la regle qui dit que tout est possible si ce n'est pas observable).

**koala01** · 04/09/2007, 17h42

Envoyé par Mongaulois

Mais euh.....

J'explique:

Les dernières évolutions permettent de faire un traitement prédictif:

Cela signifie que, quand ils arrivent à un saut conditionnel(ce que l'on pourrait représenter par un je, jne ou autre), il peuvent "aller voir ce qui les attend" apres cette jonction, et profiter d'un certain temps pour s'avancer dans une tache.

L'avantage, c'est que, s'ils ont choisi de traiter "la bonne réponse", ils peuvent valider ce qu'ils ont fait, et on a gagné du temps

L'inconvénient, c'est que, s'ils ont choisi de traiter la mauvaise réponse, ils devront commencer par "revenir en arrière"... et donc de perdre un peu de temps

L'explication n'est sûrement pas tout à fait juste, mais on dira que le principe y est

On a déjà vu que le processeur faisait certaines optimisations qu'il arrivait à déduire des commandes et fonctions qu'il rencontre:
Le coup du

Code :

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

1
2
3
4
5
6
7
8
 
int main()
{
    int j=0;
    for(int i=0;i<10;i++)
        j++;
    return 0;
}

est dans toutes les mémoires

De là à dire que, s'il peut déduire une valeur renvoyée, à un moment donné, par une fonction... "yakunpas"

(peut être un peu vite franchi

)

[EDIT]beaucoup trop vite franchi, le pas

Affichage des résultats du sondage: Au finale, pour vous, faut-il

C et C++ mythe et realité

C++

Discussions similaires

Partager

Partager