est-ce qu'il existe des fonctions toutes faite pour des calculs binaires ?
 
ex :  
x = 7 (00000111 en binaire)
y = 2 (00000010 en binaire)
 
result = fonction(x, y)
 
et avoir result = 5 (00000101 en bianaire)
 
et si ensuite on fait result = fonction(result, y)
qu'on obtienne result = 7
 
quelqu'un connait ?

pas à ma connaissance, il existe je crois hex(), ect...fait une recherhe dans l'aide sur ce mots et tu auras les autres noms, mais je te le répète : j'ai une gros doute.

en fait, hex() permet de travailler avec de l'hexadecimal et pas avec du binaire
 
merci kan meme

je sais bien ça, mais avec ce mots dans l'aide, tu aurais pu trouver, les autres si éventuellement ils existent. Va faire un tour sur www.vbfrance.com pour voir !  

à part les And, Or et Xor, il n'y a pas de fonction qui permette de travailler au niveau binaire en VB.
 
Et ce sera de surcroit très lent si tu essaies de les émuler

En VB  
x = 7  
y = 2
print (x XOR y) donne quoi ? (NB paresse d'allumer le PC où VB3 pour tester)

ça donne bien 5 oui

encore heureux sinon je me demande bien comment ma procédure de cryptage fonctionnerait

pour ça, c'est ok
 
par contre, je pense pas qu'il existe une fonction pour mettre à 1 ou 0 le bit qu'on veut dans un octet ?
car j'en ai fait une (qui marche) mais c'est une grosse bidouille

non, ce genre de choses là, on n'a pas en VB

tant pis alors je resterai avec mes fonctions équivalentes mais en bidouille

carbon_14 : quand t'as pas envie de te faire chier avec VB, y'a un truc très bien qui s'appelle VBS.
 
Tu crées un ficier txt.
Tu tapes dedans :
 
x = 7
y = 2
msgbox(x XOR y)
 
et tu le renomme en *.vbs
 
Puis dblclick dessus et ô miracle ça affiche 5 !

purée je viens de créer mon tout premier .vbs pour le coup

Spa compliqué pourtant...
 

t'aurais dû noter de BIT0 à BIT7 pour être logique mais je chicane un peu, je te l'accorde

on est en VB, on commence à compter à partir de 1

jamais de la vie: les arrays sont indicés à zéro sauf directive spécifique.

c'est le contraire
 
par défaut VB commence à compter à 1, mais si on affecte 0, alors il décalle tout pour commencer à partir de 0
 
-- Edit ; tiens, nan, c'est chelou...
 
a = Array("a", "b", "c" ) commence bien à 0...
 
bah, c'est dans quel cas qu'il commence à 1 bon, ben ça commence en effet à 0 jusqu'à preuve du contraire
 
PS: de toute façon on s'en fout, c'est plus joli BIT1 que BIT0

ps: et y'a pas que les tableaux, tous le langage est architecturé de façon à privilégier 1 plutôt que 0.
 
for i = 1 to 10 c'est quand même plus clair que for i = 0 to 9 ... y'a 10*E^9999999 exemples qui tendent à montrer que VB est fait pour bosser (et c'est plus naturel) avec 1 plutôt que 0
 
m'enfin on s'en fout, le principal c'est qu'en fin de compte VB a tout ce qu'il faut pour bosser en binaire contraîrement ce ce qui a pu être dit, et qu'il suffit de connaître un minimum son algèbre de bool pour écrire soit-même les fonctions plus évoluées.
 
-- edit : et que vbs c'est vachement bien et plus pratique que vb pour faire des tests bidons (pas decompilation, pas d'IDE à installer, etc.)

perso quand il s'agit de faire de l'algèbre de bool, je préfère le bas niveau. Certes, tu peux toujours émuler les fonctions qui n'existent pas (ce que je me suis amusé à faire il y a un temps), mais tu as la lenteur de traitement en contrepartie
 
Quand au débat 0/1, ben le vbiste de base va prendre 1 (qui n'est pas la valeur par défaut je le répète), et le programmeur prendre 0. Comme quoi il y a naturel et naturel. Et de mon point de vue, il me semble naturel de prendre zéro (et ce avec d'autant plus de raison qu'en .NET t'as pas le choix, ça sera toujours zéro)
 
Attention ami lecteur, un troll s'est glissé dans ce post, sauras-tu le trouver?

en effet, c'est 0, j'ai vérifié et t'as raison.
 
qu'est-ce que je peux dire comme conneries moi en ce moment, c'est hallucinant !
 
sinon PS de troll argenté :
 
certes, c'est plus "logique", d'un point de vie informatique de partir de 0 (puisqu'au niveau du processeur, tab(5) c'est traduit par ptrDeBase * (sizeof(type) * 5) et que donc pour le premier indice, si on veut pas perdre de place, il faut partir de 0
 
mais pour le lecteur, quand il se trouve face à un for i = a to b, quand a = 0, b = le nombre d'ittérations - 1 et ça c'est pas logique du tout pour l'humain de base.

c'est bon, tout marche maintenant merci, même si j'ai utilisé aucun AND et OR

bin en fait, un troll en amène un autre: un programmeur est censé connaître la logique d'un ordinateur. D'ailleurs on la lui enseigne et il devient normalement naturel pour lui de commencer à compter à partir de zéro et non plus de un. Mais vu que VB est (malheureusement) employé la plupart du temps par des end-users ou des apprentis-programmeurs qui ont été formés en 3 jours (ok j'exagère mais dans les SSII c'est un peu trop courant) ou d'autres qui font ça en autodidacte, ben je comprends ton raisonnement.
 
Ce qui me fait penser que l'application sur laquelle je bosse actuellement a viré, lors de son déploiement, les quelques 90 applications écrites par les gens du marketing. Et on voit qu'ils ont pas l'habitude  L'auteur de la dernière application du genre sur laquelle j'ai posé les yeux ne connaît visiblement par le concept même d'array parce qu'ils auraient pu en économiser du code

a ce moment, autant bosser en ASM
 
mais sinon, je suis d'accord, si les informaticiens étaient moins paresseux, les end users arrêteraient de nous faire chier avec des applis VB buggées et nous ferait faire le boulot dont ils ont besoin...
 
mais bon, vu qu'on préfère troller ici au lieu de bosser bah... on n'a plus qu'à corriger les bugs VB à la con

 
Ou changer de langage

changer de métier aussi c'est pas mal. j'aime bien les chèvres, pas toi ?

Toc toc toc, c'est ici le troll VB ?
 
On me charge de passer ce message : http://www.ddj.com/documents/s=150 [...] /jan00.htm
 
Bonne lecture.

c'est pas toi qui avais posté ce lien dans un autre topic?

 
Si, mais je l'aime bien ce post. Il est un peu sur le ton de la plaisanterie mais il est difficile d'objecter quoi que ce soit à ce qu'il dit

 
effectivement

bah disons qu'il est dur d'objecter quoi que ce soit parceque c'est pas très objecttif non plus. c'est un peu hors sujet.
 
il demande à vb des trucs chelous et s'étonne que ça merde (grossomodo)
la plupart de ses remarques peuvent s'appliquer, moyennant nuances, à la plupart des autres langages.
 
style "on m'a dit que les pointeurs c'est génial ! mais expliquez moi pourquoi quand je fais ptr * 'a' / sizeof(int) ça merde.
 
Par exemple, pour le premier point.
Je trouve rien d'extraordinaire là-dedans. Différencier la syntaxe entre procédure et fonction ne me choque pas, et quand à se comporter anormalement quand on appelle une fonction sans récupérer la valeur de retour, il suffit de faire de l'ADA pour voir que dans ce langage, c'est même pas que le comportement est anormal, c'est carrément que ça compile pas.
En bref, quand on vient du C, ces spécifications de VB semble vraiment batardes. Mais quand on vient de vrais langages à la fois évolués et réfléchis, on trouve que cette approche faite par VB n'est pas forcément mauvaise.
 
Alors après, c'est vrai, je dis pas. VB a de grosses lacunes. Mais certaines, je trouve ça pas plus mal... Le seul truc qui est domage, c'est que le compilo, au lieu de lever une erreur, fait un prog bizarre (tout comme le C dans 99% des cas pour remprendre le // avec cette surcouche d'ASM approxymative)
 
Par exemple Dim a, b, c, d as String
 
Je trouve ça très bien que ça fasse n'importe quoi. C'est vraiment crade de déclarer une série de variables de cette façon.
 
Oui, avoir 20 lignes de déclarations pour déclarer 20 variables c'est chiant, mais au moins c'est lisible, on s'y retrouve immédiatement.
 
Parceque quand je vois des fois en C une trentaine de variables déclarées en une seule ligne, avec des affectations dans tous les sens, j'ai très vite mal à la tête...
 
m'enfin ça vaut pas l'affectation d'une variable à l'interrieur de l'appel d'une fonction. surtout si à ça on ajoute une série de petits trucs sympa, y'a des gars qu'on toujours de l'imagination pour ce genre de choses.
désolé, mais dans une équipe de développeur, tout le monde n'est pas autiste, et c'est très bien de pouvoir relire le code d'un gars sans avoir besoin de se griller les neuronnes pendant 2 heures pour décoder une pelotte de laine qui fait la moitié du programme en 2 lignes.
 
enfin voilà quoi. certes vb a un compilateur merdique, mais au moins ça force (quand on est un minimum consciencieux) à faire un truc un peu plus lisible et qui entre dans la logique du langage.

Perso j'ai une chose à objecter à ce qu'il dit: Check1.Value n'est pas un booléen mais un Integer. Le coup du Not est donc fatalement foireux: la constante vbChecked vaut 1, donc l'expression Not 1 vaut... -2, qui est une valeur non nulle (donc vraie -> True)

MagicBuzz>tu confonds qualité d'un langage et qualité de code d'un programmeur.
En même temps, tu parles de lisibilité mais définir ses variables par "a", "b", "c" ou "d", c'est pas super explicite

bah j'ai juste recopié l'exemple du mônsieur qui dit que vb est pourri

sinon, je confond plus ou moins.
 
L'avantage avec VB, c'est que si tu te force pas à faire des trucs à peut près propres et dans la logique du compilateur (une sub N'EST PAS une fonction qui ne retourne rien) tu vas avoir un prog qui fait portnawak.
 
En C, à partir du moment où tu t'es pas planté dans ton algo, tu peux écrire n'importe quoi dans tous les sens comme un plutonnien échoué sur une plage, ça marchera de la même façon que si tu fais un truc propre.
Donc en ce sens, VB est mieu foutu que le C, puisqu'il t'oblige à un minimum de rigueur.
 
Bon, on est d'accord, on part du principe que le développeur à mis Option Explicit en haut de la page et qu'il bosse avec des variables typées, sinon ça peut vite devenir encore pire qu'en C
 
M'enfin de toute façon, au niveau de la rigeur, rien de ce que je connais n'arrive à la cheville d'ADA, qui est selon moi le seul langage permettant, à coup sûr de prévoir simplement à la lecture du code, 100% du fonctionnement de l'appli. Rien n'est laissé au hasard, et le compilo ne manque pas de te faire piquer une crise de nerf pour s'en assurer... Quand il décide de pas compiler, bah y compile pas, faut lui parler gentillement et réécrire la moitiée de son code pour qu'il comprenne bien tout ce qu'on veut faire

C'est pas en disant que le VB n'est pas pire que le C que l'on pourra conclure que le VB n'est pas pourri
 
Moi, j'aime bien déclarer plusieures variables sur la même ligne car ça donne un code plus lisible parfois. Par exemple :

Et VB, c'est soit une écriture lourde, soit tu as fais une grosse erreur.
 
Pour la syntaxe d'appel des fonctions, je lance ce défi pour tous les utilisateurs de VB : qui connaissait la difference de fonctionnement entre ces 2 lignes :

Le comportement du VB va droit dans le mur ici et ce n'est pas la peine de le comparer à l'ADA dans ce cas car ce dernier à fait le bon choix lui au moins !
 
 
 

Pourquoi tu multiplies un char par un pointeur ? Qu'est ce que tu espère faire comme ça ? Et puis en général, qui va aller multiplier un char ???
 
 
 
Oui, le comportement de "not Checked" est comprehensible. Non ce n'est pas une bonne chose. Il y a 2 erreures fondamentales ici. La première est dans le nom de la propriété. Semantiquement, un "Checkbox" est un boolean. Moi quand je vois ça, je pense à un truc à 2 états mais non, en VB il en a trois : Oui, Non, Peut-être. Et la deuxième erreur est dans l'affectation

 
Le fait de pouvoir écrire b = Check1.Value ne fait que renforcer l'idée que Check1.Value est un booléen ! L'erreur du VB ici est de faire une convertion implicite entre l'enumeration à 3 états qu'est le checkbox et le vrai seul booléen qui compte en informatique.
 
Ce genre de convertion implicite entre 2 types qui n'ont rien à voir est la marque des langages faiblement typés. Et un langage faiblement typé est un langage de mauvaise qualité.

Pour des cas précis, coordonnées par exemple, en effet, déclarer en une seule ligne peut avoir un sens.
 
Mais cette "lacune" de VB peut-être "contourner" si on aère le code :
 

Il suffit de regrouper les déclarations qui initialisent des données se rapportant à une même chose. Evidement, avec ce système, t'as rapidement deux pages de déclarations mais bon, au moins quand tu recherches les variables "partenaires" d'une variable, tu les retrouve facilement, même si elles ne sont pas du même type.
 
Parceque très souvent en C on va trouver :
 

 
Et là, quand tu cherches le nom de la variable du rayon du cercle qui est en [x,y] bah t'as un peu plus de mal, et tu fini par envoyer un mail d'insultes à ton chien, ou utiliser les dents du hamster pour faire le cercle, et je sais pas s'il va être très d'accord
 
FuncName(Param1, Param2) est pour moi une hérésie. Si tu ne récupère pas de valeur, alors tu ne dois pas utiliser de fonction (c'est un crime, tu mérites de te faire mordre par le hasmter autant de fois qu'il y a de cercles dans la note de ton fils en maths.
 
Mais bon, sur le principe, en disant que c'est une Sub, je suis d'accord que le fait que ça se comporte pas pareil entre un appel direct ou un appel avec call est pas très normal, et c'est certainement en effet un des trucs les plus pourris de VB, je te l'accorde.
M'enfin si tu te forces à coder ANSI compliant, t'auras de toute façon jamais de Sub dans ton code (ce que je trouve absurde car détourne les fonctions de leur rôle mais bon )
 
Sinon, mon ponteur multiplié par un caractère, c'était juste un délire parceque j'avais pas d'exemple sous la main Enfin, juste pour montrer quand même que le C permet des trucs pas catholiques... Notamment utiliser un caractère directement dans une oppération mathématique, on a vite fait de partir en couilles. Deplus, je préfère la méthode "propre" pour bosser avec des "pointeurs", c'est à dire le ByVal et ByRef de VB (ou de C#), qui pour moi sont bien plus sécurisés, et clairs, sans pour autant être plus restrictifs (suffit de changer sa façon de coder et de ne plus aller taper comme un porcs dans des zones mémoires non sûres et utiliser des vraies variables avec des vrais types à la place)
 
Sinon, faire un not sur un int, puis l'affecter dans un bool, ça marche aussi avec certains compilos C (si y'avait que ça...).
 
Et un checkbox a par définitions 3 états. Le peut-être existe depuis toujours, et signifie habituellement qu'on a coché un certain nombre de sous-ensembles mais pas tous. Donc sémantiquement, il est normal que ce ne soit pas un bool.
Deplus, .Value en VB est systématiquement un int, un string ou un variant. Mais bon, faut être habitué pour bosser avec pour le savoir. Par contre l'attribut .checked, quand présent, est un bool.

Le not standard en C (  l'operateur ! donc ) renvoye toujours un "bool". Son sens est connu : il indique si l'entier utilisé est égal à zero. Ce fesant, tu garantis que si !!a s'évalue à vrai, alors a s'évalue à vrai aussi.  
 
Le not en VB fait à la fois non binaire et non logique et c'est de la que viens le problème.
 

je veux pas chipoter mais en VB, tu sais déclarer plusieurs variables sur la même ligne
 
oui bien sûr qu'on peut faire comme ceci:

 
mais je pensais à ceci:

 
c'est plus subtile que le C mais ça marche

accessoirement, un code lisible n'emploiera pas de noms kilométriques
perso mes variables ne dépassent jamais les 15 caractères