Je ne connais personne qui code en C++ sans EDI ou éditeur avancé style Vim/emacs.Envoyé par Klaim
Je trouve que c'est une bonne chose d'éliminer les redondances dans le code.
Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Je ne connais personne qui code en C++ sans EDI ou éditeur avancé style Vim/emacs.
Je trouve que c'est une bonne chose d'éliminer les redondances dans le code.
Cours : Initiation à CMake
Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
Ce message a été tapé avec un clavier en disposition bépo.
C'est ce que j'appelle "le cas normal".Je ne connais personne qui code en C++ sans EDI ou éditeur avancé style Vim/emacs.
Je dis que c'est naïf parcequ'il arrive que tu ais du code a toucher sans avoir d'editeur sous la main ou encore parcequ'il y a un probleme avec l'editeur (par exemple eclipse).
Après tout, les languages de programmation sont fait pour l'homme d'abord, avant les outils.
A priori non, personnellement je n'ai vu que des jeux et applications amateur en D. C'est déjà pas mal.Ça commence à être utilisé dans l'industrie, le D ?
Le problèmes c'est qu'en plus, c'est hors jeu pour tout ce qui est informatique de gestion :
- Pas d'API SGBD
- Pas d'API pour imprimer, même basique
- Librairies GUI en peau de banane
- IDE en tôle ondulée (rouillée)
Bref, D a aucune chance de se démarginaliser s'il se borne à des applications console sans interface graphique. La meilleure façon de remédier à cela serait que les contributeurs décident ensemble d'un unique IDE et qu'ils focalisent leurs efforts dessus. Ca permettrait à terme d'avoir un outil puissant et des fonctions avancés (visual designer, unit test, documentation etc..).
On est dans le scénario catastrophe typique où tout le monde fait un projet dans son coin qui se meurt après 1-2 ans, au lieu de se recentrer autour d'un outil spécifique qui s'imposerait comme standard.
Je ne pense pas que ce soit un cas catastrophique parceque le language évolue et qu'au moins pas mal de gens l'essayent. Effectivement il manque des choses pour qu'il soit plus utilisé en industrie, mais comme il faut en moyenne 10 ans pour qu'un language arrive a maturité (commence a être sérieusement utilisé) ben on peut dire que c'est plotot bien partie si il y en a qui font déjà des jeux en OpenGL (la première fois que j'ai entendu parler de D c'était a cause d'un shoot experimental).
Pour l'ide, je sais pas si c'est l'idéal de se concentrer sur un seul, je me dit que Code::Blocks + Eclipse ça serait mieu (histoire de couvrir l'ensemble des utilisateurs potentiels).
Eventuellement une implémentation d'entreprise (genre Microsoft) serait a mon avis plus efficace( surtout en exploitant un VisualStudio, comme ils ont fait avec IronPython par exemple, ou encore F#).
Dans tous les cas on y est pas encore, c'est sur.
Pour les libs d'impression etc, effectivement ce qui manque le plus c'est toutes les libs auxquelles on a accès en C++. Ya peu de bonne raison de les produires pour les vendeurs, a parti si un marché se crée (dans le jeu vidéo? pourquoi pas mais c'est un milieu qui a du mal a évoluer techniquement hors rendu graphique et IA...).
En tout cas ya pas mal de features interessantes et d'autres que je trouve étrangement pas très logique. A voir comment ça évolue. On devrait aussi parler de Go de google qui entre dans la même catégorie de langauge (système). Après tout ce sont les deux potentiels challenger dans cette catégorie (même si ça dépends des 10 ans a venir).
Il n'y a pas de lib C pour tout ça ?
Il m'a bien semblé lire que D pouvait s'interfacer avec le C avec assez peu d'effort.
Cours : Initiation à CMake
Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
Ce message a été tapé avec un clavier en disposition bépo.
C'est exact.
Donc on doit avoir un certain nombre de libs disponibles ?
Un binding D de GTK, par exemple, doit être possible ?
Après une petite recherche, il semblerait que ça existe : http://www.gtk.org/language-bindings.html
Cours : Initiation à CMake
Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
Ce message a été tapé avec un clavier en disposition bépo.
Oui, mais ça reste très limité comparé au nombre de libs dispo pour C++.
Mais effectivemetn ya "au moins" la compatibilité avec le C.
Es ce difficile d'utiliser des dll C++ avec D?
Par exemple en utilisant gdc avec une lib c++ compilé avec gcc, ça devrait passer non?
Appeler du code C++ depuis du code D ne serait que la partie émergée de l'iceberg : Pour utiliser confortablement du code C++ depuis un autre langage, il faudrait aussi pourvoir dériver d'une classe C++ et redéfinir des fonctions virtuelles, avoir un modère de gestion des ressources compatible, être capable de transmettre les exceptions entre les différents langages dans les deux sens...
Pour avoir fait pas mal de C++/CLI pour interfacer du C++ et du C#, je peux dire que sans ces aspects, l'interfaces entres langages demande des efforts très importants, probablement trop pour que je jeu en vaille la chandelle dans nombre de cas.
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
Bien sûr mais comme dit JollyLoic c'est pas forcément un choix sans risques. Les développer toi-même est vraiment assez risqué alors que d'autres technos t'offrent ça out-of-the-box avec des outils d'édition à l'appui.
En ce qui concerne les IHM, il existe déjà des bindings sur GTK et wxWidgets, également Qt. Mais je fais difficilement confiance à des projets qui reçoivent un commit tous les 6 mois (j'exagère un peu) et qui n'ont pas de roadmap clairement établie. Si tu devais te retrouver bloqué et être livré à toi-même sans support à cause d'un bug, ce serait un sacré coup dur sur tes délais.
Idem pour l'aspect SGBD, as-tu réellement envie de développer un binding sur les libs C de postgres ou mysql alors que java ou .Net t'offrent des drivers testés et activement développés? Avec en plus toute une palette d'ORM éprouvés?
Ce que je veux dire, c'est que je ne dis pas que les choses sont impossibles avec D, si on se base sur des bindings C, tout est possible. Simplement que c'est pas un choix facile par rapport aux risques et au travail supplémentaire que cela engendre.
Oui, ça explique effectivement bien pourquoi une adoption de D par l'industrie est pour l'instant impossible.
Il faudrait qu'une entreprise influente s'y intéresse, ou bien (comme ça a pu être le cas pour Python) que la communauté du libre l'adopte de façon significative pour que le langage ait un avenir industriel.
Plus d'info sur le sujet : http://stackoverflow.com/questions/2...-have-a-future
Plus je progresse en C++, plus je me dis qu'on a besoin d'un successeur de ce langage qui commence à devenir quelque peu overbloated.
Je m'en vais feuilleter le bouquin d'Alexandrescu pour voir à quel point D mériterait d'être évangélisé…
Cours : Initiation à CMake
Projet : Scalpel, bibliothèque d'analyse de code source C++ (développement en cours)
Ce message a été tapé avec un clavier en disposition bépo.
Personellement, je pense que D a de très bonne idées, et d'autres moins bonnes, mais tant que je n'ai pas tout lu le bouquin, je n'aurais pas tous les arguments des créateurs.
Selon moi quelque chose plus proche de C++ mais avec certaines feature du D (thread-local par défaut + shared , différence concrète et utile entre struct et class, modules...) serait encore plus interessant que le D.
Il faudrait aussi que la communauté D s'affiche et cesse de se disperser dans tout un tas de projets foireux :
http://dsource.org/forums/index.php
Ca manque gravement de coordination tout ça...
si le D avait un cross-compiler c'est presque sur que je développerais avec
mais je ne crois pas qu'il y ait un cross-compiler D pour mips, arm ou powerpc, malheureusement
Oui justement l'arrivée du D2.0 était censé remettre certaines pendules a l'heure mais je ne pense pas qu'on puisse voir immédiatement l'effet. Il va falloir voir comment ça évolue dans les mois (voir années) a suivre.
Il me semble que gcc utilise un pseudo-langage intermédiaire (un peu comme le CIL) pendant la compilation et que les binaires étaient compatible. De plus, je n'ai pas vue de choses qui était incompatible entre le D et le C++ qui empêcherais une classe D d'hériter d'une classe C++.
Mais bon, je ne fais que supposer.
Es ce que l'on ne pourrais pas imaginer un équivalent de boost.python pour D ?
Disclaimer : Je n'ai jamais fait de D, j'ai juste lu quelques articles.
J'ai l'impression que le modèle objet n'est pas le même, par exemple l'absence d'héritage multiple doit pas mal influencer la manière dont les fonctions virtuelles sont gérées...
En cherchant d'autres exemple, je suis tombé sur :
Features To Drop
Link compatibility with C++. The C++ runtime object model is just too complicated - properly supporting it would essentially imply making D a full C++ compiler too.Je n'ai pas utilisé boost.python non plus. Je pense qu'on doit pouvoir arriver au même genre de fonctionnalités, avec le même genre de limites, qui impose d'écrire pas mal de code intermédiaire (par exemple :
http://www.boost.org/doc/libs/1_44_0...tual_functions)
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
C'est le moins qu'on puisse dire :
- pas d"héritage multiple
- struct et class sont radicalement différent (sémantique de valeur et sémantique d'objet, respectivement) - ça pose des problèmes avec les objets c++;
- le compilo définit à la compilation si il y a besoin de virtualité sur un fonction membre, ou pas - non-précisé par l'utilisateur
- garbage collector par défaut (mais pas de vm)
- thread-local par défaut...
En gros je vois pas comment les deux languages peuvent être directement compatible. Au mieu, on pourrait pouvoir manipuler un pointeur vers un objet C++ et appeler des méthodes... et encore je suis pas sur qu'il n'y aurait pas des complications.
Donc en gros on pourrait au mieux faire pour D un truc comme C++/CLI est fait pour le C#.
Et d'expérience, même si c'est fonctionnel, c'est lourd, c'est peu élégant, et c'est une source de bugs.
Ma session aux Microsoft TechDays 2013 : Développer en natif avec C++11.
Celle des Microsoft TechDays 2014 : Bonnes pratiques pour apprivoiser le C++11 avec Visual C++
Et celle des Microsoft TechDays 2015 : Visual C++ 2015 : voyage à la découverte d'un nouveau monde
Je donne des formations au C++ en entreprise, n'hésitez pas à me contacter.
Répondre avec citation
Partager