visual studio 2005

Arnaud Meurgues <news.arnaud@meurgues.non.fr.invalid> writes:

Jean-Marc Bourguet wrote:

Turbo faisait reference a la rapidite de compilation. Ce n'etait pas
un mensonge du tout quand on compare au Pascal de MS a l'epoque.

Il y avait un Pascal Microsoft à l'époque de Turbo Pascal 1.0 ?!

J'ai utilise un Pascal Microsoft plus ou moins a la meme epoque. Mais
ca fait loin et c'est peut-etre apres TP 1.0.

Moi, ce que j'ai connu à l'époque, c'était Turbo Pascal sur CPM
(merci la carte Z80 sur Apple ][) que j'ai pu comparer au Pascal
UCSD.

Et, effectivement, le « turbo » était largement justifié. Il me
semble que Borland avait inventé la compilation du Pascal en une
passe, ce qui l'a considérablement accélerer par rapport aux
compilateurs concurrents.

Par rapport au Pascal USCD, il y avait aussi que TP etait ecrit en
assembleur optimise a la main, Pascal USCD ecrit en Pascal et compile
en pcode qui etait interprete. Au moins pour certaines machines.

Pascal, ce n'etait pas le Pascal normalise (est-ce qu'il l'etait deja
a l'epoque au fait, la norme est sortie tres tard) mais personne ne
l'a jamais reellement supporte celui-la.

J'ai l'impression que la norme de fait était Turbo Pascal, justement. Au
moins jusqu'à la version 5.5 où ils ont créé une rupture pour introduire
la POO (ce qui a abouti à Delphi).

La norme de fait sur PC, oui. Mais Digital avait un pascal aussi, qui
etait loin de TP. Il y a eu aussi un Object Pascal avec TP 5.5.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Je crois que ça veut dire que la syntaxe des ajouts est dans
l'esprit C++... Ce qui n'est pas complètement faux.

La semantique par contre... as-tu lu les remarques du comite anglais?

Lesquelles? Une référence?

Je ne dis rien la sur C++/CLI mais sur CLI. L'idee d'une
infrastructure commune utilisable par tous les langages me semble tres
seduisante et CLI aurait ete de nature a favoriser de la diversite
dans les langages employes. Mais le resultat... pour profiter de CLI,
il faut avoir C# comme sous-ensemble (note que ce n'est pas une
critique sur C#, il aurait fallu avoir C++ ou Java comme
sous-ensemble, ma critique aurait ete la meme). La diversite des
langages m'interesse surtout pour la diversite de semantique. Je ne
vois pas l'interet d'avoir simplement d'une diversite syntaxique.

Ben justement, il me semble que C++/CLI est le 1er langage "compatible
.NET" à apporter des éléments sémantiques nouveaux par rapport à
la sémantique de base du CLI (soit grosso-modo celle du C#).
L'exemple le plus flagrant étant les "stack semantics" qui permettent
de séparer les notions de destructeurs et de finaliseurs, et d'avoir
des destructeurs qui s'executent de manière synchrone en C++/CLI,
exactement comme en ISO C++ (ce qui veut dire que l'on dispose de
l'idiome RAII en C++/CLI...)

Par contre, c'est vrai que C++/CLI impose un certain nombre de
lourdeurs sémantiques, comme la séparation arbitraire entre les
"value-type" et les "reference-types"...

Je suppose que Java aussi est un échec alors...

Je ne vois pas le rapport. Java ne se veut pas un environnement
commun independant du langage et pourtant y reussit a peut pres aussi
bien que CLI.

AMHA, le gros atout de CLI par rapport à Java ne tient pas à
l'indépendance du langage, mais à la BCL (librairie de base, comme on
voudra l'appeler) qui est bien mieux foutue...

C++ est deja complexe. C++/CLI l'est encore plus (la description de
C++/CLI prend autant de pages que la partie langage de la norme C++,
avec en plus des references aux specifications de CLI pour certaines
choses) et une meme syntaxe va avoir des comportements plus ou moins
subtilement different suivant le type d'objets qu'on emploie. Ca me
semble etre un cauchemard a enseigner. Si on fait reellement usage
des deux types d'objets, ca me semble etre un cauchemard a maintenir.

Tu as essayé? Moi oui, et je trouve que justement la nouvelle syntaxe
de C++/CLI (comparé au C++ managé) rend les choses assez faciles à
gérer en pratique. L'utilisation de "^" versus "*" permet de s'y
retrouver assez bien...

Si je dois participer a un projet, j'insisterais *tres* fort pour
qu'il y ait une separation stricte entre les parties C++ ISO et les
parties CLI. Et vu que ces deux parties sont en fait deux langages,
je ne vois aucun interet en dehors de la partie interfacage pour du
C++/CLI quand C# existe.

Il y a quand même un autre argument qui milite en faveur du C++/CLI
par rapport au C# : le modèle de compilation séparé, donc la
réduction des temps de (re)compilation.
Cependant, vu la complexité horrible du C++ par rapport au C# du point
de vue du parser/lexer, cet argument n'est en pratique valable que sur
de *gros* volumes de code. Sur des petits projets, C# atomise C++ (CLI
ou ISO) en temps de compilation :-(

Arnaud

Si je peux me permettre de reprendre l'idée de Jean-Marc à mon
compte, je dirai que l'échec est l'"interface" entre C++ et .Net.

Justement, MS a décidé de ne pas en proposer. C'est un échec pour
C++ peut-être...

Je ne comprends pas ta première phrase. Mais pour aller dans le sens de
la seconde, il faut avoir à l'esprit que le développement sous Windows
est en train d'évoluer doucement mais massivement vers .Net. Vista
devrait marquer une rupture plus franche avec Win32. Autrement dit, il
va d'ici quelques temps devenir très pénalisant de ne pas pouvoir faire
du .Net dans ses applications Windows.
Hors, jusque là, et encore aujourd'hui, C++ est un langage très utilisé
sous Windows (à commencer par MS) et qui est certainement celui qui
permet le mieux de tirer parti de cet OS. Dans la mesure où Windows va
de plus en plus s'appuyer sur .Net, les développeurs C++ et d'une
manière plus globale le langage C++ lui même vont être fortement
pénalisés. C'est ce qui a motivé C++/CLI chez MS, selon Herb Sutter.
Ca va donc plutôt à l'encontre de ton argumentation sur le fait de
vouloir imposer C#. Il suffirait pour cela de ne pas proposer de binding
C++.Net, et de laisser la communauté C++ rétrécir...
En tous cas on verra comment ça se passe pour les programmeurs C.

AMHA "C++/CLI" est un échec à cause de son nom.

What's in a name...

Je suis d'accord qu'un autre nom serait mieux, encore que l'on
peut discuter longuement sur ce que ça aurait changé si on l'avait
appelé CLI++ (ou autre). Je crois que ça donne simplement une
munition facile à ceux qui veulent critiquer (et en ce sens, c'est
un échec « publicitaire »). Mais bon, on a déjà vu plus menteur
comme nom, genre Turbo Pascal ? :-)

Fréquentant régulièrement d'autres forums, je ne peux que constater
l'échec de ce nom. Presque tout le monde parle de "C++.Net".

En gros, si je comprends bien, les choses se sont passées comme

^^^^^^^^^^^^^^^^^^^^^
Rien à voir avec une compréhension, tu fais des suppositions...

suit : - Microsoft veut imposer son propre langage, pour que les
programmeurs l'apprennent et se retrouvent incapables de
s'intéresser à d'autres plate-formes.

C'est un peu prendre les programmeurs pour des cons :-) "Mais Microsoft
ne m'a appris que le C#, je ne peux pas programmer sous un autre OS!"

Pourquoi en apprenant un langage serait-on plus désintéressé des
autres plate-formes. Disons que je connais C, Java, C++, C# et
C++/CLI, et les utilise quand leur emploi me semble approprié,
suis-je fou ?

Le service marketing appelle
ça "C#". - Ah ben zut, y'a plein de gens qui programment en C++.
Peuvent
pas programmer en VB, comme tout le monde, ces petits cons ? Bon,
c'est pas grave, affinons notre tactique : on va créer un deuxième
nouveau langage, avec un nom qui contient "C++", en espérant que les
programmeurs C++ viennent à nous, tout en évitant que les
utilisateurs de ce nouveau langage ne soient tentés d'aller vers le
C++.

"Comme ça on ne vendra plus de VC++", dixit le service *marketing*.
Pour rappel, y'a plein de gens qui programment en C++ à commencer chez
MS. Des milliers de leurs employés ont pissé du C++ pendant 10 ou 20
ans, c'est un *détail* qu'ils ont du prendre en compte.

--
Aurélien Regat-Barrel

adebaene@club-internet.fr writes:

Je crois que ça veut dire que la syntaxe des ajouts est dans
l'esprit C++... Ce qui n'est pas complètement faux.

La semantique par contre... as-tu lu les remarques du comite anglais?

Lesquelles? Une référence?

Il me semble que Francis a donne une URL publique au debut de l'annee.

Ben justement, il me semble que C++/CLI est le 1er langage
"compatible .NET" à apporter des éléments sémantiques nouveaux par
rapport à la sémantique de base du CLI (soit grosso-modo celle du
C#). L'exemple le plus flagrant étant les "stack semantics" qui
permettent de séparer les notions de destructeurs et de finaliseurs,
et d'avoir des destructeurs qui s'executent de manière synchrone en
C++/CLI, exactement comme en ISO C++ (ce qui veut dire que l'on
dispose de l'idiome RAII en C++/CLI...)

Par contre, c'est vrai que C++/CLI impose un certain nombre de
lourdeurs sémantiques, comme la séparation arbitraire entre les
"value-type" et les "reference-types"...

Je suppose que Java aussi est un échec alors...

Je ne vois pas le rapport. Java ne se veut pas un environnement
commun independant du langage et pourtant y reussit a peut pres aussi
bien que CLI.

AMHA, le gros atout de CLI par rapport à Java ne tient pas à
l'indépendance du langage, mais à la BCL (librairie de base, comme on
voudra l'appeler) qui est bien mieux foutue...

Je ne connais ni l'une ni l'autre assez bien pour commenter. Ce que
je sais, c'est que pour profiter de cette bibliotheque, un langage
doit avoir un sous-ensemble dont la semantique est tres proche C#. Si
on veut un langage propre -- et c++/cli avec deux modeles de template,
deux modeles objets n'est pas propre a mon gout --, c'est quand meme
tres contraignant.

C++ est deja complexe. C++/CLI l'est encore plus (la description
de C++/CLI prend autant de pages que la partie langage de la norme
C++, avec en plus des references aux specifications de CLI pour
certaines choses) et une meme syntaxe va avoir des comportements
plus ou moins subtilement different suivant le type d'objets qu'on
emploie. Ca me semble etre un cauchemard a enseigner. Si on fait
reellement usage des deux types d'objets, ca me semble etre un
cauchemard a maintenir.

Tu as essayé? Moi oui, et je trouve que justement la nouvelle syntaxe
de C++/CLI (comparé au C++ managé) rend les choses assez faciles à
gérer en pratique. L'utilisation de "^" versus "*" permet de s'y
retrouver assez bien...

Je n'ai ecrit que des petits programmes d'essai en C++/CLI. Je n'ai
jamais utilise C++ managé.

Mais on double les regles sur des points plus ou moins subtils. Si on
prend par exemple la discussion recente au sujet des fonctions cachees
par ce qui pourrait etre une surcharge dans une classe fille, c'est le
cas pour la partie C++ mais ce n'est pas le cas pour la partie CLI.
Celui qui veut enseigner cela va s'amuser. Celui qui va debugger un
probleme du a cela aussi.

A+

--
Jean-Marc
FAQ de fclc++: http://www.cmla.ens-cachan.fr/~dosreis/C++/FAQ
C++ FAQ Lite en VF: http://www.ifrance.com/jlecomte/c++/c++-faq-lite/index.html
Site de usenet-fr: http://www.usenet-fr.news.eu.org

Je crois que ça veut dire que la syntaxe des ajouts est dans
l'esprit C++... Ce qui n'est pas complètement faux.

La semantique par contre... as-tu lu les remarques du comite anglais?

Lesquelles? Une référence?

Les critiques, et leurs réponses de MS:
http://www.research.att.com/~bs/bs_faq.html#CppCLI

Je ne dis rien la sur C++/CLI mais sur CLI. L'idee d'une
infrastructure commune utilisable par tous les langages me semble tres
seduisante et CLI aurait ete de nature a favoriser de la diversite
dans les langages employes. Mais le resultat... pour profiter de CLI,
il faut avoir C# comme sous-ensemble (note que ce n'est pas une
critique sur C#, il aurait fallu avoir C++ ou Java comme
sous-ensemble, ma critique aurait ete la meme). La diversite des
langages m'interesse surtout pour la diversite de semantique. Je ne
vois pas l'interet d'avoir simplement d'une diversite syntaxique.

Ben justement, il me semble que C++/CLI est le 1er langage "compatible
..NET" à apporter des éléments sémantiques nouveaux par rapport à
la sémantique de base du CLI (soit grosso-modo celle du C#).
L'exemple le plus flagrant étant les "stack semantics" qui permettent
de séparer les notions de destructeurs et de finaliseurs, et d'avoir
des destructeurs qui s'executent de manière synchrone en C++/CLI,
exactement comme en ISO C++ (ce qui veut dire que l'on dispose de
l'idiome RAII en C++/CLI...)

Par contre, c'est vrai que C++/CLI impose un certain nombre de
lourdeurs sémantiques, comme la séparation arbitraire entre les
"value-type" et les "reference-types"...

Je suppose que Java aussi est un échec alors...

Je ne vois pas le rapport. Java ne se veut pas un environnement
commun independant du langage et pourtant y reussit a peut pres aussi
bien que CLI.

AMHA, le gros atout de CLI par rapport à Java ne tient pas à
l'indépendance du langage, mais à la BCL (librairie de base, comme on
voudra l'appeler) qui est bien mieux foutue...

Moi je trouve que c'est là qu'il pèche justement. Utiliser
System::String^, System::Console, etc... est à mon avis la principale
raison de l'impression de programmer en C# et non en C++.
De même que int est mappé sur System::Int32, etc... j'aurais aimé avoir
ce genre de chose en C++/CLI.
La STL.Net semble aller dans ce sens. On devrait pouvoir écrire:

string s = "Hello world";

//Using the ICollection<> interface
for each(wchar_t c in s)
{
Console::Write(c);
}
Console::WriteLine();

//Using the default indexed property
for(int i=0; i<s.Count; i++)
{
Console::Write(s[i]);
}
Console::WriteLine();

//Using iterators
for(string::iterator i = s.begin(); i != s.end(); i++)
{
Console::Write(*i);
}
Console::WriteLine();

là, j'ai l'impression de faire du C++. Mais elle tarde à venir. De même,
j'aimerai pouvoir compiler en clr pure:

#include <iostream> // bon à la limite ici, on peut envisager
using namepsace std; // un <cliext/iostream> et un namespace stdcli

int main()
{
cout << "Hello";
}

j'ai essayé de créer une mini lib dans ce genre, mais ça semble
impossible car les objets managés globaux (cout) ne sont pas permis (et
je manque d'imagination/connaissances). Dommage...
Pourtant, d'un point de vue théorique, ça me semble possible de créer
une version complètement managée de la CRT, en replaçant les appels
Win32 par leurs équivalents .Net. Enfin, pour moi, ça serait l'idéal
utopique...

C++ est deja complexe. C++/CLI l'est encore plus (la description de
C++/CLI prend autant de pages que la partie langage de la norme C++,
avec en plus des references aux specifications de CLI pour certaines
choses) et une meme syntaxe va avoir des comportements plus ou moins
subtilement different suivant le type d'objets qu'on emploie. Ca me
semble etre un cauchemard a enseigner. Si on fait reellement usage
des deux types d'objets, ca me semble etre un cauchemard a maintenir.

Tu as essayé? Moi oui, et je trouve que justement la nouvelle syntaxe
de C++/CLI (comparé au C++ managé) rend les choses assez faciles à
gérer en pratique. L'utilisation de "^" versus "*" permet de s'y
retrouver assez bien...

J'ai été déçu de ne pas pouvoir hériter une classe managée d'une classe
native afin de facilement réutiliser du code existant. Mais apparement
c'est bien au programme, pour la prochaine version. Ca, avec la
possibilité de faire des gcnew sur des types non managés (mais je n'en
saisi pas bien l'utilité).

Si je dois participer a un projet, j'insisterais *tres* fort pour
qu'il y ait une separation stricte entre les parties C++ ISO et les
parties CLI. Et vu que ces deux parties sont en fait deux langages,
je ne vois aucun interet en dehors de la partie interfacage pour du
C++/CLI quand C# existe.

Il y a quand même un autre argument qui milite en faveur du C++/CLI
par rapport au C# : le modèle de compilation séparé, donc la
réduction des temps de (re)compilation.
Cependant, vu la complexité horrible du C++ par rapport au C# du point
de vue du parser/lexer, cet argument n'est en pratique valable que sur
de *gros* volumes de code. Sur des petits projets, C# atomise C++ (CLI
ou ISO) en temps de compilation :-(

Chez MS ils mettent aussi beaucoup l'accent sur l'optimisation. Le
compilo peut passer pas mal de temps à optimiser, pas le jiter...

--
Aurélien Regat-Barrel

AMHA, le gros atout de CLI par rapport à Java ne tient pas à
l'indépendance du langage, mais à la BCL (librairie de base, comme on
voudra l'appeler) qui est bien mieux foutue...

Moi je trouve que c'est là qu'il pèche justement.

Désolé, j'ai lu C++/CLI et non CLI.

--
Aurélien Regat-Barrel

"Michel Michaud" <mm@gdzid.com> writes:


[...]

| Je suppose que Java aussi est un échec alors...

Pas mal de gens qui ont utilisé Java sur de gros projets pensent cela.

-- Gaby

On Wed, 17 May 2006 01:22:44 -0400, "Michel Michaud" <mm@gdzid.com>:

Et le rapport avec le reste ? Désolé, mais je ne te suis plus.

Tu as coupé un peu trop -- j'avais laissé ta phrase "Je suppose que
Java aussi est un échec alors..."

(en fait, j'ai deux opinions sur
C++/CLI : le nom doit changer [...]

Inutile de poursuivre le débat, puisque nous sommes d'accord.

On Wed, 17 May 2006 16:05:25 +0200, Aurelien Regat-Barrel
<nospam.aregatba@yahoo.fr>:

"Comme ça on ne vendra plus de VC++", dixit le service *marketing*.

La tendance (ou au moins l'espoir de MS) est plutôt de vendre Visual
Studio comme un truc monobloc, non ?

Dans le message pxbu07q6o4l.fsf@news.bourguet.org,

L'ampleur des differentes est une admission implicite de l'echec de
CLI. CLI n'est pas une infrastructure qui peut etre commune aux
langages si un langage aussi repandu que C++ doit etre autant
modifie pour en profiter.

Un troll, non ?

Je ne veux pas défendre C++/CLI (même si j'en fais présentement :-),
mais dire que quelque chose qui n'est pas supporté directement par
C++ est un échec, ça me paraît gros ! Je suppose que Java aussi est
un échec alors...

Je pense que l'échec est le suivant :

Un des postulats de base de .NEt est que les différents langages de
programmation objet ne sont en fait pas si différents les uns des
autres, suffisemment peu différents pour qu'on puisse les mèler les une
les autres dans un même programme, grâce à une bas commune, le CLR.

Or, quand on regarde les langages compatibles .NET livrée pas Microsoft
dans visual studio 2005 :
- VB : Pas compatible avec les versions précédentes, et même pas de
convertisseur de code
- C# : Nouveau langage
- C++ : Nouveau langage qui à force de tours de passe-passe assez
impressionnants à regarder arrive à mèler des bouts de programme en C++
avec des bouts en .NET.

Force est de constater que non, les différences entre langages objets ne
sont pas si mineures que ça, et .NET, plutôt qu'un moyen d'unifier
différents langages, est plutôt un langage particulier avec différentes
syntaxes.

PS : Je fais aussi du C++/CLI actuellement pour interfacer du C++ et du
C#, et je trouve assez lourd la manière dont on peut réaliser une telle
interfacE. Il est par exemple bien plus simple d'interfacer du COM et du
.NET.

--
Loïc