/* Topic des codeurs couche-tard [5] */

grim7reaper · Le 01/08/2011, à 17:08

Πυλάδης a écrit :

Dites, vous savez si l’on peut se passer du typedef dans ce cas ?
typedef int (*ParserPointer)(const struct code*);

ParserPointer select_parser(const struct code*);

Non je ne pense pas (les pointeurs de fonctions c'est un peu particulier quand même).

Et quand bien même on pourrait le faire, je ne le conseillerai pas (paye ta lisibilité…)

Dernière modification par grim7reaper (Le 01/08/2011, à 17:09)

Pylades · Le 01/08/2011, à 17:12

OK, je vais laisser comme ça.

Elzen · Le 01/08/2011, à 17:46

Dites, les gens, y a moyen de connaître la position à l'écran du contenu d'une fenêtre, en PyGTK ? Quand je fais win.get_position() ou win.window.get_root_origin(), ça me renvoie les coordonnées de la fenêtre en incluant ses décorations.
Donc quand j'veux qu'un menu apparaisse dans le coin supérieur droit interne de la fenêtre, par exemple, il est décalé vers le haut et sur le côté de la taille des décorations (et vers le haut, c'est la taille de la barre de titre, donc c'est pas juste un pixels ou deux).
Et comme la taille de la barre de titre, ça dépend du navigateur de fenêtres, j'peux pas juste mettre une valeur de décalage en dur
Et j'peux pas utiliser (event.y_root - event.y) pour repérer la coordonnée du début du widget, parce que c'est sur un raccourcis clavier général à la fenêtre…

Quelqu'un a une idée ?

xapantu · Le 01/08/2011, à 18:53

from gi.repository import Gtk 

win = Gtk.Window.new(Gtk.WindowType.TOPLEVEL)


win.connect("delete-event", Gtk.main_quit)

button = Gtk.Button.new_with_label("Go")

win.add(button)

def coords(a):
    print win.get_window().get_root_coords(0, 0)[1]

button.connect("clicked", coords)

win.show_all()
Gtk.main()

C'est en pyGI, je ne sais pas comment c'est en pygtk, mais ça doit être à peu près pareil. Le get_root_coords reflète la fonction:

void                gdk_window_get_root_coords          (GdkWindow *window,
                                                         gint x,
                                                         gint y,
                                                         gint *root_x,
                                                         gint *root_y);

Comme les root_x et root_y sont out, pygi les retourne dans un tuple, mais peut-être que pygtk fait autre chose (mais je vois pas ce que ça pourrait faire d'autre, donc ça devrait le faire).

edit, en fait, on peut virer get_root_cords(0,0) et mettre get_root_origin() à la place, ça marche aussi

edit 2: non, en fait faut bien utiliser get_root_coords, get_root_origin ne fait pas ce que tu veux (ça inclut les bordure)

edit 3: en fait, le plus simple est d'utiliser get_position() En pygtk ça donne ça :

#from gi.repository import Gtk
import pygtk
import gtk
win = gtk.Window()


win.connect("delete-event", gtk.main_quit)

button = gtk.Button()

win.add(button)

def coords(a):
    print win.get_window().get_position()[1]

button.connect("clicked", coords)

win.show_all()
gtk.main()

Dernière modification par xapantu (Le 01/08/2011, à 19:06)

helly · Le 01/08/2011, à 19:41

Plop !
Encore moi et mes tests de int :].
Petit truc bizarre, pour mes séries de test, j’ai cherché sur combien d’octets est écrit tel type.
J’ai donc trouvé sur cette page : http://www.cplusplus.com/reference/std/ … ic_limits/
la méthode digits10

Number of digits (in decimal base) that can be represented without change.

Donc si j’ai bien compris, ça affiche sur quel nombre d’octets ça s’utilise.
Or étrange, pour un char, généralement sur un octet, cette valeur est de 2 !
C’est normal ?

Bon, en attendant, voilà ma modeste fonction test pour savoir si un string est un unsigned int :

bool isUnsignedInt(const std::string & nb)
{
    //on test si nb est un nombre
    for ( unsigned int cpt = 0 ; cpt < nb.size(); cpt++ )
        if (! isdigit(nb[cpt]))                                                                                                                                        
                return false;

    //nb est un nombre, on test maintenant si le nombre de caractère est correct
    if (nb.size() > std::numeric_limits<unsigned int>::digits10)
        return false;

   //le nombre d’octet est okay, maintenant on test la valeur.
    long int li;
    std::istringstream iss(nb);
    iss >> li;

    if (li > std::numeric_limits<unsigned int>::max())
        return false;


    return true;

}

Dernière modification par helly (Le 01/08/2011, à 19:46)

grim7reaper · Le 01/08/2011, à 20:25

helly a écrit :

Plop !
Encore moi et mes tests de int :].
Petit truc bizarre, pour mes séries de test, j’ai cherché sur combien d’octets est écrit tel type.

Pour faire quoi ?

Sinon pour avoir cette info, je te propose cette fonction :

template<typename T>
unsigned int size_in_octet()
{
    // version avec #include<limits>.
    return sizeof(T) * std::numeric_limits<unsigned char>::digits / 8;

    // Version avec #include<climits>.
    // return sizeof(T) * CHAR_BIT / 8;
}

helly a écrit :

J’ai donc trouvé sur cette page : http://www.cplusplus.com/reference/std/ … ic_limits/
la méthode digits10
Number of digits (in decimal base) that can be represented without change.
Donc si j’ai bien compris, ça affiche sur quel nombre d’octets ça s’utilise.
Or étrange, pour un char, généralement sur un octet, cette valeur est de 2 !
C’est normal ?

Oui c'est normal, et ça te paraît étrange car tu as mal compris (à ta décharge, c'est vrai que c'est pas super clair )

J'arrive pas à formuler une phrase pour expliquer ça >_<, donc je vais y aller avec des exemples.
Si ça te renvoie 1 ça veux dire que tu peux représenter tout les nombres de 0 à 9 avec ce type, si ça renvoie 2 alors c'est de 0 à 99, si ça te renvoie 3 c'est de 0 à 999, etc.
Donc pour char tu peux représenter sans problème 99 mais pas 999 alors ça te renvoie 2. Normal.

helly a écrit :

Bon, en attendant, voilà ma modeste fonction test pour savoir si un string est un unsigned int :

Bon bah avec ma remarque précédente, tu te rends compte que ta fonction a un bug : elle renvoie faux (à tort) sur l'intervalle [1 000 000 000, 4 294 967 295].

Édit : Ha, tu as publié une nouvelle version (bon pas grave, le bug est toujours présent donc mon message reste d'actualité).

Dernière modification par grim7reaper (Le 01/08/2011, à 20:30)

Pylades · Le 01/08/2011, à 20:31

[master 62cbf5e] great refactoring for parse(); implementation of ‘!’ options; next work have to focus on select_parser() and open_parser()
 9 files changed, 229 insertions(+), 88 deletions(-)
 create mode 100644 global.h
 create mode 100644 parser.c
 create mode 100644 parser.h

Ça commence à ressembler à quelque chose.

@ helly : en fait ça signifie que si tu passe un nombre de deux chiffres décimaux ou moins, il pourra être représenté sans problème dans un char. Parfaitement normal, donc.
Et ton troisième test est un supertest du second, c’est donc redondant.
Et grim7reaper m’a encore grillé.

Dernière modification par Πυλάδης (Le 02/08/2011, à 03:56)

Elzen · Le 01/08/2011, à 20:33

xapantu a écrit :

edit 3: en fait, le plus simple est d'utiliser get_position() En pygtk ça donne ça :

Ah ben oui ^^"

Comme j'avais déjà utilisé le get_position() de gtk.Window, je n'ai même pas pensé qu'il y aurait un get_position() différent dans gtk.gdk.Window…

Bon, ben, voilà, ça marche nettement mieux, maintenant. Merci beaucoup

helly · Le 01/08/2011, à 20:38

Pour faire quoi ?

Bha par exemple, disons que si la valeur max d’un type s’écrit avec N chiffres, si mon string test est plus grand que N, bhé c’est que c’est pas bon :]
@Pylade : vu pour le super test, c’est que j’avais mal compris.
Ce que je cherche en fait c’est comme je disais, un truc pour savoir sur combien de chiffres s’écrit un MAX.

@grim : sinon si, ma fonction marche aussi pour 4 000 000 000 (par exemple)
Par contre, il faut ajouter un autre test, visiblement on ne peut pas créer un vector aussi long >_<.

nouvelle release :

bool isUnsignedInt(const std::string & nb)
{
    //on test si nb est un nombre
    for ( unsigned int cpt = 0 ; cpt < nb.size(); cpt++ )
        if (! isdigit(nb[cpt]))
                return false;


    //le nombre d’octet est okay, maintenant on test la valeur.
    long long int li;
    std::istringstream iss(nb);
    iss >> li;

    if (li > std::numeric_limits<unsigned int>::max())
        return false;

    return true;                                                                                                                                                       

}

Dernière modification par helly (Le 01/08/2011, à 20:46)

grim7reaper · Le 01/08/2011, à 20:46

helly a écrit :

Pour faire quoi ?
Bha par exemple, disons que si la valeur max d’un type s’écrit avec N chiffres, si mon string test est plus grand que N, bhé c’est que c’est pas bon :]

Et en quoi le nombre d'octet qui code le type va t'aider ?

Bon, je vais commencer à te distiller des extraits de ma solution.
Remplace ça :

for ( unsigned int cpt = 0 ; cpt < nb.size(); cpt++ )
    if (! isdigit(nb[cpt]))
        return false;

par ça :

if(nb.find_first_not_of("0123456789") != std::string::npos)
    return false;

helly a écrit :

@grim : sinon si, ma fonction marche aussi pour 4 000 000 000 (par exemple)

Bah pas chez moi…
Du moins les versions qui se basaient sur digits10

Dernière modification par grim7reaper (Le 01/08/2011, à 20:56)

helly · Le 01/08/2011, à 20:51

Cool, merci pour ça déjà .
Je ne connaissais pas du tout cette fonction oO, nan mais tu les sors d’où ? oO
Bon, et j’ai ajouté une ligne pour la condition (nb > vector.max_size());

grim7reaper · Le 01/08/2011, à 20:59

Sinon ta dernière release semble mieux fonctionner (mais y'a encore quelques soucis).
Et puis bon, le long long c'est mignon mais c'est du C99, pas du C++ (du moins pas du C++98).

warning : ISO C++ 1998 does not support ‘long long’ [-Wlong-long]

Ptain gcc c'est de la merde sérieux -__-
Il peut compiler en C++98 ou en C++0x mais pas C++2003…
/facepalm

Édit : bon je vais virer l'option Wlong-long, tfaçon le standard actuel c'est 2003, pas 98.

helly a écrit :

Je ne connaissais pas du tout cette fonction oO, nan mais tu les sors d’où ? oO

De la doc bien sûr

http://www.cplusplus.com/reference/string/string/
4e fonction en partant de la fin.

Dernière modification par grim7reaper (Le 01/08/2011, à 21:05)

tshirtman · Le 01/08/2011, à 22:19

hum, je tente de contribuer à un projet C

j'ai définit:

typedef struct SGParticle      
{     
        float x, y, angle, speed, age;     
} SGParticle;     
     
typedef struct SGEmitter      
{     
        float x, y, angle, delta_angle, initial_speed, duration, rate, friction;
        SGTexture* texture;     
        SGParticle* particles[];     
} SGEmitter;     
     
SGEmitter* sgEmitterCreate(     
                float x,              /* initial x of particles */     
                float y,              /* initial y of particles */     
                float angle,          /* direction of particles */     
                float delta_angle,    /* variation in direction */     
                float initial_speed,  /* initial speed of particles */         
                float duration,       /* lifetime of particles */     
                float rate,           /* production rate of particles */       
                float friction,       /* environmental friction to particles */
                int nb_particles,     /* size of particles pool */     
                SGTexture* texture);  /* texture used by particles */

(entre autres) dans le header, et là j'étais candidement dans mon .c, en train d'implémenter…

SGEmitter* sgEmitterCreate(
                float x,              /* initial x of particles */
                float y,              /* initial y of particles */
                float angle,          /* direction of particles */
                float delta_angle,    /* variation in direction */
                float initial_speed,  /* initial speed of particles */
                float duration,       /* lifetime of particles */
                float rate,           /* production rate of particles */
                float friction,       /* environmental friction to particles */
                int nb_particles,     /* size of particles pool */
                SGTexture* texture)   /* texture used by particles */
{
        SGEmitter* emitter = (SGEmitter*) malloc(sizeof(SGEmitter));
}

heuuuuu, je fais comment pour faire un malloc à la bonne taille en fonction de nb_particles? ^^ mon approche est-elle mauvaise? :]

Кຼزດ · Le 01/08/2011, à 22:20

Io, c’est sympa

grim7reaper · Le 01/08/2011, à 22:36

@tshirtman : C'est quoi ton problème en fait ?
C'est particles que tu veux allouer ?
C'est censé être quoi : un tableau de SGParticle ou un tableau de pointeur sur des SGParticle ?

En tout cas, la déclaration me semble bizarre . Ça m'étonnerait que ça compile sans soucis cette affaire là.

Édit : c'est quoi comme projet ?

Dernière modification par grim7reaper (Le 01/08/2011, à 22:38)

tshirtman · Le 01/08/2011, à 22:44

en fait je viens de me dire que je devais faire un deuxième malloc pour le tableau, et accrocher son résultat dans particles, (je devrais sans doute remplacer particles[] par *particles, pour être plus clair). Pour l'instant ça compile (le header en tout cas), je t'en reparle quand j'ai finit.

le projet c'est siege, un moteur 2D en openGL.

edit: ça compile:
https://gitorious.org/~tshirtman/siege/ … articles.h
https://gitorious.org/~tshirtman/siege/ … articles.c

Dernière modification par tshirtman (Le 01/08/2011, à 22:50)

grim7reaper · Le 01/08/2011, à 22:50

tshirtman a écrit :

en fait je viens de me dire que je devais faire un deuxième malloc pour le tableau, et accrocher son résultat dans particles,

Ouais voilà c'est ça.

tshirtman a écrit :

(je devrais sans doute remplacer particles[] par *particles, pour être plus clair).

Disons que c'est pas la même chose. Enfin, les deux sont bien des tableaux de pointeurs sur des SGParticle, mais en mémoire c'est pas foutu pareil.

SGParticle* particles[];

Ça c'est un flexible array (une feature C99 only, dont je ne vois pas trop l'utilité dans le cas présent)

SGParticle** particles;

Ça c'est ce que tu veux faire, du moins je pense.

La principale différence c'est que le premier intègre le tableau directement dans ta structure, dans le second t'as juste un pointeur sur le tableau qui est quelque part en mémoire.
Du moins je l'interprète comme ça, je code rarement en C99 et j'ai jamais touché aux flexible array.

Édit : apparemment j'ai vu juste, c'est bien ça.

Dernière modification par grim7reaper (Le 01/08/2011, à 23:00)

tshirtman · Le 01/08/2011, à 23:08

grim7reaper a écrit :

Disons que c'est pas la même chose. Enfin, les deux sont bien des tableaux de pointeurs sur des SGParticle, mais en mémoire c'est pas foutu pareil.
SGParticle* particles[];
Ça c'est un flexible array (une feature C99 only, dont je ne vois pas trop l'utilité dans le cas présent)
SGParticle** particles;
Ça c'est ce que tu veux faire, du moins je pense.
La principale différence c'est que le premier intègre le tableau directement dans ta structure, dans le second t'as juste un pointeur sur le tableau qui est quelque part en mémoire.
Du moins je l'interprète comme ça, je code rarement en C99 et j'ai jamais touché aux flexible array.
Édit : apparemment j'ai vu juste, c'est bien ça.

J'ignorais cette subtilité! Bon, du coup j'ai fait un tableau normal, pas un tableau de pointeurs, je devrais? Hum ça devrait prendre moins de place quand le générateur contiens moins de particules que son maximum… mais le niveau suplémentaire d'indirection est il couteux?

grim7reaper · Le 01/08/2011, à 23:19

J'ai un peu de mal à voir de quoi tu parles et ce que tu compares là.
À la base, le code c'est un flexible array de pointeurs sur des SGParticle, ça c'est OK.
Toi tu dis que du coup t'as fait un tableau normal, c‑à‑d ?

Une fois les choses clarifiés, je pourrais te répondre (enfin essayer) sur les histoires de taille et d'indirection entre les deux solutions.

Dernière modification par grim7reaper (Le 01/08/2011, à 23:19)

tshirtman · Le 01/08/2011, à 23:29

Ben tu proposait de remplacer:

SGParticle* particles[];

par

SGParticle** particles;

j'ai coupé la poire en deux

SGParticle* particles;

et je lui assigne le résultat de

(SGParticle*) malloc(nb_particles * sizeof(SGParticle));

maintenant, je me demande si je ne devrait pas utiliser ta solution, et le résultat de:

(SGParticle*) malloc(nb_particles * sizeof(SGParticle*));

tout simplement

edit: pas d'urgence, je continue demain bonne nuit!

Dernière modification par tshirtman (Le 01/08/2011, à 23:33)

grim7reaper · Le 01/08/2011, à 23:42

Bah disons que si le code des mecs est fait pout bosser avec un particles qui est un tableau de pointeurs, faut peut‑être le laisser comme ça (ou alors modifier tout le code qui joue avec le tableau particles, je sais pas ce que ça représente comme taff (dépend de comment ils ont encapsulés leur code)).
Le fait de passer par des pointeurs, c'est peut‑être pour éviter des copies (je sais pas d'où viennent les fameuses particules qui vont remplir le tableau).

Après, je sais pas pourquoi ils ont utilisés un flexible array . Ptetr pour des raisons de perfs vu que tu gagnes une indirection, mais bon tu te payes des contraintes en contrepartie et l'allocation se fait de manière un peu déroutante (enfin ça surprend la première fois quoi). À voir si ça se justifie.

En fait le choix va surtout dépendre de la manière dont c'est utilisé dans le code (comme j'ai vu qu'un aperçu du code je ne peux qu'énoncer des banalités, jpense pas que ça t'aide des masses ^^").

Ha si, un truc concret : le cast du retour de malloc est inutile (c'est fait automatiquement par le compilo)

Édit : tiens, au cas où tu doives rester avec les flexible array voilà un lien qui explique plutôt bien comment ça se manipule.

Dernière modification par grim7reaper (Le 01/08/2011, à 23:44)

tshirtman · Le 02/08/2011, à 00:07

Ah, mais non, sur ce bout là, tout le code est de moi (les deux fichiers que j'ai lié plus haut) et pour l'instant rien n'en dépends, vu que c'est une nouvelle feature…
pour les flexibles array, c'est moi qui pensais que c'était la façon propre de déclarer un tableau de pointeurs comme ça.

ok pour le cast, je pensais que c'était plus propre

Dernière modification par tshirtman (Le 02/08/2011, à 00:08)

cm-t · Le 02/08/2011, à 00:15

'Nuit,

grim7reaper · Le 02/08/2011, à 00:16

tshirtman a écrit :

Ah, mais non, sur ce bout là, tout le code est de moi (les deux fichiers que j'ai lié plus haut) et pour l'instant rien n'en dépends, vu que c'est une nouvelle feature…
pour les flexibles array, c'est moi qui pensais que c'était la façon propre de déclarer un tableau de pointeurs comme ça.

Ha bah cool alors, tu peux faire comme tu le sens alors
Bah du coup, choisi le truc avec lequel t'es plus à l'aise et développe ton code en conséquence. Ou inversement, si t'as déjà idée de comment tu vas manipuler tout ça, bah choisi la structure la plus adaptée.
L'optimisation c'est pour plus tard si le besoin s'en fait sentir.

tshirtman a écrit :

ok pour le cast, je pensais que c'était plus propre

Bah c'est pas faux non plus de le mettre, c'est comme les parenthèses à sizeof sur une variable quoi.
Mais bon quand tu fais ça, faut bien garder la cohérence : si tu changes le type faut penser à changer le cast.

tshirtman · Le 02/08/2011, à 00:30

ok

pour le tableau, j'ai demandé au dev principal, il préfère un tableau direct, parait que le tableau de pointeur serait horriblement inefficace, comme j'en sais rien, et de toutes façons ça m'arrange, j'acquiesce…

sinon, c'est grave ça?
(code sur http://paste.pocoo.org/show/450887/ par ce que ça fait planter le post )

(c'est surtout le & sur un tableau qui m'embète, ça compile, mais avec le C, on sait jamais, ça pourrait tout à fait pas du tout faire ce que je pense que ça fait ^^).

bon, et dodo pour de vrai là :]

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1676 Le 01/08/2011, à 17:08

Re : /* Topic des codeurs couche-tard [5] */

#1677 Le 01/08/2011, à 17:12

Re : /* Topic des codeurs couche-tard [5] */

#1678 Le 01/08/2011, à 17:46

Re : /* Topic des codeurs couche-tard [5] */

#1679 Le 01/08/2011, à 18:53

Re : /* Topic des codeurs couche-tard [5] */

#1680 Le 01/08/2011, à 19:41

Re : /* Topic des codeurs couche-tard [5] */

#1681 Le 01/08/2011, à 20:25

Re : /* Topic des codeurs couche-tard [5] */

#1682 Le 01/08/2011, à 20:31

Re : /* Topic des codeurs couche-tard [5] */

#1683 Le 01/08/2011, à 20:33

Re : /* Topic des codeurs couche-tard [5] */

#1684 Le 01/08/2011, à 20:38

Re : /* Topic des codeurs couche-tard [5] */

#1685 Le 01/08/2011, à 20:46

Re : /* Topic des codeurs couche-tard [5] */

#1686 Le 01/08/2011, à 20:51

Re : /* Topic des codeurs couche-tard [5] */

#1687 Le 01/08/2011, à 20:59

Re : /* Topic des codeurs couche-tard [5] */

#1688 Le 01/08/2011, à 22:19

Re : /* Topic des codeurs couche-tard [5] */

#1689 Le 01/08/2011, à 22:20

Re : /* Topic des codeurs couche-tard [5] */

#1690 Le 01/08/2011, à 22:36

Re : /* Topic des codeurs couche-tard [5] */

#1691 Le 01/08/2011, à 22:44

Re : /* Topic des codeurs couche-tard [5] */

#1692 Le 01/08/2011, à 22:50

Re : /* Topic des codeurs couche-tard [5] */

#1693 Le 01/08/2011, à 23:08

Re : /* Topic des codeurs couche-tard [5] */

#1694 Le 01/08/2011, à 23:19

Re : /* Topic des codeurs couche-tard [5] */

#1695 Le 01/08/2011, à 23:29

Re : /* Topic des codeurs couche-tard [5] */

#1696 Le 01/08/2011, à 23:42

Re : /* Topic des codeurs couche-tard [5] */

#1697 Le 02/08/2011, à 00:07

Re : /* Topic des codeurs couche-tard [5] */

#1698 Le 02/08/2011, à 00:15

Re : /* Topic des codeurs couche-tard [5] */

#1699 Le 02/08/2011, à 00:16

Re : /* Topic des codeurs couche-tard [5] */

#1700 Le 02/08/2011, à 00:30

Re : /* Topic des codeurs couche-tard [5] */

Pied de page des forums