Reprise du message précédent :
http://successisnotanoption.tumblr [...] -scares-me

Vérifier si il n'y a pas des temps de trajets différents ?

PQ pour anti-flandisme.

moi c'est Hunter s. Thompson. pour les cheveux.

 
Y'a pas les caddie-voiture chez Casto, c'est nul.
 
Par contre, il m'est arrivé de me trimballer dans les allées de LM tout seul avec 2 caddies voitures, ça fait les bras.

Yo les gens, y'en a qui sont allés voir Drive ?
Ca a l'air d'être un film d'action plébiscité par la presse.

si j'ai bien compris, en fait y'a pas vraiment d'action. Genre une attente énorme puis un peu d'action.

Bon, je verrai bien, je ne verrai rien, vu la queue devant le ciné.

Wow, C++11 a l'air de méchamment nettoyer la syntaxe. S'ils ont réécrit toute la standard lib avec ça et les lambda, le code applicatif devrait être nettement plus lisible (sans parler des erreurs  de compil). Au vu des quelques exemples donnés, c'est vraiment plus le même langage.
Bon, j'imagine qu'il y a toujours autant de pièges et autres chausse-trappes qu'avant, mais le code devrait être largement plus clean, surtout s'ils ont tiré parti des nouveautés pour booster (si j'ose dire) la standard lib. Et j'imagine aussi (sauf s'ils ont réduit le nombre d'includes ou s'ils ont intégré la notion de module), que les temps de compilation sont toujours aussi pénalisants...

oui, c'est bien, non ce n'est pas un film d'action

Les modules seront pour la prochaine fois, mais le papier est interessant : http://www.open-std.org/jtc1/sc22/ [...] /n2316.pdf
Quel standard lib ? La plus moderne (libcxx) ne semble pas utiliser les nouveautes du C++11 ( http://llvm.org/svn/llvm-project/l [...] ude/string ) , en meme temps, on s' en fout de comment est implementer la lib non?

La librairie standard, qui fait partie du standard. Non, on ne s'en fout pas, vu que la librairie standard conditionne énormément la façon dont on code dans un langage. L'API STL a radicalement changé la façon dont on code le C++, par rapport au temps où elle n'existait pas. Une STL réécrite avec les nouveaux paradigmes aurait l'avantage d'ête plus lisible, et p-ê aussi de permettre de cracher des messages d'erreur eux-mêmes bcp plus intelligibles (le typechecker est bcp plus intelligent et gueulera au moment de l'inférence de types, et sera je pense capable de pointer plus facilement sur le code erronné).
Idem pour le multithreading, il n'y avait pas de façon standard pour cela, maintentant, ça sera à base de std::thread, threadpools, futures et promises, qui sont autrement plus simples à utiliser que pthread ou les threads windows (c'est d'ailleurs le modèle de MT de Java et je suppose .NET).

prem's

 
Reprenons les points de Herb,
 
* auto, il n'y a rien à changer dans la lib standard
* Smart pointers, c'est un ajout à la lib standard
* nullptr, il n'y a rien à changer dans la lib standard
* Range for, c'est défini de manière à ce qu'il n'y ait rien à changer à la lib standard -- comme ça tout le code qui a le même style en profite sans rien changer
* Nonmember begin and end, ajout dans la lib standard,
* Lambda Functions, c'et défini de manière à ce qu'il n'y ait rien à changer à la lib standard
* Move / &&, la lib standard a été complètée pour les utiliser.

 
Le point le plus important (et le plus complexe) pour le MT est la définition d'un modèle mémoire.

Ca m'a pas paru clair en parcourant l'article, mais je m'en doutais un peu, ça permet de garder la compatibilité ascendante. Mais je trouve ça dommage, pour les raisons que j'ai invoquées.
Je me trompe p-ê, mais m'est avis qu'il va y avoir tôt ou tard réécriture de la plupart des libs de base pour exploiter les nouveautés. Herb le dit lui-même dès le départ: "They change the styles and idioms you’ll use when writing C++ code, often including the way you’ll design C++ libraries. " Je ne vois pas pourquoi ça ne s'appliquerait pas à la lib standard elle-même.

Comme quoi, même les chats se fient à ce qu'ils croient, et non à ce qui est.  

et Moktar il devient quoi ?  
ça serait con qu'il vienne plus juste parce qu'il s'est pris une taule avec rankmill, il a qu'à bosser un peu chez darty et re-tenter un autre truc après.

Ah ? Tu vas re-tenter un autre truc toi ?

bah probablement, oui. Et puis là je suis toujours dans une startup à tenter de démarrer un peu les choses.

On me demande un antivirus gratuit qui ne soit pas avast. Vous avez une recommandation ?

winsecure ?

windows security essential si il a une clé de windows originale, sinon antivir.

linux ?  

si c'est pour etre toujours emmerdé avec son pc, autant avoir des virus

 
Un lib a deux aspects, l'interface et l'implémentation. L'interface de la lib standard a été modifiée dans les cas connus comme pertinents (et aussi pas mal complétée).
 
Les implémentations, on s'en fout un peu tant que c'est pas notre boulot de les implémenter. Il doit y avoir mieux à faire que de remplacer des types explicites par auto ou d'utiliser la nouvelle syntaxe de for dans du code déjà écrit auquel on ne touche pas pour une autre raison.

Ouais mais pour les templates ? Il n'y a pas vraiment de séparation ?

antivir

 
  Le fait que tout se retrouve dans le même fichier n'empêche pas qu'il y a une interface et une implémentation.

much

Rankmill existe toujours, et Moktar y travaille encore. Il ne vient plus ici surement parce qu'il a du taf par dessus la tête

Non mais d'accord, mais le problème, c'est que dès que t'as un pb de compilation pour mauvais typage, tu te retrouves avec tous les boyaux de la STL qui dégueulent sur le carrelage, parce que l'erreur de typage peut être détectée par le compilateur dans les profondeurs de l'implémentation. C'est pas quelque chose que tu auras si tu n'utilises pas de templates, par ex, parce que les types sont concrets et infiniment plus simples. Je pense qu'avec une implémentation simplifiée par une syntaxe fortement simplifiée, ces boyaux sont nettement plus compréhensibles, et j'imagine même (rêvons un peu) que l'inférence de type d'un compilo un tant soit peu intelligent devrait pouvoir aider à déterminer la source de l'erreur.

Vas-y, éclaire-nous de ta profonde connaissance du sujet.

Pour le moment j'approuve
So:  

D'ailleurs si vous avez d'autres séries à conseiller je suis preneur.

Non mais la "librairie standard" (celle decrite par l'ISO) n' est pas une librairie existante sous forme de code binaire linkable, c' est juste une description d'une interface de programmation.
Le standard ne decrit pas comment implementer son interface ..

 
Je ne vois pas en quoi de l'inférence peut aider. En fait, l'inférence me semble plus une gène qu'une aide quant à la qualité des messages d'erreurs. Un message d'erreur est d'autant plus clair qu'il est donné proche de l'endroit où le problème réel est présent et est formulé dans les termes de l'utilisateur plutôt que de l'implémentation. L'inférence, en supprimant des endroits où on explicite ses hypothèses, retarde la détection de l'erreur et en ne laissant qu'un contexte d'implémentation.  Les concepts par contre auraient aidés, mais ils fonctionnent exactement à l'envers de l'inférence, ils rendent explicitent les hypothèses plutôt que de les rendre encore plus implicites, avancent le moment où on peut détecter qu'elles ne sont pas valides plutôt que de le retarder, donne un nom à celles-ci plutôt que de ne laisser que les caractéristiques.

Je suis d'accord, mais n'empêche que la STL fait partie du standard, et même si on programme pour l'interface, tu colles à ton programme toute l'implémentation derrière.

toi tu confond norme et standard  

Prem's !