C et C++ mythe et realité

Version imprimable

Voir 40 message(s) de cette discussion en une page

04/09/2007, 16h45
yan
Code:

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 :aie:.
04/09/2007, 16h47
koala01
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 :P
04/09/2007, 16h47
yan
Citation:
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:

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 :cry:
04/09/2007, 16h53
Matthieu Brucher
Citation:
Envoyé par Mongaulois

Code:

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 :aie:.
L'ordre d'appel des fonctions n'est pas donné, selon les optimisations, il peut être quelconque.
04/09/2007, 16h55
koala01
Me suis trompé dans mes proportions:
- deux chances sur huit d'entrer dans le bloc "vrai" (2^3==8:D)
- 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 :P
04/09/2007, 16h56
yan

Citation:

Envoyé par Miles

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

ah...ok :cry::cry::cry:
Tu es sur?

Pourtant je n'ai jamais eu de problème....
Je vais plus le faire alors....
04/09/2007, 16h58
Matthieu Brucher

Certain, malheureusement. C'est pour ça aussi que les fonctions avec effet de bord sont à proscrire, surtout dans les expressions logiques ;)
04/09/2007, 16h59
koala01

Citation:

Envoyé par Mongaulois

ah...ok :cry::cry::cry:
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 ;):D
04/09/2007, 17h00
yan

Citation:

Envoyé par koala01

Jean-Marc vient de confirmer que c'est garanti par la norme ;):D

que c'est de gauche a droite?
04/09/2007, 17h01
koala01

Citation:

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 :question: ca commence à m'inquiéter, tout cela :P
04/09/2007, 17h05
Jean-Marc.Bourguet

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.)
04/09/2007, 17h08
Matthieu Brucher

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 ?
04/09/2007, 17h09
yan

http://www.codepedia.com/1/ShortCircuitEval
:D ca va je pense que je peut continuer.
04/09/2007, 17h12
Matthieu Brucher

Pour une fois qu'on est sûr que c'est bien dans l'ordre :)
Merci pour le lien :)
04/09/2007, 17h13
koala01

Citation:

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 :question:
04/09/2007, 17h28
yan

Citation:

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 :question:

Mais euh.....
04/09/2007, 17h31
yan

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++ ??
04/09/2007, 17h33
Matthieu Brucher

C'est du C, en C++, vaut mieux éviter et prendre un conteneur à la place ;)
04/09/2007, 17h42
Jean-Marc.Bourguet

Citation:

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).
04/09/2007, 17h42
koala01
Citation:

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 :D

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 :evilred::furieux::piou:

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:

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 :D

De là à dire que, s'il peut déduire une valeur renvoyée, à un moment donné, par une fonction... "yakunpas" :D (peut être un peu vite franchi :P)

[EDIT]beaucoup trop vite franchi, le pas :P

Voir 40 message(s) de cette discussion en une page