OVH Cloud OVH Cloud

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
Arnold McDonald \(AMcD\)
Bertrand Lenoir-Welter wrote:

C'est un aveu !



Lol. C'est surtout une démonstration que les normes, c'est pas aussi génial,
obligatoire, inévitable qu'on croit.

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/
Avatar
Arnaud Debaene
Vincent Burel wrote:
"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é...)


Et bien tu n'as pas encore "tout vu", c'est tout....


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.


La norme ne s'addresse pas prioritairement aux développeurs (il n'y a pas
pire pour l'apprentissage par exemple), mais aux auteurs de compilateurs...

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.


??? Tu peux expliciter stp?

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".


Certes, mais si ce n'est pas les développeurs qui poussent pour encourager
la qualité logicielle dans l'entreprise, qui va le faire? Le service
qualité? Je rigole....

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


Tout à fait, et c'est vrai aussi du C++.

(et Microsoft à l'air de s'en
foutre légèrement).


Ah bon??? Pourquoi çà? si tu t'en tiens au C, Microsoft n'implémente pas
C99, mais il n'as jamais prétendu le faire non plus. A part çà, il me semble
bien que VC est 100% full compliant en ce qui concerne le C89...

Arnaud
MVP - VC
Avatar
Vincent Burel
"Arnaud Debaene" wrote in message
news:43b97711$0$27618$
> 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é...)
Et bien tu n'as pas encore "tout vu", c'est tout....



oui, c'est ce que je dis.

> 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.
??? Tu peux expliciter stp?



Non. pour plusieurs raisons :
- je ne te connais pas,
- j'ai autre chose à faire.
- ca ne m'apportera rien.
- Je ne comprends pas que tu me pose la question.

Bonne Année
VB
Avatar
adebaene
Vincent Burel a écrit :

"Arnaud Debaene" wrote in message
news:43b97711$0$27618$
> > Bien que je n'ai jamais vu d'équipe de dev de 100 personnes, (au de là
> > de 10 je croyais qu'on s'échangeait de la lib ou du module
> > compilé...)
> Et bien tu n'as pas encore "tout vu", c'est tout....

oui, c'est ce que je dis.

> > 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.
> ??? Tu peux expliciter stp?

Non. pour plusieurs raisons :
- je ne te connais pas,
- j'ai autre chose à faire.
- ca ne m'apportera rien.
- Je ne comprends pas que tu me pose la question.



Et bééé, ca c'est de l'argumentaire qui te rend crédible;-) Bonne
journée à toi aussi....

Arnaud
Avatar
Vincent Burel
wrote in message
news:


Et bééé, ca c'est de l'argumentaire qui te rend crédible;-)



crédible ? pourquoi faire ?

Bonne journée à toi aussi....



Merci

VB
Avatar
John Deuf
Bertrand Lenoir-Welter :

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.



Disons que ca ira beaucoup mieux que sans.

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...



Le logiciel n'est plus maintenu. Admettons qu'on veille sous-traiter une
bibliotheque a rajouter, le sous-traitant ne peut meme pas acheter la
licence du meme compilateur que toi.

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.



??
On est oblige de refaire le code parce que les particularites du compilo
sont dependantes du bon vouloir de l'editeur du logiciel, et que donc,
elles peuvent disparaitre du jour au lendemain. La norme par contre, est
assuree par un organisme independant (l'ISO) et il y a plein de compilo
sur le marche.

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.



Pour un projet d'un million de lignes ou de 50 ?
Dans une equipe de combien de personnes ?

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.



Dans une grosse boite, ce n'est jamais a toi de decider ce genre de
chose. La personne qui decide ca tu ne la connais meme pas.
En tant que programmeur professionnel, tu dois seulement produire du
code maintenable et reutilisable au mieux, parce qu'il y a 90% de chance
qu'il le soit.
De toute facon, dans la plupart des boites de developpement industriel,
le code non-ISO ne passe meme pas la revue de code (quand il compile).

Et si un autre programmeur doit faire evoluer ton code ?



Là, je vois pas le rapport.



Un autre programmeur qui connait le C++ (puisqu'on parle de la norme
C++) ne connait peut-etre pas les specificites du compilo que tu as cru
bon utiliser.

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.



Mon compilateur n'est pas de ton avis.
Du code bordelique mais qui respecte la norme, il se compile sur tous
les compilos conformes.
Par contre du code qui utilises des specificites du compilo, aussi clair
soit-il, il ne conpilera pas sur autre compilo.

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.



Ca ne resoud pas tout, mais ca tend vers cet objectif.

Ce qui dure en informatique n'a même plus
besoin de normes, et quand ça ne dure pas, la norme devient un boulet.



On a toujours besoin de normes.

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

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.



Non, ce n'est pas binaire.
Comme j'ai dis, appliquer la norme prend du temps.

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.



Je crois que tu confonds plusieurs choses. Une norme, ce n'est pas un
standard.

Une norme, c'est decrit par un organisme independant (l'ISO par exemple)
pour tenter d'uniformiser l'existant.
Ce n'est pas comme quand Microsoft tente d'imposer son wma pour raffler le
marche de la musique en ligne. Ca c'est meme le contraire d'une norme : ca
c'est un standard proprietaire et ferme.

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 ?



La norme c'est la base du langage !

Un exemple trivial, en c++, tu peux desallouer un pointeur NULL en
ecrivant delete(mon_pointeur). Ca, c'est la norme qui l'a decide, et tous
les compilo doivent adopter ce comportement.
Si la norme n'existait pas, comment tu programmerais en sachant qu'un
compilo peut accepter le delete(mon_pointeur) avec un pointeur NULL et que
sur un autre ca causera une operation illegale ? Ca devient ingerable.

Et le C++ est tellement complexe, avec le template, la surcharge, le
polymorphisme, la STL, etc. que si on ne connait pas exactement les
reactions d'un compilateur, ca cree beaucoup de problemes.

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é.



Non. Ton code vc++ sous Windows avec les entiers 64 bits "__int64", essaye
de le compiler avec BC++ (par exemple) toujours sous Windows, et bien il
va t'envoyer ballader. Ca depend bien du compilateur.

La norme ISO dit "long long" pour un entier 64 bits. Vc++ 7.1 le supporte,
mieux vaut utiliser celui-la.

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.



C'est sur que si le code est ecrit avec des __int64 et autres joyeusete
partout, on n'a pas le choix du compilateur lol

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 as l'air bien sur de toi. Les decideurs d'entreprises n'ont pas l'air
aussi confiants.

Et si un autre programmeur doit faire evoluer ton code ?



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



Tu commentes donc particulierement les specifites du compilo que tu
utilises ?

Bidouilleur ? Pourquoi de suite les insultes ?



Bizarre que tu prennes ca comme une insulte.

Personne ne suit les normes, surtout ceux qui veulent te
l'imposer.



Tous les programmeurs professionnels que je connais (et notamment ceux sur
fr.comp.lang.c++) suivent la norme au plus pres.

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.



A quelle norme ISO fais-tu references ?
Que je sache, les fonctions specifiques au systeme Windows sont tout sauf
normalisees.

Non, ici on parle d'informatique. Les normes en info c'est bidon.



Du bidon ?
Sans les normes, il n'a aurait pas d'informatique. Pas d'octets, pas
d'ascii, pas de vga, pas d'agp, etc...

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.



Ca permet a ton programme de supporter d'autres langues, comme l'arabe, le
russe...

--
John Deuf
Avatar
Bertrand Lenoir-Welter
John Deuf :

Disons que ca ira beaucoup mieux que sans.



Je pense qu'on est plus ou moins d'accord. Simplement, je pose en
préalable au respect des normes que c'est pas le problème numero 1 dans
un projet. Je parle d'un projet qui marche et qui se vend parce que les
clients en sont contents et donc l'achètent. Si la seule chose qui
compte c'est la norme, alors tout le monde passe son temps à vérifier
qu'il est bien dans la ligne officielle - pour peu qu'elle change pas
trop souvent - et il te faut des dizaines de gus pour faire le boulot de
5 personnes. Ce qui induit d'autres problèmes de maintenance, soit dit
en passant, et pas des moindres. Plus y'a de monde, plus il faut de
normes pour les faire cohabiter ; et plus y'a de normes, plus il faut de
monde pour coder.


Le logiciel n'est plus maintenu. Admettons qu'on veille sous-traiter une
bibliotheque a rajouter, le sous-traitant ne peut meme pas acheter la
licence du meme compilateur que toi.



Admettons, mais à force d'admettre, on arrive à spéculer les mouches sur
des cas de plus en plus restreints. J'ajoute que rien ne m'empêche de
fournir un compilo disparu à un sous-traitant hors licence. L'éditeur
qui a officiellement décidé d'abandonner son compilo sans assurer sa
maintenance et qui me poursuit devant une cour de justice parce que j'ai
été obligé de le prêter à un sous-traitant, il aura besoin d'un très
très bon avocat pour me causer du souci.

Argument rejeté.


On est oblige de refaire le code parce que les particularites du compilo
sont dependantes du bon vouloir de l'editeur du logiciel, et que donc,
elles peuvent disparaitre du jour au lendemain. La norme par contre, est
assuree par un organisme independant (l'ISO) et il y a plein de compilo
sur le marche.



Bon, j'ai acheté le Borland C++ 5.02 OWL en 1997. Borland l'a abandonné,
mais mon projet continue (un peu plus de 323 000 lignes de code, hein,
c'est pas un projet minuscule). J'ai sciemment décidé d'utiliser OWL
pour ne pas avoir à me fader l'encapsulage de l'API et réinventer la
roue. Evidemment, c'est hors normes, et en plus abandonné par Borland.
Tu remarques d'ailleurs que l'API elle-même contient un certain nombre
de trucs "NT only", "XP only", etc. On fait donc de la norme sur une
base système mouvante. Au risque de se tordre la cheville.

Alors tu fais quoi ? Tu rejettes tout ce qui n'est pas commun à tous les
compilos du marché ? C'est un point de vue certes prudent, mais tu vas
avoir du mal à créer - rapidement - un projet qui marche et se vend.

J'insiste que je n'ai rien contre les normes, mais que j'en rêve pas non
plus la nuit. Je prends ce qui me semble intéressant, et le reste, je
m'asseois dessus. Certes je peux me tromper et le regretter, mais si je
prends aucun risque, y'aura tout simplement pas de projet.


Dans une grosse boite, ce n'est jamais a toi de decider ce genre de
chose. La personne qui decide ca tu ne la connais meme pas.



Dépend des boîtes et des projets. J'ai même passé 2 ans chez IBM dans
une vie antérieure et c'est moi qui ai choisi mon compilo - détail dont
les pontifes se contrefoutaient totalement, ce qu'ils voulaient, c'était
que ça marche et vite. Bon, certes, c'était un cas exceptionnel.


En tant que programmeur professionnel, tu dois seulement produire du
code maintenable et reutilisable au mieux, parce qu'il y a 90% de chance
qu'il le soit.



Non. En tant que programmeur professionnel, je dois avant tout produire
du code qui marche et qui comporte les fonctionnalités fixées dans le
cahier des charges (plus celles que les petits génies qui "décident"
auront oublié, et c'est aussi mon métier que de le prévoir à leur
place). La maintenance et la réutilisation sont importantes, mais ça
passe après. En tout cas pour ce qui me concerne.


De toute facon, dans la plupart des boites de developpement industriel,
le code non-ISO ne passe meme pas la revue de code (quand il compile).



J'ai déjà vu du code qui passait et que le client nous renvoyait à la
figure avec des insultes parce que ça marchait pas génial. Que ça soit
programmé selon les normes ou pas, lui, il s'en fout un peu.


Un autre programmeur qui connait le C++ (puisqu'on parle de la norme
C++) ne connait peut-etre pas les specificites du compilo que tu as cru
bon utiliser.



Certes. Mais soit il est psychorigide, soit il peut se bouger le cul
pour les apprendre. Quand on m'a bombardé dans des équipes qui bossaient
selon la méthode Truc et le compilo Machin, même si je connaissais pas,
j'ai pas commencé par pousser des cris d'orfraie. Un programmeur qui ne
veut pas toucher un code qui ne cadre pas au point-virgule près avec ses
dogmes et idéaux cosmiques, il reste pas trois jours dans mon équipe. Je
suis pas assez couillon pour m'asseoir sur les normes, hein, parce qu'en
général c'est plutôt du bon sens, mais faut quand même pas en devenir
fondamentaliste. Y'a le bon sens aussi qui compte.

De toute façon, pour créer une appli C++ sous Windows, j'ai du mal à
imaginer qu'il y ait une Vérité Unique, ne serait-ce que parce que l'OS
lui-même a évolué et qu'on peut de moins en moins imposer la version
d'OS au client. Mon code tourne toujours de Win95 à XP, NT-4 compris. Je
me sers pas des truc spécifiques NT ou XP - et je le regrette parfois -
mais ça devrait t'indiquer que je crache pas sur le standard pour me
jeter sur la première API spécifique venue.

De là à considérer que c'est la seule chose qui compte dans un projet,
il y a un très très grand fossé.


Mon compilateur n'est pas de ton avis.



Mes compilateurs n'ont pas d'avis, ou quand ils en ont un, ils sont
assez aimables pour la fermer et faire ce que moi j'ai décidé. A leur
décharge, faut dire que je leur demande pas non plus l'impossible.


Du code bordelique mais qui respecte la norme, il se compile sur tous
les compilos conformes.



... et ne marche pas, donc ne se vend pas, donc te laisse sur le carreau
avec ta norme. Va dire au client qui hurle que ton code est strictement
conforme à la norme ISO, juste pour voir sa réaction.


Par contre du code qui utilises des specificites du compilo, aussi clair
soit-il, il ne conpilera pas sur autre compilo.



... mais peut très bien tourner proprement chez le client, lequel s'en
branle de savoir quel compilo a été utilisé et s'il existera encore
après-demain. Et je vois pas pourquoi, quand j'achète un compilo, je
devrais me préoccuper de savoir si d'autres compilos acceptent ou non le
code que je fais avec, puisque je les utiliserai jamais. Il me semble
que mon exemple de projet toujours maintenu avec un compilo datant de
1997 et abandonné depuis 1998 si je ne m'abuse devrait assez le démontrer.


Mais j'ai un peu l'impression qu'on joue le fond contre la forme, là.


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.



Ca ne resoud pas tout, mais ca tend vers cet objectif.



Quel objectif ? L'utopie ou l'intégrisme ?

Bon, pas crier. J'déconne.


On a toujours besoin de normes.



Ca, je parie que c'est une citation de Pol Pot. J'ai bon ?
Avatar
Bertrand Lenoir-Welter
John Deuf :

Je crois que tu confonds plusieurs choses. Une norme, ce n'est pas un
standard.



Ca, ça demande un peu de développement. Parce que tu fais abondamment
référence à l'ISO qui comme son nom l'indique, s'occupe de standardiser.


Une norme, c'est decrit par un organisme independant (l'ISO par exemple)
pour tenter d'uniformiser l'existant.
Ce n'est pas comme quand Microsoft tente d'imposer son wma pour raffler le
marche de la musique en ligne. Ca c'est meme le contraire d'une norme : ca
c'est un standard proprietaire et ferme.



Ok, l'API Windows n'est pas un standard puisque c'est du privé. Donc,
quand on programme une appli destinée exclusivement à tourner sous
Windows, on n'a pas à en tenir compte. C'est un point de vue.

A mon avis, peu importe qu'un standard - ou une norme, je sais plus -
soit édictée par l'ISO, l'IEEE ou par une vilaine boîte privée qui veut
gagner des sous avec (qui a commis le format GIF, au fait ?), du moment
que tout le monde s'en sert.


Tu as l'air bien sur de toi. Les decideurs d'entreprises n'ont pas l'air
aussi confiants.



Tiens, ça me rappelle les très longues hésitations de
Schneider-Automation pour passer d'OS/2 à Windows. Heureusement pour
eux, ils ont fini par se décider.

Plus sérieusement, les décideurs qui se contentent de suivre
frileusement sont nombreux, mais c'est pas leurs produits qui font boum
sur le marché. Plutôt ceux des voisins qui, eux, ont décidé de prendre
quelques risques et casser les académismes.


Tu commentes donc particulierement les specifites du compilo que tu
utilises ?



Press F1. En haut à gauche sur le clavier normalisé.


Tous les programmeurs professionnels que je connais (et notamment ceux sur
fr.comp.lang.c++) suivent la norme au plus pres.



Je me disais aussi...

Question bête : combien d'entre eux ont déjà mis le nez hors de leur
labo universitaire pour créer un truc qui, tout simplement, se vendait ?


A quelle norme ISO fais-tu references ?
Que je sache, les fonctions specifiques au systeme Windows sont tout sauf
normalisees.



Là, ça devient surréaliste.

Tu te rends compte de ce que tu écris ?


Sans les normes, il n'a aurait pas d'informatique. Pas d'octets, pas
d'ascii, pas de vga, pas d'agp, etc...



Les octets ont été définis par une société privée. L'ASCII a longtemps
été concurrent d'EBCDIC. Le VGA était une idée IBM, etc.

Finalement, la norme, c'est ce qui marche. Peu importe qui la crée.


Ca permet a ton programme de supporter d'autres langues, comme l'arabe, le
russe...



Pour lesquelles il ne sera jamais compilé. Ca lui fait une belle jambe.
Avatar
Arnold McDonald \(AMcD\)
Laisse tomber. Je me demande s'il sait seulement programmer.

--
Arnold McDonald (AMcD)

http://arnold.mcdonald.free.fr/
1 2 3 4 5