C et C++ mythe et realité

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

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

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:

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.

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

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....

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

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

Citation:

---

Envoyé par koala01

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

---

que c'est de gauche a droite?

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

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.)

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 ?

http://www.codepedia.com/1/ShortCircuitEval
:D ca va je pense que je peut continuer.

Pour une fois qu'on est sûr que c'est bien dans l'ordre :)
Merci pour le lien :)

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:

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.....

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++ ??

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

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).

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

Citation:

---

Envoyé par Mongaulois

Une autre question,

va_list, Va_start, va_arg et va_end (pour les fonction a variable multiple) c'est du C ou C++ ???

---

J'ai envie de repondre oui.

C'est du C et du C++, mais generalement en C++ on evite (une technique est de chainer des appels, comme ce qui est fait dans les streams).

Tout le monde n'est pas fan des streams, je reste fan du printf.

Vas y pour localiser des messages donnés a cout

Citation:

---

Envoyé par screetch

Tout le monde n'est pas fan des streams, je reste fan du printf.

Vas y pour localiser des messages donnés a cout

---

Vas-y pour passer un UDT a printf. Meme une std::string.

On peut preferer un systeme de formatage avec format (je fais tellement peu d'IO que je n'ai pas d'opinion informee), mais ce n'est pas une raison pour preferer une interface non extensible et non sure: les deux ne sont pas lies.

D'après Efficient C++, dans l'expression if (e1 || e2) tirée de la partie Speed Up the Common Path semble exclure que e2 puisse être évaluée en premier.

Et que penser des : if ( p && p->somebool() ) que je suis sûr d'avoir vu récement dans un autre livre ?

Citation:

---

Envoyé par NiamorH

D'après Efficient C++, dans l'expression if (e1 || e2) tirée de la partie Speed Up the Common Path semble exclure que e2 puisse être évaluée en premier.

Et que penser des : if ( p && p->somebool() ) que je suis sûr d'avoir vu récement dans un autre livre ?

---

idem
si p == 0 alors on ne fait pas p->somebool().
je trouve plus propre et lisible que

Code:

---

1 2 3 4 5 6 7

if (p!=0) { if(p->somebool()) { } }

---

Oui, c'est comme ça.
Le deuxième exemple s'appuie là-dessus, comme expliqué plus haut. Si p est nul, il n'est pas possible d'appeler une méthode dessus, il y aurait un segfault ou qqch du genre.

Je crois que vous vous embaler un peu... :mouarf:
Les évaluations d'expression sont normalisées (encore heureux), ce qui ne l'est pas c'est l'ordre dans lequel les paramètres d'un appel de fonction le sont.

Oui :

Code:

---

++i && --i

---

Non:

Code:

---

f( ++i, --i )

---

MAT.

Citation:

---

Envoyé par Mat007

Les évaluations d'expression sont normalisées (encore heureux), ce qui ne l'est pas c'est l'ordre dans lequel les paramètres d'un appel de fonction le sont.

---

Ce n'est pas une question d'ordre d'évaluation (ce qui voudrait dire que

Code:

---

1 2	f( ++i, --i )

---

signifie ou

Code:

---

1 2 3 4

t1=++i; t2=--i; f(t1, t2);

---

ou

Code:

---

1 2 3 4

t2=--i; t1=++i; f(t1, t2);

---

) mais d'absence de point de séquencement entre les deux expressions ++i et --i qui rend l'ensemble indéfini. Donc un appel à abort() est autorisé.

Code:

---

++i && --i

---

A un point de séquencement avec &&.

Citation:

---

Envoyé par koala01

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

---

Re mais .... euh.

Je comprend de quoi tu parle, mais si le langage certifie qu'il fait du Short Circuit Evaluationl je ne pense que le proc va faire n'importe quoi. par exemple

Code:

---

1 2 3 4

if (p!=0 && p->blablabla()) { ... }

---

Je ne pense pas qu'il va faire p->blablabla() avant p!=0.
Ce qui ferai un blablabla() -> ta gueule (dsl c'est juste un clin d'oeil :aie:)
Par contre

Code:

---

int X = ++i * (4*a+b + --i) ;

---

le proc peut choisir de faire --i avant le ++i

Bonjour à tous,

je n'ai pas programmé en C (pur) depuis mon avant-dernière vie, et je me demandais:
Pouvez-vous me donner quelques exemples de code qui fonctionne en C mais pas en C++?

:merci:

Citation:

---

Envoyé par r0d

Bonjour à tous,

je n'ai pas programmé en C (pur) depuis mon avant-dernière vie, et je me demandais:
Pouvez-vous me donner quelques exemples de code qui fonctionne en C mais pas en C++?

:merci:

---

Il n'y a pas tant que ca. Le plus courant doit etre:

Code:

---

1 2	int *ptr = malloc(10*sizeof int);

---

(en C++ il faut un cast pour passer de void* a un autre type de pointeur, en C pas).
Il y a aussi l'utilisation des mots cles du C++ comme identificateur, et une bonne partie de ce qui vient de C99. Il y a aussi quelques differences silentieuses (deux qui me viennent en tete, en C sizeof('a') == sizeof(int), en C++ sizeof('a') == 1; inline a un sens plus ou moins subtilement different en C et en C++).

Citation:

---

Envoyé par Jean-Marc.Bourguet

Il n'y a pas tant que ca. Le plus courant doit etre:

Code:

---

1 2	int *ptr = malloc(10*sizeof int);

---

(en C++ il faut un cast pour passer de void* a un autre type de pointeur, en C pas).
Il y a aussi l'utilisation des mots cles du C++ comme identificateur, et une bonne partie de ce qui vient de C99. Il y a aussi quelques differences silentieuses (deux qui me viennent en tete, en C sizeof('a') == sizeof(int), en C++ sizeof('a') == 1; inline a un sens plus ou moins subtilement different en C et en C++).

---

Pourquoi vouloir les séparer alors?

Citation:

---

Envoyé par Mongaulois

Pourquoi vouloir les séparer alors?

---

Parce que si l'on programme bien en C++, on se retrouve à ne plus du tout utiliser les même méthodes qu'en C à part les bases impérative communes.

Les langages sont semblables dans une certaine mesure, leur utilisation beaucoup moins.

Citation:

---

Envoyé par Mongaulois

Pourquoi vouloir les séparer alors?

---

Ils sont séparés depuis plus de vingt ans. Ils ont une influence l'un sur l'autre. Certains -- dont moi -- aimeraient que le C soit aussi proche que possible d'un sous ensemble bien défini du C++ et sont prêts à des concessions sur la rigueur du langage C++ pour ça, mais le C n'a jamais été un sous-ensemble strict même si on exclu les mots clés. Mais il est des gens qui pensent l'inverse, que le C ne doit pas tenir compte du C++ lors de son évolution, que le C++ ne doit pas considérer la compatibilité avec le C comme un objectif et donc importer les nouveautés du C ou tenir compte du C plus généralement.

Citation:

---

Envoyé par Jean-Marc.Bourguet

Ils sont séparés depuis plus de vingt ans. Ils ont une influence l'un sur l'autre. Certains -- dont moi -- aimeraient que le C soit aussi proche que possible d'un sous ensemble bien défini du C++ et sont prêts à des concessions sur la rigueur du langage C++ pour ça, mais le C n'a jamais été un sous-ensemble strict même si on exclu les mots clés. Mais il est des gens qui pensent l'inverse, que le C ne doit pas tenir compte du C++ lors de son évolution, que le C++ ne doit pas considérer la compatibilité avec le C comme un objectif et donc importer les nouveautés du C ou tenir compte du C plus généralement.

---

Pour moi, la différence entre le C et le C++ est le "style de programmation". Je les trouvent trop proche pour être réellement séparable.
La preuve, à la simple question donné un exemple en C qui n'est pas valide en C++? y as pas beaucoup réponse (dizaine de cas peut être).
Au contraire, je trouve que cela complique les choses de les séparer. On se retrouve avec deux langages, dont un (le C++), un peu plus puissant, dans le sens où il peut (quasiment) faire la même chose que l'autre (le C), tout en en faisant d'autre à coté.

Après je veut pas critiquer les raisons historique de leurs différences, j'en serait incapable. Mais de nos jours, je ne voit pas l'utilité de vouloir encore les séparer, même si apparemment leurs unions n'arrivera jamais...
Ce qui créé des confusions "le code que j'ai écrit c'est du C ou du C++?" et souvent, la réponse est ... les deux. :?
Un autre exemple avec la SDL :
SDL is written in C, but works with C++ natively

Faudrait peut être créer un nouveau langage le ++C :aie:

Citation:

---

Envoyé par r0d

Pouvez-vous me donner quelques exemples de code qui fonctionne en C mais pas en C++?

---

Cf le threads C vs C++, quantité de cas y ont été déjà énumérés.

bon les gars la je crois qu'il à des enculeur d'anophèles qui cherchent à mystifier le comportement du cpu sous prétexte que le pipeline du cpu est capable de traitement prédictif ou de pipeline sur biproc ect....

1) le seul composent a evaluer une opération booleene est le core d'un processeur donné pour un thread donné. Donc il n'y a pas de possibilité de plantage a cause d'une mauvaise évaluation du pipeline est exclu. de plus le pipeline ne stoque pas plus de 4 opérations assembleur (1 instruction = 1 operateur booleen en ce qui concerne les tests).

2) le pipeline ne vas chercher que jusque à 4 instruction et si le processeur lui dit qu'il s'est planté alors il vas rechercher le bon code en mémoire avant d'envoyer le code au processeur (ce qui lui fais perdre 4 cycles)

3) si un processeur modifie une donnée partagé entre 2 core un mécanisme d'avertissement des pipelines entre en jeux et les caches ainsi que la mémoire sont remis a jours automatiquement ce qui fais perdre plusieurs cycles aux processeurs (min 4 mais la mise a jour de la mémoire peux prendre plus).

4)Quant aux caches de premiers et second niveaux ils sont soumis aux mêmes règles et mécanismes de protections que les pipelines

enfin les pipelines ont été mis en place a partir du 386 alors ne vous d'inquietez pas trop parce qu'intel et amd savent très bien ce qu'ils fonts et ils se sont arrengé pour que les gents qui ont appris l'assembleur ne soient pas trop dépaysé. c'est pas comme microsoft qui change ses api a chaque révision de son os.

je vous concède que les docs d'intel en la matières sont pas facile a trouver mais une recherche sur les forums et le site d'intel avec les mots clé "datasheet" et "Intel® 64 and IA-32 Architectures Software Developer’s Manual" vous permettrons de retrouver les informations justes sur le comportement des proceseurs IA-32 et IA-64

cordiallement

a l'attention des enculeurs d'anophèles : ce que j'ai ecrit ci dessus est une simplification du fonctionnement plus complèxe encore des systèmes de sécurités alors ne venez pas me dire que j'ai comis une faute de précision ou que je suis resté trop vague c'est voulu. svp merci.

Citation:

---

Envoyé par Mongaulois

Re mais .... euh.

Je comprend de quoi tu parle, mais si le langage certifie qu'il fait du Short Circuit Evaluationl je ne pense que le proc va faire n'importe quoi. par exemple

Code:

---

1 2 3 4

if (p!=0 && p->blablabla()) { ... }

---

Je ne pense pas qu'il va faire p->blablabla() avant p!=0.
Ce qui ferai un blablabla() -> ta gueule (dsl c'est juste un clin d'oeil :aie:)
Par contre

Code:

---

int X = ++i * (4*a+b + --i) ;

---

le proc peut choisir de faire --i avant le ++i

---

Pour ce code :

Code:

---

1 2 3 4

if (p!=0 && p->blablabla()) { ... }

---

je peux te certifier qu'il ne fera pas p->blablabla() avant d'etre sur que p est bien different de 0. mais je préfère l'implémentation :

Code:

---

1 2 3 4

if (p && p->blablabla()) { ... }

---

qui est plus propre et plus rapide a évaluer par le processeur une fois compilé.

Quant a :

Code:

---

int X = ++i * (4*a+b + --i) ;

---

le proc ne choisira pas c'est le compilo qui vas le faire et comme les [in/dé]crementation ont le rang le plus fort c'est elles qui vont etre executé en premier, pus viendrons les indexations "[]", les parenthèses, les operations logiques, les puissances, les multiplications/divisions et enfin les additions/soustractions, le tout dans l'ordre de priorité et de lecture.

on aura don dans l'ordre d'execution

++i
--i
4*a
(4*a)+b+(i)
(i)*((4*a)+b+(i))
x = ((i)*((4*a)+b+(i)))

Ou
--i
++i
http://www.scit.wlv.ac.uk/cbook/chap3.order.html

Citation:

---

Envoyé par doccpu

(snip)
mais je préfère l'implémentation :

Code:

---

1 2 3 4

if (p && p->blablabla()) { ... }

---

qui est plus propre et plus rapide a évaluer par le processeur une fois compilé.
(snip)

---

Hé bien, personnellement, je ne suis absolument pas convaincu qu'il y ai la moindre différence entre les deux du point de vue de la rapidité.
Du point de vue de la "propreté", j'aurais tendance à préférer l'écriture "verbeuse" (!=0 ou !=NULL)...Mais ce n'est que mon avis ;)

Le fait est que, de toute facon, il y aura d'office un cmp suivi du JE/JNE que tu mette ou non le !=0/!=NULL...