Discussion :

[PauseKawa]

Bonjour,

Voici un bout de code qui me laisse perplexe, ou du moins qui me laisse l'impression de passer à coté de quelque chose:

Source: Tix.py

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
# Some constants used by Tkinter dooneevent()
TCL_DONT_WAIT     = 1 << 1
TCL_WINDOW_EVENTS = 1 << 2
TCL_FILE_EVENTS   = 1 << 3
TCL_TIMER_EVENTS  = 1 << 4
TCL_IDLE_EVENTS   = 1 << 5
TCL_ALL_EVENTS    = 0

Quel en est l’intérêt par rapport à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
TCL_DONT_WAIT     = 2
TCL_WINDOW_EVENTS = 4
TCL_FILE_EVENTS   = 8
...

?

@+

[tyrtamos]

Bonjour PauseKawa,

Ça donne le même résultat, mais à mon avis, quand on veut positionner un bit à une place précise, la 1ère solution est un peu plus lisible:

1<<3 ==> 00001000

plutôt que:

8 ==> 00001000

[PauseKawa]

Bonjour tyrtamos,

Je m'attendez bien à une réponse dans ce sens.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
>>> import dis
>>> def wint():
...     TCL_DONT_WAIT = 2
... 
>>> dis.dis(wint)
  2           0 LOAD_CONST               1 (2)
              3 STORE_FAST               0 (TCL_DONT_WAIT)
              6 LOAD_CONST               0 (None)
              9 RETURN_VALUE        
>>> def woutint():
...     TCL_DONT_WAIT = 1 << 1
... 
>>> dis.dis(woutint)
  2           0 LOAD_CONST               2 (2)
              3 STORE_FAST               0 (TCL_DONT_WAIT)
              6 LOAD_CONST               0 (None)
              9 RETURN_VALUE

Mais quel intérêt à partir du moment ou le code a été interprété (2) ?

la 1ère solution est un peu plus lisible:

1<<3 ==> 00001000

plutôt que:

8 ==> 00001000

Pas pour moi... Un exemple ? Merci d'avance.

@+

[tyrtamos]

Pour moi, la lisibilité un peu plus grande n'existe que pour le développeur qui écrit le script.

Mais ça dépend peut-être des personnes? En tout cas, moi, j'utilise souvent cette présentation.

[PauseKawa]

Mon avis c'est que c'est ceci que je n'arrive pas à cerner:

mais à mon avis, quand on veut positionner un bit à une place précise, la 1ère solution est un peu plus lisible

Pour moi, la lisibilité un peu plus grande n'existe que pour le développeur qui écrit le script.

Je ne serais pas contre une explication plus détaillée car je ne comprend pas ( courge attitude du weekend) ceci:

la 1ère solution est un peu plus lisible:

1<<3 ==> 00001000

plutôt que:

8 ==> 00001000

[tyrtamos]

J'ai un octet D qui contient 8 drapeaux (levé/baissé ou vrai/faux ou 1/0) appelés D0 à D7. Le drapeau D3 est positionné au 4ème bit en partant de la droite. Quand je lui donne une valeur, je comprend mieux:

D3 = 1<<3

que

D3 = 8

Les 2 donnant le même résultat: 00001000 = 8

On peut ensuite combiner les drapeaux pour une application donnée:

- avoir en même temps D3 et D4: D = D3 | D4
- ajouter le drapeau D5 au D précédent: D = D | D5
- mettre le bit correspondant à D4 à zéro: D = D & ~D4
- etc...

Ok?

[mont29]

Je suis d’accord avec Tyrtamos. Il n’y a aucun intérêt du point de vue du programme lui-même, de ses fonctionnalités. Par contre, pour celui qui doit écrire un ensemble de bit flags (ou pire, étendre un ensemble défini par quelqu’un d’autre), c’est un plus indiscutable.

Cette opération permet de matérialiser quel bit on utilise. Si pour les premiers, tout programmeur normalement constitué est capable de savoir que 4 correspond au troisième bit, je ne pense pas qu’il y en ait beaucoup qui soient capables de citer instantanément le bit correspondant à la valeur 2097152*? Dans ce cas, 1 << 21 est nettement plus parlant.

Et on risque moins la faute de frappe*! Sinon, gare aux flags qui se répandent chez les copains.

[PauseKawa]

Ok?

Pour ce qui est du décalage binaire oui bien sur.

En fait en relisant

(ou pire, étendre un ensemble défini par quelqu’un d’autre)

Je me dit que je suis passé à coté de

# Some constants used by Tkinter dooneevent()

Si dooneevent() utilise les opérateurs binaires (&, |, ^, ~, », «) il semble "évident/naturel" d'écrire 1<<3 plutôt que 8: Cela reste dans l'"esprit".

Pour toute autre écriture je doute encore de l'utilité de la chose.

Merci pour vos réponses

[fred1599]

Hello tout le monde,

En effet aucun intérêt de montrer cette représentation comme le dis PauseKawa.

Le seul intérêt que pourrait avoir l'auteur (mais je ne sais pas pourquoi), est peut-être de montrer la différence de décalage de bits entre chaque constante.

Il est possible que se soit pour montrer une certaine logique de réflexion dans son code, ce qui permet de le rendre plus maintenable, si il y a un bug et qu'il pourrait être résolu par une tierce personne.

Mais tout ça reste des suppositions

[PauseKawa]

Si dooneevent() utilise les opérateurs binaires

Tcl_DoOneEvent

int flags (in)
This parameter is normally zero. It may be an OR-ed combination of any of the following flag bits: TCL_WINDOW_EVENTS, TCL_FILE_EVENTS, TCL_TIMER_EVENTS, TCL_IDLE_EVENTS, TCL_ALL_EVENTS, or TCL_DONT_WAIT.

Résolu et encore merci

[wiztricks]

Salut,

La déclaration de la valeur des flags acceptés par Tcl_DoOneEvent dans tix.py est un cut&paste de leurs valeurs dans le tcl.h:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
#define TCL_DONT_WAIT		(1<<1)
#define TCL_WINDOW_EVENTS	(1<<2)
#define TCL_FILE_EVENTS		(1<<3)
#define TCL_TIMER_EVENTS	        (1<<4)
#define TCL_IDLE_EVENTS		(1<<5)	/* WAS 0x10 ???? */
#define TCL_ALL_EVENTS		(~TCL_DONT_WAIT)

Comme ce cut&paste est fait "à la main" (et non par un outil qui automatiserait), si on ne veut pas se planter, le programmeur de Tix restera "proche" du C (et si le C avait été écrit autrement, la copie Python serait aussi différente).

Dans tk.h on trouve aussi les champs de bits écrits ainsi:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#define TK_MAPPED		1
#define TK_TOP_LEVEL		2
#define TK_ALREADY_DEAD		4
#define TK_NEED_CONFIG_NOTIFY	8
#define TK_GRAB_FLAG		0x10
#define TK_CHECKED_IC		0x20
#define TK_DONT_DESTROY_WINDOW	0x40
#define TK_WM_COLORMAP_WINDOW	0x80
#define TK_EMBEDDED		0x100
#define TK_CONTAINER		0x200
#define TK_BOTH_HALVES		0x400
#define TK_DEFER_MODAL		0x800
#define TK_WRAPPER		0x1000
#define TK_REPARENTED		0x2000
#define TK_ANONYMOUS_WINDOW	0x4000
#define TK_HAS_WRAPPER		0x8000
#define TK_WIN_MANAGED		0x10000
#define TK_TOP_HIERARCHY	0x20000
#define TK_PROP_PROPCHANGE	0x40000
#define TK_WM_MANAGEABLE	 0x80000

1, 2, 4, 8 sont des valeurs décimales. Au délà, on passe dans la représentation hexa... pour être sur qu'on alloue un seul bit au flag.

Le budget (en flags) est limité par le type char, short, int,... qui permettra de les stocker, échanger. A l'époque où nous devions faire attention à la capacité mémoire, on évitait d'allouer 32 bits, au cas où, à un champ qui n'avait pas de bonnes raisons de dépasser 8 bits.

Mais si une nouvelle fonctionnalité demandait l'ajout d'un flag, savoir ou on en est côté allocation des bits est plus simple avec ces représentations (comparées à leurs valeurs décimales).

Avoir des flags ne présuppose pas des opérations logiques qu'on fera dessus: en général, on ne peut pas mélanger n'importe quoi!

- W

[wiztricks]

Re-...

La déclaration de la valeur des flags acceptés par Tcl_DoOneEvent dans tix.py est un cut&paste de leurs valeurs dans le tcl.h:

Au delà du pourquoi de la mise en forme de ces "flags", je ne vois pas trop l'intérêt de leur définition dans tix.py: tk ne donne que des accès indirects à Tcl_DoOneEvent, je ne vois pas trop quand ils pourraient être utilisables.
- W

[PauseKawa]

Bonjour wiztricks,

Avoir des flags ne présuppose pas des opérations logiques qu'on fera dessus: en général, on ne peut pas mélanger n'importe quoi!

C'est noté.

Au delà du pourquoi de la mise en forme de ces "flags", je ne vois pas trop l'intérêt de leur définition dans tix.py: tk ne donne que des accès indirects à Tcl_DoOneEvent, je ne vois pas trop quand ils pourraient être utilisables.

La fin d'un mythe... Moi qui avez espoir de pouvoir y trouver un autre accès à l'event loop... Merci de m'éviter la lecture de plus de code.

@+