ce topic est tres intéressant, mais bien trop complexe pour des débutants en C++
alors allons au plus simple:
conseillez vous d'apprendre le C++ actuellement, ou bien le C++ devient un langage mort?
Version imprimable
ce topic est tres intéressant, mais bien trop complexe pour des débutants en C++
alors allons au plus simple:
conseillez vous d'apprendre le C++ actuellement, ou bien le C++ devient un langage mort?
Le C++ est loin d'être un language mort puisque c'est le principal language utilisé dans les industries embarquées et les développements de systemes de base comme les OS. (et les jeux vidéos - console oblige)
En fait dés qu'on sort de contraintes fortes, pas mal de languages (principalement des languages dis "dynamiques") peuvent être utilisés de manière tout aussi efficaces ou même tout simplement plus rapide en temps de production.
Mais avec ces contraintes (rapiditée d'execution + mémoire réduite), le C et le C++ sont rois.
Sinon, le souci actuel d'un point de vue du débutant, je pense, c'est que le prochain standard devrait apporter pas mal de choses simplifiant le code, mais ajoutant aussi sont lot de choses à connaitre.
Mais de toutes manières le temps que l'on passe au nouveau standard, un débutant aujourd'hui aura eu le temps (si il pratique souvent) de se familiariser avec une bonne partie du language.
Enfin, notez que Stroustrup (avec d'autres il me semble) a écrit un bouquin spécialement pour les débutants et il sortira en aout. Au vu de la préface, l'ordre dans lequel les points sont abordés est surprenant, donc je suis curieux de le lire. Peut être une future référence.
Un petit article interessant au passage:Citation:
Envoyé par deubelte
http://trolltech.com/company/tt/cont...r-06/article01
Les windows xp,vista sont codés en C/C++?Citation:
Le C++ est loin d'être un language mort puisque c'est le principal language utilisé dans les industries embarquées et les développements de systemes de base comme les OS.
En partie, il me semble, oui.
Il faut bien se rendre compte que, dans un système d'exploitation, il y a quantité de choses qui sont impossibles à gérer s'il faut passer par une machine virtuelle (java, par exemple) ou par un interpréteur MSIL ou autre, pour la simple et bonne raison que la gestion de ces choses doit commencer bien avant que le système ne soit justement en mesure de disposer des dits interpréteurs...
On peut, bien sur avoir un débat des plus houleux concernant l'utilité de travailler "bas niveau" alors que des alternatives de plus haut niveau ou plus "abstraites" existent, mais il faut en tout cas garder en tête le fait que, pour atteindre le sommet, il faut bien commencer par escalader la base.
Dés lors, il apparait certain que les langages qui peuvent être considérés comme étant de "bas niveau" dans le sens où "ils se suffisent à eux-même" - fussent-il orientés objets à l'instar du C++ - continueront à représenter une des pierres d'angle de la programmation ;)
Quand on parle de l'utilite du C++,on en revient systematiquement a parler rapidement developpement d'OS, de drivers, de machines virtuelles, de compilateurs, etc... Bref, de projets hyper complexes sur lequel le commun des mortels ne travaille pas. Pour moi, c'est falsifier les choses de restreindre le C++ a ces domaines, qui sont marginaux. Il s'agit la de domaines tres specifiques et minoritaires.
Clique sur ton menu demarrer, regarde la liste de tes programmes, la grande majorite sont developpes en C++. Le C++ reste quand meme un des langages de predilection pour les applications desktop. On a une communaute Qt et boost qui ne cesse de grandir, pour moi le langage a encore un bel avenir.
Je me suis mal exprimé...
Ce que je voulais dire, c'est que, quoi qu'il arrive, et même si on en venait à n'utiliser C++ que pour cela, il faudra toujours des langages compilés, capables de travailler de manière très proche du système.
De plus, même s'ils finissent par prendre des segments "de niches" on remarque que la grosse majorité des langages qui ont provoqué l'écriture de nombreuses lignes de code continuent malgré à exister, malgré une certaine "obsolecence" avérée ou imaginaire (je pense à des langages tels que COBOL, Ada et autres, qui sont toujours utilisés de nos jours)
En outre, les communautés C et C++ continuent d'écrire du code en masse, et il existe énormément de projets importants qui utilisent ces langages.
Enfin, je fais partie de cette sorte de gens qui trouvent dommage qu'un langage décide d'interdire une manière de faire sous prétexte que "son utilisation est dangereuse", et qui apprécient donc la grande liberté (y compris celle de me tromper) apportées le C++, par comparaison à d'autres langages plus ou moins "aseptisés" dans lesquels on en arrive à ne pas s'inquiéter outre mesure de la libération des ressources et autre "déresponsabilisants" similaires.
Mais ce n'est bien sur qu'un avis personnel, qui ne m'empeche en outre pas d'envisager l'utilisation d'autres langages pour certains objectifs particuliers
Je suis en moment comme 1 petit cheveu dans la soupe, je n'apporterai peut être rien à ce sujet mais c'est pour dire que je le suis avec passion ctte discussion, je suis novice dans la programmation et fais des progrés grâce à ces lectures merci et continuez.:P
coolD
salut tout le monde;
grossomodo on va faire le menage dans la STl et simplifier les chose comme avec java et ensuite les programme écrit seront aussi lourd ,
Ooooooooh là non pas du tout :)
La SL (pas STL) va être renforcée avec énormément de choses : de quoi gérer les fonctions comme des objets "ordinaires", ce qu'il faut pour le multithreading, les pointeurs intelligents et bien d'autres choses.
Le langage quand à lui va permettre bien plus de choses au niveau de la programmation générique, il va désormais permettre de mettre en oeuvre la sémantique de mouvement, etc...
Je te conseille de suivre l'index C++ (http://cpp.developpez.com/) car nous essayons de publier un maximum de choses au sujet de la prochaine version de C++.
Et en aucun cas les programmes vont être alourdis... Donc le C++ ne tend absolument pas à devenir comme Java. L'objectif du comité est de palier aux manques du C++, d'arranger ce qu'on a pu lui reprocher jusqu'aujou'd'hui, et de fournir un maximum d'outils/classes/modules de manière standard pour faciliter la vie des programmeurs C++.
salut;
j'epère que ça ne sera pas une révolution et que c'est juste une évoltion.
Mais bon je pense que l'equipe de rédacteur de developpez.com vont nous donner les moyens et les conseil necesaire pour réapprendre ces nouveaux concepts
voila merci
Ben tu as déjà un aperçu...
http://blog.developpez.com/alp?title...adic_templates
http://loic-joly.developpez.com/tuto...mart-pointers/
Et de manière générale, abonne-toi au RSS du blog C++ car on compte bien publier pas mal de choses là-bas et sur http://cpp.developpez.com/ .
Mais rien que maintenant tu as déjà de quoi lire, entre les liens ci-dessus et en cherchant "C++0x" sur le forum C++ ;)
Salut;
grossomodo le C++0x va nous ramener a ne plus se soucier des desallocation memoires, et vas entrer dans l'age d'or des templates, comme l'etaient les classes avec le c++ ce qui donnera plus de libértés
a propos, c'est c++ est du c potincrémenté, le 0x siginfie quoi ?
Le 0x c'est comme le 98 dans C++98... C'est l'année où est publiée officiellement la norme. Ici, on ne sait pas encore, d'où le 'x'. Mais si tout va bien, le x se transformera en 9 ;)
Et si l'on résumer grossièrement la situation, oui C++0x c'est un peu ça.
On peut déjà ne plus se soucier des allocs/désallocs... Mais ce n'est pas dans la bibliothèque standard, c'est dans Boost, Loki ou autres. Dans C++0x, ce sera dans la bibliothèque standard.
Mais il y a tellement plus...
Tu peux te faire une très très rapide idée de ce qu'il y aura de nouveau avec cet article : http://www.artima.com/cppsource/cpp0x.html .
Ca me fais penser que récemment les détails concernant les Concepts et Concept Maps ont été rajouté sur la page wikipedia concernant C++0x.
Vu toutes les possibilités (héritage, combinaisons, template etc), les concepts et concept_map vont a mon avis rendre tout ce qui est template tellement plus simple....
Les fonction lambda aussi d'ailleurs. Je suis impatient de tester un compilo avec toutes ces features d'intégrées!
Pour le moment, il y a conceptgcc et g++ 4.3 et plus récents qui intègrent quelques petites choses... Mais rien d'exceptionnel encore.
Oui, d'ailleurs je me dit qu'il y a une chance pour que le prochain compilo de microsoft soit plus avancé. Le peu que j'ai lu dessus laisse présumer qu'ils bossent a fond avec l'optique du prochain standard.
Par contre il est quand même prévu pour la fin de l'année prochaine... date ou sera officialiée a priori c++0x (mais le Darft devra être pret pour septembre de cette année...)
Effectivement. Mais ça rentre un peu en contradiction avec la place importante de C++/CLI. On va voir quelles vont être leurs priorités et donc par conséquent à quel point ils vont coller à la prochaine norme, mais _surtout_ quand est-ce qu'ils vont y coller.
Hélas il semblerait que ce soit plutôt 0xA !Citation:
Envoyé par Alp
http://www.open-std.org/jtc1/sc22/wg...008/n2705.htmlCitation:
Envoyé par State of C++ Evolution (Mid-term 2008 Mailing)
Tiens :(
Il y a quelques jours encore, j'avais lu que la publication étaient prévue fin 2009.
Pfff, quand même je trouve ça mou.
Ils peuvent pas lever des fonds pour que ça aille plus vite franchement, avec tous les réseaux et partenariats d'entreprise qu'ils ont ?
----
Deuxièmement, je vais peut-être m'avancer un peu trop.
Je remarque que souvent, ils apportent beaucoup de correction au niveau syntaxique, au niveau des règles, ce qui est illégal ou légal d'écrire.
La manière dont ils font ça me fait penser que c'est expérimental, empirique et pas très rigoureux.
Pourtant, le C++ dispose d'une grammaire, donc on peut appliquer les théorèmes et propriétés en théorie des langages, au moins partiellement !
Donc on peut raisonnablement penser qu'en spécifiant bien les prédicats, il soit possible d'en déduire une règle qui marche une bonne fois pour toute, à l'erreur de démonstration près !
En même temps, vous me direz, la grammaire du C++ est tellement horrible que...
D'un autre côté, regarde la complexité de la chose !
Il faut garder dans une certaine mesure une syntaxe de type C, on ne peut pas aller trop loin sinon ça deviendra un tout autre langage.
Après, faut qu'on reste compatible C++98 et même normes précédentes.
Le tout en essayant de fournir des outils pratiques et efficaces aux programmeurs C++.
Bref si il y a un comité qui bosse sur ça et des milliers de gens qui apportent leur pierre à l'édifice c'est que ça ne doit pas être si simple que ça :aie:
Et puis ne parlons pas du fait que les compilos doivent pouvoir suivre assez vite :aie: Je me demande bien comment ça va se passer pour C++0x là...
Justement, c'est complexe, c'est pourquoi je disais que pour ça, raisonner formellement et directement sur la syntaxe/grammaire permettrait potentiellement d'aller plus vite, de faire moins d'erreurs.Citation:
Envoyé par Alp
Assisté par ordinateur bien évidemment.
Il y a des milliers de gens qui apportent leur pierre, mais la grande majorité le font pendant leur temps libre, ou de manière bénévole.Citation:
Envoyé par Alp
C'est juste au niveau gestion de projet que je critiquerais.
Ok. Bon c'est clair qu'on peut redire sur la gestion du "projet C++". Mais les choses se concrétisent progressivement. De toute manière, d'ici peu, les compilos sauront exactement ce qu'ils ont à faire. Retarder de quelques mois la publication officielle ne changera pas grand chose pour eux.
C++ tient à ne pas se rapprocher des théories des langages, logique et sémantique et à rester un langage de programmation pragmatique.Citation:
Pourtant, le C++ dispose d'une grammaire, donc on peut appliquer les théorèmes et propriétés en théorie des langages, au moins partiellement !
Ayant moi-même fait de l'info théorique en quantité non négligeable (j'ai fait une année à l'ENS) je trouve qu'ils ont raison.
C"'est une conclusion de la dernière réunion. Les processus ISO a des délais importants, qui s'ajoutent aux délais nécessaires pour faire un bon standard.
D'où l'idée de publier un "brouillon officiel" pour revue aux différents membres plus tôt (revue finie en 2009), brouillon qui aura encore surement plein d'erreurs de détail, mais sera globalement fini, et sur lesquels les implémenteurs pourront se baser avec sérénité, sans risque de voir leur travail réduit à néant lors d'une modification ultérieure.
Par contre, la version finalisée officielle sera effectivement prévue plus tard (200A ?).
Mais je ne lui reproche pas son côté pragmatique.Citation:
Envoyé par loufoque
C'est juste que quand bien même sa grammaire est plutôt imparfaite niveau théorie des langages, il y a quand même des invariants à maintenir, au niveau de la norme du C++.
Des ambigüités qu'il faut lever ou non.
Et ça, même si sa grammaire est très pragmatique, peu uniforme, ça doit sûrement pouvoir être vérifié rigoureusement.
D'un côté, on se farcit aussi l'héritage de certaines parties du C assez peu jolies, ce qui explique certaines choses.
Mis a part quelques ajouts, je ne vois que des réduction des ambiguitées justement.Citation:
C'est juste que quand bien même sa grammaire est plutôt imparfaite niveau théorie des langages, il y a quand même des invariants à maintenir, au niveau de la norme du C++.
Des ambigüités qu'il faut lever ou non.
Les concepts et concept_map pour clarifier tout ce qui est template (rendre les erreurs de compilo explicites et permettre de contourner les problèmes des "mots"), l'initialization unifiée pour rendre les initialization pareil partout (et du coup plus claires, même si les autres façons d'initializer sont toutjours là), les fonctions lambda pour ne plus avoir a écrire des class fonctors, etc...
Au final, c'est surtout dans la STL/SL qu'il y a des ajouts.
Mais globalement je me dit qu'il se peut qu'au début les débutants aient plus de mal parcequ'on tentera de leur apprendre plus de choses que nécessaire, parceque nous même ne seront pas encore habitué aux nouvelles facilitées du language.
Il faudrait déjà pour commencer qu'on commence à enseigner aux débutants actuels le vrai C++ actuel, avant de se pencher sur l'enseignement de C++0x... :aie:
Sinon, la nouvelle syntaxe de déclarations de fonctions, c'est pas mal, mais j'la trouve très laide :mrgreen:.
C++ est défini par des mots et des phrases.
Pour pouvoir appliquer des théorèmes etc, il faudrait le décrire avec des règles d'inférence.
Venant de la communauté "langage fonctionels", je vais juste faire un petit commentaire à ce niveau : Un certain nombre de langage "grand public" ont integré plusieurs de trait issus des langages fonctionnels. Je pense en particulier à python (et sans doute plein d'autres) ou il est très simple de faire une liste de fonction, une lambda abstraction, etc.
On a l'impression que pour C++0x, ils se sont dit qu'il fallait peut être faire pareil, ont commencé... et se sont arreté en cours de route ! Ok, on a maintenant une notation (assez horrible) pour faire une fermeture, où l'ont doit spécifier à la main quelles sont les variables que l'on copie et celle dont on garde juste la référence (obligatoire si l'on veut retourner la fonction, puisque la gestion de la mémoire se fait manuellement et que l'utilisation d'une variable dans la pile serait problématique.). Mais là, bam, on ne donne pas de type pour les fonctions, c'est compilo-dépendent (page 85 du draft de mai 2008) ! Alors on fait quoi de notre fermeture ? Si on n'en a pas le type, on ne peut pas la mettre dans un tableau, la retourner, la passer en argument... On perd tout intéret à avoir des fonctions annonymes. Je ne comprends vraiment pas pourquoi ils se sont embeter à ajouter ça au langage...
(Il faudrait que je revoie ca, mais bon le temps me manque).Citation:
Envoyé par alex_pi
L'utiliser dans les contextes ou le type est deductible. Je suis d'accord ca limite l'utilite, mais il me semble que ca couvre les cas d'utilisations les plus courant tout en prevenant les cas incompatibles avec les modeles d'implementation courants.
IdemCitation:
Envoyé par Jean-Marc.Bourguet
Il me semble qu'on peut initialiser un std::function avec une telle expression, non ?
Ca devrait, c'est un contexte deductible il me semble.Citation:
Envoyé par JolyLoic
(Ce qui me fait penser que ma premiere idee -- limiter la complexite d'implementation -- est fausse -- il faut vraiment que je relise cela pour voir comment la capture se fait et ce qui se passe apres le retour de la fonction; est-ce que c'est simplement des "upward closure" ou bien est-ce qu'on passe dans le domaine indefini ou bien on fait du GC sur les stack frames; je pensais a la premiere, je penche maintenant vers la seconde).
J'avais lu le draft et je crois bien que c'est le cas oui.Citation:
Envoyé par JolyLoic
Avec quand même le cas notable ou si la liste de capture n'est composée que de références, la fermeture est du type reference_closure<R(P)> (ou P est la liste des paramètres), une classe qui a un comportement défini (cf [func.referenceclosure], section 20.6.17 du dernier draft (pdf)).Citation:
Envoyé par alex_pi
En même temps, les closure ont été principalement ajoutées pour simplifier l'écriture de programmes utilisant les algorithmes de la CSL. Exit l'écriture de foncteurs pour résoudre des problèmes aussi simple qu'un test sur un des membres de la classe:
Dorénavent, on pourra écrire le code de manière beaucoup plus compacte:Code:
2
3
4
5
6
7
8
9
10
11
12
Le code est largement lisible une fois qu'on a identifié qu'il s'agit d'une closure. On a pas besoin de définir une fonction ou un foncteur externe (donc un gain appréciable de temps), et le debuggage est simplifié puisqu'on a le code sous les yeux. L'utilisation des algorithmes de la CSL s'en trouve grandement simplifiée (à mon sens).Code:
2
3
4
5
6
7
8
9
10
J'avoue que j'aurais aimé que le standard soit capable de typer l'objet fermeture qui est créé dans ce cas. On peut toujours utiliser les traits pour obtenir quelques informations, mais on est rapidement limité par les possibilités offertes par le système. La seule information qu'on a, c'est qu'un objet fermeture est callable - ça ne vas pas très loin... Exit donc l'écriture élégante de delegates simples (à défaut de pouvoir spécifier le type des delegates...).
Dans l'idée, même si on peut initialiser un std::function<T> avec un objet closure, il n'en reste pas moins que T est indéfini et inconnu, donc on ne peut définir d'objet de ce type (à moins de la stocker dans une variable définie comme étant du type "auto").
De plus, rien ne définit dans le standard que deux closure ayant la même liste de capture, les même paramètres et le même type de retour sont du même type.
En ce qui concerne la notation généralisée pour la définition de fonctions, j'avoue que j'ai un faible pour elle. Elle est très mathémique, dans le sens ou on définit une fonction auto F (S) -> S', ou S et S' sont respectivement le domaine d'entrée et le domaine de sortie de la fonction. Ca me plait plutôt bien. On est pas loin de la notation mathématique usuelle F : S -> S'. Bon, ok, je trouve la présence du mot-clefs auto et le wording du draft courant à ce sujet assez perplexants...
A noter que Herb Sutter a annoncé il y a déja un mois et demi que le premier draft "final" sera proposé en septembre. Il n'y a aucune chance d'avoir une ratification du standard en 2008, mais il n'est pas impossible que le standard sorte quand même en 2009 - comme prévu.
Justement, ce qui serait bien c'est que l'on puisse écrire des fonction à la "remove_if", attendant une fermeture en argument, pas juste les utiliser ! Mais peut être que l'on peu avec auto ? (malheureusement, on ne peut pas tester ;-))Citation:
Envoyé par Emmanuel Deloget