Discussion :

[Jean-Marc.Bourguet]

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

[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

[Jean-Marc.Bourguet]

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.

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

[yan]

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 C++ :

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

1
2
3
4
5
6
7
 
if (p!=0)
{
 if(p->somebool())
{
}
}

[Matthieu Brucher]

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.

[Mat007]

Je crois que vous vous embaler un peu...
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 :

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

++i && --i

Non:

Code :

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

f( ++i, --i )

MAT.

[Jean-Marc.Bourguet]

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 :

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

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

signifie ou

Code :

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

1
2
3
4
 
t1=++i;
t2=--i;
f(t1, t2);

ou

Code :

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

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 :

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

++i && --i

A un point de séquencement avec &&.

[yan]

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

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 C++ :

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

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 )
Par contre

Code C++ :

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

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

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

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

[Jean-Marc.Bourguet]

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

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

Code :

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

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

[yan]

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

Code :

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

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?

[Aszarsha]

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.

[Jean-Marc.Bourguet]

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.

[yan]

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

[Luc Hermitte]

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.

[doccpu]

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.

[doccpu]

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 C++ :

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

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 )
Par contre

Code C++ :

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

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

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

Pour ce code :

Code C++ :

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

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 C++ :

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

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 C++ :

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

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

[Luc Hermitte]

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

[koala01]

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

Code C++ :

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

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