Microsoft Visual C++ Toolkit 2003 - Page 2

Oué, moi aussi j'avais essayé, mais il demande des DLL dans le répertoire Windows, etc... donc ça tombe dans le lac.
Et puis MASM apparemment est utilisé dans VC6 d'une autre manière que ML.exe (genre une DLL p-ê) ou bien
c'est même pas MASM mais ça m'étonnerais, quoiqu'il en soit c'est bien ML.exe qui est utilisé sous VS .Net 2003,
et je pense que vu que Microsoft fait plus trop de bénef avec ça signifie aussi sa distribution dans le toolkit.

-

-

Ben le compilo VC7 peut compiler en natif (c'est bien le seul compilateur Microsoft qui le permet d'ailleurs)

-

^^ c pas le seul
Y'a aussi Visual Basic 6 et toutes les anciennes versions de Visual C++

GC > Ben oué, mais c qu'une histoire de version, pas de langage

Visual Basic et C# compilent tous pour le framework SDK.
VC7 peut compiler aussi bien pour le framework (en sortant de l'assembleur MSIL)
que sortir de l'assembleur en syntaxe MASM (compilable par MASM 7.1)

Euh et puis nan, VB6 est loin de faire du natif (enfin ça dépend, 36000 DLLs c'est du natif ???)

Pollux
: Tu programmes en Managed C++ ? Plutôt pour la GC et la réflexion/les attributs, ou pour l'interaction avec les langages genre C# ?

F#

Kevin Kofler
:

Pollux
: cross-plateformes (Win32, Win64 Itanium et x86-64, PocketPC...)

Cross-plateforme comme redéfini par M$...

Et pas que Win, il y a aussi BSD...

Orion_ :
a tiens juste une question, est ce que mingw peut generer du code avec une librairie run-time en Multithreaded DLL ? (ce n'est qu'une question.)

Oui (mingwm10.dll, une librairie de 22 KO pour le multithreading qui s'ajoute à la librairie C normale livrée avec Windows).

-

Kevin Kofler
:

Orion_ :
a tiens juste une question, est ce que mingw peut generer du code avec une librairie run-time en Multithreaded DLL ? (ce n'est qu'une question.)

Oui (mingwm10.dll, une librairie de 22 KO pour le multithreading qui s'ajoute à la librairie C normale livrée avec Windows).

Ah oué d'accord, maintenant je comprends pourquoi SDL foire systématiquement
avec GCC et fonctionne tranquillement avec mes progs VC6.

Si tu veux du multithreading, tu dois compiler avec l'option appropriée. Par défaut, c'est single-threading seulement.

-

Y a pas windows.h ?

Pourtant ils disent qu'il y a tous les headers std ?

-

Enfin un prog C++ peut aussi inclure windows.h, hein

Donc en gros ils se foutent de la gueule du monde

^^ windows.h ne fait pas partie des headers standards Headers standards c'est la librairie C et la STL...
Si tu veux utiliser l'API windows faut télécharger le Platform SDK Win32, mais c'est pas un petit téléchargement...
(D'ailleurs si je me souviens bien, l'installation du platform sdk n'est pas activée en standard dans l'installation de VS ^^)

-

Plus avec managed C++

-

Va regarder là (Internet Explorer requis...)

-

Pas de chance. Tu peux toujours essayer de le réparer. Essaye voir sfc au cas où ça suffirait

Il y a aussi les headers libres "w32api", compatibles avec plusieurs compilateurs, donc qui devraient aussi marcher avec M$VC: http://prdownloads.sf.net/mingw/w32api-2.5.tar.gz?download.

GoldenCrystal :
Plus avec managed C++

Mais tout le monde pisse dessus.
Faire du .NET avec VC++ c'est nul, non seulement ça exploite pas
.NET (pas de conception Drag & Drop dans l'IDE, pas de C++ en ASP.NET,
et ça fait pleins de choses à apprendre pour contrôler les paramètres propres
à .NET), et de plus on travaille pas en natif.
Mieux vaut utiliser C++ pour le natif uniquement, pour faire du .NET
faut faire du C# (Possibilité de conception de formulaires Drag & Drop,
utilisable partout en .NET, dispo avec le .NET SDK, l'IDE SharpDevelop,
et il est FAIT POUR .NET, donc ça cale mieux avec)

Kevin Kofler
: Si tu veux du multithreading, tu dois compiler avec l'option appropriée. Par défaut, c'est single-threading seulement.

Quelle est l'option ?

Je pense pas que tout le monde lui pisse dessus, nan

Faire du .NET avec VC++ c'est nul, non seulement ça exploite pas .NET (pas de conception Drag & Drop dans l'IDE,

*faux*

pas de C++ en ASP.NET,

En quoi est-ce anormal ?

et ça fait pleins de choses à apprendre pour contrôler les paramètres propres à .NET

Pas vraiment... ça reste du C++, y'a juste quelques __gc et autres à rajouter

), et de plus on travaille pas en natif.

nan, bien sûr A ton avis, c quoi l'intérêt du Managed C++ ? Va essayer de nous pondre un Managed DirectX en C# toi... On verra si tu y arrives

Mieux vaut utiliser C++ pour le natif uniquement

Juste une *légère* précision, le Framework.NET n'aurait probablement pas pu être tel qu'il est actuellement sans Managed C++

pour faire du .NET faut faire du C#

ou VB.NET

(Possibilité de conception de formulaires Drag & Drop,

Possible aussi avec C++

utilisable partout en .NET, dispo avec le .NET SDK,

Le C++ aussi

l'IDE SharpDevelop,

A ton avis, pourquoi la team de SharpDevelop a-t-elle décidé d'ajouter le C++ dans la très prochaine version 1.0 ?

et il est FAIT POUR .NET, donc ça cale mieux avec)

Managed C++ est aussi fait pour le .NET...

avec GoldenCrystal

"*faux*"
Pardon: "Faire du .NET avec VC++ c'est nul, non seulement ça exploite pas
.NET aussi bien que C# et VB (pas de conception Drag & Drop dans l'IDE, "

Vala. Et pour la conception Drag & Drop, ben désolé mais ça reste à voir.
Tu l'as vu où ?

*En quoi est-ce anormal ?*
Ben on trouve tous les langages pour faire des scripts ASP.NET, aussi bien
C# et VB par défaut, que JScript, NetCobol ou FORTRAN, certains ont même
rendu possible de mettre dans des feuilles ASP.NET le langage Eiffel#,
ou bien l'assembleur x86 ("ASM.NET").
Vu le nombre de langages qui marchent en ASP.NET, le C++ n'y est pas,
ça fait clairement le langage oublié par .NET.
(Et c'est à Microsoft qu'il appartenait de faire un C++ en ASP, et il ne l'a pas fait...
Donc C++ n'est plus son fer de lance comme dans VC6, il s'efface un
peu au profit de C#)

*Pas vraiment... ça reste du C++, y'a juste quelques __gc et autres à rajouter*
Sous C#, pas besoin. On apprend le langage et pas besoin
de lire une doc supplémentaire qui dise quoi faire en code managé.
Ces __gc feront préférer le C# au C++ pour programmer sous .NET.
(.NET est clairement un clone de Java d'ailleurs, donc C# est LE langage
qui mérite d'être utilisé, étant proche de Java)


*Le C++ aussi *
Etrange, mais il fait profil bas à côté des deux autres.
J'ai vu partout des docs pour se servir du compilo VB en ligne de commande,
mais pour Managed C++, rien ne m'est passé sous les yeux.
(Je parle uniquement de ce que j'ai vu bien en évidence, pour le reste y'avait sans
doute une doc qqpart)

*A ton avis, pourquoi la team de SharpDevelop a-t-elle décidé d'ajouter le C++ dans la très prochaine version 1.0 ?*
Dommage, elle a commencé par VB
Et Managed C++ n'a aucune chance face à du C++ natif sous un IDE aussi bon...
(Dev-C++ ?)

*Managed C++ est aussi fait pour le .NET...*

Je parle de la conception toute entière du langage, non du compilo.
Le C++ n'a pas été inventé pour .NET, et pour l'y adapter, ben forcément faut
ces __gc très moches. C# est né pour .NET, et ses mots-clés eux-mêmes
sont prévus pour .NET. Même chose pour VB (avec son remaniement en profondeur
depuis VB6)[/cite]

Mais bon...