Bjarne Stroustrup, l'auteur du langage C++, vient de publier un essai prospectif pour envisager le futur de son bébé à l'échelle de la décennie. Il évoque les améliorations potentielles du langage et de la librairie standard.
Lien vers le fichier pdf (5 pages et moins de 200 ko) : http://www.informit.com/content/images/art_stroustrup_2005/elementL(...)
PS : J'ai eu beau chercher frénétiquement des trolls du style "C# puxor" ou " Python c'est tout lent"…mais Stroustrup est très décevant sur ce point particulier qui fait pourtant habituellement la joie des lectures d'articles sur les langages informatiques.
Journal Le C++ du futur
11
juil.
2005
# Si ça peut te faire plaisir
Posté par Flink . Évalué à -1.
oki -->[]
# Le bilan
Posté par pierthi . Évalué à 8.
C :
+ Complètement rodé
+ Peut tout faire
- On doit tout faire
- Framework souvent (très) pénible
-/+ Doc : le pire cotoie souvent le meilleur
C++ :
+ Vraie couche objet
- Portabilité douteuse
- Syntaxe (souvent) imbitable
- Framework bas niveau
c# :
+ Bon framework
- Une partie du framework est détenu par Microsoft
Perl :
+ Très bonne portabilité (Windows / et quasiment tous les Unix)
+ Framework intéressant (CPAN)
+ Documentation (du moins la v5.8)
- Subtilité syntaxique à consommer avec modération
- Pas d'API graphique unifiée (Windows / Unix)
Java :
+ Framework excellent
+ Rapide sous Windows
- Lent sous Linux (en attendant gcj)
- Lourd (JRE à déployer, pas dans toutes les distribs Linux, en attendant gcj)
- Consomme beaucoup de RAM
Python :
+ Syntaxe sympathique et simple
- Lent ?
- Framework ?
Caml :
+ Syntaxe logique
+ Rapide
- élitiste, peu de compétences (par rapport aux autres langages, hein)
-/+ Framework ?
Alleé zou dans la foulée, quelques langages proprios :
4D :
+ Simple et productif
+ Excellente intégration des services webs (HTTP, XML, XSL) avec une base de données.
+ Documentation exhaustive, avec tutoriel et exemple de code abondants, libre d'accès.
- Syntaxe nullissime (dépendante de la locale ...)
- Lent, cher et ultra proprio (il y eu des efforts pour la v2004)
- bug, bug, bug, bug, bug, bug, bug, et encore des bugs.
Realbasic :
+ Simplissime et productif
+ Framework très sympa (cross plateforme Linux GTK2 / Mac OS X / Windows)
+ Entreprise très réactive
- Format des fichiers propriétaires.
-/+ Doc
Visualbasic :
+ Simple et productif
- Bug, bug, bug, bug.
- Lourd à déployer (dll et co)
- Syntaxe nullissime (dépendante de la locale ...)
- Documentation
C'est un peu près tout ce que j'ai du testé (python, caml) ou du mettre en production un jour (le reste), et si on pouvait compléter les autres (genre PHP, ruby, ...). tout ça pour dire, que j'attends toujours le langage idéal qui pourrait convenir à tous les besoins. Techniquement qu'on ne vienne pas me dire que c'est infaisable ...
<avis perso>gcj a le potentiel de tout déchirer</avis perso>
Mes 2 cents.
[^] # Re: Le bilan
Posté par Yusei (Mastodon) . Évalué à 6.
+ langage objet, pas seulement "orienté objet" comme le C++ ou Java
+ syntaxe agréable, conçue pour optimiser le programmeur
+ un petit côté fonctionnel avec ses blocs
+ aussi flexible/expressif que le Perl, le côté "tout objet" en plus
+ la bibliothèque de base est bien fournie, il existe beaucoup de "contributions", et il est très facile de l'interfacer à une bibliothèque en C
- le typage dynamique, c'est bien pour coder rapidement, mais ça rend la détection des bugs plus compliquée (pas de "copmpile-time")
- la VM actuelle est lente
[^] # Re: Le bilan
Posté par bobefrei . Évalué à 7.
Et moi qui pensais que seul le café et l'augmentation de salaire pouvaient "optimiser" le programmeur!
[^] # Re: Le bilan
Posté par Croconux . Évalué à 2.
On peut aussi adjoindre au programmeur une programmeuse, ça marche aussi. Moi on m'a "filé" une stagiaire récemment... (grande brune charmante)
[^] # Re: Le bilan
Posté par LeMagicien Garcimore . Évalué à 5.
+ Vraie couche objet
heuuu t'es sûr de toi là ?
[^] # Re: Le bilan
Posté par CrEv (site web personnel) . Évalué à 3.
Et un langage avec :
- la simplicité et le langage de perl (très expressif, très simple pour tout ce qui est traitement bateaux tels texte, ...)
- avec une vision objet poussée (un peu de java, c#)
- qui puisse etre à la fois compilé / interprété (interprété pour le devel par ex, compilé pour l'exécution)
- bien lié avec les toolkits graphiques (qt par ex)
- surement plein d'autres choses comme la possibilité de travailler à la fois avec un simple emacs mais aussi un bon ide qui peut rendre service, etc
Quelqu'un connait un langage de ce genre ??
[^] # Re: Le bilan
Posté par vrm (site web personnel) . Évalué à 3.
[^] # Re: Le bilan
Posté par Brahici . Évalué à 3.
[^] # Re: Le bilan
Posté par bobefrei . Évalué à 2.
[^] # Re: Le bilan
Posté par Brahici . Évalué à 7.
rien à dire sur la syntaxe, la structuration par indentation oblige à une grande rigueur dans l'écriture du code. de là à dire qu'elle est sympathique ...
lent ? je ne sais pas. nous utilisons python quotidiennement pour traiter de grandes quantités de fichiers et de données en tous genres, il ne nous a pas semblé que python était lent.
framework ? il n'y a pas de framework python au sens .net framework, mais il me semble par contre que la librairie standard de python est très fournie. et il existe un grand nombre de modules / frameworks / bindings pour combler / compléter la librairie standard.
un oubli impardonnable de ta part: tu as omis de mentionner que python est multiplateforme, y compris pour les interfaces graphiques (tkinter, pygtk et wxpython pour ne citer que ceux-là).
dernier point, il faut évoquer la vitesse de développement, qui de nos jours est un point important voire crucial pour les décideurs (trop ?) pressés. j'ai été pendant longtemps (et je l'évoque aujourd'hui encore avec une certaine honte, d'autant plus que j'étais considéré comme expert) un développeur en VB. j'ai participé à des projets 'usine à gaz' où python aurait vraiment fait merveille. nous sommes toujours arrivés à faire ce que l'on voulait en VB (faut pas déconner non plus) mais que de temps aurait été gagné si cela avait été fait en python. et je ne parle pas de la pseudo-implémentation objet de VB (même si ça s'est beaucoup amélioré avec VB.net), rien que d'y repenser, les poils se hérissent sur mes bras.
un décideur pressé n'aura même pas l'excuse de dire qu'il n'y a pas d'IDE comparable à Visual Studio pour python, on peut citer en vrac et sans préference: Wing IDE, Komodo ou boa constructor (même si j'utilise plutôt anjuta et vim).
[^] # Re: Le bilan
Posté par harbort1 . Évalué à 4.
Alors :
- Pour la syntaxe, elle est plutôt bien pensée (sauf qq exceptions) et j'arrive à me relire assez bien même quand il s'agit de code fait à mes débuts ... c'est une des force de Python. Par contre, il y a des gros défauts de logique qui peuvent amener à des bugs tout bizarre (mais on apprend à les éviter)
- Pour le "framework", comme déjà dit, la bilbiothèque standard est très bien fournie et il existe de très nombreuses extensions sur le oueb. Ensuite, pour l'étendre soi-même c'est relativement facile si on utilise un outil (non-standard) d'aide à l'extension tel que SWIG (multi-langage) ou Boost.Python (C++).
- Pour la vitesse, il faut être clair : PYTHON EST LENT !!! C'est indéniable ! Par contre, ça veut pas dire qu'on ne peut pas être efficace en utilisant Python. Car si le langage lui-même est très lent, les extensions qui ont besoin de vitesse sont toutes écrites dans un autre langage (le plus souvent C, Fortran et C++). Il faut notamment citer pour le calcul scientifique le très bon scipy qui apporte à Python tout un ensemble de fonctions codés en Fortran pour du calcul matriciel. Pour ceux qui auraient un doute, je conseille la lecture de cet article ( http://www.python.org/doc/essays/list2str.html(...) ), écrit par le créateur de Python, sur l'optimisation (la conclusion est très instructive ... ).
Enfin, sur C++ (parce que je trouve qu'il n'y a pas grand chose de dites dans le message d'origine :P) :
- Il y a indéniablement du "vrai objet" : héritage multiple (mais avec beaucoup de subtilités), méthodes virtuelles, méthodes/classes abstraites, ...
- Sur le framework, bah de base on peut pas dire qu'il y en ait un ... par contre il en existe beaucoup, des très bon comme des très mauvais. Par exemple Qt est un très bon framework orienté GUI (mais pas seulement). On a aussi Boost ( http://www.boost.org(...) ) qui propose un ensemble de bibliothèques le plus souvent très bien faites, même si un peu difficile à maitriser.
- Pour les perf, ça peut être très rapide, mais c'est tout de même plus lent que du C pur. Par contre, la vitesse de dev est quand même bien plus rapide que sur le C.
- On notera aussi la possibilité de faire de la programmation générique (avec les template). Notamment, Boost utilise beaucoup cette fonctionnalité du langage. Parmis les intérêts de l'approche: la généricité est résolue à la compilation ce qui permet de ne pas perdre de temps à l'exécution. Inconvénient: ça peut être très complexe (cf. Boost) et le débuggage des templates devient vite subtile
- Par contre, je suis pas d'accord sur la syntaxe imbittable ... ou alors c'est pareil pour C, Java, C#, ...
- Pour la portabilité, le problème vient de ce qu'aucun compilo ne supporte totalement la norme ! (Et VC6 est l'un des pires pour ça ...). A leur décharge, la norme est mal foutue et surtout, elle impose des éléments quasi-infaisable ... (dsl, trouve plus la ref ...)
- Et quand même: ça doit être un des langage pour lequel il existe actuellement un maximum de développeur !
[^] # Re: Le bilan
Posté par LeMagicien Garcimore . Évalué à 5.
Et il y a aussi du vraiment pas objet (les types primitifs par exemple)
Par contre, je suis pas d'accord sur la syntaxe imbittable
Heuuu, c'est quand même un peu la mort le C++. Pour moi :
boost::test_tools::tt_detail::equal_and_continue_impl(const int (*const & )[9],const int (&)[9],class boost::basic_wrap_stringstream &,class boost::unit_test::basic_cstring<char const >,unsigned int,enum boost::unit_test::log_level,unsigned int)
Ok, l'exemple est extréme, mais faut quand même être gonflé pour trouver ça simple... Par exemple l'initialisation de variables d'instances statiques :
class Truc {
static int compteur;
};
int Truc::compteur = 0;
C'est complétement merdique comme truc, désolé. Et c'est pas le seul problème. Java et C# ont une syntaxe bien plus simple !
Et quand même: ça doit être un des langage pour lequel il existe actuellement un maximum de développeur !
Je me demande si Java est pas passé devant quand même...
[^] # Re: Le bilan
Posté par gourgou . Évalué à 4.
Tout le problème, avec la plupart des fanas de l'OO, c'est que si on met autre chose dans leur monde, ils râlent. Bonté divine d'intaigristes !-)
Ce qui était dit là, c'est que les élément d'OO de c++ ne sont pas des demies fonctionnalités objet. (Pas comme le implement de java, par exemple.)
l'exemple est extréme
Non, l'exemple est juste inapproprié :
- les enchaînements de ns-qualification (les enfilades de ::) n'ont rien à voir avec le langage ;
- les const int (*const & )[9], faut se plaindre du côté de C (voire peut-être même des prédécesseurs de C)... et encore, dedans, c'est écrit dans « le bon sens » ;
- le class boost::unit_test::basic_cstring<char const>... bah c'est super rare, les templates aussi simples que ça !
Par exemple l'initialisation de variables d'instances statiques [...] C'est complétement merdique comme truc
Encore une fois, ce genre de problème ne vient pas tant de ce qui a été apporté à C pour en faire C++ qu'à ce qui n'en a pas été enlevé au passage. Là, il me semble que ça garde un rapport avec la pauvreté effarante du préprocesseur en général, et de #include en l'occurence.
J'ai été définitivement convaincu que « tout le préprocesseur est mal » le jour où j'ai compris que ceci était parfaitement valide et fait pour l'être :
// .h
struct ma_struct { int un_champ ; }
// .c
#include ".h"
;
int toutvabien = 1 ;
Bien sûr, j'ai compris ça après avoir passé deux heures à comprendre qu'il manquait le « ; frauduleux » du .c quelque part. Et comme si ça ne suffisait pas, ça m'est arrivé juste après la période où j'ai eu à faire du java (donc c'est encore retombé sur sa tête, pour m'avoir embrouillé mes pinceaux ;)
Mais bon, comme je disais, ce n'est pas un problème de C++.
Java et C# ont une syntaxe bien plus simple !
Je ne connais pas C#, mais pour mon expérience passée de java, « limitée en termes d'expressivité » me viendrait plus facilement à l'esprit que « simple » pour en qualifier la syntaxe...
Je me demande si Java est pas passé devant quand même...
Hmm... et à part à sun, à qui ça change quoi ? Tout ce qu'il y a à savoir, c'est qu'il y en a beaucoup. Suffisamment pour les deux langages au moins, en tout cas.
[^] # Re: Le bilan
Posté par LeMagicien Garcimore . Évalué à 3.
[^] # Re: Le bilan
Posté par gourgou . Évalué à 1.
Hmm... goûts, couleurs, toussa... c'est effectivement pas toujours évident à débiter, mais j'aime tellement ce qu'il apporte par ailleurs --- en termes d'expressivité, de typage (car oui, chers amis, un typage fort, c'est bien pour pas transformer son code en porcherie dès qu'il prend un peu de volume) et de généricité (c'est justement parce que c'est les templates, précisément à cause de certaines de leurs limitations, que je m'y suis intéressé) --- que je suis complètement passé outre.
[^] # Re: Le bilan
Posté par vrm (site web personnel) . Évalué à 2.
Quelle parties du framework te pose pb ? Perso j'utilise rien de chez MicroSoft
[^] # Re: Le bilan
Posté par B16F4RV4RD1N . Évalué à 5.
je ne suis pas calé pour répondre en faisant un petit comparatif comme tu l'as fait, mais il me semble qu'il n'a pas certains défauts que l'on reproche souvent au C++
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Le bilan
Posté par pierthi . Évalué à 1.
Sinon pour compléter encore un peu le descriptif, j'avais oublié les points suivants :
Perl :
- Extensions (package) écrit dans d'autres langages que perl sont assez gores à développer.
Python (résumé des commentaires - on a dit dicaïdor) :
+ Syntaxe simple et intuitive
+ Rapide avec Pyrex (pas trop testé) ?
+ Bibliothèque standard complète, extension facile à intégrer (même dans d'autres langages ?).
- Lent, voire très lent, en interprété.
Javascript :
+ Approche objet très sympa. Mon préféré, de loin.
+ Framework HTML DOM v2 assez bien fait (mais ne couvre pas tout, volontairement).
- Fortement associé au Web.
- Internet Explorer
- Pas d'arithmétique entière (on peut contourner avec pas mal de bidouille).
C# :
- windows.forms : c'est un peu l'équilavent de SWT de java, detenu par Microsoft (pas normalisé, changements en douce, éventuellement brevets). Cela dit, les devs de mono ont l'air sacrément enragé.
- "This program cannot be run under dos mode" Mouhahahaha.
4D :
+ Cross plateforme Mac OS 1.0 à Mac OS X et Windows 95 à XP (sans doute même 3.1, avec interface native).
- La version Windows est nulle (Force à utiliser une interface MDI : beurk).
Realbasic :
- La version Linux/GTK2 ne fonctionne que sur x86 évidemment (avec pas mal de limitations dans le framework).
[^] # Lisaac
Posté par Ontologia (site web personnel) . Évalué à 1.
+ généricité, redéfinition des opérateurs avec spécifications des priorités (* est prioritaire sur +)
+ Syntaxe très propre
+ Aussi rapide à l'exécution que du C
- inconnu
- librairie de base, mais vraiment de base.
Mais beaucoup d'avenir ! :-)
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
# Petit joueur
Posté par jigso . Évalué à 1.
[^] # Re: Petit joueur
Posté par gourgou . Évalué à 1.
http://www.open-std.org/jtc1/sc22/WG21/docs/papers/(...)
Maintenant, je me demandais l'intérêt de ce papier, puisqu'il ne fait que réaffirmer des principes clairement énoncés il y a déjà plus de dix ans dans le Design & Evolution... et en fait, ce serait juste une pièce rapportée à une nouvelle édition du DnE.
Dans ce cadre là, je trouve un peu bizarre d'évoquer aussi furtivement les « concepts » (ou plutôt de les évoquer tout court, en fait) et curieux de s'étendre encore sur les mêmes arguments... Quelqu'un a plus d'infos sur la nature de cet article ?
[^] # Re: Petit joueur
Posté par patrick_g (site web personnel) . Évalué à 1.
In the Japanese edition of his latest book, Bjarne Stroustrup added an extended essay, reflecting on C++ use over the last decade, and presenting plausible directions for the next revision of the C++ standard.
[^] # Re: Petit joueur
Posté par gourgou . Évalué à 2.
On remerciera au passage la volonté de ces messieurs d'informit.com de se donner le niveau d'un pcinpact ou d'un 01net (je ne les connais pas donc je me permets d'être vache ;), puisqu'ils ont réussi à confondre un article donné au C++ journal (le pdf qu'ils donnent à lire) avec le papier qu'ils décrivent : http://www.research.att.com/~bs/DnE2005.pdf(...)
A noter que ce dernier (32 pages) est très intéressant --- notamment, on en apprend un peu plus sur les « concepts » (j'en connais qui vont encore râler ;) --- et très agréable à lire, entre autres quand BS, une fois n'est pas coutume, se lâche sur java (soyez gentils avec mon trollomètre, plz). En fait, l'article de 5 pages est un résumé hyper approximatif.
# C++ trop gros
Posté par Guillaume Knispel . Évalué à 4.
Donc le C++ va être de plus en plus gros et de plus en plus difficile à apprendre, avec des concepts d'abstraction dans tous les sens qui ne dispenseront pas de connaitre ou du moins d'avoir une idée sur leur implantation réel pour pouvoir s'en servir efficacement.
Connaitre la teneur de tout le sucre syntaxique que ca va engendrer va bientot etre difficile pour un seul homme, ce qui risque fort d'accelerer le déclin de ce langage. Car on ne métrise bien le C++ qu'en ayant une idée de ce qu'il y a derrière ce qu'on tape, sinon ca produit de gros trucs qui rament (encore plus que d'hab ;)
Personnelement j'adore la version 2 du langage, tout ce qui a été fait depuis (dont les templates qui sont a mon avis une mauvaise réponse au problème de la généricité) et bien trop compliqué sur une base déjà suffisement dure à assimiler pour permettre de produire efficacement des résultats performants. Exercice pour vous en convaincre : lisez la STL de SGI (celle qui vient généralement sous une distribution Linux)
Quand Java sera compilable efficacement en natif par GCJ avec de bonnes performance et une grande couverture des classes standard, a mon avis C++ prendra un sacré coup dans le monde libre.
[^] # Re: C++ trop gros
Posté par Sylvain Sauvage . Évalué à 1.
En ce qui concerne la STL, un exemple simple : soit i un itérateur (sur une séquence quelconque), ++i est dix fois plus rapide que i++. Et pour le savoir, il faut lire et surtout comprendre le code...
Par contre, les génériques sont une bonne idée, ce sont les templates (leur mise en ½uvre en C++) qui est casse bonbon.
Ce qui me gêne moi avec les langages comme Python, Ruby ou Php, c'est qu'il manque la possibilité* de déclarer les variables et de reconnaître l'utilisation d'une variable non déclarée, c'est-à-dire, en général, une variable avec une faute de frappe...
(* : je ne demande pas l'obligation, juste la possibilité, avec un warning derrière)
[^] # Re: C++ trop gros
Posté par Moonz . Évalué à 5.
[^] # Re: C++ trop gros
Posté par Yusei (Mastodon) . Évalué à 3.
a = 2
crée la variable a et lui affecte 2. Par contre, lorsqu'on utilise une variable pour autre chose que l'affectation, soit on se heurte à un objet initialisé à Nil, qui n'a pas la méthode qu'on essaye d'utiliser, soit on se heurte à un "NameError: undefined local variable or method". Ce n'est pas idéal, mais au moins la plupart des erreurs que l'on pourrait identifier tout en gardant le typage dynamique sont identifiées assez vite. Par exemple, impossible de faire
> toto = 2
> a = 3 + totp
NameError: undefined local variable or method `totp'
Ou bien avec des variables de classe (qui elles sont initialisées à Nil)
> @toto = 2
> a = 3 + @tpto
TypeError: nil can't be coerced into Fixnum
[^] # Re: C++ trop gros
Posté par Yusei (Mastodon) . Évalué à 2.
[^] # Re: C++ trop gros
Posté par Sylvain Sauvage . Évalué à 2.
Si j'écris : x = 2 * y alors que y n'est pas défini, j'ai bien une erreur.
Par contre, si x n'est pas la bonne variable (elle n'a jamais été déclarée), cela ne provoque aucun message.
Autre exemple, plus clair, en PHP :
class T {
var $x;
function f() {
$this->y = 12; // oups : je voulais dire $this->x = 12 !
}
}
$t = new T();
$t->f();
print "#" . $t->x . "#"; // affiche "##" !
Moi, j'aimerais bien avoir la possibilité d'une vérification à certains moments. Parce que passer 3 plombes (quand on a du bol) à trouver pourquoi la variable x n'a pas la bonne valeur alors qu'il s'agit juste d'une faute de frappe...
[^] # Re: C++ trop gros
Posté par Moonz . Évalué à 1.
[^] # Re: trop gros, c'est sûr
Posté par gourgou . Évalué à 1.
j'ai bel et bien l'impression que pour Bjarne Stroustrup évolution signifie juste ajouts
BS a toujours été clair qu'il était a priori contre l'inclusion de n'importe quel truc nouveau. D'ailleurs, t'as pas dû bien lire l'article pointé par le journal, sur cette question là. Tu mériterais clairement d'avoir à apprendre par coeur le §6.4.1 du Design & Evolution !
Tiens, je renonce même à répondre au reste de ton commentaire. Désolé, mais pour avancer des trucs comme
- accelerer le déclin de ce langage
- tout ce qui a été fait depuis et bien trop compliqué
- une base déjà suffisement dure à assimiler pour permettre de produire efficacement des résultats performants
- lisez la STL
tu dois pas souvent lire ce qu'en dit Stroustrup lui-même...
# C++0x ?
Posté par Obsidian . Évalué à 4.
« C++0x », mais il est fou, ou bien il fait une cure à l'héroïne. Et c'est un fan de C++ qui le dit. D'ailleurs comment cela se prononce-t-il ? « SuX » ?
Allez Bjarne, on est tous très reconnaissants de ce que tu as fait pour le monde, mais là, tu vas réfléchir un peu, hein ...
[^] # Re: C++0x ?
Posté par patrick_g (site web personnel) . Évalué à 5.
Si c'est en 2007 et bien le nom sera C++07
Si c'est en 2008 et bien le nom sera C++08
Si c'est en 2009 et bien le nom sera C++09....voila je pense que t'a compris l'idée générale.
[^] # Re: C++0x ?
Posté par Obsidian . Évalué à 2.
[^] # Re: C++0x ?
Posté par thom_ra . Évalué à 2.
soit 0x pour 00 à 0F, ou alors 0x00 à 0xFF, etc...
On est en 05 (ou 0x05) je vous le rappelle ;-))
Allez, je vais aller prendre un café moi !
[^] # Re: C++0x ?
Posté par Sylvain Sauvage . Évalué à 2.
Le standard C en cours est... C 99
Quelques standards de langages de programmation : Ada 95, Fortran 77, Fortran 90, Fortran 95, Cobol 61, Cobol 68, Cobol 74, Cobol 85, APL 96, Simula 67, Algol 68, Smalltalk{72,74,76,78,80}, Haskell 98, SML 90, SML 97, Scheme 84...
Voilà. Je n'ai pas d'exemple où l'année est écrite autrement qu'en décimal.
Par contre, si le nombre commence par un zéro, c'est de l'octal. On pourrait donc imaginer qu'il pensait à 0x pour 05 à 07 (ben oui, ça m'étonnerait que ce soit moins que cinq, il aurait fallu qu'il soit déjà sorti).
Reprends donc un café, pour moi ;o)
[^] # Re: C++0x ?
Posté par thom_ra . Évalué à 2.
Ceci dit, je retourne bien volontier boire un café pour toi...
[^] # Re: C++0x ?
Posté par Sylvain Sauvage . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.