Oui , la calculette je la fait sans problème et le tp n°1 aussi , je pense que je vais faire une petite pause pour réfléchir tranquilement et je pense que après je vais y arriver !

OUIN !! ! JE CROYAIS PASSER AUX FENETRE ... Il m´on dit sur le 0 de télécharger la configuration sp1 pour visual sur le site j´ai beau toute les choisir les configuration et ben ça marche pas ... HELP ! d´avance .
je voulais aussi savoir si quelqu´un connais quelque chose a ropos de Kingdom Hearts Origin ?

c´est SUR le site où on télécharge visual studio, pas DANS le logiciel.
c´est logique non ?
hum, si tu crois direct passer de la console à la fenêtre en ayant débuté le C++ il y a deux semaines en connaissant un brin de basic, ca va être trtès difficile.
car la programmation est difficile et/ou l´a été pour tout le monde.
tu as déja fait le programme SDL du site du zero ? indispensable avant de passer au vraies fenêtres.

J´ai des vieux restes d´API Windows (y´a trois ans de cela maintenant ), mais il me semble qu´il faut surtout maîtriser certains concepts de la POO fondamentaux (je me trompe peut-être ceci dit).
Enfin, quoi qu´il en soit, passer du programme en mode console au programme en mode fenêtré, c´est possible mais bon... Si ton but c´est d´apprendre un max de choses en un minimum de temps, fais autre chose parce que ça marchera pas en programmation.

je ne compte pas faire rapido ... oui je sui allé sur le site ou on télécharge visual car je ne suis pas bete et je n´ai pas trouvé ... (alors personne connais Kingdom Hearts Origin?).

Il y a une semaine tu étais a faire une calculette, est maintenant tu veux crée des fenêtres ? GUI ?

@Chaos_Clad : Si tu crée des fenetres avec la SDL du C donc, pas besoin de POO ?

Pour le SP1 de visual, soit tu laisses tomber, soit si tu as vista tu regarde windows update et il y est, soit tu va ici

http://msdn2.microsoft.coom/fr-fr/express/aa975050.aspx

mais bon ... si tu bloques grave quand il faut télécharger un service pack, t´es mal foutu ...

Avec SDL non mais comme il parle de fenêtres j´ai plutôt pensé à de la programmation Windows.

dans tous les cas, la programmation graphique est un exercice difficile que je ne recommande pas a ceux qui ne maitrisent pas le langage qu´ils vont utiliser.
Ca nous fait manipuler des concepts plus compliqués et multiplie les causes d´erreur. Mon conseil sera de rester en console tant que l´on en maitrise pas tres bien son langage.

Oui mais attend, maitriser un langage comme le C++ ... ça prend des années, donc moi je dis qu´il faut passer en graphique car ça fait de la pratique, mais bien entendu, on aura moins le controle de ce qu´on fait par rapport a un gars qui maitrise le langage .

Souvent, les programmes où l´on a besoin de la puissance absolu sur sa machine et ceux où l´on veut une interface graphique complexe (avec des boutons, des menus, etc.) ne sont pas les même, où, tout au moins, on peut très bien séparé les deux problèmes.

C´est pourquoi je recommande très fortement d´utiliser un langage moderne pour faire des interface graphique, genre du C#, qui ressemble suffisamment au C pour que le passage puisse se faire en douceur (quoi qu´il y a beaucoup de nouveaux concepts a comprendre), et qui permet de créer des interfaces terriblement compliqué d´une manière extrêmement simple. Quitte à appeler du code écrit en C++ depuis le code en C# si on veut (mais on n´y gagne pas forcément).

On n´a pas réellement plus de contrôle sur l´interface en utilisant une lib bas niveau, par contre on produit quelque chose de bien plus propre, plus souple, avec moins de bogue, etc. si on utilise un langage de haut niveau.

On peut par exemple comparer MonoDevelop qui est beaucoup plus jeune que des IDE libres équivalentes comme anjuta ou kdevelop mais qui a quasiment autant de fonctionnalités aujourd´hui, car codé en C# et non en C ou en C++.

Le monde change, l´ère des langages de "bas" niveau est terminé. Aujourd´hui, coder vite et bien est beaucoup plus important que de coder un programme ultra-rapide, les différences ne se faisant pas sentir.

Bon, tout ça pour dire, que si vous faites du C++, apprenez à programmer correctement en console. C´est déjà très bien et on peut faire énormément de chose. Et la complexité de la programmation d´interface graphique dans ce langage ne vaut pas le coup de l´apprentissage je pense.

P.S. bon, il y a un peu de troll dans ce message, mais pas trop non plus. Au passage, je ne l´ai pas cité, mais le langage de l´avenir si vous voulez vraiment le savoir, c´est F#, vous pouvez le télécharger là :
http://research.microsoft.com/fsharp/fsharp.aspx c´est une variante d´OCaml, qui est la vrai langage de l´avenir, mais comme F# est produit par microsoft, il se répandra bien plus vite.

très interressant dnob700, mais tu peut argumenter un peu sur F# ?

J´ai reussi a afficher un Hello World mais donc pour déclarer une variable on utilise ´let´ ? sinon ça ressemble a C# pour afficher un texte en tous cas .

Mais sinon, au fil du temps, si on utilise que des langages "facile", on aura oublier la complexiter d´un langage comme le C !

Mais est-ce qu´avec les langages de l´avenir comme F# que tu as cité, on va pouvoir inové ? car l´interet d´un langage bas niveau, c´est d´avoir un controle absolu ?

Sinon, tu peut donner un chiffre, de quand le C/C++ sera abandoné ? Car disons que dans 5 ans je passe le bac et j´ai peur de

--> j´apprend le C++
--> je sors de l´école, on me dit qu´il faut connaitre le F# (par exemple )

merci

le C et le C++ resteront utilisé dans les applications bas niveau. Plus les langages sont abstrait et plus ils sont difficiles à optimiser (manuellement comme automatiquement).

Quand on apprends la programmation, on se fout du langage, les vrai probleme sont independnt de la technologie que tu utilises...

oui c´est vrai, on m´avais déjà dit que l´important etait la théorie de la programmation pas le langage

il n´y a pas de date pour l´abandon du C++, il sera probablement encore utilisé pendant très longtemps (même s´il va continuer à évoluer et que dans quelques année ils ne ressemblera pas forcément exactement à ce qu´il est aujourd´hui).

Pour le reste il faut distinguer le très petit nombre d´application vraiment critique (globalement les jeux vidéo et les applications embarquées temps-réel), et l´immense majorité d´application qui doivent être écrite rapidement, sans bogues et facilement maintenable (toute la bureautique, les appli WEB, les OS, etc.). Là, ça ne sers à rien de jouer avec des bits pour faire de l´optimisation, de toute manière le compilo fera un boulot largement suffisant.

"Mais est-ce qu´avec les langages de l´avenir comme F# que tu as cité, on va pouvoir inové ? car l´interet d´un langage bas niveau, c´est d´avoir un controle absolu ?"

Est-ce que tu pourrais expliciter ce à quoi tu pense ?

Pour ce qui est du F#, je recommende pour l´instant d´apprendre plutôt l´OCaml que F#, par exemple avec ce cours :
http://www.pps.jussieu.fr/Livres/ora/DA-OCAML/index.html

Il s´agit, pour les deux langages, de langages fonctionnels, c´est-à-dire qu´une fonction est manipulé comme n´importe quelle autre "variable" (je mets ça entre guillemet car il n´y a pas exactement des variables dans ces langages). Par exemple des fonctions peuvent prendre en argument des fonctions, fabriquer une nouvelle fonction à partir de celle là et renvoyer un fonction en valeur de retour.

Un exemple est l´opérateur o de composition de fonction, que je vais noter << ici :

let ( << ) f g = function x -> f (g x)

et après je peut par exemple appeler la fonction f o g (lire f rond g) comme ceci :
(f << g) 5
qui va effectuer le calcul f(g(5)). Mais je peut aussi enregister f rond g dans une nouvelle fonction :
let h = f << g
et me servir de h n´importe où.
Bon ça, ce n´est que le tout début de ce que l´on peut faire.

Mais avec la programmation fonctionnelle, je programme beaucoup plus vite qu´en C++, des programmes qui ont beaucoup moins de fautes. Entre autre parce que le compilateur est assez "méchant", c´est à dire qu´il est très stricte sur ce que l´on peut écrire (entre autre, il y a un système de type très rigoureux en OCaml) et que quand un programme compile sans erreur, généralement, il va faire ce que l´on veut à l´exécution.

Le problème, c´est qu´écrire un programme fonctionnel est assez différend d´un programme impératif et que ça demande un peu de boulot pour un programmeur qui a toujours coder en impératif.

Mais là, ça devient complétement HS.

À noter, qu´avec OCaml, on ne résout pas le problème des interfaces graphiques, et je ne me souviens plus si F# gère les winforms (ça fait un bout de temps que je n´ai pas essayé).

hum, ya encore des trucs que je pige pas ... déjà, le F# et le OCalm n´a pas besoin d´etre compiler ? car moi j´ai entré 2 / 3 lignes dans le command prompt de F# et il ma sortit un hello world sans me dire des trucs du genre return code natif 0x0 ( j´ai sa sous visual c++ )

Sinon je verai ce soir pour OCalm, mais sa ma l´air asser dur comparer au C++, ( ou alors je me fait des idées je n´ai pas trop regarder )

"Est-ce que tu pourrais expliciter ce à quoi tu pense ? "

Laisse tomber, tu as répondu plus bas dans ton message a ma question ... en gros je voulais savoir si avec F# on pouvais codé facilement rapidement, et avoir l´avantage des langages bas niveau ( controle, optimisation ), mais cependant, on m´a dit que si on compilait en release avec toutes les optimisation activé, le compilo te fait tous le boulot, pas besoin de passer par des optimisation en ASM etc ... Donc au final et surtout pour les jeux video ou on a besoin de gratter de la mémoire, le C++ restera gagnant ? car sinon ils pourront sortir des jeux beaucoup plus rapidement, pour la même qualité (F#) ??

Il y a certain jeux, qui, à chaque fois qu´ils sortent représentent l´état de l´art en matière d´optimisation graphique, etc. Mais pas mal de jeux pourrait être codé en C# et/ou en F# qu´on n´y verrais que du feu (particulièrement des jeux amateurs).

Pour le F#, il peut être compilé, mais il peut aussi être directement interprété au fur et à mesure que tu tape les commandes. C´est très pratique, car ça en fait un langage de script terriblement puissant : il peut servir de langage de calcul mathématique et tu as des retour visuel en temps réel (quitte à utiliser les bons outils).
Donc si tu tape dans le command prompt, ça exécute tout de suite (mais je crois qu´on peut le faire aussi avec les autres langages .NET), mais tu peut aussi créer un projet et le compiler comme du C# en un exécutable.

OCaml n´est certainement pas dur comparé au C++, c´est juste différent (et si tu as regardé le F#, c´est bon : la base des deux langages est compatible).

pour continuer dans le hors sujet complet.
Il y a de tres bon livre de caml. En particulier un ecrit par deux gars de l´INRIA.

Heu ... c´est bon pour la SDL . Dis donc , c´est vrai que ça fais peur le f# (j´ai d´ailleur pas très bien compris si j´étais obligé de l´apprendre ) . heu en hors cour j´ai tenté de faire
sizeof(main) par ce que je me demandais si c´était pas plus simple pour calculer le nombre de octet pris par le proramme (ça a pas marché ) . Peut on écrire des script en C/C++ avec RPG maker ?

"Heu ... c´est bon pour la SDL"

c´est une question ?

Personne n´est obligé d´apprendre quoi que ce soit. Le F# est un langage très sympa (bon, je ne m´en sers pas trop, je préfère OCaml, mais F# doit être aussi bon), que je te recommende, mais si tu apprend le C++, tu peut tout aussi bien te concentrer dessus pour l´instant.

sizeof renvoie la taille d´une variable ou d´un type de donnée. Pour connaitre la taille d´un programme, il faut regarder l´exécutable produit. On ne peut pas le deviner en regardant le code source, ça dépendra énormément du compilo, des options de compilation et de l´OS.

Non, RPG Maker dans les versions récente supporte le langage Ruby je crois, et avant utilise un système de script qui lui est propre. Mais on ne peut pas faire de C ou de C++ avec.

Heu le ruby c´est facile ? Tu n´aurais pas un tuto silte plait ?