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

<halfwolf@free.fr> wrote in message
news:1136542392.870611.307320@z14g2000cwz.googlegroups.com...

Vincent Burel wrote:

<halfwolf@free.fr> wrote in message
news:1136461969.657431.210780@g43g2000cwa.googlegroups.com...

Vincent Burel a écrit :

> Remarques que beaucoup écrirait :
> if (mon_pointeur) delete(mon_pointeur);
>
> Alors là c'est pire, car l'opération logique peut varier d'un compilo à
> l'autre (certains compilo ne considère que le bit 0), la valeur du
pointeur
> null peut ne pas etre ZERO d'un systeme à l'autre.

>Je n'ai pas très bien compris ce que tu veux dire.
> Est-ce que tu veux dire que c'est le compilateur qui est en faute car
> il fait une supposition erronée sur l'implémentation physique du
> pointeur NULL et que dans ce cas, vu qu'il y a des compilateurs
> buggués, il vaut mieux faire un test explicite ?

Je ne parle pas de compilateur buggé, je parle de certains compilo

"c/c++"

(notamment pour DSP) qui peuvent faire une évaluation bolean sur un seul

bit

(considéré comme FALSE si le bit 0 est à 0) et non pas sur la valeur
complete. Ecrire "if(mon_pointeur)" c'est considérer que "mon_pointeur"

est

un bolean ou bien qu'il possède toutes les propriétés d'un bolean (ce qui
est largement faux).

il n'y pas d'implementation physique du pointeur NULL. NULL est un define
qui sous Windows est egal à ZERO. mais qui pourrait etre égal à

0x00000010,

car cette adresse là non plus n'est pas valide. pourquoi pas !? y'a des
systemes ou les pointeurs d'objets sont des indices basés sur zéro et où

le

pointeur null est -1 = 0xFFFFFFFF.

Je ne sais pas en C++ mais en C il est garanti que NULL vaut (void*)0
par la Norme (et je pense que ça doit être pareil en C++).
Si la représentation en mémoire du pointeur est 0xFFFFFFFF le
compilateur fait l'abstraction. Donc le cas que tu décris serait un
bug du compilateur. D'où mon incompréhension sur le sens exact de ta
phrase.

Je comprends pas tout non plus . Tu parle de quel pointeur ? le compilo
ferait abstration de quoi ? et ton incompréhension s'applique à laquelle de
mes phrase ? Et tant que j'y suis, comment tu t'appelle ?

VB

D'après Bertrand Lenoir-Welter <bertrand-dot-2006-at-galaad-dot-net>:

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.

«Heureusement», c'est une question de goût.
Ils ont surtout décidé de _ne pas maintenir_ leurs logiciels.

Je préfère encore et de loin l'atelier XTEL aux immondes logiciels de
développement qui sont sortis sous MS-Windows ensuite : buggés, instables
et avec un manque d'ergonomie poussé à l'extrême.

Et je n'ose mentionner toutes les versions sorties pour DOS, Windows 3.1,
Windows 9x totalement incompatibles avec NT, les versions NT incompatibles
avec W2K et XP...

Ce qui, pour maintenir un parc matériel, demande à maintenir un parc
logiciel de quinze ans, systèmes d'exploitations compris.

David MAREC :

«Heureusement», c'est une question de goût.

Ouais, z'auraient mieux fait de rester avec OS/2. Un système qui
n'évolue plus, c'est Byzance pour les équipes de développeurs.

Bon, certes, question marché, c'est moins bien.

Je préfère encore et de loin l'atelier XTEL aux immondes logiciels de
développement qui sont sortis sous MS-Windows ensuite : buggés, instables
et avec un manque d'ergonomie poussé à l'extrême.

Ca, c'est depuis que je suis parti. Tout à foutu le camp ensuite.

Ce qui, pour maintenir un parc matériel, demande à maintenir un parc
logiciel de quinze ans, systèmes d'exploitations compris.

Tu suggères quoi ? Ils auraient dû comprendre dès 1989 qu'OS/2 était une
impasse et que Windows 2 allait prendre le pas ?

Moi j'aimais bien OS/2.

D'après Bertrand Lenoir-Welter :

Je préfère encore et de loin l'atelier XTEL aux immondes logiciels de
développement qui sont sortis sous MS-Windows ensuite : buggés, instables
et avec un manque d'ergonomie poussé à l'extrême.

Ca, c'est depuis que je suis parti. Tout à foutu le camp ensuite.

Je m'en doutais. :-)

Ce qui, pour maintenir un parc matériel, demande à maintenir un parc
logiciel de quinze ans, systèmes d'exploitations compris.

Tu suggères quoi ? Ils auraient dû comprendre dès 1989 qu'OS/2 était une
impasse et que Windows 2 allait prendre le pas ?

Je suggère qu'ils auraient du se tenir à un seul environnement de travail,
au lieu de se disperser tout azimut.
Et s'il choisissent d'en changer, qu'ils y portent les logiciels existants,
qu'ils assument leurs choix au lieu de le faire supporter à leurs clients.

Moi j'aimais bien OS/2.

Itou.

--
<.>

Salut,

Vincent Burel wrote:

<halfwolf@free.fr> wrote in message
news:1136542392.870611.307320@z14g2000cwz.googlegroups.com...
>Je ne sais pas en C++ mais en C il est garanti que NULL vaut (void*)0
>par la Norme (et je pense que ça doit être pareil en C++).
>Si la représentation en mémoire du pointeur est 0xFFFFFFFF le
>compilateur fait l'abstraction. Donc le cas que tu décris serait un
>bug du compilateur. D'où mon incompréhension sur le sens exact de ta
>phrase.

Je comprends pas tout non plus . Tu parle de quel pointeur ?

Du pointeur null.

le compilo ferait abstration de quoi ?

Du fait que la valeur du pointeur null puisse ne pas être ZERO d'un
système à l'autre.
Le code suivant affichera toujours "Mon pointeur est null." en C tant
que le compilateur est C90 et quelque soit la plateforme :

#include <stdio.h>

int main(void)
{
void* mon_pointeur_null = NULL;

if (mon_pointeur_null)
{
printf("Mon pointeur n'est pas null.n");
}
else
{
printf("Mon pointeur est null.n");
}

return 0;
}

En revanche, le code suivant n'affichera PAS toujours "Mon pointeur est
null." suivant la plateforme :

#include <string.h>
#include <stdio.h>

int main(void)
{
void* mon_pointeur_a_zero;

memset(&mon_pointeur_a_zero, 0, sizeof(mon_pointeur_a_zero));

if (mon_pointeur_a_zero)
{
printf("Mon pointeur n'est pas null.n");
}
else
{
printf("Mon pointeur est null.n");
}

return 0;
}

et ton incompréhension s'applique à laquelle de mes phrase ?

>> Vincent Burel a écrit :
>>
>> > Remarques que beaucoup écrirait :
>> > if (mon_pointeur) delete(mon_pointeur);
>> >
>> > Alors là c'est pire, car l'opération logique peut varier d'un co mpilo à
>> > l'autre (certains compilo ne considère que le bit 0), la valeur du
>> pointeur
>> > null peut ne pas etre ZERO d'un systeme à l'autre.

Je me posais la question lorsque tu as posté ça si tu voulais dire
que sur certains compilateurs le 1er code que j'ai posté ci-dessus ne
faisait pas ce qu'on en attendait parce que le compilateur est bogué.
Visiblement ce n'est pas ce que tu semblais dire.
De ce que j'en comprends maintenant : tu voulais plutôt dire que la
représentation physique d'un pointeur n'est pas toujours ZERO, ce en
quoi je suis d'accord, et que le pointeur null n'est pas toujours
évalué comme étant ZERO ce en quoi je ne suis PAS d'accord : le
compilateur doit l'évaluer comme étant à ZERO même si ça
représentation physique n'est pas ZERO. C'est ce que je voulais dire
par :

<halfwolf@free.fr> wrote in message
news:1136542392.870611.307320@z14g2000cwz.googlegroups.com...
>Si la représentation en mémoire du pointeur est 0xFFFFFFFF le
>compilateur fait l'abstraction.

Et tant que j'y suis, comment tu t'appelle ?

Est-ce bien important ?
J'espère juste que nous nous comprenons un peu mieux maintenant...

HalfWolf

<halfwolf@free.fr> wrote in message
news:1136803876.118433.265910@g43g2000cwa.googlegroups.com...
Salut,

le compilo ferait abstration de quoi ?

Du fait que la valeur du pointeur null puisse ne pas être ZERO d'un
système à l'autre.
Le code suivant affichera toujours "Mon pointeur est null." en C tant
que le compilateur est C90 et quelque soit la plateforme :

je ne sais pas, et je ne compterai pas dessus. NULL est un define, faire des
suposition sur sa valeur et la façon dont il sera évalué, c'est déjà

void* mon_pointeur_null = NULL;
if (mon_pointeur_null)
{
printf("Mon pointeur n'est pas null.n");
}

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)

évalué comme étant ZERO ce en quoi je ne suis PAS d'accord : le
compilateur doit l'évaluer comme étant à ZERO même si ça
représentation physique n'est pas ZERO. C'est ce que je voulais dire

Et bien je voulais dire que jamais je ne ferais confiance au compilo pour ca
, d'où l'utilisation d'une écriture explicite if (lp == NULL)

Et tant que j'y suis, comment tu t'appelle ?

Est-ce bien important ?

non, cependant, quand la discussions s'éternise, j'aime bien savoir avec
qui je passe mon temps.

VB

Vincent Burel wrote:

Et bien je voulais dire que jamais je ne ferais confiance au compilo
pour ca , d'où l'utilisation d'une écriture explicite if (lp == NULL)

Tssss.

if ( NULL == lp ) plutôt...

Apprends aux djeunz à programmer bien s'il te plaît :-).

--
Arnold McDonald (AMcD) - Help #7 /2006

http://arnold.mcdonald.free.fr/

Vincent Burel wrote:

je ne sais pas, et je ne compterai pas dessus. NULL est un define, faire des
suposition sur sa valeur et la façon dont il sera évalué, c'est d éjà

C'est un bon principe général de ne pas faire de supposition sur la
valeur d'un define.
Cependant dans ce cas particulier NULL est garanti valoir 0 par la
norme.
En fait NULL a du être défini car ça évoquait plus de choses que 0.

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)

Effectivement, c'est bizarre. Peut-être que tous les pointeurs valides
doivent être impairs sur la plateforme ? ;-)
Juste par curiosité, quel est ce compilateur ?

>évalué comme étant ZERO ce en quoi je ne suis PAS d'accord : le
>compilateur doit l'évaluer comme étant à ZERO même si ça
>représentation physique n'est pas ZERO. C'est ce que je voulais dire

Et bien je voulais dire que jamais je ne ferais confiance au compilo pour ca
, d'où l'utilisation d'une écriture explicite if (lp == NULL)

D'où mon post original, il s'agissait en fait d'une question de
confiance et non pas d'une possibilité "légale".
Moi aussi j'aime bien que ce soit explicite. J'avoue faire comme toi
quand je teste le pointeur null. De plus, je n'arrive décidemment pas
à me mettre à if (NULL == lp), comme le suggère AMcD, car mon
cerveau comprend mal, sans doute un reste de pratiques mathématiques
qui le polluent. J'ai pourtant essayé.
Cependant, je m'appuie sur le fait que delete tolère qu'on lui passe
NULL et je ne teste donc pas le pointeur avant de le libérer. Je
n'aime pas me fatiguer pour un compilateur non conforme tant que je
n'en rencontre pas un. Peut-être à tort...

>> Et tant que j'y suis, comment tu t'appelle ?
>
>Est-ce bien important ?

non, cependant, quand la discussions s'éternise, j'aime bien savoir av ec
qui je passe mon temps.

Je comprends, mais j'ai une vie trop dissolue pour prendre le risque
qu'on me repère ici. :-)
Plus sérieusement, je suis un peu parano et je n'aime pas laisser trop
de traces sur le net.
Voilà.

HalfWolf

halfwolf@free.fr wrote:

De plus, je n'arrive décidemment pas
à me mettre à if (NULL == lp), comme le suggère AMcD, car mon
cerveau comprend mal, sans doute un reste de pratiques mathématiques
qui le polluent. J'ai pourtant essayé.

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. Par contre, si tu tapes if NULL = lp, là le
compilo beuglera. C'est donc une astuce pour se simplifier la vie.

Oui, ce n'est pas mathématique, mais il faut savoir désolidariser la théorie
et l'informatique réelle.

--
Arnold McDonald (AMcD) - Help #8 /2006

http://arnold.mcdonald.free.fr/

AMcD :

il faut savoir désolidariser la théorie et l'informatique réelle.

Arnold, tu vas pas encore relancer la polémique !