Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

compatibilité VC60 et VC.Net c++ library (MFC / ATL)

57 réponses
Avatar
Vincent Burel
hello

Avec VC.NET , il semble que Microsoft ait modifié pas mal de libraries,
notamment C++ (MFC 70 et ATL) et ait ajouté quelques raffinement au langage
(keyword super / __super par exemple)... qui posent divers problemes de
portage / partage de projet VC.NET - VC 6.0.

Sans compter le fait que VC-Net est conçu pour etre multiplatforme (IA32
IA64 etc...), est-il quand même possible d'envisager une compatibilité
descendante VC 60 sur certains composants : Par exemple d'utiliser MFC 7.0
avec VC 6.0 ?

Vincent Burel
PS : Bonne année.
PS : oui, 2006 sera studieuse

10 réponses

1 2 3 4 5
Avatar
Arnaud Debaene
Vincent Burel wrote:
hello

Avec VC.NET , il semble que Microsoft ait modifié pas mal de
libraries, notamment C++ (MFC 70 et ATL) et ait ajouté quelques
raffinement au langage (keyword super / __super par exemple)... qui
posent divers problemes de portage / partage de projet VC.NET - VC
6.0.



Les quelques keywords ajoutés au C++ natif (mais aussi pour le C++ managé)
dans VC.NET sont des mots réservés par la norme C++ (ils commencent par "__"
ou par "_" suivi d'une majuscule et sot donc réservés pour
l'implémentation). Normalement, tu ne les as donc pas utilisés dans ton
code....

Sans compter le fait que VC-Net est conçu pour etre multiplatforme
(IA32 IA64 etc...),


Tu parles du C++ managé là? Si tu te lances là dedans, il faut bien
comprendre que ce n'est plus du C++ "standard" du tout.... (et à tout
prendre, si tu est intéressé par le sujet, utilises tout de suite C++/CLI
qui vient avec VC2005, tu sera nettement moins embêté par la syntaxe...)

est-il quand même possible d'envisager une
compatibilité descendante VC 60 sur certains composants : Par exemple
d'utiliser MFC 7.0 avec VC 6.0 ?



Non : les MFC et les ATL version 7 utilisent les nouveaux éléments de
conformance à la norme du compilateur et ne compileront pas avec VC6 (et tu
ne peux pas utiliser las binaires, parce que le mangling n'est pas le même
entre les 2 compilos).

Qu'est ce qui t'embête exactement que tu n'arrive pas à compiler avec VC7 et
qui passait avec VC6 ? 99 fois sur 100, c'est du code incorrect selon la
norme qui passait avec VC6, mais VC7 est moins permisif : c'est une occasion
de faire un peu de ménage dans ton code!

Arnaud
MVP - VC
Avatar
Vincent Burel
"Arnaud Debaene" wrote in message
news:43b81dd4$0$21053$
Vincent Burel wrote:
> hello
>
> Avec VC.NET , il semble que Microsoft ait modifié pas mal de
> libraries, notamment C++ (MFC 70 et ATL) et ait ajouté quelques
> raffinement au langage (keyword super / __super par exemple)... qui
> posent divers problemes de portage / partage de projet VC.NET - VC
> 6.0.

Les quelques keywords ajoutés au C++ natif (mais aussi pour le C++ managé)
dans VC.NET sont des mots réservés par la norme C++ (ils commencent par


"__"
ou par "_" suivi d'une majuscule et sot donc réservés pour
l'implémentation). Normalement, tu ne les as donc pas utilisés dans ton
code....

> Sans compter le fait que VC-Net est conçu pour etre multiplatforme
> (IA32 IA64 etc...),
Tu parles du C++ managé là? Si tu te lances là dedans, il faut bien
comprendre que ce n'est plus du C++ "standard" du tout.... (et à tout
prendre, si tu est intéressé par le sujet, utilises tout de suite C++/CLI
qui vient avec VC2005, tu sera nettement moins embêté par la syntaxe...)

> est-il quand même possible d'envisager une
> compatibilité descendante VC 60 sur certains composants : Par exemple
> d'utiliser MFC 7.0 avec VC 6.0 ?

Non : les MFC et les ATL version 7 utilisent les nouveaux éléments de
conformance à la norme du compilateur et ne compileront pas avec VC6 (et


tu
ne peux pas utiliser las binaires, parce que le mangling n'est pas le même
entre les 2 compilos).

Qu'est ce qui t'embête exactement que tu n'arrive pas à compiler avec VC7


et
qui passait avec VC6 ? 99 fois sur 100, c'est du code incorrect selon la
norme qui passait avec VC6, mais VC7 est moins permisif : c'est une


occasion
de faire un peu de ménage dans ton code!



Mouai, il faut que tu sache qu'usuellement je programme en C, genre 1980 old
style, et que pour qu'un compilo ne me comprenne pas il faut qu'il ait été
sortie avant ma naissance... Cependant il m'arrive (quand je travaille pour
d'autre boite) d'utiliser, d'user, d'abuser même de code source exotiques
comme le ++ le -- le +- le +=0 le 000 et même parfois le +-+-... que
jusqu'ici, mon VC6 arrivait à comprendre, parfois en faisant quelques
adaptations.

Note que le standard, je connais pas, pour moi il existe 2 choses : ce que
mon compilo comprend, et ce que mon compilo ne comprend pas. Et là je suis
déçu par mon VC++ 6.0 SP 6... Même avec le Platform SDK 2003.

Bref, allons au but, suis-je obligé d'acheter VC7 pour compiler du code VC7
? ou y'a t'il des exception ? Pourquoi ne pourrait on pas utiliser MFC 7
avec VC 6 par exemple ?

VB
Avatar
Arnold McDonald \(AMcD\)
Vincent Burel wrote:

Cependant il m'arrive
(quand je travaille pour d'autre boite) d'utiliser, d'user, d'abuser
même de code source exotiques comme le ++ le -- le +- le +=0 le 000
et même parfois le +-+-... que jusqu'ici, mon VC6 arrivait à
comprendre, parfois en faisant quelques adaptations.



Ouah, du ++ ! T'es plus avancé que moi, j'en suis encore au inc eax moi :-).

Note que le standard, je connais pas, pour moi il existe 2 choses :
ce que mon compilo comprend, et ce que mon compilo ne comprend pas.



Ouaip, +1. Je le dis poliment, ils nous gonflent avec leurs standards, leurs
normes, que chacun respecte finalement comme mon lui semble ou adapte à sa
sauce. De plus, c'est souvent du verbiage de marketeux plus que des avancées
indispensables. Et ne parlons pas des normes qui changent tous les ans.
Bizarre, je croyais qu'on devait tendre vers de l'info portable :-).

Moi, ce qui m'intéresse, c'est de connaître les possibilités de mes
compilos. Qu'ils respectent ISO schmiltruc ou ANSI trabzac ne présente aucun
intérêt. Ce qui compte au final, c'est de savoir si la plate-forme cible
pourra faire tourner l'appli développée, sous quelle contrainte, etc.

Exemple, stupide, les entier 64 bits de Kro sont pas norme ISO flambant neuf
? Bah oui, mais j'ai besoin d'entier 64 bits moi, alors, je les utilise et
ça tourne parfaitement sur les OS Kro. C'est tout ce qui m'importe. Je ne
fais pas de l'art ou de la démo universitaire, je code.

Na.

Bonne année à tous les vieux briscards d'ici sinon. Aux autres aussi
d'ailleurs, allez, faites péter vos TD et TP :-).

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/
Avatar
John Deuf
Arnold McDonald (AMcD) :

Ouaip, +1. Je le dis poliment, ils nous gonflent avec leurs standards,
leurs normes, que chacun respecte finalement comme mon lui semble ou
adapte à sa sauce.



Mettre une compilo a la norme prend du temps. En ce qui concerne VC++,
je crois qu'il y arrive a 99% pour le C++.

De plus, c'est souvent du verbiage de marketeux
plus que des avancées indispensables.



Le but de la norme n'est pas de faire progresser le langage, mais
d'homogeneiser l'existant.

Moi, ce qui m'intéresse, c'est de connaître les possibilités de mes
compilos.



C'est une information que la norme t'apporte.
Si tu dois travailler sur un compilo que tu ne connais pas, mais qui est
conforme, tu connais d'emblee non seulement ses possibilites mais aussi
son comportement.

Ce qui compte au final, c'est de savoir si la
plate-forme cible pourra faire tourner l'appli développée, sous quelle
contrainte, etc.



C'est exactement le travail de la norme de t'aider a ces choses la.
Elle concerte editeurs de logiciels, utilisateurs industriels et
universitaires pour que tout ca s'harmonise.
En d'autres termes, elle rend le boulot plus facile.

Exemple, stupide, les entier 64 bits de Kro sont pas norme ISO
flambant neuf ?



Si, ils sont conformes. La norme iso C++ indique la taille des int est
du ressort de l'implementation.

Bah oui, mais j'ai besoin d'entier 64 bits moi, alors,
je les utilise et ça tourne parfaitement sur les OS Kro.



Non, ca ne tourne qu'avec vc++ dans une version donnee.

Et si ton entreprise t'impose de changer de compilateur ou d'OS ?
Ou si, tout simplement, vc++ cesse d'exister ou change de version ?
Tu ira expliquer a ton patron que tu dois refaire le logiciel de 1000
heures de boulot parce que t'es amuse a faire un programme avec des
particularites du compilo ?
Et si un autre programmeur doit faire evoluer ton code ?

Bonne année à tous les vieux briscards d'ici sinon. Aux autres aussi
d'ailleurs, allez, faites péter vos TD et TP :-).



Tu es peut-etre un bidouilleur passionne, mais tu n'as pas l'air d'avoir
travaille en industrie, avec une equipe de developpement de 100
personnes, des revues de code, et sur plateformes heterogenes. Parce que
la tu verrais tout de suite l'interet de la norme.

De la meme maniere, j'espere que tu vois l'interet de la norme iso pour
les prises electriques par exemple ? Tu vas me repondre, "je m'en fout
je soude les fils dont j'ai besoin" ?

--
John Deuf
Avatar
Arnold McDonald \(AMcD\)
John Deuf wrote:

Mettre une compilo a la norme prend du temps. En ce qui concerne VC++,
je crois qu'il y arrive a 99% pour le C++.



Puisque tu veux chippoter, alors allons-y ! 99 % ? Ben c'est nul ! Ou on
respecte ou on respecte pas, il n'y a pas de "presque". Dire on est à 99 %
de la norme est ridicule. Soit tu l'es à 100% et oui, t'es à la norme, soit
tu l'est pas.

Le but de la norme n'est pas de faire progresser le langage, mais
d'homogeneiser l'existant.



Tatata. Le but des normes est d'imposer SES standards de la part des gros
pontes du milieu.

C'est une information que la norme t'apporte.
Si tu dois travailler sur un compilo que tu ne connais pas, mais qui
est conforme, tu connais d'emblee non seulement ses possibilites mais
aussi son comportement.



Non. Moi, je choisis un compilo en fonction de son ergonomie, des APIs qu'il
me permet d'interfacer, de son éditeur (en tant que société), de l'aide
disponible, des mise à jour, de son évolution possible, des cibles
compilabes, etc. La norme ? Mais je m'en moque mon pauvre ami, que t'as pas
idée. Quelle norme déjà ? Celle des langages ? Celles de sécurité ? ISO ?
ANSI ?

Bah oui, mais j'ai besoin d'entier 64 bits moi, alors,
je les utilise et ça tourne parfaitement sur les OS Kro.





Non, ca ne tourne qu'avec vc++ dans une version donnee.



Non, ça tourne sous un OS donné à la limite si tu veux. Donc au pire, c'est
du code dédié.

Et si ton entreprise t'impose de changer de compilateur ou d'OS ?



Cela n'est faisable qu'en toute intelligence. Le gars qui va décider de
changer de compilo pour une équipe, il doit bien calculer son coup.

Ou si, tout simplement, vc++ cesse d'exister ou change de version ?



Les compilos Kro disparaître ? Faut arrêter l'alcool là, les fêtes sont
passées :-).

Tu ira expliquer a ton patron que tu dois refaire le logiciel de 1000
heures de boulot parce que t'es amuse a faire un programme avec des
particularites du compilo ?



Ha la sacro-sainte utopie du code portable... Je ne fais pas mumuse avec les
spécificités ultra-spécifiques d'un compilo, j'essaye autant que je peux
d'utiliser du classique. Mais quand la vénérée norme ne me le permet pas,
j'utilise du spécifique.

Et si un autre programmeur doit faire evoluer ton code ?



Mon code est abondamment commenté, cela ne poserait aucun problème.

Tu es peut-etre un bidouilleur passionne, mais tu n'as pas l'air
d'avoir travaille en industrie, avec une equipe de developpement de
100 personnes, des revues de code, et sur plateformes heterogenes.
Parce que la tu verrais tout de suite l'interet de la norme.



Je dis que la norme, chacun la suit à sa manière. Ce n'est que mon avis.
Bidouilleur ? Pourquoi de suite les insultes ? Moi, c'est le hack, la sécu,
le système, l'assembleur, etc. La norme, ça me fait rire. Personne ne suit
les normes, surtout ceux qui veulent te l'imposer. Allez tiens, simple
exemple dont je discutais il y a peu avec des gars de ce forum. Désassemble
quelques bouts du kernel de Windows, tu avs voir comment ils respectent les
normes, tu avs bien rire ! C'est truffé d'appels de fonctions soit-disant
deprecated, de bits soit-disant ignored et autres. T'as l'impression que
tout ce qui est déconseilé dans le MSDN est inversement mis en oeuvre dans
le code de l'OS :-). Le suivi des normes ? Lol.

De la meme maniere, j'espere que tu vois l'interet de la norme iso
pour les prises electriques par exemple ? Tu vas me repondre, "je
m'en fout je soude les fils dont j'ai besoin" ?



Non, ici on parle d'informatique. Les normes en info c'est bidon. 10 ans
après le CSS2 qui le suit à 100% ? personne ! Des processeurs aux softs en
passant par les OS chacun fait sa tambouille en essayant d'imposer ses
propres standards. Je ne dis pas que les normes sont inutiles, je ne suis
pas débile non plus. Je me place dans le contexte de l'informatique, où le
grand n'importe quoi règne. Oui, c'est bien que les langages soient normés,
que des tentatives soient faites au niveau de l'uniformisation, etc. Oui, le
libre c'est génial, le free encore mieux ! Mais voilà, arrêtez de vouloir
idéaliser l'informatique, c'est un monde de fric, géré pour gagner encore
plus de fric. Alors, les normes... ce sont avant tout des prétextes de
légitimisation, de caution.

Allez, dernier exemple dont nous discutions il y a 2-3 jours ici, l'UNICODE.
Tout mon code est à la norme UNICODE, ce nouveau standard a absolument
suivre pour être full compatible gnagnagna. Pourtant ça ne sert foncièrement
strictement à rien du tout. Donc, je réitère, les normes informatiques ?
Lol.

On parle d'OpenGL ? Et vas-y que chaque fabricants tente d'imposer ses
fonctions propres à al norme !

On parle de réseau ? De routeurs ? C'est partout pareil !

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/
Avatar
Arnaud Debaene
Vincent Burel wrote:

Mouai, il faut que tu sache qu'usuellement je programme en C, genre
1980 old style, et que pour qu'un compilo ne me comprenne pas il faut
qu'il ait été sortie avant ma naissance... Cependant il m'arrive
(quand je travaille pour d'autre boite) d'utiliser, d'user, d'abuser
même de code source exotiques comme le ++ le -- le +- le +=0 le 000
et même parfois le +-+-... que jusqu'ici, mon VC6 arrivait à
comprendre, parfois en faisant quelques adaptations.

Note que le standard, je connais pas, pour moi il existe 2 choses :
ce que mon compilo comprend, et ce que mon compilo ne comprend pas.
Et là je suis déçu par mon VC++ 6.0 SP 6... Même avec le Platform SDK
2003.


Le Platform SDK ne change rien à ton compilateur....


Bref, allons au but, suis-je obligé d'acheter VC7 pour compiler du
code VC7 ? ou y'a t'il des exception ? Pourquoi ne pourrait on pas
utiliser MFC 7 avec VC 6 par exemple ?



Je l'ai déjà dit!
- les sources des MFC7 ne compilent pas sous VC6.
- les ersions binaires ne sont pas compatibles.

Tu ne nous a toujours pas dit quel est le problème concret que tu cherches à
résoudre...

Arnaud
MVP - VC




VB


Avatar
Bertrand Lenoir-Welter
AMcD :

Tout mon code est à la norme UNICODE, ce nouveau standard a absolument
suivre pour être full compatible gnagnagna. Pourtant ça ne sert foncièrement
strictement à rien du tout.




C'est un aveu !
Avatar
Bertrand Lenoir-Welter
John Deuf :

Et si ton entreprise t'impose de changer de compilateur ou d'OS ?



De deux choses l'une : soit ils ont conscience de la tâche que ça
représente et mettront les moyens et le temps, soit vaut mieux changer
d'entreprise.

J'ai vécu le passage d'OS/2-PM à Windows dans une boîte où il y avait
une petite centaine de développeurs. C'était pas trop mal organisé et
pourtant ça a été le souk. Justement parce qu'on était nombreux et qu'on
avancait pas à la même vitesse.

Penser que, parce qu'on respecte la norme Truc et la méthode Machin,
tout va aller pour le mieux dans le meilleur des mondes possibles est
une utopie d'universitaire ou de chef de département. Dans la salle des
machines, ça marche rarement comme on l'imagine sur la passerelle.


Ou si, tout simplement, vc++ cesse d'exister ou change de version ?



Et après ? Je continue de faire vivre un gros projet que je recompile
chaque semaine avec Borland C++ 5.02, sorti en 1997. Où est le problème
? Démodé ? La belle affaire...


Tu ira expliquer a ton patron que tu dois refaire le logiciel de 1000
heures de boulot parce que t'es amuse a faire un programme avec des
particularites du compilo ?



Si le fait d'utiliser des particularités du compilo t'oblige à refaire
tout ton code et non pas modifier juste ces particularités, mieux vaut
changer de métier. J'ai porté du code BC (avec particularités genre OWL)
vers VC (avec autres particularités genre MFC) et ça n'a pas été la fin
du monde.

Maintenant, si tu dois prévoir dès le départ qu'on va te demander ça, tu
codes en intégrant ton propre isolant. On change l'interface ; on garde
le coeur.


Et si un autre programmeur doit faire evoluer ton code ?



Là, je vois pas le rapport.


Tu es peut-etre un bidouilleur passionne, mais tu n'as pas l'air d'avoir
travaille en industrie, avec une equipe de developpement de 100
personnes, des revues de code, et sur plateformes heterogenes. Parce que
la tu verrais tout de suite l'interet de la norme.



J'ai bossé dans plusieurs grosses boîtes avec plusieurs grosses équipes
de développement, et j'ai jamais vu un changement de compilo ou d'OS se
passer tout seul ni se rater complètement. Tu prends un codeur hors
normes qui code de façon claire et organisée, ça passera facilement. Tu
prends un codeur qui code de façon bordélique, tout en respectant les
diverses normes et méthodes, et ça coincera de toute façon. La norme,
c'est rien qu'un outil, et ça t'empêche pas de t'en mettre un bon coup
sur les doigts.

Je suis pas contre les normes, hein, ça aide bien évidemment à
travailler en groupe ou à passer le flambeau aux suivants. De là à
croire que ça résoud forcément les problèmes de portage, c'est de
l'utopie ou de l'intégrisme. Ce qui dure en informatique n'a même plus
besoin de normes, et quand ça ne dure pas, la norme devient un boulet.

Ce n'est que mon avis et depuis 12 ans je travaille seul.


De la meme maniere, j'espere que tu vois l'interet de la norme iso pour
les prises electriques par exemple ? Tu vas me repondre, "je m'en fout
je soude les fils dont j'ai besoin" ?



Drôle d'exemple... Quelles prises ? Américaines ? Anglaises ? Françaises
? Italiennes ? Allemandes ? Suédoises ? :-D
Avatar
Vincent Burel
"Arnaud Debaene" wrote in message
news:43b8d096$0$4354$
> Vincent Burel wrote:
> Bref, allons au but, suis-je obligé d'acheter VC7 pour compiler du
> code VC7 ? ou y'a t'il des exception ? Pourquoi ne pourrait on pas
> utiliser MFC 7 avec VC 6 par exemple ?

Je l'ai déjà dit!
- les sources des MFC7 ne compilent pas sous VC6.
- les ersions binaires ne sont pas compatibles.



ok, merci.

Tu ne nous a toujours pas dit quel est le problème concret que tu cherches


à
résoudre...



Alors je te le dis pour la 3ieme fois : j'ai des sources venant de VC7 à
intégré dans des projets et jai pas VC7.


VB
Avatar
Vincent Burel
"John Deuf" wrote in message
news:
Arnold McDonald (AMcD) :



Tu es peut-etre un bidouilleur passionne, mais tu n'as pas l'air d'avoir
travaille en industrie, avec une equipe de developpement de 100
personnes, des revues de code, et sur plateformes heterogenes. Parce que
la tu verrais tout de suite l'interet de la norme.



Bien que je n'ai jamais vu d'équipe de dev de 100 personnes, (au delà de 10
je croyais qu'on s'échangeait de la lib ou du module compilé...) je dirais
"oui et non", la norme est trop lourde et trop complexe pour présenter de
réel intérêt dans la production de code source. Rien qu'en C par exemple, si
il n'y a pas de loi drastique (beaucoup plus stricte que la norme) limitant
les effets de style et rafinnement syntaxique, alors ca sera la cata. Et
pour connaitre le milieu pro (des l'équipe de 4 à 10 programmeurs), la norme
en vigueur c'est bien celle du compilo, la méthode de programmation c'est
FFF (First Function Found) et la devise c'est "dépèche toi faut livrer".

De la meme maniere, j'espere que tu vois l'interet de la norme iso pour
les prises electriques par exemple ? Tu vas me repondre, "je m'en fout
je soude les fils dont j'ai besoin" ?



C'est chouette les normes, mais il faut savoir à qui ca s'adresse. La norme
"C" ne s'adresse pas en premier lieu au programmeurs, elle s'adresse à ceux
qui font les compilo (et Microsoft à l'air de s'en foutre légèrement).
Ensuite le programmeurs fait ce qu'il veut... c'est la force du "C".

VB
1 2 3 4 5