Logo GNT
Actualités Tests & Guides Bons Plans
GTA 6 iPhone 17 Copilot Switch 2 Temu ChatGPT Tesla
OVH Cloud OVH Cloud
Entraide Développement Développement Visual Basic True or False intuitif au programme VB2005

True or False intuitif au programme VB2005

10 réponses
Avatar
elocirga
Bonjour,
Plus nécessaire d'écrire
if Propriété = True then
....
else
alléger de 5 caractère déjà en écrivant
Tout simplement
if Propriété then
....
else

A bientôt
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Patrice Henrio
C'était déjà le cas en VB6, seuls les programmeur en C continuait à ne pas
utiliser des booléens.




"elocirga" a écrit dans le message de
news:
Bonjour,
Plus nécessaire d'écrire
if Propriété = True then
....
else
alléger de 5 caractère déjà en écrivant
Tout simplement
if Propriété then
....
else

A bientôt


Avatar
Fred
Dans : news:%,
Patrice Henrio disait :

C'était déjà le cas en VB6, seuls les programmeur en C continuait à
ne pas utiliser des booléens.



Bonjour Patrice,
Je ne comprends pas le sens de ta remarque ?
Je crois qu'un programmeur en C n'écrirait pas ce genre de chose (une
tautologie (?)).
En C tout ce qui est non nul est vrai, tout ce qui est nul est faux
(même de type pointeur).
Cela autorise des constructions parfois illisibles mais optimisées au
maximum (quand le compilateur n'est pas trop sophistiqué).

while(*(d++)=*(s++)) ; /* recopie d'une chaîne dans une aure avec test,
affectation et incrémentations ensemble */

Jean-Marc me corrigera éventuellement car je n'ai pas pratiqué le C
depuis un temps ;-)

--
Fred
http://www.cerbermail.com/?3kA6ftaCvT
Avatar
jean-marc
> "Patrice Henrio" a écrit dans le message


de news:%

C'était déjà le cas en VB6, seuls les programmeur en C continuait à ne


pas
utiliser des booléens.



Hello,

C'est exact, car il n'y a pas de type booléen en C ANSI.
Ce type est apparu avec C99, mais celui ci est très peu
employé.

Cependant, on utilise quand même en C des mécanismes
approchants;
En C, tout ce qui vaut 0 ou NULL est faux, le reste est vrai.

C'est une pratique courante que d'écrire en C:

/* ma_variable est un entier ou un pointeur */

if(ma_variable) /* ici on l'utilise comme un boolean */
{
/* Vrai donc faire ceci */
}
else
{
/* faux, donc faire cela */
}

On écrit plutot ça que:
if(ma_variable != NULL)
ou que : if(ma_variable != 0)

On peut aussi faire des choses comme cela:

#define FALSE 0 /* constante pour FALSE */
#define TRUE 1 /* constante pour TRUE */
typedef int Boolean; /* un "nouveau" type */

Boolean my_result;

if(...)
my_result = TRUE;
else
my_result = FALSE;

if(my_result)
{
...
}

=> Moralité: on s'en sort quand même et on peut rester lisible
et cohérent, même avec un langage dépourvu d'un "vrai" type
booléen :-)

C'est la responsabilité du programmeur de faire en sorte
que le programme soit immédiatement lisible et compréhensible,
tout en s'adaptant aux contraintes/limites du langage.

--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;
Avatar
jean-marc
"Fred" a écrit dans le message de
news:
Dans : news:%,
Patrice Henrio disait :

> C'était déjà le cas en VB6, seuls les programmeur en C continuait à
> ne pas utiliser des booléens.

Bonjour Patrice,
Je ne comprends pas le sens de ta remarque ?
Je crois qu'un programmeur en C n'écrirait pas ce genre de chose (une
tautologie (?)).
En C tout ce qui est non nul est vrai, tout ce qui est nul est faux
(même de type pointeur).
Cela autorise des constructions parfois illisibles mais optimisées au
maximum (quand le compilateur n'est pas trop sophistiqué).

while(*(d++)=*(s++)) ; /* recopie d'une chaîne dans une aure avec


test,
affectation et incrémentations ensemble */

Jean-Marc me corrigera éventuellement car je n'ai pas pratiqué le C
depuis un temps ;-)



Hello Fred,

Rien à corriger, tout est exact :-)

En fait, comme je le disais précédemment, il n'y a pas de
vrai type Booléen en C, mais les programmeurs C utilisent
sans cesse la logique booléenne.
C'est en particulier vrai avec les pointeurs, et ton exemple
est parfait pour illustrer ce point:

while(*(d++)=*(s++)) ;

Ici, d et s sont tous 2 des (char*) et la condition de sortie de la
boucle,
c'est quand *s vaut '0', c'est à dire une fin de chaine en C;

On pourrait écrire à la place:

#define FALSE 0
#defien TRUE 1
typedef int Boolean;

Boolean fin_copie;

fin_copie = (*s == ');
while( !fin_copie )
{
*d = *s;
d++; s++;
fin_copie = (*s == ');
}

Note:
while( !fin_copie ) est équivalent à
while( fin_copie != FALSE ) ou encore
while ( (!fin_copie) == TRUE)

Bien sur, la plupart des programmeurs C savent lire et comprendre
en un coup d'oeil le sens de:
while(*(d++)=*(s++)) ;

C'est pourquoi ils emploient cette forme sans se poser de questions,
puisque d'un point de vue sémantique elle est identique à celle que
je donne en exemple.

Evidemment, un compilateur convenable produira le même code
assembleur pour les 2 formes d'écriture!

--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;
Avatar
Fred
Dans : news:,
Patrice Henrio disait :

C'était déjà le cas en VB6, seuls les programmeurs en C continuaient
à ne pas
utiliser des booléens.



OK, j'ai compris ;-)
Je n'y étais pas du tout !

Pour ma part, depuis 25 ans, je défends l'idée que le langage doit
être le plus près possible du langage naturel, ou au moins de
l'algorithme, et que c'est au compilateur d'optimiser le code.
Ainsi, même s'il m'arrive d'utiliser, en C ou en Java, n++ ou a=+b,
c'est une écriture que je ne recommande pas car elle est absconses et
n'est pour moi qu'une abréviation de n=n+1 et a=a+b.



Oui. Il faut éviter le code abscur. À moins que l'on souhaite participer
au ioccc (http://www.ioccc.org).
Mais n'oublions pas non plus l'âge du C et ce pourquoi il a été inventé
:-)
À l'époque, un n++ économisait quelques cycles par rapport à un n=n+1.

--
Fred
http://www.cerbermail.com/?3kA6ftaCvT
Avatar
jean-marc
"Patrice Henrio" a écrit dans le message de
news:
J'ai commencé la programmation à une époque où il n'était pas question


de programmer avant d'avoir >suivi un cours d'algorithmique, j'ai
l'impression que cette matière est devenue accessoire et c'est >bien
dommage.

Entièrement d'accord. Cependant, dans les bonnes écoles/formations,
l'enseignement de l'algorithmique est heureusement toujours d'actualité.

Je pense qu'il ne faut pas confondre programmeurs amateurs et
programmeurs
professionnels. Je pense que sur ce forum, la proportion doit être plus
ou moins de 1/5, c'est à dire 80% amateurs, 20% pro.

--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;
Avatar
jean-marc
"Fred" a écrit dans le message de
news:
Dans : news:,
Patrice Henrio disait :



> Ainsi, même s'il m'arrive d'utiliser, en C ou en Java, n++ ou a=+b,
> c'est une écriture que je ne recommande pas car elle est absconses


et
> n'est pour moi qu'une abréviation de n=n+1 et a=a+b.

Oui. Il faut éviter le code abscur. À moins que l'on souhaite


participer
au ioccc (http://www.ioccc.org).
Mais n'oublions pas non plus l'âge du C et ce pourquoi il a été


inventé
:-)
À l'époque, un n++ économisait quelques cycles par rapport à un n=n+1.



Hello Fred,

une petite clarification sur ce dernier point: Le C a été développé au
milieu des années 70, initialement sur un PDP-11. Sur cette machine, il
y avait une instruction assembleur qui ajoutait ou retranchait la
constante "1" à un entier. C'est pourquoi Kernighan et Ritchie ont
introduit dans le langage les notations n++, ++n, n--, etc.

Quand au fait que n=n+1 fait ou faisait gagner des cycles, il faut être
très prudent: cela dépend totalement du compilateur. Je n'ai pas
immédiatement sous la main de compilateurs C vriament anciens, mais en
tout cas, avec les compilateurs dont je dispose, les expressions n++ et
n=n+1 génèrent le même code assembleur: compilateur de Visual Studio,
gcc sous windows, gcc sous Sun Solaris, le compilateur IBM AIX, et le
compilateur C d'IBM pour mainframe sous z/OS et OS/370.

Exemple

; 7 : n++;

0001f 8b 45 fc mov eax, DWORD PTR _n$[ebp]
00022 83 c0 01 add eax, 1
00025 89 45 fc mov DWORD PTR _n$[ebp], eax

; 7 : n = n + 1;

0001f 8b 45 fc mov eax, DWORD PTR _n$[ebp]
00022 83 c0 01 add eax, 1
00025 89 45 fc mov DWORD PTR _n$[ebp], eax

Ainsi, je suis vraiement d'accord avec Patrice: il faut vraiment
éviter d'utiliser les formes condensées, en tout cas dans les
programmes pro, qui par nature vont être lus, modifiés, débuggués
par des personnes différentes, souvent longtemps après la première
écriture du code. Plus le code est lisible ET humainement lisible,
plus il sera aisé de le modifier/corriger, etc.

C'est la première chose que j'apprend aux jeunes programmeurs qui
arrivent chez nous pour programmer en C (idem en VB d'aiileurs):
- Soyez clairs
- N'essayez pas d'optimiser, on verra ça après
- Une écriture absconse/concise ne rend PAS (JAMAIS) un programme
plus rapide. C'est un meilleur algorithme qui rend un programme plus
rapide, dans TOUS les cas!

Il faut malheureusement bien souvent leur faire "désapprendre" ce que
leurs profs (des universitaires n'ayant pour la plupart jamais écrit de
code de production) leur ont appris. Pas facile :-)

--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;
Avatar
Fred
Dans : news:4495a163$0$10462$,
jean-marc disait :
"Fred" a écrit dans le message de
news:
Dans : news:,
Patrice Henrio disait :



Ainsi, même s'il m'arrive d'utiliser, en C ou en Java, n++ ou a=+b,
c'est une écriture que je ne recommande pas car elle est absconses
et n'est pour moi qu'une abréviation de n=n+1 et a=a+b.



Oui. Il faut éviter le code abscur. À moins que l'on souhaite
participer au ioccc (http://www.ioccc.org).
Mais n'oublions pas non plus l'âge du C et ce pourquoi il a été
inventé :-)
À l'époque, un n++ économisait quelques cycles par rapport à un
n=n+1.



Hello Fred,



Hello Jean-Marc,

une petite clarification sur ce dernier point: Le C a été développé
au milieu des années 70, initialement sur un PDP-11. Sur cette
machine, il y avait une instruction assembleur qui ajoutait ou
retranchait la constante "1" à un entier. C'est pourquoi
Kernighan et Ritchie ont introduit dans le langage les
notations n++, ++n, n--, etc.

Quand au fait que n=n+1 fait ou faisait gagner des cycles, il faut
être très prudent: cela dépend totalement du compilateur.



Oui, c'est bien ce que j'évoquais dans mon premier post.

Ainsi, je suis vraiement d'accord avec Patrice: il faut vraiment
éviter d'utiliser les formes condensées, en tout cas dans les
programmes pro, qui par nature vont être lus, modifiés, débuggués
par des personnes différentes, souvent longtemps après la première
écriture du code. Plus le code est lisible ET humainement lisible,
plus il sera aisé de le modifier/corriger, etc.



Je suis d'accord aussi. Mais tu devrais tout de même jeter un œil sur le
site ioccc ;-)

Bonne soirée !


--
Fred
http://www.cerbermail.com/?3kA6ftaCvT
Avatar
jean-marc
"Fred" a écrit dans le message de
news:uB$
Dans : news:4495a163$0$10462$,
jean-marc disait :
> "Fred" a écrit dans le message de
> news:
>> Dans : news:,



Je suis d'accord aussi. Mais tu devrais tout de même jeter un œil sur


le
site ioccc ;-)

Bonne soirée !



Je connais, c'est super :-))

Bonne soirée à toi aussi!

--
Jean-marc
Tester mon serveur (VB6) => http://myjmnhome.dyndns.org
"There are only 10 kind of people
those who understand binary and those who don't."
mailto: remove '_no_spam_' ;
Avatar
Patrice Henrio
"jean-marc" a écrit dans le message de news:
44959ce8$0$10454$
"Patrice Henrio" a écrit dans le message de
news:
J'ai commencé la programmation à une époque où il n'était pas question


de programmer avant d'avoir >suivi un cours d'algorithmique, j'ai
l'impression que cette matière est devenue accessoire et c'est >bien
dommage.

Entièrement d'accord. Cependant, dans les bonnes écoles/formations,
l'enseignement de l'algorithmique est heureusement toujours d'actualité.

Je pense qu'il ne faut pas confondre programmeurs amateurs et
programmeurs
professionnels. Je pense que sur ce forum, la proportion doit être plus
ou moins de 1/5, c'est à dire 80% amateurs, 20% pro.

--



Oui mais justement je suis un programmeur amateur, passionné depuis 25 ans.

D'ailleurs disposant d'un peu de temps je serai tenté par le télétravail :
réaliser des parties de programme de chez moi à partir d'un cahier des
charges.

A plus.