Discussion :

[Hinault Romaric]

GCC r�impl�ment� en C++
les d�veloppeurs du compilateur andonnent le C pour garder son code facilement maintenable et compr�hensible

Le d�veloppement du compilateur GCC (GNU Compiler Collection) passe du langage C au C++.

La communaut� en charge du d�veloppement de la suite de compilateurs libre GCC vient d�annoncer que son code a �t� r�impl�ment� avec le langage orient� objet C++.

Avant cette adoption d�finitive du C++, le code utilis� dans l��tape un du processus de construction de GCC a �t� mis en �uvre avec le langage C. Le code des �tapes deux et trois de ce processus a �t� d�velopp� pendant un certain temps en C++ avant d��tre abandonn�.

L�id�e d�utiliser le C++ en lieu et place du C avait germ� dans la t�te des d�veloppeurs de GCC en mai 2010, qui estimaient que le C++ �tait acceptable pour d�velopper le compilateur.

Selon les explications sur le Wiki du projet, le passage du C au C++ a pour objectif de maintenir le code du GCC compr�hensible et facilement maintenable. Les d�veloppeurs du projet notent n�anmoins que l�utilisation imprudente de C++ peut �tre lourde de cons�quences. Un point qui cependant n�est pas qualitativement diff�rent des probl�mes rencontr�s actuellement.

Les modifications du code de GCC ont �t� planifi�es et mises en �uvre dans le cadre du projet � GCC in Cxx �. Certaines structures de donn�es ont d�j� �t� r�impl�ment�es en C++ et, actuellement, les d�veloppeurs sont en train de travailler sur les changements qui ont �t� int�gr�s � la branche 4.7.

GCC est � sa version 4.7.1 depuis juin 2012. La suite de compilateurs permet de transformer le code source en langage machine pour plusieurs langages de programmation dont C, C++, Java, Objective-C, Ada et m�me Fortran 95.



Source : Wiki conversion GCC vers C++


Et vous ?

Bonne ou mauvaise id�e ? Pourquoi ?

[Freem]

Bonne ou mauvaise id�e ? Pourquoi ?

Bonne... question.

D'un c�t�, C++ permet d'utiliser plus de paradigmes de d�veloppement, mais cet ajout implique pour moi une certaine n�cessit� de re-r�fl�chir � la conception.
Je ne suis pas du tout persuad� que la migration d'un langage � un autre soit une bonne id�e.

D'un autre c�t�, C++ permet de compiler du C. Le fait qu'il soit multi-paradigme permet tout simplement une refonte en douceur, tr�s progressive, via divers refactoring tr�s l�gers.
Donc la stabilit� ne devrait pas trop en souffrir.

Apr�s... Quels sont les avantages de C++ contre C?
_ la possibilit� d'utiliser des outils pour g�n�rer des diagrammes de classes UML afin de comprendre nettement plus rapidement la structure de code. Diagrammes UML qui sont quand m�me de plus en plus connus par les d�veloppeurs, je pense. L'int�r�t de ce point, c'est de pouvoir amener facilement de nouveaux contributeurs: plus un projet est simple a appr�hender, moins �a co�te cher en formation et motivation, plus rapidement les nouveaux contributeurs peuvent contribuer. Donc, plus vite le projet peut lui-m�me �voluer.
Bien s�r, ce n'est pas parce qu'un projet est �crit en C qu'il est mal document�, mais je n'ai jamais entendu parler d'outils qui extraient la structure d'un projet �crit en langage non objet.

_ utilisation des templates. Ca allonge la dur�e de compilation, mais �a permet de r�duire la base de code de fa�on parfois drastique. Je doute fortement que �a aie un impact en terme de performances, en revanche, niveau maintenance, c'est une �vidence. Bon... tant qu'il n'y a pas besoin d'aller lire le code source des templates fournis par G++, parce que bon, ces bouts de code n'ont pas grand chose de simple � lire... Voire de lisible...

Donc, pour moi, le seul gain potentiel sera un gain en terme de maintenance, une certaine partie du code sera fusionn�e via les templates, une autre sera plus lisible gr�ce aux fonctions inline, et une doc pourra �tre g�n�r�e � partir du source via les diagrammes de classe.

Peut-�tre m�me de l�g�res pertes de performances dans l'absolu, parce que migrer du langage C au langage C++ est truff� de subtilit�s, mais s'ils g�rent bien (ce qui est probable, on parle de gens qui �crivent des compilateurs, dont un compilateur C++ hein), la diff�rence ne sera pas perceptible (voire inexistante?):
Utiliser les m�thodes et fonctions inline � bon escient et ne pas abuser du code virtuel (h�ritages et m�thodes) permet de n'avoir que peu voire pas du tout d'impact.
Vu que la base de code est en C, je doute qu'il y ait de l'h�ritage de structures autre que "manuel" et du coup, il ne devrait pas y avoir trop de virtuel. De ce c�t�, il est m�me possible qu'il y ait un gain de performances occupation m�moire et/o� utilisation CPU).
Pour l'inlining, le compilateur fait bien le boulot lui-m�me, je pense.

D'ailleurs, cette nouvelle am�ne une question:
C++, oui, mais C++11?
Parce que si ce n'est pas le cas, ils vont se priver de certains m�canismes qui peuvent consid�rablement simplifier leur vie: move semantic, int�gration des instructions multi-thread, et ce genre de choses. Choses qui pour certaines sont fournies avec le C11, mais �a n'aurait �t� "qu'une simple mise � jour" du code, avec de probables oublis r�guliers (je n'ose imaginer la taille en LOC du projet!). Ici, le changement de langage va probablement impliquer un travail avec plus d'attention, qui pourrait permettre d'int�grer les avanc�es de C11 et C++11, et la, je suis certain qu'on aura des am�liorations de performances.

Quant � la question du fait que �a emp�cherait que �a fonctionne sur certaines architecture d'utiliser du code trop r�cent: je suis s�r � 95% qu'ils utilisent GCC pour compiler, du coup, �a implique qu'au moins un compilateur pourra compiler leur compilateur: le leur. Et donc, il pourra le faire sur toutes les plate-formes d�j� support�es, non?

[edit]
J'ai vu juste, le gain qu'ils semblent attendre est effectivement ax� sur la maintenance:

Background

What matters for GCC going forward is that it continue to be comprehensible and maintainable. That is a struggle that GCC has faced for its entire existence as a free software project. It is certainly true that using C++ unwisely can make that struggle more difficult. But this issue is not qualitatively different from the issues we face today.

Whether we use C or C++, we need to try to ensure that interfaces are easy to understand, that the code is reasonably modular, that the internal documentation corresponds to the code, that it is possible for new developers to write new passes and to fix bugs. Those are the important issues for us to consider. The C++ features which are not present in C -- features which are well documented in many books and many web sites -- are not an important issue.

For additional background information on this effort and its scope, please check out http://airs.com/ian/cxx-slides.pdf .

==>
Ce qui importe est que GCC reste compr�hensible et maintenable[...]que nous utilisions C ou C++ nous devons nous assurer que les interfaces soient simples � comprendre, que le code soit raisonnablement modulaire, que la documentation interne corresponde au code, qu'il soit possible pour de nouveaux d�veloppeurs d'�crire de nouvelles passes et de corriger les bugs.

==>
Les fonctionnalit�s de C++ qui ne sont pas pr�sentes en C -- fonctionnalit�s qui sont tr�s bien document�es [...] -- ne sont pas importantes.

Du coup, j'en d�duis qu'ils ne vont pas utiliser les fonctionnalit�s des nouveaux standards, ce qui r�pond(?) � ma question pr�c�dente.

[jmnicolas]

GCC r�impl�ment� en C++ ?

Les signes avant-coureurs sont bien l�, les Mayas avaient raison : 2012 c'est la fin du monde

[gbdivers]

Pourquoi pas ? Mais perso, je suis plus int�ress� par les nouvelles fonctionnalit�s qui seront impl�ment�es : support complet de la norme (il doit manquer des choses je crois), proposition de nouvelles fonctionnalit�s pour le prochaine TR ou C++1x (SG1 et SG5 en particulier), am�lioration des temps de compilation et des messages d'erreurs de template (clang en mieux). Si cette �volution permet de faciliter l'ajout de ces fonctionnalit�s, je prend

[Freem]

GCC r�impl�ment� en C++ ?

Les signes avant-coureurs sont bien l�, les Mayas avaient raison : 2012 c'est la fin du monde

Post tr�s argument� s'il en est.

J'ai lu un peu plus en d�tail le contenu de cette source et des documents qui y sont cit�s...

D'ailleurs, j'ai l'impression que le titre de cet article fait dans la sensation.

Le C n'est pas abandonn�, pas totalement du moins, puisque "GCC generates temporary garbage which is only freed by ggc collect", GCC �tant �crit en C. D'un autre c�t� "C++ permits reference counting smart pointers." et donc "We may want to use a mixture of reference counting and garbage collection."

En gros, le C++ va �tre utilis�, oui, mais uniquement quand il pr�sente un avantage par rapport au C.
Basiquement, je suppose qu'ils ne vont pas utiliser les stream (et je ne pourrait leur en vouloir, personnellement je ne les appr�cie pas du tout)

Pendant que j'y suis, j'ai juste ador� le PDF que j'ai cit�, notamment un passage:

The FSF doesn�t like it!
◮ The FSF is not writing the code.

Je salue la justesse du raisonnement de l'auteur

Ce PDF attaque aussi d'autres id�es re�ues, telles que:
_ C++ trop lent
_ C++ trop compliqu�
_ C++ pas portable
Et surtout, les exemples de code sont tr�s instructifs.

Bon... n'emp�che, il pr�cise aussi que ce n'est pas la panac�e, juste une am�lioration.
Pour le coup, je me demande ce qu'en pense ce cher Linus.

Au sujet de la source elle-m�me, il semble qu'ils attendent un v�ritable gain en m�moire, et donc en dur�e de compilation.
Gain d� au fait que le C++ aie des destructeurs, et que donc, d�s que l'on sors d'une port�e, on lib�re de la m�moire. La ou l'impl�mentation C utilisais un gargage collector, une impl�mentation C++ �conomise la m�moire gr�ce � la RAII.
Quand je vois qu'en 2-3 threads je monte vite � 1Gio, qui est la limite de mon netbook, c'est plut�t une bonne nouvelle qu'ils esp�rent ce type d'am�lioration.
Divers autres passages parlent aussi de diminution du nombre de cast dynamiques, et donc d'optimisation de la vitesse �galement.

En tout cas, je pense que ce projet permettra de montrer clairement si oui ou non, C++ est une am�lioration par rapport au C, et dans quelle mesure l'efficacit� est am�lior�e.
A noter tout de m�me, qu'ils ne semblent pas vouloir tout convertir, mais juste quelques modules.

En tout cas, ils n'y parlent pas d'impl�menter les fonctionnalit�s restantes des standards.
Ce qui para�t logique: je pense qu'ils vont commencer par migrer les parties stables, pour faciliter le travail.
Migrer une partie stable, �a veut dire qu'il est possible qu'il existe des tests unitaires pour cette partie, donc que le code migr� sera bien test�, plut�t que de devoir � la fois lutter contre les bugs de migration et ceux d'impl�mentation.
Donc, pour moi, a court et moyen terme, on ne peux s'attendre qu'a une am�lioration en terme de m�moire et de vitesse � la compilation (pour les raisons d�j� �voqu�es)

[gbdivers]

Pour le coup, je me demande ce qu'en pense ce cher Linus.

On connait d�j� sa position sur le C++ et ce n'est pas non plus lui qui �crit le code de gcc

Pour les id�es re�ues, le pdf date de 2008. Si les gens ont encore ce genre d'id�es 4 ans apr�s, faudrait peut �tre qu'ils se remettent en question

Dans http://gcc.gnu.org/gcc-4.8/changes.html :

GCC now uses C++ as its implementation language. This means that to build GCC from sources, you will need a C++ compiler that understands C++ 2003.

Donc pas de C++11

[Freem]

On connait d�j� sa position sur le C++ et ce n'est pas non plus lui qui �crit le code de gcc

Ce n'�tait pas une phrase s�rieuse en m�me temps

Pour les id�es re�ues, le pdf date de 2008. Si les gens ont encore ce genre d'id�es 4 ans apr�s, faudrait peut �tre qu'ils se remettent en question

En m�me temps, si j'avais confiance dans la capacit� des gens (y compris moi-m�me hein) � se remettre en question ou � changer d'id�es quand la raison l'impose, je pense que j'aurai pr�f�r� un m�tier avec plus de contact humain. Le fait que mon contact se limite � des rapports de bugs et des demandes de fonctionnalit�s me suffit amplement.

Dans http://gcc.gnu.org/gcc-4.8/changes.html :

Donc pas de C++11

La source indique �galement que le compilateur version N doit pouvoir �tre compil�e par le compilateur version N-1, donc effectivement, C++11 ne sera pas utilis� de sit�t.
Je suppose qu'il faudrait d�j� qu'il soit compl�tement impl�ment� et surtout d�bogu� pour �a... Un compilateur qui utilise une techno qui n'est pas n�cessairement stable risquerait d'introduire pas mal de bugs dans les binaires par effet de cascade.
Je suis tout de m�me assez content de voir qu'ils n'y vont pas comme des brutes. En tout cas, je me demande combien de temps �a va mettre pour qu'ils sortent un truc en b�ta, et je me demande quel sera le r�sultat niveau am�liorations de perfs.

D'ailleurs, vu que mingw est bas� sur GCC, peut-�tre qu'on aura aussi des am�liorations de ce c�t�-ci? Histoire de pouvoir concurrencer un peu VS, ce serait pas mal.

[PINGOUIN_GEANT]

GCC now uses C++ as its implementation language. This means that to build GCC from sources, you will need a C++ compiler that understands C++ 2003.

Donc pas de C++11

Tu posais une question sur les nouvelles fonctionnalit�s support�es par gcc, mais il me semble que la version de langage pour d�velopper gcc est quelque chose diff�rent de l'actuel support d'un langage. J'ai peut-�tre rat� quelque chose.
Passer de C a C++, qu'est ce que cela veut dire sur l'optimisation des 2 versions de gcc pour compiler du C et du C++ ? Est-ce que la variante pour compiler du C++ est maintenant plus mature que la variante pour le C ? A-t-on des indices pour le savoir (aussi en comparaison des variantes pour Java, FORTRAN 95, etc.) ?

[guillaume07]

c'est pas trop t�t !!

[gbdivers]

La source indique �galement que le compilateur version N doit pouvoir �tre compil�e par le compilateur version N-1, donc effectivement, C++11 ne sera pas utilis� de sit�t.

Je suppose que c'est le num�ro de version mineur de gcc, j'esp�re qu'ils compilent pas gcc avec la version 3
Dans ce cas, la version N-1 (gcc 4.7) supporte d�j� une tr�s grande partie du C++11, donc ils pourraient l'utiliser sans probl�me pour gcc 4.8

Tu posais une question sur les nouvelles fonctionnalit�s support�es par gcc, mais il me semble que la version de langage pour d�velopper gcc est quelque chose diff�rent de l'actuel support d'un langage. J'ai peut-�tre rat� quelque chose.

Pas compris. On parle du langage pour �crire gcc et non du langage pris en charge par gcc

Passer de C a C++, qu'est ce que cela veut dire sur l'optimisation des 2 versions de gcc pour compiler du C et du C++ ? Est-ce que la variante pour compiler du C++ est maintenant plus mature que la variante pour le C ? A-t-on des indices pour le savoir (aussi en comparaison des variantes pour Java, FORTRAN 95, etc.) ?

Il n'y a pas plusieurs variantes de gcc, il y a une version de gcc en cours de dev et la prise en charge des langages d�pend : 1. de l'�volution des langages (le C et le C++ ont eu des nouvelles normes r�centes) 2. de la disponibilit� des �quipes de dev
Bref, pas trop compris la question

[Freem]

Je pense aussi que c'est le num�ro mineur, parce que sinon, la compilation qui met d�j� 50 plombes quand on joue avec quantit� de template mettrait probablement 50 si�cles

Pour le reste, je suppose que PINGOUIN_GEANT demande si un compilateur GCC est �crit dans le langage qu'il est cens� compiler... Mais en fait, je suis presque s�r de ne pas trop avoir compris non plus.

Mais bon...
GCC, pour ce que j'en sais, est con�u de fa�on modulaire, quand on �crit un compilateur GCC pour un nouveau langage, on �crit un nouveau module. Pr�c�demment, GCC �tait �crit 100% en C, mais il semble qu'ils aient d�cid� de commencer � utiliser le langage C++ pour continuer certains modules.

Pour ce qui est de l'int�r�t d'utiliser C++ au lieu de C, ce n'est pas tant une question de maturit� du compilateur (puisqu'on pourrait vouloir compiler GCC avec VS, pour ce que j'en sais), mais de techniques utilisables dans les langages.
C++ offre plus de possibilit�s que C pour impl�menter les choses, entres autres parce que C++ est multi-paradigme, alors que C n'en utilise qu'un.
Et, selon l'auteur du PDF que j'ai cit�, C++ permet d'�crire du code plus lisible, et donc plus simple � maintenir, que s'il �tait �crit en C. Cette personne estime aussi que le gain de performance obtenu en �crivant en C est n�gligeable voire inexistant. Elle estime d'ailleurs que sur certains points, le C++ est plus performant.
Cette performance serait par exemple due au fait que, si je me souviens bien, le C n�cessite de d�clarer toutes les variables en d�but de fonction, contrairement au C++.
L'int�r�t de ceci pour le C++, est que l'on peut par exemple �crire cela:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
int main()
{
  //code divers
  {
     Foo f;
     //code exploitant f
  }
  // encore un peu de code
  {
     Bar b;
     // code exploitant b
  }
  //autre code divers
}

Alors qu'en C il eut fallut �crire:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
 
int main()
{
  Foo f;
  Bar b;
  //code divers
  //code exploitant f
  //code exploitant b
  //autre code divers
}

La diff�rence provenant du fait que dans le code C++ la m�moire utilis�e par f n'est pas allou�e avant que f ne serve, et est vid�e quand il ne sert plus � rien. Idem pour b. Selon le programme, ces trucs peuvent prendre plus ou moins de m�moire, entres autres.

Autre point sur lequel C++ est meilleur en terme de performance, c'est le support de la RTTI, qui, bien que lourde, est plus rapide que d'effectuer deux fois la conversion d'un type � un sous-type, afin de v�rifier que le type est le bon.

Et il semble que ces technologies aient un potentiel non n�gligeable d'optimisation de GCC, dont la r�putation de lenteur et de lourdeur doit �tre connue de la plupart des gens ici. (je ne sais pas si elle est av�r�e, je ne me suis jamais amus� � faire de comparaison r�elle, mais c'est � coup s�r un reproche que l'on voit souvent sur le web)

[screetch]

j'ai lu le PDF et a la page 3 il dit

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
typedef std::vector<struct loop, gcallocator> loopvec;
loopvec *superloops;
superloops->reserve (depth);
superloops[depth];

un pointeur sur un vecteur... c'est peut etre pas si bien barr� que ca

[Tryph]

[...]je n'ai jamais entendu parler d'outils qui extraient la structure d'un projet �crit en langage non objet.

Doxygen est capable d'analyser du code C, de d�crire les structures, de les lier entre elles et m�me de faire des diagrammes pour synth�tiser tout �a.

bon c'est pas de l'UML, mais c'est d�j� bien pratique.

[gbdivers]

@screetch
Aie, en effet, si on ce genre de code, �a fait mal

Et il semble que ces technologies aient un potentiel non n�gligeable d'optimisation de GCC, dont la r�putation de lenteur et de lourdeur doit �tre connue de la plupart des gens ici. (je ne sais pas si elle est av�r�e, je ne me suis jamais amus� � faire de comparaison r�elle, mais c'est � coup s�r un reproche que l'on voit souvent sur le web)

Je crois pas que l'optimisation de gcc (qui en a effectivement bien besoin) puisse venir de quelques fonctionnalit�s du langage C++
Le probl�me de gcc est plus profond, c'est un probl�me d'algorithmie (en particulier, on lui reproche de parser plusieurs fois les fichiers d'en-t�te et de ne pas garder en m�moire ce qu'il a d�j� analys�, d'o� la perte de temps)
A voir si c'est toujours le cas. Mais si oui, on pourrait tout r��crire en assembleur (voir en langage machine ou en micro code processeur) que cela ne changerait rien

Tr�s clairement pour moi, si �a avait �t� un d�butant qui proposerait de recoder gcc en C++ pour diminuer les temps de compilation, je lui aurait r�pondu que c'est de la premature optimization, qu'il teste d'abord le temps passer dans les algos et dans les appels de fonctions et ne r��crire que s'il montre que c'est n�cessaire.
Bon mais l�, c'est les devs de gcc, je vais rien dire...

Pour moi, le principal int�r�t reste le gain en �volutivit�, qui lui permettra d'impl�menter plus facilement de nouvelles m�thodes de compilation qui vont faire gagner du temps (et l'ajout des nouvelles fonctionnalit�s aux langages, ce qui est encore mieux)

[rt15]

Cette performance serait par exemple due au fait que, si je me souviens bien, le C n�cessite de d�clarer toutes les variables en d�but de fonction, contrairement au C++.
L'int�r�t de ceci pour le C++, est que l'on peut par exemple �crire cela:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
int main()
{
  //code divers
  {
     Foo f;
     //code exploitant f
  }
  // encore un peu de code
  {
     Bar b;
     // code exploitant b
  }
  //autre code divers
}

Alors qu'en C il eut fallut �crire:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
 
int main()
{
  Foo f;
  Bar b;
  //code divers
  //code exploitant f
  //code exploitant b
  //autre code divers
}

La diff�rence provenant du fait que dans le code C++ la m�moire utilis�e par f n'est pas allou�e avant que f ne serve, et est vid�e quand il ne sert plus � rien. Idem pour b. Selon le programme, ces trucs peuvent prendre plus ou moins de m�moire, entres autres.

Ce code montre aussi beaucoup plus pourquoi le C++ peut �tre plus lent que le C.

Mais parlons donc m�moire tout d'abord. D�j�, le mot "allocation", pour des variables locales ferais presque bondir certaines personnes, assez peu il est vrai. Elle r�servent ce terme aux allocations dynamiques, � base de malloc ou new par exemple. Pour une variable locales, ces personnes parlent plus de "r�servation dans la pile".
Car ces deux m�thode pour obtenir de la m�moire sont tr�s diff�rentes. Dans un cas, on ne change que la valeur d'un registre du processeur pour d�placer la t�te de pile, dans l'autre on appelle toute une machinerie qui g�re un tas.
(C'est a nuancer car il y a toute une gestion de la pile par l'OS derri�re : taille initiale, taille maximale, ajout de pages lors des d�fauts de pages. Mais dans la grande majorit� des cas, la pile est pr�te).

Bref, que repr�sente donc l'"allocation" de f et b dans le code C ci-dessus ? Une mis�rable instruction sub esp, XXX ou XXX correspond (Au moins � peu pr�s, d�pend de la gestion de l'alignement) � la taille d'une instance de Foo + une instance de Bar. Il y aurait 200 variables, il n'y aurait quand m�me qu'une instruction. Pour un co�t � l'ex�cution quasi nul. Effectivement, il y a de la m�moire consomm�e, mais dans la pile donc c'est carr�ment anecdotique -> Par d�faut, la taille max de la pile est de 1 ou 2 Mo (Pr�cis�e dans le .exe par le linker). Malgr� �a, pour faire un d�passement de pile, il faut souvent mettre un bon gros tableau en variable locale, ou faire un r�cursivit� qui ne s'arr�te pas.

Bref, le code C ci-dessus ne coute quasi rien en CPU et pas grand chose en m�moire.

Pouvoir donner une port�e en interne aux variables r�duirait potentiellement un peu la consommation m�moire, mais ralentirait l'ex�cution (1 sub esp, XXX par port�e, et pourquoi pas un add esp � la fin des port�es).

En fait, pouvoir limiter la port�e des variables comme ci-dessus sert surtout au C++. Non pas pour limiter la consommation m�moire, d'ailleurs, mais la consommation CPU !

Et c'est l� tout le pi�ge du C++ en ce qui concerne les performances !

Le code C ci-dessus est quasi instantan�. Il ne PEUT PAS prendre de temps.
Mais le code C++ ci-dessus prend un temps... Inconnu ! Peut �tre plusieurs secondes ! Peut �tre des heures... Avec juste ce bout de code, on ne sait pas ce que le processeur va devoir ex�cuter.

Tout d�pend en effet des constructeurs de Foo et Bar ! Et c'est pour �a que la port�e limit�e est bien plus int�ressante en C++ qu'en C, par exemple pour ne pas ex�cuter de constructeurs d'instances dont on a pas besoin.

Et c'est une des raisons pour laquelle une impl�mentation en C est souvent plus rapide. Car le C colle au comportement du processeur, l� ou le C++ permet d'ajouter de l'abstraction qui nous cache des instructions.

[gbdivers]

C'est quoi cette argumentation ??? Surtout la derni�re phrase

Si tes variables f ou b ont besoin d'�tre initialis�, que ce soit dans le constructeur des classes (C++) ou dans une fonction d'initialisation (C), �a sera pareil en terme de temps d�ex�cution. Si tu n'as pas besoin de les initialiser, �a te co�tera pas plus en C++ qu'en C.
De plus, en C++ comme en C, les variables seront sur la pile, il n'y aura pas de diff�rence sur le code g�n�r� et les performances


Il faudrait comprendre un jour que le C++ et le C ont les m�mes performances pour les m�mes fonctionnalit�s (et les fonctionnalit�s du C++ qui n'existent pas en C, comme par exemple les fonctions virtuelles, n�cessiteront du code suppl�mentaire en C, ce qui donnera les m�mes performances au final)

[rt15]

Effectivement, le message est assez fin, et est presque plus philosophique que technique. Mais prenons par exemple le code C++ suivant :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
#include <vector>
 
#define VECTOR_SIZE 10000000
 
int main()
{
  std::vector<int> my_vector(VECTOR_SIZE);
 
  for (int i = 0; i < VECTOR_SIZE; i++)
    my_vector[i] = i;
 
  return 0;
}

On construit un vecteur de int avec chaque �l�ment qui est �gale � son indice.
Bien s�r, un vector n'est pas tr�s adapt�, mais c'est pour l'exemple.

La question est : combien de fois les �l�ments du vecteurs sont ils parcourus et affect�s ?

Ne lisez pas la suite avant de vous �tre pos� la question !

On comprend bien qu'un seul parcourt devrait suffire pour r�aliser cette t�che. Pourtant le code ci-dessus en fait deux. Les �l�ments sont initialis�s � z�ro dans le constructeur, et ce quel que soit le niveau d'optimisation donn� au compilo.

Encore une fois, ce n'est pas tranchant comme argument. Mais en lisant le code, on a quand m�me bien l'impression de voire une complexit� en n, pas en 2n. Tout �a � cause d'un constructeur qui ex�cute du code dans notre dos, sans que �a ait d'int�r�t pour nous. C'est donc quand m�me tr�s vite fait d'�crire un code deux fois plus lent qu'il ne devrait, sans que �a saute aux yeux.

Pour en revenir � la philosophie, on peut remarquer que ce genre de "d�tail" � une f�cheuse tendance � �tre plus rep�r� par des d�veloppeurs C que des d�veloppeur C++. Nan mais franchement, vous imagineriez une double initialisation d'une liste dans le noyau linux ? �a ferait pas tr�s s�rieux quand m�me...

[gbdivers]

Ok donc �a confirme ce que je dis

Il faudrait comprendre un jour que le C++ et le C ont les m�mes performances pour les m�mes fonctionnalit�s (et les fonctionnalit�s du C++ qui n'existent pas en C, comme par exemple les fonctions virtuelles, n�cessiteront du code suppl�mentaire en C, ce qui donnera les m�mes performances au final)

L� tu compares avec une classe qui encapsule un tableau avec RAII en C++ et un tableau sans initialisation en C. Deux fonctionnalit�s diff�rentes, deux r�sultats diff�rents.
En C++, tu n'as pas en effet de s�paration allocation et initialisation pour un vector, donc on pourrait oublier (ou ne pas savoir) que l'on parcours deux fois le tableau dans ton code. Mais :
- on trouve plus souvent l'erreur d'utilisation d'un tableau C non initialis� qu'un probl�me de performance d'un tableau C++
- on trouve plus souvent des probl�mes d'algorithme sur la gestion des ressources que des probl�mes de performance d'un tableau C++ (typiquement des tableaux qui sont allou� et lib�r� plusieurs fois dans un algo)
- la diff�rence de temps d'allocation d'un tableau C ou C++ est en g�n�ral ridicule sur la dur�e total d'un programme (si on s'amuse pas � allouer et lib�rer les tableaux tout le temps)
- le C++ autorise d'autres types de tableaux qui ne pr�sente pas la s�curit� du RAII (new[], malloc) ou de fournir d'autres allocateurs

Bien s�r, un vector n'est pas tr�s adapt�, mais c'est pour l'exemple.

C'est claire qu'en prenant des outils non adapt�s, on arrive aux conclusions que l'on veut

de voire une complexit� en n, pas en 2n

Jusqu'au derni�re nouvelle, O(n) = O(2n)

C'est donc quand m�me tr�s vite fait d'�crire un code deux fois plus lent qu'il ne devrait, sans que �a saute aux yeux.

Tu l'as test� ton code pour dire qu'il est deux fois plus lent ?


Bref, ton argument est bas� sur une m�connaissance du C++

HS :

Effectivement, le message est assez fin, et est presque plus philosophique que technique.

Merci de ne pas prendre les gens de haut

[transgohan]

Jusqu'au derni�re nouvelle, O(n) = O(2n)

Seulement apr�s simplification (qu'on effectue dans 99% des cas je te l'accorde, mais si on veut parler bien, parlons bien !).
Certains chercheurs travaillent dans des domaines o� ils ne peuvent se permettre de dire que O(10n) est n�gligeable et �quivalent � O(n).

[screetch]

mathematiquement, O(2n) est equivalent a O(n)
programmatiquement, le code philosophique de rt15 n'est pas equivalent a son pendant vector, le code equivalent est:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
#include <vector>
 
#define VECTOR_SIZE 10000000
 
int main()
{
  std::vector<int> my_vector;
  my_vector.reserve(VECTOR_SIZE);
 
  for (int i = 0; i < VECTOR_SIZE; i++)
    my_vector.push_back(i);
 
  return 0;
}

ou il n'y a qu'un seul parcours (le O(1N) philosophique)
pour en revenir au sujet sur GCC, nul doute que les erreurs sur la page 3 du PDF sont simplement de l'inattention (un copie/colle vite fait) puisque il cumule 4 erreurs en 3 lignes (1 - pointeur sur vecteur, 2 - operateur [] sur le pointeur et non sur le vecteur, 3 - acces hors borne puisque il y a depth elements donc le dernier est depth-1, 4 - reserve ne grandit pas le vecteur, donc il y a toujours 0 element dans le vecteur).

meme un programmeur C qui n'a jamais code C++ aurait fait mieux, je suppose donc une simple slide fait a la va-vite.