compatibilité VC60 et VC.Net c++ library (MFC / ATL)
57 réponses
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
"Arnold McDonald (AMcD)" wrote in news:43c28285$0$19117$:
Oui, ce n'est pas mathématique, mais il faut savoir désolidariser la théorie et l'informatique réelle.
a = a+1 ça fait criser les puristes mathématiciens aussi. Au moins avec une notation genre a := a+1 on n'a pas ce genre de problème, vu que le symbole est plus symétrique on est pas tentés de dire la même chose de la relation.
Par contre == en C est bien une relation d'équivalence (sur les entiers) ;-)
-- Cyrille Szymanski
"Arnold McDonald (AMcD)" <killspammers@free.fr> wrote in
news:43c28285$0$19117$636a15ce@news.free.fr:
Oui, ce n'est pas mathématique, mais il faut savoir désolidariser la
théorie et l'informatique réelle.
a = a+1 ça fait criser les puristes mathématiciens aussi. Au moins avec une
notation genre a := a+1 on n'a pas ce genre de problème, vu que le symbole
est plus symétrique on est pas tentés de dire la même chose de la relation.
Par contre == en C est bien une relation d'équivalence (sur les entiers)
;-)
"Arnold McDonald (AMcD)" wrote in news:43c28285$0$19117$:
Oui, ce n'est pas mathématique, mais il faut savoir désolidariser la théorie et l'informatique réelle.
a = a+1 ça fait criser les puristes mathématiciens aussi. Au moins avec une notation genre a := a+1 on n'a pas ce genre de problème, vu que le symbole est plus symétrique on est pas tentés de dire la même chose de la relation.
Par contre == en C est bien une relation d'équivalence (sur les entiers) ;-)
certes, et la norme dis que l'évaluation boléenne de la valeur 0 donne FALSE. mais encore une fois c'est la norme qui le dit, y'a des compilo
qui
font une évaluations boléenne sur le bit 0 (ce qui reviens à considérer
tout
les pointeurs paires comme NULL)
Juste par curiosité, quel est ce compilateur ?
je ne sais plus, et a y bien y réfléchir, c'était peut-être pas un compilo "c" , mais ASM. Quand on programme des DSP, on mélange souvent C, ASM... et quand il faut optimiser, on a tendance à suivre les contraintes du processeur plutot que celle de la norme "C" d'autant qu'on prépare souvent les data en "C" pour faire un process en ASM....
VB
<halfwolf@free.fr> wrote in message
news:1136818235.900673.64960@g14g2000cwa.googlegroups.com...
Vincent Burel wrote:
certes, et la norme dis que l'évaluation boléenne de la valeur 0 donne
FALSE. mais encore une fois c'est la norme qui le dit, y'a des compilo
qui
font une évaluations boléenne sur le bit 0 (ce qui reviens à considérer
tout
les pointeurs paires comme NULL)
Juste par curiosité, quel est ce compilateur ?
je ne sais plus, et a y bien y réfléchir, c'était peut-être pas un compilo
"c" , mais ASM. Quand on programme des DSP, on mélange souvent C, ASM... et
quand il faut optimiser, on a tendance à suivre les contraintes du
processeur plutot que celle de la norme "C" d'autant qu'on prépare souvent
les data en "C" pour faire un process en ASM....
certes, et la norme dis que l'évaluation boléenne de la valeur 0 donne FALSE. mais encore une fois c'est la norme qui le dit, y'a des compilo
qui
font une évaluations boléenne sur le bit 0 (ce qui reviens à considérer
tout
les pointeurs paires comme NULL)
Juste par curiosité, quel est ce compilateur ?
je ne sais plus, et a y bien y réfléchir, c'était peut-être pas un compilo "c" , mais ASM. Quand on programme des DSP, on mélange souvent C, ASM... et quand il faut optimiser, on a tendance à suivre les contraintes du processeur plutot que celle de la norme "C" d'autant qu'on prépare souvent les data en "C" pour faire un process en ASM....
VB
Christian ASTOR
Arnold McDonald (AMcD) wrote:
Cela est pourtant simple. Si tu fais une erreur de frappe, lp = NULL sera pris en compte et t'affecteras une valeur NULL à ton pointeur. Ce genre d'erreur m'est arrivé 500 fois dans ma vie. Et c'est ultra-pénible à déceler vu que le compilo bronche pas.
BTW, VC++ bronche (Level 4)...
Arnold McDonald (AMcD) wrote:
Cela est pourtant simple. Si tu fais une erreur de frappe, lp = NULL sera
pris en compte et t'affecteras une valeur NULL à ton pointeur. Ce genre
d'erreur m'est arrivé 500 fois dans ma vie. Et c'est ultra-pénible à déceler
vu que le compilo bronche pas.
Cela est pourtant simple. Si tu fais une erreur de frappe, lp = NULL sera pris en compte et t'affecteras une valeur NULL à ton pointeur. Ce genre d'erreur m'est arrivé 500 fois dans ma vie. Et c'est ultra-pénible à déceler vu que le compilo bronche pas.
Je ne compile plus grand chose... Mais sinon, oui, justement pour les "==", car ds quasi tous les autres langages, c'est "=", donc on se plante facilement sur cette particularité.
Arnold McDonald (AMcD) wrote:
BTW, VC++ bronche (Level 4)...
Wep. Mais bon, tu compiles en level 4 toi ?
Je ne compile plus grand chose...
Mais sinon, oui, justement pour les "==", car ds quasi tous les autres
langages, c'est "=", donc on se plante facilement sur cette particularité.
Je ne compile plus grand chose... Mais sinon, oui, justement pour les "==", car ds quasi tous les autres langages, c'est "=", donc on se plante facilement sur cette particularité.