Reprise du message précédent :
et pourquoi ne pas intégrer boost dans la stl, dans sa totalité ?

c'ets le plan.
le std::tr1 contient aps mal de morceaux de boost : tuples en particulier

boost se veut experimental.  Il y a des aspects qui le sont et la normalisation de ce qui vient de boost tient compte du resultat de l'experience.  Une fois que c'est normalise c'est la pour longtemps. Donc, meme les gens de boost n'y pensent pas.  

 en partie seulement !

je vois ty

Votre troll Java, c'est un peu aussi la différence entre un éditeur et un groupe de travail.

LOL j'ai adoré la dernière partie de cette phrase ! C'est tellement vrai ! Pour avoir programmé en Prolog, je ne peux que confirmer. Mais ça reste pour moi un langage "poétique", dans le sens où écrire des programmes en Prolog est difficile, mais ô combien satisfaisant. On a l'impression d'être tout puissant lorsqu'on programme en Prolog.  
D'ailleurs dans le même style il y a Objective Caml. Lorsqu'on veut écrire des programmes récursifs terminaux, c'est pire que BrainFuck ou Prolog ^^. Mais encore une fois, c'est en programmant dans ces langages compliqués qu'on se rend vraiment compte que la programmation est un art. Je n'ai jamais été satisfait de mes programmes en C ou en Java...  
 
J'ai lu ici que certains se demandent pourquoi Java n'est pas utilisé dans les jeux vidéo ou dans les applications temps-réel en général. La réponse est simple :  
- Ca ne vient pas d'un manque de performance par rapport à C++ (ou tout autre langage).  
- Ca vient de la difficulté (voire l'impossibilité) de savoir combien de mémoire un programme va utiliser.  
 
Pour faire un bon langage adapté au temps réel, il ne faut pas utiliser de malloc (allocation dynamique) et il ne faut pas autoriser la récursivité. Or tout ou presque en Java nécessite l'allocation dynamique de la mémoire. Manipuler un simple couple d'entiers nécessite un "new", alors qu'en C une structure suffit. Le garbage collector n'arrange rien à la difficulté de prévoir la quantité de mémoire utilisée.  
Il existe des versions de Java adaptées au temps-réel. C'est peu connu du grand public mais c'est utilisé.  
 
Personnellement je n'ai jamais programmé en C++ donc je ne peux pas vraiment me prononcer. Mais je programme en Objective-C, qui est un peu dans le même style que C++.

oui prolog c'est puissant comme langage c'est indiscutable, mais alors par contre niveau performance on est à des années lumière du C++.

J'ai pas lu tout le topic, alors j'espère ne pas nourir un troll, mais :
 
 

Déjà je me méfie de la notion d'informaticien expérimenté. J'en ai vu avec 20 ans d'expérience qui n'avaient pas le niveau de jeunes sortis de l'école mais passionnés. Et puis expérience ou pas, on peut aimer ou non un langage.
 

En terme de code généré, c'est un des + légers, avec C, Pascal et Fortran.
S'il parle de syntaxe, je dirais qu'il est complet, pas "lourd" et il applique un principe important, le "ne paye pas pour ce que tu n'utilises pas". On peut ne pas utiliser les templates, l'héritage multiple, le RTTI, ça n'aura aucun cout à l'execution. Je n'aime pas les langages volontairement "allégés" comme Java. On finit par avoir besoin des features complexes et on les rajoute à postériori, ce qui rend caduque les arguments étalés au départ. Voir la généricité en Java par exemple.
 
 

C'est quoi un langage pas rigide ?
Un langage qui accepte de compiler n'importe quoi et qui sort ses erreurs à l'exécution ?
Normalement plus un langage a une syntaxe rigide et moins les erreurs grossières sont possibles. On est à l'opposé des langes complètement interprétés comme Lua ou des langages avec une liberté totale de syntaxe comme Perl.
 
Accessoirement, les typedef, les macros et la surcharge d'opérateurs permettent de redéfinir pas mal de points de syntaxe et donc de garder un code clair pour des fonctions avancées.
Il manque peut-être l'inférence de type, je reconnais que des trucs du genre
typename std::map< T, typename U::value_type >::const_iterator it = ...
ça en rebute certains, mais l'inférence de type va être ajouté dans la prochaine version.
 
 

C'est un peu un argument de mauvais codeur C++ ça, quand on connais bien le langage, on arrive vite à ne plus se servir des fonctions du C, sauf les parties tellement fondamentales qu'on les retrouve en Java bien sûr.
A part quelques char* qui trainent des quelques signatures de la lib-c++ (std::fstream, std::exception::what ...) le C++ pur n'utilise plus la libc, fini les malloc, les void*, les FILE*, les memcpy et tout le reste. Là aussi, le C est possible en C++ mais pas obligatoire, je ne vois pas en quoi c'est un problème. Le temps où le C++ était une surcouche du C++ (C with classes) est révolu.

Je ne sais pas si on peut dire ça, il l'utilise abondamment. La libC++, inclut la libc cf les entêtes incluses dans le fichier iostream de la STL, in fine tu te retrouves avec cstdio cstdlib à tout va...

Donc il serait plus correct/précis de dire, l'utilisateur du langage C++, n'utilise plus directement la libC plutôt que de dire le c++ n'utilise plus la libC.

oui je suis d'accord, indirectement ça reste largement basé sur la libC, ce qui est plutôt une bonne chose tant cette lib est bien écrite avec le temps, mais du point de vu du programmeur lambda, il y a moyen de ne pas s'en servir directement.
 
On fait des new à la place des malloc, des std::copy à la place des memcpy, std::string plutôt que les buffer de char, des ostream plutot que des printf etc...

 
C'est un argument relayé par la communauté GNU en transhumance dans prog, ou c'est vraiment suite à appréciation technique?
 
Parce que dire que GCC est un compilateur de grande qualité, ca me fait rire jaune.

pour un compilo gratuit il se débrouille pas mal, et a l'immense avantage d'être dispo pour à peu près tout ce qui est capable de faire une addition.
 
Sous windows, il faut garder en tête que visual C++ est gratuit aussi maintenant, et que c'est le meilleur debugger du marché. (je balaye d'un revers de main tout argument disant que c'est ddd ou un autre debugger qui sent les années 80).
 
Sur x86, les comparatifs de perfs entre VC++ et GCC à version contemporaines donne des résultats équivalents.
 
Certes GCC a qlq problèmes comme la gestion cahotique des precompiled-headers, mais j'en ai entendu moins de critiques que les produits de Borland ou Metrowerks, payants, eux.

 
ça dépends matte le lien http://www.boost.org/doc/libs/1_37 [...] ttests.htm y a des diff

gcc est quand meme blaqueboulé par VC++ sur windows et ICC sur toutes palteformes intel et XLC sur PPC
 
L'avantage c'ets qu'il est souvent uptodate sur la norme et facile d'accés.

 
Oui effectivement. Pour faire du code sur des additions, ca va, il s'en sort. Après, dès qu'on sort du gros x86 ou du ppc de base, faudrait pas trop en demander.
 

 
La qualité d'un compilateur ne se mesure pas uniquement à la vitesse d'execution de petits kernels qu'il compile.
 

 
Le fameux "y'a moins bien mais c'est plus cher".
 
Pour GCC, il faudrait parler de la gestion de frontend/backend imbitable, un code à peu près illisible (une horreur qui sent justement les années 80), la qualité du parser et des informations/erreurs qu'il retourne (pas mal d'erreurs relevées par -Wall n'en sont pas...), et d'autres encore.
 
Vu qu'on en parle au dessus, on pourra aussi dire qu'en dehors des quelques grosses architectures "big daddy" (celles sur lesquelles rognent le mainteneur principal de GCC, Redhat), le reste pète régulièrement et de manière imprévisible. Il a rendu chauve plus d'un mainteneur chez nous, et pas que sur des archis vieillotes comme le m68k.
 
En plus, remarqué dernièrement, il a la sale manie de dégager les bouts de code qu'il juge parfaitement inutile, genre les mises à zéro de segments mémoire, y compris avec -O0. Intéressant pour les bouts de code qui travaillent avec des lib de crypto.

sans compter la qualité exécrable du code Altivec ou SSEx qu'il génére :s

hum... pourtant j'avais précisé :

 
Mais en plus l'écart doit être + important entre VC2008 et le GCC actuel qu'entre VC6 et GCC 2.9
Je me retrouve à défendre un compilo que j'utilise presque jamais, mais je trouve qd même que ses messages d'erreurs sont plutôt bien fait, et j'ai été surpris par certains warning comme avec des %s pour lesquel j'avais passé une std::string plutôt qu'un char*. Par contre je préfère en général les messages de VC++.
Après j'en ai pas fait une utilisation assez poussée pour atteindre ses limites.

tu les sens des que tu fait quelque chose qui sort de la apire ppc/x86

hop: http://www.artima.com/weblogs/view [...] ead=252441

hum j'ai un peu le sentiment après la lecture de cet article, de n'avoir strictement rien appris, très stérile. Enfin il y est quand même fait mention du designed de merde de ce langage lol

duquel ? car il bache plus JAVA que C++
et bon, puisque tu dis que c'ets de la merde, on t'attend vas y design un langage et on en reparle

Non c'est pas mon avis, moi perso je trouve le C++ beaucoup plus fun que n'importe quel autre langage, total liberté, multi paradigme, performance etc etc

Tu en connais combien, d'autres langages?

de tête je pourrais citer les suivants:
java
clips
prolog
c
plus les petits amuse bouche style vba php python javascricpt

<troll> php c'est un langage ???</troll>

<troll>non c'est une plateforme</Troll>

bon je lurke ce topic c ets surtout pas pour entendre parler de php hein

C'est weblook, t'es pas censé lire ce qu'il écrit.

lol il a pas aimé que je taille son lien

Si t'appelles ça tailler, évite de "tailler" des gens IRL parce que ton estime de toi en prendrait un coup violent

ok

c ets très sensé quand on applique la loi de pratchett aux lol
/me retourne lurker

Un peu choqué de voir Python considéré comme un amuse-bouche, et encore plus de le voir relégué au même plan que VBA, php et Javascript  

c'est un langage de script impératif quoi, tu trouves la diff si énormissime que ça ??

Pour en revenir au sujet, des librairies comme QT4 montrent que l'on peut faire de très belles choses avec le C++

C++ n'est pas du tout un mauvais langage, et C++ fait toujours encore parti des langages les plus utilisés, le probleme c'est que le standard C++ contient beaucoup moins que ce que l'on peu trouver aujourd'hui dans Java ou dans C#. Pour certains développeurs cela ne pose aucun soucis, pour d'autres pour obtenir l'équivalent de la richesse qu'on peu trouver en standard sur Java ou C# il faut en effet en plus faire l'effort de sélectionner une librairie ou un framework, comme par exemple Qt qui est très bien en effet. Bref Java et C# c'est en gros des solutions complètes clef en main, alors que pour avoir l'équivalent de Java ou C# en C++ il faut sélectionner des choses en plus...

Sur ce sondage sur les langages de programmation, on peu voir que le trio de tête c'est apparemment Java, C# et C++.

Il n'y a pas que ça, il y a surtout le fait que même si C++ est très utilisé, finalement assez peu de monde maitrise réellement le langage. Et comme il est très puissant, au sens où il permet de faire pas mal de bidouilles qui ne sont pas possibles ne serait-ce qu'en Java, on se tire plus facilement une balle dans le pied. C'est toujours le même problème: donnez un outil puissant à un crack, il en tirera des merveilles, donnez le même outil à qq qui ne sait pas s'en servir, il jouera à l'apprenti sorcier avec et pondra une ...(mettez ce que vous voulez ici). Or partant du constat que les cracks sont moins nombreux que les neuneus, Gosling et cie ont inventé un langage volontairement limité nommé Java.
Je me souviens des critiques faites à ce langage à ses débuts (du temps de la 1.0 à 1.2), les flamewars emplissaient les forums. Les perfs du langage étaient en particulier très critiquées. Au fur et à mesure des versions, les critiques faites à Java ont nettement baissé.
Perso, malgré ses limitations, j'aime bien Java et je trouve que le compromis entre features et limitations est assez bon. S'il y a au moins une feature que Java a et qui manque singulièrement à C++, c'est bien l'introspection. On ne mesure pas suffisamment tout ce qu'apporte cette seule feature, alors qu'en réalité pratiquement pas une seule lib reconnue du monde Java n'existerait sans celle-ci.
Perso, je suis pas fan de C++ pour le travail, parce que j'ai vu quelques bouses faites avec. J'ai aussi bossé sur un très bon produit fait avec. Mais il faut admettre que, d'une part le niveau moyen de l'équipe était supérieur à d'autres, et d'autre part, le processus de développement impliquait de la revue de code presque systématique (le niveau de l'équipe n'était d'ailleurs pas étranger à cela, la pratique de la revue de code permettant aux développeurs de s'améliorer plus rapidement). Donc pour moi, c'était plus l'exception plus que la règle. Après, pour les projets perso où le temps n'est pas trop compté, c'est différent. Mais alors, je crois que si j'avais le choix, je développerais plutôt en D.

J'avoue qu'à la lecture du très intéressant article ici, j'ai l'impression qu'on va droit dans le mur
 
Ce genre de feature, ça va être super, seulement ça manque de quelque chose d'automatique pour l'usage quotidien (par exemple en C# pour une relation de comparaison, il suffit de faire un == et ça roule. Oui je sais y aura toujours boost, mais bon, dans beaucoup de projet, j'ai du mal à faire rentrer boost qui n'a pas que des qualités).

Quel est l'inconvénient principal, qui fait que tu choisis de ne pas rentrer Boost dans beaucoup de tes projets ? Trop de fichiers à inclure ?