Discussion :

[Altess]

Bonjour,

Personnellement, je pencherais plus pour l'IDE Visual Express 2008 téléchargeable gratuitement. Il est puissant, simple, ultra-documenté, et en plus, en français (aussi bien la documentation MSDN, que le logiciel lui meme. C'est à mes yeux le meilleur editeur gratuit actuellement.

Je dit actuellement, car j'ai entendu parler d'un IDE spécifique à Qt (actuellement en bêta sur leur site). Connaissant la puissance de Qt, et son passage au LGPL avec la 4.5, je suis persuadé que ça va faire du bruit, et au passage, de l'ombre a notre (mon) ami VC++

Après, chacun ses gouts hein

[white_tentacle]

Je dit actuellement, car j'ai entendu parler d'un IDE spécifique à Qt (actuellement en bêta sur leur site). Connaissant la puissance de Qt, et son passage au LGPL avec la 4.5, je suis persuadé que ça va faire du bruit, et au passage, de l'ombre a notre (mon) ami VC++

Je l'ai téléchargé, je l'utilise un peu, et... je ne suis pas super convaincu.

Ce n'est pas un mauvais ide, loin de là. Mais pour l'instant, c'est surtout un IDE de plus. L'auto-complétion n'est pas top, l'intégration du debugger, pas gégé. Il manque encore beaucoup de choses (support doxygen notamment, aussi bien dans la coloration syntaxique que dans l'ide). Obligé de modifier le fichier projet à la main pour rajouter des libs QT aussi (dbus, par exemple), et non QTs, qui manquent dans l'interface (très bête, ça, il manque un champ libre).

Cela dit, c'est un projet prometteur.

[superjaja]

j'ai un probleme avec CodeBlocks , j'ai crée un projet en C++ pour essayé au debut et pas defaut il m'a crée un fichier Main.C :
j'ai compilé et fait Run le code marche je quitte Codeblocks et je lance l'exe qui aété crée pour essayée et quand je lance le fichier .exe
la fenetre se referme tres vite et impossible de lire le texte . il ya t'il un parametre a rajouter au code .

Code zoltars43 :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
#include <iostream>
 
using namespace std;
 
int main()
{
    cout << "Hello world!" << endl;
    return 0;
}

Au passage tu veux apprendre le C ou le C++ ?
Car si tu veux faire du C les fichier on une extension .c et c++ .cpp.

Il y a beaucoup de difference entre le C et le C++ et si tu veux faire des fenetre tu peux les faire soit en C ou en C++ c'est pas un probleme. Un autre truc super important, selon quelle est ta cible (sur quel OS va etre executer ton prog) on fait pas des fenetres de la meme façons en general...

C'est bien de commencé avec du code genre programme DOS les GUI c'est beau mais c'est relativement lourd a gérer....

[Invité]

Bonjour,

Personnellement, je pencherais plus pour l'IDE Visual Express 2008 téléchargeable gratuitement. Il est puissant, simple, ultra-documenté, et en plus, en français (aussi bien la documentation MSDN, que le logiciel lui meme. C'est à mes yeux le meilleur editeur gratuit actuellement.

Je dit actuellement, car j'ai entendu parler d'un IDE spécifique à Qt (actuellement en bêta sur leur site). Connaissant la puissance de Qt, et son passage au LGPL avec la 4.5, je suis persuadé que ça va faire du bruit, et au passage, de l'ombre a notre (mon) ami VC++

Après, chacun ses gouts hein

oui ma Visual Express 2008 utilise le framework et j'aime pas du tout

[koala01]

Le problème, c'est que C++ a décidé une bonne fois pour toute (ou du moins, si cela vient à changer, ce ne sera pas avant la norme qui suivra C++0x) de ne pas proposer de bibliothèque graphique en standard.

Si tu veux pouvoir faire "de zolies interfaces", il n'y a pas à discuter, il faut passer par une bibliothèque tierce.

En gros, les possibilités sont:

• le framework "microsoft"
• Qt
• WxWidget
• éventuellement SDL
• OpenGl
• d'autres que j'aurais oubliée

Il faut savoir que ces différentes possibilités ont toutes des avantages et des inconvénients, et que le fait de les aimer ou non dépend très fortement des égouts et des couleuvres de chacun

Il me semble juste de dire que, si tu veux travailler avec Visual Studio, il vaut mieux te tourner vers le framework microsoft, bien qu'il me semble que Qt puisse s'intégrer de belle manière dans cet EDI

Pour les autres, certaines sont aussi utilisable sous Visual Studio, et d'autres seront tout aussi faciles à mettre en oeuvre sous C::B ou sous d'autres EDI...

Maintenant, le gros problème vient du fait que toute discussion sur le sujet est destinée à dégénérer en une discussion stérile entre les pro machin et les anti trucs qui tenteront de te convaincre de la justesse de leur point de vue

[Invité]

juste une derniere question
pour qu'une personne puisse faire tourner des programmes crée avec Visual , il faut qu'ell est installer le Frameworks ?

[Noxen]

Si tu fais juste un programme console, sans appel extérieur, non, il te suffit de donner l'exécutable (et éventuellement tous les fichiers de ressources dont il a besoin).
Si tu crées une application C++/CLI, c'est-à-dire si tu crées avec visual C++ express une application avec les fonctionnalités .NET, il faut que la machine cible dispose du framework .NET (pareil pour C# ou VB .NET, d'ailleurs) ; c'est à dire qu'à priori tu ne cibles que du Windows, mais généralement le framework est déjà installé.
Si tu fais du natif (ou même du CLI) en utilisant une autre bibliothèque, ça dépend. Tu devras fournir au client la dll (dynamic link libriray, bibliothèque de liens dynamiques) dont le programme a besoin ; à moins que tu n'utilises une dll fournie par l'OS. Et il me semble qu'on peut compiler un projet en incorporant dans l'exécutable les bibliothèque dont il a besoin (mais là je demanderais confirmation).

[3DArchi]

Si tu fais du natif (ou même du CLI) en utilisant une autre bibliothèque, ça dépend. Tu devras fournir au client la dll (dynamic link libriray, bibliothèque de liens dynamiques) dont le programme a besoin ; à moins que tu n'utilises une dll fournie par l'OS. Et il me semble qu'on peut compiler un projet en incorporant dans l'exécutable les bibliothèque dont il a besoin (mais là je demanderais confirmation).

Si tu n'utilises pas l'API Windows mais uniquement du 100% C++ (STL inclu), alors tu n'as pas besoin d'autre chose que ton executable.
Je ne crois pas qu'on puisse lié statiquement les librairies de bases de windows (type kernel.lib).
Enfin, quand tu compile un code c'est forcément vers une plateforme cible. Donc même si ton programme est 100% C++ sans librairie externe, si tu le compiles avec Visual pour windows, tu obtiendra un .exe qu'il te sera impossible d'utiliser tel quel sur un MAC ou sur Linux. L'inverse est aussi vrai : si tu génère un exécutable pour Mac ou Linux, tu ne pourras pas l'utiliser tel quel sur Windows.

[Invité]

Merci de vos reponses

[Noxen]

Par bibliothèque tiers je pensais par exemple à OpenGL/GLUT ou même wxWidget ; je pense qu'il doit faloir livrer la dll de glut (pour windows), même si le code lui-même est portable et peut être compilé de la même manière sous windows et sous linux (portable ? du coup j'ai un doute, je ne me souviens plus si glut c'est portable ou windows only).

[Alp]

Je doute que le PO en soit là de toute manière...

[Invité]

je vous remercie de vos reponses ,je vais mettre le C et C++ de coté pour le moment et lire le livre suivant qu' un ami m'as preté :
http://www.microapp.com/livre_debute...30.html?menu=2

[3DArchi]

Par bibliothèque tiers je pensais par exemple à OpenGL/GLUT ou même wxWidget ; je pense qu'il doit faloir livrer la dll de glut (pour windows), même si le code lui-même est portable et peut être compilé de la même manière sous windows et sous linux (portable ? du coup j'ai un doute, je ne me souviens plus si glut c'est portable ou windows only).

wxWidget peut être lié en statique pour éviter les DLL.
Pour GLUT, je ne sais pas s'il faut une DLL ou si cela peut être lié en statique. En revanche, j'ai cru comprendre que c'est portable. Mais, je ne suis pas sûr.

[Senji]

salut à tous,

désolé de revenir dessus mais j'estime que pour permettre à notre ami de devenir un bon programmeur il faudrait qu'il commence par l'approche de l'algorithme en C.
pourquoi? =>> because l'apprentissage de l'algorithmique en C permet de percevoir la gestion mémoire à partir d'une gestion manuelle, qui apporte une meilleur compréhension des constructeurs et destructeurs du C++ ou des subtilités du Garbage Collector en Java.
L'apprentissage des structures de données en C permet notamment de comprendre en détail la nature des objets manipulés à travers les librairies Java ou la STL du C++. L'abord de la programmation par le C est le moyen le plus efficace de former des developpeurs complets, ayant au final une maîtrise parfaite du bas niveau comme du haut niveau et une compréhension profonde des concepts.
Lui plonger dans la prog C++ en Gui sans ces fondements, on formera encore un developpeur qui va rejoindre la liste des ceux qui codent mal et font des releases des applis complètement buguées et super dur à maintenir. Et au final il se découragera car plus il codera, plus les manques de ses fondements se feront ressentir.
ça serait vraiment dommage.
voilà ce que j'en pense (on peut ou ne pas être d'accord, on est en démocratie)

bye

[JolyLoic]

J'ai l'impression qu'il y a confusion entre deux aspects :
- Utiliser le C ou le C++
- Utiliser le paradigme procédural ou la paradigme objet (ou fonctionnel, ou...).

Autant je suis d'accord pour dire que dans un premier temps, le paradigme procédural est probablement préférable, afin d'avoir entre autre des bases d'algorithmie et de commencer en douceur, autant je pense que le C++ est plus adapté que le C pour ça, car il va permettre de ce concentrer sur l'algorithme lui même, en éludant les aspect bas niveau dans un premier temps, pour ne les introduire qu'au fur et à mesure de l'apprentissage.

Il n'est pas question en général (sauf pour des aspects motivation dans le cadre d'un auto apprentissage, et uniquement sous forme de teaser), de plonger quiconque directement dans "la prog C++ en GUI".

[koala01]

salut à tous,

désolé de revenir dessus mais j'estime que pour permettre à notre ami de devenir un bon programmeur il faudrait qu'il commence par l'approche de l'algorithme en C.
pourquoi? =>> because l'apprentissage de l'algorithmique en C permet de percevoir la gestion mémoire à partir d'une gestion manuelle, qui apporte une meilleur compréhension des constructeurs et destructeurs du C++ ou des subtilités du Garbage Collector en Java. <snip>

A vrai dire, ma conviction personnelle est qu'il est préférable de passer par une approche de ce que j'appellerais volontiers "les principes de programmation" qui permet de comprendre les principes (et les méthodes) algorithmiques et d'avoir une idée générale de certains termes que l'on rencontre de manière systématique dans l'ensemble des langages procéduraux impératifs.

Cela va de la simple "explication" de ce qu'est une variable, à l'explication des structures de contrôles (test "vrai / faux" ou à choix multiple, différents types de boucles) à la compréhension des "structures de données" (compréhension de ce qu'est un tableau, une pile, un tas, une liste, une liste circulaire ou un arbre binaire) et de leur utilité / utilisation.

Sans passer par le C, il faut admettre que de tels concepts sont incontournables dés que l'on parle de langage de programmation procédural impératif.

Partant de ce constat, on ne tarde plus à se rendre compte que la création d'un code source (quel que soit le langage envisagé) se limite à un "long et fastidieux travail de dactylographie", qui, bien que permettant l'obtention du résultat utilisable ne présente qu'un intérêt réellement minime

Cela sous entend d'utiliser les méthodes algorithmiques adaptées aux langages dits "de troisième génération", comme par exemple, et bien que d'aucuns ici n'aient certains griefs à leur sujet, le nassi-schneiderman ou le jackson, et d'en réserver d'autres (telles que le flowchart) aux langages "proches du langages machine" (langage machine "him self" ou assembleur).

Le C++ étant un langage qui supporte très bien de ne pas être utilisé dans une optique "orientée objet", le fait d'arriver à mettre de bons algorithmes au point permet d'assurer la création de bonnes applications, y compris sans mettre en branle le coté "orienté objet"

Evidemment, si l'idée est de "tirer la quintessence" du langage et d'en tirer tous les profits possibles, l'approche orientée objet est de nature à faciliter d'une certaine manière la mise au point, mais cela sous entend que, plutôt que de faire la conception (et les diagrammes UML, par exemple) "après coup" comme c'est encore trop souvent le cas, il faut prendre la bonne habitude de baser sa conception sur les différents diagrammes proposés par UML, afin de s'assurer l'entière adéquation de ce que l'on envisage avec les besoins réels (ou futurs) ressentis par l'utilisateur.

Enfin, seulement, il y a tout ce qui fait que le C++ est un langage tout à fait particulier, allant des problèmes potentiels dus à la gestion dynamique de la mémoire à la portée des variables, en passant par l'utilisation de template et autres joyeusetés du genre, qui sont sans doute gérés de manière différente des autres langages "en vogue" actuellement.

Cette approche a surement l'inconvénient de ne pas permettre de voir tout de suite le résultat de ce que l'on apprend (un algorithme ne vaut effectivement qu'une fois qu'il a été mis en oeuvre dans un langage quelconque et que l'on peut en appréhender le résultat) mais te donne par contre l'énorme avantage d'être sur que, si ta conception est bonne, et si les algorithmes mis en oeuvre utilisent une logique cohérente, la première compilation réussie (comprend: une fois supprimées les fautes de frapes et de syntaxe) te permettra d'obtenir le résultat escompté, quitte à ce que la logique mise en oeuvre ne soit pas *forcément* la "meilleure" (comprend: celle qui permet d'utiliser le moins de ressources (en mémoire et/ou en fréquence d'horloge) qu'il était possible de mettre en oeuvre

Maintenant, je ne fais ici qu'énoncer mon point de vue personnel, car il se fait que j'ai eu la chance de suivre un enseignement qui respectait cet ordre d'apprentissage, et je reconnais à tous le droit d'avoir un autre avis.

Mais c'est mon avis, et je le partage

[Altess]

white_tentacle > Effectivement, QTCreator (c'est le nom de l'IDE) est assez foutoir, pas encore au point, mais il est à noter qu'il ne s'agit là que d'une BETA.
Wait and See comme on dit ...

zoltars43 > Libre à toi d'utiliser un autre Framework si celui proposé par M$ ne te correspond pas. Il est vrai que le MFC, c'est un sacré bordel