Discussion :

[Niark13]

Comment suivez-vous l�actualit� du C++ ?

Sites comme DVP, ou le blog de Herb Sutter notamment, Channel 9 (m�me si c'est quand m�me centr� sur Microsoft), et d�sormais isocpp.org.

Connaissiez-vous le fonctionnement du comit� de standardisation du C++ ?

Oui, ce fonctionnement a �t� d�crit ici dans les grandes lignes avant la standardisation de C++11, et apr�s (nouvelles propositions, comme static if).

Utilisez-vous le dernier standard (C++11) en production ? � titre personnel ?

� titre personnel presque exclusivement, mais tr�s prochainement en production, puisque les compilateurs impl�mentent rapidement la norme.

Comment vous formez-vous � l�utilisation de la derni�re norme (C++11) ?

Essentiellement avec des vid�os de talks d'Alexandrescu, Sutter, Meyers, Lavavej, Stroustrup ou des articles de blogs.

[gbdivers]

J'ai l'impression que personne ne lit : Nouvelles fonctionnalit�s du C++11 prises en charge dans gcc

[Niark13]

J'ai l'impression que personne ne lit : Nouvelles fonctionnalit�s du C++11 prises en charge dans gcc

En ce qui me concerne, je l'ai lu, cependant dans le cadre professionnel, nous utilisons plusieurs compilateurs, en fonction du syst�me cible. Par exemple, pour un produit qui doit tourner sous Red Hat Entreprise Linux 4, c'est GCC 3.4, la cible.

Pour nos produits Windows, nous venons de passer de VS2008 � VS2010. Donc on va pouvoir commencer � utiliser C++11 dans des produits Win-only...

[Freem]

@Freem
On en avait parl� dans la derni�re news sur le C++17 http://www.developpez.net/forums/d11...e-version-cpp/
Tu as le draft l� : http://www.open-std.org/jtc1/sc22/wg...2012/n3347.pdf

Je n'avais pas lu cette new... faudra que j'y rem�die dans un avenir proche.
Pour le coup, je vois l'int�r�t des modules (j'ai lu tr�s vite le d�but), mais je pense qu'ils vont en baver pour pondre un truc pareil, vu que �a va n�cessiter par exemple de pouvoir compiler sans conna�tre la taille des objets que l'on veut... d'un autre c�t�, on peut d�j� faire plus ou moins �a avec des techniques alakon quand on cache l'interface non publique.
Heureusement qu'ils ont 5 ans pour faire �a :}

Et puis �a pourrait aussi pas mal simplifier la vie des gens qui font des logiciels d'auto-compl�tion, j'ai l'impression...

Et pour ce qui est de http://www.developpez.net/forums/d12...es-charge-gcc/ je l'avais lu... mais compar� � http://fr.wikipedia.org/wiki/C%2B%2B11 que j'acc�de en 9 frappes de touches, y'a pas photo (``CTRL+T "w C++11" entr�e`` j'adore) ^^

L'un est centr� sur GCC et pas si simple que �a � parcourir, l'autre parle de la norme, et est plut�t clair, bien qu'incomplet sur certains points, qui peuvent �tre �claircis en passant � la version anglaise.

@niark: c'est pas un peu �trange d'utiliser un GCC si vieux � c�t� d'un VS si r�cent? REHL sont encore plus en retard que debian stable pourtant r�put�e pour sa lenteur (et qui utilise la 4.4) !
Pourrais-tu m'�clairer sur la raison derri�re ce point (que je qualifierai quand m�me de probl�me l�... parce que je doute que GCC3 soit encore maintenu?)

[Freem]

To promote greater availability of high-quality C++ libraries, [...] and community libraries (by having an organized, and ideally tool-supported, way for C++ developers to discover and use libraries).

Ce passage viens de me faire penser � un truc... Actuellement, le pseudo-standard de facto, make, n'a rien de standard et doit changer selon la cha�ne de compilation... Accessoirement, sur de gros projets, c'est tout sauf facile � manipuler (d'o� les autotools et cmake, entres autres).

Ca serait pas mal d'avoir un outil, ou au moins un processus standard (que ce soit vraiment standard ou juste de fait) pour g�rer les compilations. Parce que m'est avis que ce point est bloquant pour plus d'une personne...

[Klaim]

C'est en parti le but des modules: virer la n�c�ssit�e des headers et imposer aux compilateurs un moyen de juste lire les fichiers puis d'en faire des index de symboles r�utilisables.
Ca va pas d�finir la compilation (autre que ce qu'impose le standard actuel), mais �a va garantir que si tu utilise sles modules, tu auras un temps de compilation r�duit (et accessoirement des fichiers moins verbeux et plus besoin d'inclure le bon fichier au bon chemin sur le disque..., faut juste le bon nom de module).

Enfin...en th�orie du moins.

[germinolegrand]

Mais �a met pas un peu le bazar quand tu compiles juste un .cpp ? (pas de link)

[mitkl]

La session Q&A qui a suivi la pr�sentation est disponible : http://herbsutter.com/2012/11/06/fri...f&utm_medium=t

[Arzar]

Mais �a met pas un peu le bazar quand tu compiles juste un .cpp ? (pas de link)

Pourquoi ? Quel est le probl�me ?
Si je comprends bien le proposal sur les modules, la mani�re de compiler tel ou tel fichier restera inchang�e.

Par exemple :

Version sans module :
Imaginons trois fichiers lib.h, lib.cpp et main.cpp
llib.cpp et main.cpp poss�dent tous les deux en d�but de fichier un #include "lib.h"

Lignes de commande :
1) $CC -c lib.cpp
2) $CC main.cpp lib.o

1) -> compile lib.cpp et g�n�re un lib.o
2) -> compile main.cpp, link et g�n�re un ex�cutable
Il y a une source d'inefficacit� dans ce processus, inefficacit� que cherche � r�gler ce proposal sur les modules : lors de la compilation de lib.cpp puis de main.cpp l'#include "lib.h" va forcer une inclusion textuelle du fichier lib.h, qui va donc �tre recopi�, scann�, tokenizer deux fois.

Version avec module :
Deux fichiers uniquement lib.cpp, main.cpp
Au d�but du fichier lib.cpp on a une directive du style export Lib: pour d�finir un nouveau module
Au d�but du fichier main.cp on a une directive du style import Lib;

Lignes de commande :
$CC -c lib.cpp
$CC main.cpp lib.o
Oui c'est pareil

1) -> compile lib.cpp et g�n�re un lib.o et un lib.mpp
lib.mpp est le fameux fichier module, c'est une sorte de .h g�n�r� automatiquement par le compilateur. Le format de ce .mpp n'est pas encore sp�cifi� dans le proposal mais je suppose que pour obtenir les temps de compilation les plus court possible il faudra laisser le format � la discr�tion du compilateur qui pourra ainsi g�n�rer des fichiers binaires extr�mement proche de la repr�sentation m�moire.
2) -> compile main.cpp, link et g�n�re un ex�cutable
Lorsque le compilateur rencontre la directive import Lib dans main.cpp il va chercher et charger le fichier lib.mpp correspondant. Ce chargement est tr�s efficace vu que le fichier est dans un format directement exploitable par le compilateur.

[germinolegrand]

Ouais ais du coup si je veux juste compiler main.cpp je peux pas

[Klaim]

Ouais ais du coup si je veux juste compiler main.cpp je peux pas

Il va falloir etre plus pr�cis parceque je comprends pas du tout ta question...

[germinolegrand]

Ben si je veux seulement compiler main.cpp (et pas lib.cpp), c'est pas possible avec le syst�me de modules, contrairement au syst�me d'include.

[Flob90]

@germinolegrand: En effet, mais pourquoi voudrait compiler main.cpp avant d'avoir effectuer un compilation (quelconque) de lib.cpp ? A part imposer un ordre sur le processus de compilation/recompilation, �a ne g�ne pas.

NB: J'ai pas lu le proposal, je me base sur ce qu'� dit Arzar.

[germinolegrand]

parce que tout simplement j'ai pas acc�s aux autres fichiers ou je compile simplement pour v�rifier que j'ai pas fait d'erreur de syntaxe/que c'est du C++ valide (beaucoup plus courant), pas envie de me taper 3h de compile si c'est un moteur complet que je modifie un peu.

Edit: ou bien qu'on est en train de bosser � 2 sur le code chacun sur son fichier mais qu'on a pas envie de compiler le fichier du voisin parce qu'en l'�tat il est pas compilable encore (bah ouais il bosse dessus), et qu'on a pas envie de m�langer toutes les erreurs de compile alors que seules celles de notre propre fichier nous int�ressent.

[Arzar]

Et puis � la r�flexion, il y a un probl�me car comment distribuer une biblioth�que (sans le code source) si l'on ne peut pas distribuer un couple .h/.dll ou .h/.lib ?

Donc j'ai en fait mal lu le proposal
En fait dans le proposal la compilation d'un fichier cpp g�n�re deux fichiers (en plus du .o) :

- Un fichier d'interface
- Un fichier d'interface pr�-compil� (PIF)

Le fichier d'interface (.mpp dans le proposal) est au format texte, lisible par un humain et destin� � �tre distribu�. Il est extr�mement proche de ce que pourrait �tre un .h g�n�r� automatiquement par le compilateur + quelques annotation. D'apr�s le proposal il est "d�sirable que les fichiers d'interface soient standardis�s". Le proposal donne un exemple de ce que pourrait ressembler un fichier d'interface "5.1 The interface file" (mais c'est juste un exemple j'ai l'impression qu'une standardisation compl�te demanderait �norm�ment de boulot...)

Le PIF est la version binaire de ce fichier d'interface, pr�-compil�, tr�s efficace, propre � chaque compilateur. Ce PIF n'a pas pour vocation � �tre distribu�, vu que s'il n'est pas pr�sent � la premi�re compilation alors le compilateur le g�n�rera pour acc�l�rer les compilations futures.

Pour ce qui est du pb soulev� par germinolegrand, il y a une section du porposal d�di� (2.4 Writing Against Unimplemented Interfaces) qui ne r�sout pas compl�tement le probl�me mais donne au moins un workaround : �crire dans un premier temps un squelette de lib.cpp ne contenant que les d�clarations (comme un .h quoi ) et compiler une fois pour obtenir le fichier d'interface correspondant. Ce fichier d'interface obtenu peut �tre alors distribu� et utilis� pour compiler et travailler ind�pendamment (comme on le ferait avec un .h).

Edit : Du coup �a m'a l'air bien complexe comme feature et difficile � standardiser... j'esp�re que �a va pas finir comme les concepts

[germinolegrand]

rhoooo
Encore un bateau coul� � ajouter sur C++Land...

[Klaim]

Edit : Du coup �a m'a l'air bien complexe comme feature et difficile � standardiser... j'esp�re que �a va pas finir comme les concepts

Errr... non puisque celui qui s'en occupe est le m�me qui a d�j� impl�ment� les modules pour Objective-C, qu'il y a une impl�mentation en cours qui est apparamment prom�tteuse (contre des difficult�s d'impl�mentations massives pour les Concepts) et qu'il est question de virer les headers, pas d'ajouter un meta language... autrement dis oui c'est complexe, surtout parcequ'il faut garder la r�tro-compatibilit�, et �a sera pas standardis� avant la prochaine grande version (tic?) qui serait pour dans 5 ans... cela dit rien n'empechera d'utiliser des impl�mentations. L'impl�mentation par celui qui s'occupe des modules est faite directement dans clang.

[Freem]

Mais... Si on vire les headers, �a implique que tout le code habituellement un peu crado des #define qui permet une relative portabilit�, celui que l'on collait dans les header parce qu'au fond c'est bien l� leur place, l� ou l'on d�finit que le code doit se compiler diff�remment que l'on compile pour WIN32 (je me demande d'ailleurs, WIN32, pour les nouveaux windows 64b, �a fait pas un poil ironique?) pour POSIX ou pour MICHU (ah non, pardon, �a le nom d'une table de bdd... ) va se retrouver au milieu de l'impl�mentation?
Idem pour les macros?

Bon, je sais que l'on a tendance � le limiter au maximum, et que des #ifdef se retrouvent au final dans le cpp, mais les macros (qui bien que d'usage limit� peuvent encore servir, parce que �a �vite d'apprendre une librairie boost et les astuces genre ## sont parfois utiles) et la majorit� du code relatif au pr�-processeur se retrouvais dans les header...

Tiens, maintenant que j'y songe, pareil pour les template?
Je pense que la distinction header/impl�mentation tenait pas mal au fait que le header, �a se compile pas (d'o� l'impl�mentaion des template contenue dedans, ou dans un fichier inclus par le header). Je me trompe?

[Niark13]

Edit : Du coup �a m'a l'air bien complexe comme feature et difficile � standardiser... j'esp�re que �a va pas finir comme les concepts

�a n'est pas sp�cialement complexe en tant que tel. C'est grosso modo ce que font les compilateurs D : les sources ont l'extension .d et le compilo peut g�n�rer des fichiers .di (D Interface) qui sont l'�quivalent de ces fichiers d'interface.
Lorsqu'il rencontre une directive import, le compilo cherche le module correspondant, que ce soit sous forme d'un fichier.di ou .d. Si c'est sous la forme d'un fichier .d, le compilo le parse et en extrait l'interface, sans s'amuser � le recompiler en entier. C'est la principale diff�rence avec un m�canisme comme #include.

Ce qui risque d'�tre plus difficile, �a va �tre que tout le monde se mette d'accord sur les formats de ces fichiers (on me glisse dans l'oreillette qu'il y a un peu plus de couples syst�me/compilateur dans le monde C++ que dans le monde D)...

[Klaim]

Mais... Si on vire les headers, �a implique que tout le code habituellement un peu crado des #define qui permet une relative portabilit�, celui que l'on collait dans les header parce qu'au fond c'est bien l� leur place, l� ou l'on d�finit que le code doit se compiler diff�remment que l'on compile pour WIN32 (je me demande d'ailleurs, WIN32, pour les nouveaux windows 64b, �a fait pas un poil ironique?) pour POSIX ou pour MICHU (ah non, pardon, �a le nom d'une table de bdd... ) va se retrouver au milieu de l'impl�mentation?
Idem pour les macros?

Bon, je sais que l'on a tendance � le limiter au maximum, et que des #ifdef se retrouvent au final dans le cpp, mais les macros (qui bien que d'usage limit� peuvent encore servir, parce que �a �vite d'apprendre une librairie boost et les astuces genre ## sont parfois utiles) et la majorit� du code relatif au pr�-processeur se retrouvais dans les header...

Tiens, maintenant que j'y songe, pareil pour les template?
Je pense que la distinction header/impl�mentation tenait pas mal au fait que le header, �a se compile pas (d'o� l'impl�mentaion des template contenue dedans, ou dans un fichier inclus par le header). Je me trompe?

D'abord, les include ne vont jamais disparaitre. Si tu as vraiment besoin de faire un include, �a marche aussi (voir le proposal).
Pour les templates c'est moins clair mais si j'ai bien compris yaurait du gain de temps de compilation associ�.