Reprise du message précédent :
Je trouve pas que ce soit une limitation notable
 
D'autant que ce que tu dis n'est qu'en partie vrai seulement.
 
- Il existe divers projets sur diverses plateformes pour exécuter du .NET sur autrechose que Windows (puisque .NET est tout de même écrit au départ pour être portable). Le plus connu est MONO pour X-likes. http://www.mono-project.com
- .NET fonctionne sur tous les PDA et téléphones dotés d'un OS Microsoft
- .NET fonctionne sur XBox et dans un futur plus ou moins proche/hypothétique sur PlayStation et Nintendo

Ouais mais bon, mono c'est pas encore ça.
Cela dit, tu as bien fait de préciser pour les pda etc. Le non support 100% sous *nix est quand même pénalisante, en entreprise déjà.

* : Ceci dit, pour les PDA, ça s'élargit aussi aux PDA sous Linux, puisque Mono est porté avec succès vers le Nokia 770 par exemple

Alors, devrais-je choisir entre C# et VB.NET ? En cherchant sur Google je crois que C# est le plus répandu, n'est pas ?

quelle importance ?

 
Les bonnes habitudes

Rien à voir avec le fait que le langage soit plus répandu;
 

(meme si en l'occurence je préfère c# que vb)

 
Non, mais quand tu a le choix, autant prendre C# dès le début, c'est une bonne habitude

bien sûr chuis d'accord
notre jeune amis devrait orienter son choix comme cela

 
 
Moi je te conseillerais VB 6 (puisque tu connais le basic)
C'est très simple, pas objet et tout de même très puissant. ça donne juste des exécutables très lourds.
 
 
sinon dans le même genre en plus complet il y a Delphi, mais il te faudra apprendre le Pascal (ça reste super accessible).

 
Non mais on est au 21ème siècle là hein
 

donc c#

 
Vous me voyez fort aise de cette entente

on s'en fou du siècle !
 
il faut adapter l'outil aux besoins.
 
D'ailleurs, c'est pas parce qu'on est au 21ème siècle que l'on utilise plus de C, de Python, de Ada, de SQL, de ...

 
Et le prix de VB6 ou delphi

 
gratuit.
 
visual basic express
http://www.commentcamarche.net/tel [...] ic-express
 
Delphi 2005 FR Edition Personnel
http://delphi.developpez.com/delphi2005/

 
Pour Visual basic, c'est la version 2005 là

ah oui très juste, lol
 
bon pour delphi en tout cas c'est gratuit ^^

.net qui plus est

 
 
En même temps VB 2002/2003/2005...

Je viens de créer un tout petit exécutable en C# (mode console) avec le typique <<hello, world>>. La taille du fichier au disque dur est de ~20 KB mais elle est de ~8 600 KB en exécution. Wow !

 
 
Pas d'inquiétude, c'est le mécanisme interne du framework .NET

Yoda ? c'est toi ?

Ah si, une appli C#/Winform est parfaitement portable ! Mes applis C# tournent sous Win98, Millenium, 2000, XP, 2003 et même Vista ! Et je suis prêt à parier qu'elles tournent aussi sous 95 ! Difficile de faire plus portable

Oui, il parait d'ailleurs que Lucy était fan de VB 6

 
 
Sous 95

et linusque ?

sarcastic spotted

en encore faut-il le trouver à la vente...
n'étant plus supporté, je doute qu'il soit encore commercialisé !

Pour les fans de X, y'a mono, comme monosapiens

Salut,
Moi je dirais du Delphi pour windows seul (sauf si tu réussis à trouver Kylix mais la tu peux oublier les apports des compilos comme Delphi 2005/6/7).
Sinon du C avec GTK pour toutes les plateformes ?

GTK c'ets so 1980, du C++ avec QT m'a l'air bien mieux

Peut être mais QT ca fonctionne partout ?

Et j'ai pas inclus QTopia

OK autant pour moi

Y'a gtkmm pour faire du gtk en c++.
 
M'enfin QT doit être mieux fait.

c'ets pas histoire de faire du GTK avec du C++ hein, le probleme vient du modele de prog de GTK qui est bien inferieur au systeme de slot/signal de QT. Ca + les trouzillions de classes annexes de QT ...

En même temps j'ai jamais dit le contraire.  

Gtk en lui même est chiant à utiliser, gtkmm rends ca moins chiant, mais ca ne reste qu'un wrapper.

edit:

Il est clair que QT est meilleur, mais je ne déconseillerais pas pour autant gtkmm.

 
Y'a exactement le même modèle sous gtkmm, en respectant la syntaxe du C++ (oui parceque faut pas oublier que QT spa du C++ qu'on fait avec, c'est une surcouche du C++...)
La doc de QT est ultra-prétencieuse à ce sujet, mais gtkmm a aussi des slots et des signaux qui fonctionnent très bien, swallow des callbacks et méthodes classiques y compris, et gtk est plus flexible niveau gestion mémoire des widgets.
La seule différence c'est qu'on ne peut par défaut balancer des signaux entre 2 threads, sauf le thread sans argument dispo dans la glib (et qui permet de couvrir une très grande partie des cas d'utilisation) et y'a libsigcx de couvrir les autres besoins.
 
( Par contre ouais, y'a pas mal de classes annexes en plus intégrées directement dans QT )

T'y vas peut-être un peu fort là, non?
Je n'ai jamais utilisé gtkmm, mais le système qu'ils utilisent ne m'a pas l'air mal du tout; ceci dit y'a des fonctionnalités dans Qt dont je ne me passerais pour rien au monde

C'est-à-dire?

Oui un petit peu mais c'est par usure, quand j'ai lut les tuto ils font une tartine la dessus, genre c'est une exclusivité alors que c'est un DP assez basique d'observer, en cours le profs à ressortit quasiment texto la même publicité élogieuse, et les 3/4 des personnes que j'ai croisé qui m'ont parlé de QT étaient tout excités et ne parlaient que de ça, principalement par méconnaissance des autres tk, c'est un poil fatiguant à la fin
Tiré de la doc qt :

Genre quoi ?

Le fait qu'on ne puisse pas allouer un widget dans la pile par exemple. (Après quand à savoir si c'est vraiment essentiel, c'est une question plus personelle... mais j'aime bien avoir ce choix)

On est d'accord, ce DP est très répandu; il est aussi possible que les gens qui t'en ait parlé n'ai jamais testé (ou ne serait-ce que regarder) la libsig++ (au hasard ). Personnellement, j'ai découvert Qt juste après les MFC, et en parallèle de wxWidgets, et sans connaître d'autres frameworks, donc j'en aurais aussi dit beaucoup de bien car je n'ai découvert de solution à base de templates que par la suite.
Un autre argument contre Qt qui revient souvent et le fait qu'ils aient développé leur -disons- QTL en recodant des conteneurs de la SL (j'en parle ici car, AMHA, c'est lié). Il y a à ça une raison toute précise: Trolltech veut que Qt soit utilisable sur une très grosse majorité des compilateurs. Y compris donc ceux sur lesquels une implémentation des template et/ou l'implémentation de la STL est/sont foireuse(s).
 

En fonctionnalité GUI pure que je n'ai pas trouvé dans la doc de gtkmm, ce sont les QAction. Avoir un objet commun pour créer/synchroniser les menus, les toolbars et la statusbar, je trouve ça extrémement pratique Il y a aussi la série des classes QGraphics* qui sont pas mal
Et hors GUI, mais lié au système Qt, le fait que les classes dérivant de QObject soit assez facilement utilisable par le biais de QSA et maintenant QtScript. On y ajoute les abstractions des liaisons au BdD, plus quelques fonctionnalités orientés systèmes (QDesktopServices, QLibrary ou encore le nouveau QFuture pour les systèmes concurrents pour ne citer qu'eux) et ça commence à peser lourd dans ma balance. Le résultat est un code assez cohérent si on utilise Qt à fond (au prix d'une dépendance monstrueuse qu'il faut accepter bien sûr).
 
Encore une fois, n'ayant pas utilisé gtkmm, il y a probablement des fonctionnalités qui y sont présentes, je ne vise pas à faire une quelconque comparaison qui donnerait lieu à un troll (mais si tu peux/veux me parler des avantages de gtkmm, j'en saurais davantage au sujet de cette lib )

Ce n'est pas qu'on ne peut pas, c'est qu'il faut le faire dans des cas bien précis, dû à des relations hiérarchiques. Personnellement, j'ai compris et accepté cette méthode, mais il est vrai que c'est une affaire de goûts et de couleurs aussi
 
edit: orthographe...