Reprise du message précédent :

 
 
heuh sous visu aussi tu peux voir l'etat des variables (?) et revenir en arriere (set next statement)
 
 
 
Le principal reproche que je ferais au debug de visu c'est de ne pas savoir afficher les registre MMX sous forme de 2 float, c quand meme un peu relou... enfin, ca sert pas tous les jours non plus
 
J'aprécie surtout le edit & continue de visu, c quand meme assez formidable ca

dire que Win32 SDK est une merde... la chsuis pas trop d'accord...
et puis ScinTE par rapport a l'editeur de Visual Studio...

[edtdd]--Message édité par deathsharp--[/edtdd]

- y'a pas que moi qui pense qu'il faut limiter l'utilisation du déboggeur. Les gens se battent depuis de nombreuses années a ce sujet. Moi je pense qu'un déboggeur doit s'utiliser en dernier recours, on réfléchie d'abord et on essaye de comprendre où il y a une erreur et pourquoi. Tu peux penser le contraire, ca me fait une belle jambe. Personne ne semble détenir la vérité absolue sur ce sujet.
 
- Ensuite tu n'as pas compris mon exemple sur le printf().
dans visual, qd tu rentres dans une fonction qui appartient au système (printf() par exemple) à l'aide de "step", il t'affiche le code en assembleur et c'est simplement pénible.
Ce n'est qu'un détail mais comme tu y tiens, voila la preuve, regarde les images dans:
http://tanguy.dyndns.org/~tanguy/visual/
Je ne suis pas un menteur et je ne raconte pas des conneries.
Le but n'est evidemment pas de débogguer un printf() !
 
- Enfin pour le niveau des warnings de Visual, j'ai les sources d'une ridicule classe String en C++ que j'ai faite.
http://tanguy.dyndns.org/~tanguy/visual/string.zip
recompile le, par défaut le niveau de warning est à 4 et ca chie dans les headers de Visual C lui même !.
Si tu le descend à 3 avec "Project / Settings / C/C++ / Warning Level", miracle il n'y a plus de warnings !
Si tu veux te convaincre que c'est bien la faute de visual, tu télécharge cygwin et tu utilises mon Makefile. Le source se compile nikel avec -g -Wall -pedantic -ansi.
Evidemment Visual C est équipé du dernier service pack : le 5 que l'on peut télécharger sur le site web mal foutu de Microsoft.
Moi je développe avec toujours le maximum de warnings !
Je ne veux surtout pas en supprimer. Je veux que le compilo m'indique tout ce qu'il y a de suspect dans mon code. Je suis ainsi certain que ca marche avec d'autre compilo que celui que j'utilise. Ca évite aussi pleins de conneries qui font perdre du temps notamment au niveau des pointeurs.
 
- Pour revenir en arrière quand on déboggue avec Visual je ne savais pas. Quand je clique sur "next statement" quand je déboggue (oui je viens d'essayer ;-) ba il ne fait rien: il ne revient pas en arrière. Soit j'ai loupé une étape soit on doit pas parler de la même chose.
Dans DDD imagine que tu déboggues et la tu fais "merde, j'ai dépassé la variable qui m'interessait !" et hop tu re-déroules ton code dans le sens inverse d'éxecution et au passage il t'affiche le contenu des variables dont celle qui t'interesse.
Le bouton sous DDD c'est tout simplement "undo", c'est logique et bien foutu.
 
 
Je ne suis pas un pro de Visual C mais je l'ai suffisamment utilisé pour comprendre que pour un produit qui coute aussi cher c'est pas le top. Je rappel que gcc, DDD et des centaines de lib fonctionnent sur des dizaines d'architectures différentes et que c'est gratuit.
 
pour les prix de visual C++ 6.0 (pas le studio, Visual C++ version pro = 3800 F):
http://msdn.microsoft.com/visualc/ [...] ricing.asp
 
Désoler d'avoir polué ce topic, mais je suis têtu

[edtdd]--Message édité par tanguy--[/edtdd]

 
Faut comparer ce qui est comparable !
SciTE est un petit éditeur sans prétention qui est bien pratique et il faut le comparer à un truc comme UltraEdit (que je connais juste de nom) ou Nedit.
Visual Studio c'est à comparer à Glade, anjusta, Kdevelop, Code Warrior...
 
Pour le SDK win32, il faut le comparer à gtk qui est une lib C.
Je t'assure que gtk avec un outil comme Glade c'est vraiment beaucoup plus simple et mieux foutu que le SDK Win32.

 
merci de ta participation.
ce serait tellement simple si la vie
etait tellement simple.
 

 
je crois avoir compris de quoi tu parlais
je disais juste que  
1- d'accord pour les libs de microsoft
mais rien n'empeche d'utiliser d'autres libs
(celles de dinkum ont des sources completes
mais elles sont payantes et ont d'autres problemes).
2- en general une erreur a l'execution d'un printf
n'est pas trop dure a determiner, une observation
du contexte d'appel (dont tu as le code puisque
tu l'as tape) suffit..
les libs Direct X non plus n'ont pas de source code
(et meme sous unix il doit bien y avoir deux ou
trois trucs qui n'existent qu'en assembleur).
et ca n'empeche pas que meme comme ca
l'utilisation du debogueur est tres utile.
 

 
je t'ai donne la solution
si seulement tu lisais les posts en entier
un simple #pragma warning(push,3)
#pragma warning(pop)
suffit.
 

 
je ne connais pas DDD mais je l'essaierai
puisque je ne suis pas sectaire.
(j'ai programme sous emacs, sous vi,
sous gdb, sous camllight, sous vb,
sous delphi, sous kdevelop, ultraedit, etc..)
je ne suis pas un fana de microsoft
mais je dis juste "attention a ce que tu dis".
 
Deuxio, on ne choisit pas toujours
les outils sous lesquels on developpe
(je n'ai pas choisi delphi personnellement)
mais on essaie de faire au mieux.
 

tanguy a écrit a écrit :   Désoler d'avoir polué ce topic, mais je suis têtu

 
Moi aussi.
 
LEGREG

[edtdd]--Message édité par legreg--[/edtdd]

tanguy : si j'ai bien compris tu veux revenir a un point precedent du code ?
 
 
ben dans visu, tu positionne le curseur sur la ligne que ou tu veux etre, et tu fais set next statement.  
je sais pas si ca a le meme effet que sous ton DDD (que je ne connais pas), ca ne reinitialise pas ls var tels quelles etaient au passage a ce point la, ca se contente de deplacer le point d'execution .
 
 
si le debugueur fonce dans le code asm de printf, c'est parce que tu le demande ! (si la encore j'ai bien compris ton probleme)
 
pour avancer dans ton code sous le debug de visu, tu as step into (qui rentre dans la fonction) ou step qui se contente d'executer la fonction sans foncer dedans
 
de cette maniere ca t'evite d'afficher le code asm de printf, dont on a rien a faire
 
c t ca ton pb ?

tain il fo un rien pour que ca dérive ...

- Au sujet de l'utilisation de débuggeur, c'était simplement pour faire remarquer que mon point de vue n'était pas stupide: il est argumenté et les arguments sont loin d'être ridicules.
 
- pour l'histoire du printf() et des appels aux libs de MS, par comparaison DDD passe uniquement dans le header quand la fonction est en inline en C++ (donc le source est dispo), mais il n'affiche pas le code en asm si la fonction n'est pas dispo en source.
D'ailleurs quand tu as une lib sous unix, t'as pas le code source de la lib directement sur ta machine, c'est toujours des .so compilé (dans /usr/lib/), donc de l'asm.
DDD a juste les headers de dispos comme Visual.
Donc en général quand j'utilise DDD j'appuie presque tout le temps sur step et pratiquement jamais sur next, j'ai pas à réfléchir si m'a fonction est à moi ou pas. Si la fonction est pas à moi (et qu'elle n'est pas en inline), il ne rentre pas dedans et m'affiche pas l'asm, il fait juste un next. Si elle est à moi il rentre dedans.
De toute facon ce n'est qu'un détail, moi ca me faisait chier sous visual parceque régulièrement j'appuyais sur step une fois de trop et paf il me chiais de l'asm, ce qui me fait perdre ton temps.
(chrisk) Je parle bien de step, quand je fais un step devant un printf() il me chie l'asm de printf.
et evidemment si je fais un next il passe la fonction sans rentrer dedans.
C'est donc evidemment une erreur de ma part puisque je fais un step de trop.
En simplifiant le problème DDD il est plus malin, il affiche pas d'asm
 
Ca vous arrive jamais de faire un step de trop ? ca vous énerve jamais qd visual affiche l'asm d'une fonction d'une lib quelconque ?
perso l'asm de strcmp ou de printf c'est pas ma tasse de thé lol
et avec DDD j'ai pas ce problème.
 
- #pragma je connais pas du tout ! j'imagine que c'est spécifique au preprocessor de visual ?
moi je veux juste qu'il me signale d'avantage de warnings dans mon code qui pourraient poser des problèmes.
Si c'est pour rajouter des #pragma partout dans le code autant rester en warning level 3 c'est plus simple
si c'est pour bidouiller, non merci. Avoue que même si ta solution fonctionne c'est qd même pas le pied !
avec gcc je peux mettre les warnings à fond sans avoir besoin de bidouiller des trucs.
 
- DDD a des fonctions sympas, il est pratique et simple. Mais il est loin d'être parfait.
Kdevelop doit surement être mieux pour débogguer.
 
- moi je choisi mes outils, je suis encore étudiant
 
- (chrisbk) on parle donc pas de la même chose !
Un exemple pour bien comprendre (il est débile cette exemple mais j'ai pas trouvé mieux).
T'as une boucle for avec i comme compteur de boucle.
for (int i = 0 ...) {
 ...
}
Dans DDD tu mets un watch sur i + un breakpoint au début du for.
Tu fais des next, donc tu déroules ta boucle et tu vois que i s'incrémente.
Imagine que i = 10 dans ton watch. A ce moment là tu fais des redo, la flèche qui t'indique ou tu es dans le code source de ta boucle va revenir en arrière comme si tu remontais le temps !
et dans ton watch de i, tu vas voir que i vaut 9 puis avec encore un redo i vaut 8 etc...
 
moi je trouves cette fonctionnalité vraiment géniale ! souvent on va un cran trop loin qd on déboggue et donc on ne voit pas où est le pb, t'es obligé de recommencer le déboggage dès le départ !
avec DDD tu fais simplement un "undo" et hop c'est fini
Avec DDD qd on déboggue on peux aller a toute vitesse et dès que la variable prend la mauvaise valeur, hop un "undo" et on comprend ce qui c'est passé !
Avouez que c'est pratique !

[edtdd]--Message édité par tanguy--[/edtdd]

Anjuta est pas mal pour un soft aussi jeune. C'est pas trop mon truc (je préfère xemacs + make + ddd etc...). Il faut ajouter a ca Devhelp qui est très sympa (un peu un help a la crosoft).
 
Par contre glade, si il est simple et rapide (a condition de regarder un peu comment fonctionne GTK et son système de containers), il a tendance a planter sévère des fois, et sans undo c'est très chaud. J'ai déja flingé plus d'une journée de travail comme ca (couper coller d'une GUI complète dans un tab ).
 
Mais bon en ce moment c'est plutot Tcl/Tk + C.
 
A propos de dev windows, j'ai commencé a voir pour faire un driver pci sous win2k, j'ai même pas trouvé un point d'entrée compréhensible dans la doc . Heureusement que pour un driver USB j'avais déja un .sys tout fait...

wow, un débat religieux au possible ...  
 
regardons les faits :  
 
* un step de trop dans une fonction ? escape, ctrl-tab, shift-f11, et hop, fini. on notera une translation intéressante de l'argument "le debugger c'est mal, faut réfléchir avant de coder" au step into justement "le step into c'est mal, faut réfléchir avant de debugger".
 
* balayons l'ignorance, on peut très bien empêcher visual de stepper dans des fonctions, suffit de chercher autoexp.dat dans google pour tomber sur qq pages intéressantes. enfin, ici on parle de coder en c++, donc debugger des classes, donc on n'a pas souvent ce genre de problèmes. on code la classe qui utilise les fonctions bas niveau, une fois qu'elle est codée elle est codée, on debugge haut niveau ensuite.
 
* de l'utilité du debugger. tu t'amènes sur un projet qui compte une dizaine de dlls, avec parfois plusieurs dizaines de fichiers par dll. tâche : comprendre tout ça et rajouter du code. hmmm, béni soit le debugger vc++. ai-je choisi vc++ ? non, c'était le truc utilisé, donc le gars qui se ramène ne va pas dire "on passe de XX à YY, PARCE QUE JE PREFERE". ça c'était pour la partie 'prendre un projet en cours'.
 
* et pour l'instruction personnelle, avoir le debugger krosoft pour faire du javascript n'est pas indispensable, mais fort bienvenu, et épargne environ des heures de recherche dans la msdn quand on ne sait même pas par où commencer. autre application à la con, tu choppes les sources de quake2, tu veux savoir où est le code d'éclairage dynamique, tu trouves ça en cinq minutes avec un debugger. je veux bien me taper les dizaines de sources à la pogne, mais seulement les 37 du mois, et à condition que ce soit la pleine lune.
 
haaa, intolérance, ignorance ... ça fait plaisir de voir ces pensées rafraîchissantes en ce glorieux seizième siècle.
 
et pour répondre à la question originale, j'utilise visual c++, parce que c'est celui que j'ai appris à l'iut, c'est celui que j'ai utilisé au boulot, et que je préfère pour le moment consacrer mon temps à apprendre des trucs plutôt qu'essayer un autre compilo.

pour la string de tanguy je la compile au niveau 4 sans aucun probleme

Continuons le débat religieux puisque tu aimes ca !
 
> un step de trop dans une fonction ? escape, ctrl-tab, shift-f11, et hop, fini.
Entre faire un step de trop et un ctrl-tab ou un shift-F11 y'a légèrement une différence.
heureusement que ca fait 3 ou 4 fois que je repète que c'est qu'un détail.
 
> on notera une translation intéressante de l'argument "le debugger c'est mal, faut réfléchir avant de coder" au step into
> justement "le step into c'est mal, faut réfléchir avant de debugger".
pfff, la voiture c'est mieux que le vélo tu ne diras pas le contraire, pourtant prends-tu ta voiture pour aller voir ton voisin au bout de la rue ?
les outils ont une utilités dans un cadre d'utilisation bien precis. débogguer te feras perdre du temps dans certain cas, quelques fois il vaut mieux réfléchir 2 min sur ce que tu viens de coder plutot que de sortir l'artillerie lourde. Mon analyse c'est pas faite dans le cadre "je dois corriger le programme d'un autre" mais "je code une fonction à moi".
 
> balayons l'ignorance, on peut très bien empêcher visual de stepper dans des fonctions, suffit de chercher autoexp.datdans  
> google pour tomber sur qq pages intéressantes.
evidemment j'ui con alors ! j'ai oublié de faire une recherche du mot "autoexp.dat" dans google.
tu t'ai levé un jour et tu t'es dis chouette "autoexp.dat" va resoudre mes problèmes ?
enfin si ce programme résoud ce problème pourquoi pas. Il n'empeche que tu t'es posé la question et que trouver une solution à ce problème n'est pas une idée stupide.
Moi ma solution c'est d'utiliser un autre outil.
 
> enfin, ici on parle de coder en c++, donc debugger des classes, donc on > n'a pas souvent ce genre de problèmes.
> on code la classe qui utilise les fonctions bas niveau, une fois qu'elle est codée
> elle est codée, on debugge haut niveau ensuite.
le titre du sujet c'est "Vous utilisez quoi pour programmer en C / C++ ?" donc on parle pas que de C++
et le problème reste entier si tu programmes en C. D'autant plus que ton argument ne me convaint pas.
 
> de l'utilité du debugger. tu t'amènes sur un projet qui compte une dizaine de dlls, avec parfois plusieurs dizaines de
> fichiers par dll. tâche : comprendre tout ça et rajouter du code. hmmm, béni soit le debugger vc++. ai-je choisi vc++ ? non,
> c'était le truc utilisé, donc le gars qui se ramène ne va pas dire "on passe de XX à YY, PARCE QUE JE PREFERE". ça
> c'était pour la partie 'prendre un projet en cours'.
Moi on m'oblige à rien, donc je prend l'outil qui me convient le mieux.
 
> et pour l'instruction personnelle, avoir le debugger krosoft pour faire du javascript n'est pas indispensable, mais fort
> bienvenu, et épargne environ des heures de recherche dans la msdn quand on ne sait même pas par où commencer.
> autre application à la con, tu choppes les sources de quake2, tu veux savoir où est le code d'éclairage dynamique, tu
> trouves ça en cinq minutes avec un debugger. je veux bien me taper les dizaines de sources à la pogne, mais seulement > les 37 du mois, et à condition que ce soit la pleine lune.
Et be c'est cool !
dans ce cas tu utilises un déboggeur.
n'empeche que si t'as un problème que tu as codé toi, en général quand tu réfléchie 2 min tu trouves ou se est le problème et ca va plus vite que de débogguer.
 
> haaa, intolérance, ignorance ... ça fait plaisir de voir ces pensées rafraîchissantes en ce glorieux seizième siècle.
no comment
 
> et pour répondre à la question originale, j'utilise visual c++, parce que c'est celui que j'ai appris à l'iut, c'est celui que j'ai > utilisé au boulot, et que je préfère pour le moment consacrer mon temps à apprendre des trucs plutôt qu'essayer un autre
> compilo.  
Tu t'es jamais posé la question s'il n'y avait pas un meilleur outil que visual C ?
quand t'achetes une voiture tu compares bein les prix et les caractéristiques alors pourquoi on ferais pas la même chose pour les outils de programmation ? surtout que en général on y passe pas mal de temps.
Tu ne t'es jamais demandé si utiliser un meilleur outil ne te ferais pas gagner du temps ?
Pourquoi utilises tu le C++ et pas l'asm ?
 
> pour la string de tanguy je la compile au niveau 4 sans aucun probleme
merde je me suis fait cassé lol dans les dents !
sérieux sans rien changer ? j'ai essayé encore avant de le poster et j'ai jamais réussi !
pourtant j'ai bien le sp5 de visual d'installé ! j'ai une page de warnings qui s'affichent et il proviennent tous des headers de visual C. A mon école j'ai aussi essayé sur des stations NT4, c'était le même pb.

c'est bien de débattre de l'interface des compilos, mais ce qui serait mieux c'est de pas générer du code pour 386!
C'est à dire utiliser SSE (ou 3Dnow si on a pas de cpu avec SSE).
Parce qu'un compilateur pour pentium, pentium pro ou pentium 2, ça ne fait qu'organiser un peu mieux les instructions, peut-être utiliser le MMX dans le meilleur des cas. Mais avec la puissance dont on dispose, c'est quand-meme dommage de ne pas utiliser les jeux d'instructions récents.

ben g changer le nivo de warning  
g Visual Studio.NET (    ) pour info

ahhhh ....
 
si j'ai répondu à ce thread c'est principalement à cause de tes premiers messages, où j'ai pu lire des trucs comme "msdn = directx = merde". je vois un gars qui a une conception unilatérale des choses, je réagis.  
 
bien sûr que je réfléchis à mon code avant d'utiliser le debugger.  
 
oui, j'ai essayé d'autres compilos, d'autres éditeurs ... aucun ne m'a autant plu que vc++. et si j'utilise vc++, c'est parce que c'est la seule bestiole que je peux utiliser efficacement pour le projet sur lequel je bosse.
 
> autoexp.dat
symptomatique de ton raisonnement, car si je dis de chercher ça sous google, c'est parce que je ne me souviens que du nom du fichier, pas de la personne qui m'en a parlé ou du bout de doc que j'ai lu. symptomatique de ton raisonnement car même si tu dis que ce n'est qu'un détail, tu en parles sur une tartine de ligne. symptomatique car ta solution est "d'utiliser un autre outil" ... tu n'as même pas pris cinq minutes pour chercher.
 
bref, ne viens pas dire que "blah blah blah = merde car je n'ai pas pris le temps de découvrir".

oui msdn est vraiment nul. Si tu compares à de la doc comme celle de QT, msdn n'arrive même pas à la cheville. Affirmer le contraire d'après moi c'est de la mauvaise fois ou de la méconnaissance. c'est mon avis et mon expérience. Je donne ici mon avis. Ca prend plein de place, c'est mal foutu, on trouve jamais rien dedans, les exemples sont plutot maigres et c'est un vrai bordel -> y'a tout pleins de trus dedans dont la moitié ne te sers à rien.
Personnellement je préfère même la doc de PHP ou encore celle de la STL par SGI. même si quelques fois c'est maigre, tu trouves tout de suite ce que tu veux, c'est bien organisé, tu t'y retrouves au moins dans cette doc !
 
Quand à DirectX, j'ai écrit "Moi je connais que le SDK, mais apparemment ..."
Ca veut dire quoi ? que ce n'est pas mon avis ni mon expérience mais bien ce que j'ai entendu dire (oui des ragots). J'ai notamment 2 amis qui ont fait un bomberman avec DirectDraw (et touché au reste) et qui n'ont pas renouvelé l'expérience. Quand j'ai écrit ca c'était justement pour avoir d'autres avis. Merci d'avoir "réagis"
 
Enfin la remarque "merde car je n'ai pas pris le temps de découvrir"
Tu ne sais rien de moi ni de mon expérience avec Visual, qui te dis que je n'ai pas pris le temps de le découvrir ?
et qui me dit que toi tu a bien pris le temps de découvrir autre chose que visual ? rien
J'ai passé des heures sur Visual pour le SDK, j'ai lu notamment le bouquin de Charles Petzold au sujet du SDK. tu me crois ou pas ca changement rien.
Les heures que j'ai passé dessus n'ont pas été concluante contrairement à toi.
Amuse toi à compiler la classe String que j'ai mis plus haut et regarde si ca fonctionne bien, ca c'est bien un fait réel et pas un avis ou un ragot !
En revanche j'admire la qualité d'OpenGL de QT et de gtk.
 
après tout si ca te fait marrer... moi j'ai donner mon avis. Toi autant que moi pouvons changer d'avis dans le futur.

C cool ici.....  
Faut ce détendre les gars....
 

ça ne me fait pas marrer, ça m'énerve de voir des avis aussi tranchés que "xxx = merde". c'est insulter tous ceux qui l'utilisent / qui trouvent ça bien, dont moi. donc je réagis.
 
je ne connais pas qt. je connais la doc de php, elle est effectivement très bien foutue. dans la msdn, je m'y paumais au début, comme tous les trucs que je découvre. mais j'ai _toujours_ trouvé ce que je cherchais, même si ça me prenait des plombes au début. aujourd'hui ce n'est plus un problème. même si je cherche avec google
 
maintenant, tu compares des choses différentes : la doc d'une lib, la doc d'un langage script, et la masse d'infos de la msdn. car la msdn, c'est la doc de tout un tas de trucs (win32 + mfc + atl + wtl + ogl + dx + etc.). donc déjà par définition plus facile de s'y perdre.  
 
ensuite, niveau architecture : je ne doute pas que qt est plus simple à utiliser que win32 de base, le contraire aurait été vraiment bizarre. maintenant critiquer niveau "c'est de la merde", c'est ignorer que qt a qq années d'âge, windows c'est vieux vieux vieux et c'est toujours resté compatible avec les anciennes apps, donc forcément il y a des résidus un peu partout, des tests, des fonctions obsolètes, etc. COM est un merdier, mais je trouve ça génial et très pratique. MacOS au début laissait accès aux variables du kernel. etc.  
 
tu admires la qualité d'ogl ? j'en déduis que tu n'as jamais fait de multitexturing, de skinning hard, de cubemap, de bump, etc. oui ogl _était_ plus simple à utiliser lors des premières incarnations de dx. là encore c'est facile de critiquer, dx était au début bien lourd et reposait à fond sur COM. ayant fait un peu de COM, je suis parti dans un trip 'tout COM', comme ils ont dû partir eux aussi. en me souvenant du début de dx et en regardant la version actuelle j'ai vite vu l'erreur : oui c'est joli d'un point de vue archi, mais c'est la chienlit à utiliser. depuis ils ont bien compris, et dx8 surpasse _de loin_ opengl. non seulement c'est aussi simple à utiliser, mais tu as des classes pour les matrices, les quaternions, les meshs, les particules, des fonctions pour faire du lod, pour relire des .3ds, etc. et surtout, c'est devenu _le_ standard pour la 3d, vu que le comité de standardisation d'ogl est aussi rapide qu'une choucroute.
 
compiler ta classe string plante chez moi, j'ai une vieille version du compilo. oui visual a des problèmes avec la STL, et non ça ne me dérange pas - je n'aime pas la STL et je ne bosse pas avec.  
 
maintenant pour te répondre littéralement :
 
>> Affirmer le contraire d'après moi c'est de la mauvaise fois ou de la méconnaissance
 
je n'ai jamais dit que la msdn était mieux que quoi que ce soit.
 
>> Tu ne sais rien de moi ni de mon expérience avec Visual, qui te dis que je n'ai pas pris le temps de le découvrir ?  
 
que tu n'aies mêmes pas pris cinq minutes pour chercher s'il y avait un moyen d'empêcher le step into. ok, c'est sûrement complètement faux, mais ne vient pas citer ça en exemple, ça ne fait vraiment pas sérieux.
 
>> et qui me dit que toi tu a bien pris le temps de découvrir autre chose que visual ? rien  
 
tu as tout à fait raison, rien. je n'ai pas cherché à fond car visual me convenait parfaitement, et j'ai jugé que le temps passé à apprendre un nouvel environnement, à voir si tout était différent, plus simple d'utilisation, plus mieux n'était pas à investir à l'époque.
 
>> Toi autant que moi pouvons changer d'avis dans le futur.  
 
où as-tu vu que je donnais mon avis ? je n'ai donné que des faits. j'ai dit que je n'essayais pas d'autres compilos/ide à fond car je n'avais pas le temps. ce n'est pas un avis.

directX et msdn y'a pire.
 
je ne connais pas d'editeur de logiciel
qui maintient une base de connaissance
aussi enorme que la msdn library et c'est en general
assez clair. (bien que ce ne soit pas forcement fait
pour apprendre mais plutot une reference
pour les developpeurs).
 
DirectX ca a ses defauts peut-etre
mais c'est vraiment pense pour les developpeurs
surtout avec le runtime debug  
la librairie + une bonne doc + de bons exemples +
les mailings list et forum microsoft
et elle evolue regulierement
avec les capacites du hardware
avec plein d'extensions sympas
(quaternions, meshes, subdivision,
skinning, force feedback)
je crois que c'est le pied pour
quelqu'un qui developpe des jeux.
Meme Carmack qui soutient a fond
OpenGL depuis le debut (bcoz portabilite)
est impressionne par DirectX.
 
A+
LEGREG

Ben moi je suis sous W2K (bientôt XP ?), avec mon brave Programmers Notepad, c'est pas lourd, ça affiche la syntaxe en couleur et les lignes, j'ai pas besoin de plus...
Pis j'uploade sur le serveur de la fac avec WinSCP2 (FTP sécurisé) en un double-clic, et je compile et teste sur place avec gcc par SSH avec Putty... Parce que c'est le seul moyen d'être sûr que ce que j'arrive à faire marcher marchera quand je le présenterai au prof sur ces bécanes pourries de la fac

QT est developpé depuis 1992 et la société trolltech a été crée en 1994 pour information, c'est vrai qu'au début ca devait être anecdotique.
Sinon le developpement des libs sous UNIX est différente. D'une version majeure à l'autre, la lib peut ne pas être compatible au niveau source et binaire. En revanche les versions mineures gardent la compatibilité binaire et source.
C'est pourquoi la numérotation des libs en essentiel sous UNIX et représente exactement la réalité. Es un problème ? nan en faite tu peux faire cohabiter plusieurs révisions d'une même lib sur ton pc sans aucun prob. Ca évite ainsi que les libs gardent trop d'archaismes (en général c'est uniquement pour ne pas dépayser le programmeur).
QT 2 et QT 3 sont par exemple incompatibles niveau source et binaire.
en revanche QT 2.2 et QT 2.3 sont compatibles source et binaire.
QT est à comparer aux MFC, c'est du même niveau d'abstraction et ca a les memes objectifs.
 
Sinon pour opengl je débute et je m'amuse bien d'ailleurs, je trouve cette lib bien foutu.
Appeler DirectX un standard alors que ca ne fonctionne que sous windows et dirigé que par microsoft c'est un peu exagéré.
TCP/IP est un standard, Ethernet aussi, XML mais directx ... on va dire que c'est utilisé dans 90% des jeux.
Autour d'un standard il y a toujours un consortium qui discute à l'élaboration du truc.
Et maya, catia, 3Dstudio max ect.. utilisent opengl, pas directx. Pour l'évolution de opengl, le draft sur la version 1.3 est sortie et est déjà implémenté dans Mesa 4.0, comme quoi ca bouge ... un peu
 
Pour la doc, je t'invite à feuilleter celle de QT par curiosité: http://doc.trolltech.com/3.0/index.html
Tous les exemples ne sont pas sur le site web, ils sont dispos dans l'archive de la source de la lib.
 
Sinon ma classe string n'utilise pas la STL c'est un programme 100% ANSI C++ tout con qui ne fait que quelques lignes de code. C'était juste un exo que je devais faire, et visual se plante dessus en level 4.
 
désolé si j'ai choqué du monde en disant que leurs outils fétiches n'étaient pas bien.
ce que j'ai dis n'engage que moi.
bon je vais un gros dodo, j'uis crevé, bonne nuit

apres le Win32 SDK qui est de la daube c MSDN...  
ten a encore bcp d'autre?
 
et pour info, 3DS max utilise aussi Direct 3D

Merci Tanguy !!!
Au début, quand j'ai installé SciTE, je l'ai trouvé un peu trop light à mon goùt mais franchement, SciTE a un sérieux air de "reviens-y"
 
J'adore, c'est clair ! Je bosse sous Perl et il me colore tout, les variables scalaires, les listes, les hash, les regexp. Tu tapes un mot, il essaie de le compléter de lui même en t'ouvrant une boite de dialogue (comme sous VB6), top moumoutte !
 
Bon, pour modifier les options, j'ai été obligé de bidouiller SciTE.global.properties à la main car dans le soft, tout ce que je veux modifier est perdu à la session suivante mais sinon, top moumoute.
 
Compilation du code sans l'exécuter, vérif de la syntaxe. Le seul truc que j'ai vu avec la syntaxe du C/C++ et que je ne trouve pas en Perl, c'est que je ne peux pas masquer le contenu des blocs IF, WHILE, DO WHILE et autres à l'affichage, j'ai po les + ou les - en bordure d'écran mais sinon, c'est vraiment trop bonnard, merci !

Emacs + g++ sous Linux
Visual C++ 6.0 sous W2K

Je reviens au sujet, perso pour le C++ je code sous C++ builder 4 de borland.